Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2020-10-01T10:03:53ZCeph
Redmine Dashboard - Bug #47714 (New): mgr/dashboard: Implement an expert settinghttps://tracker.ceph.com/issues/477142020-10-01T10:03:53ZStephan Müller
<p>To simplify forms implement an expert setting that if disabled hides not mandatory fields in the forms as the first step.</p>
<p>How should it look like?<br />Maybe on the top right an expert slider on the form and on the top panel. As it will have impact on what a users sees in the future.</p>
<p>Tip before getting to deep into the implementation please ask in the stand up if that's path we want to go down.</p> Dashboard - Bug #44753 (New): mgr/dashboard: Secure the Alertmanger receiver endpointhttps://tracker.ceph.com/issues/447532020-03-25T14:10:42ZStephan Müller
<p>Currently it is possible send push notification unauthenticated to the dashboard and the push notifications are not verified if they actually are coming from an Alertmanager instance.</p>
<p>To see whats configurable see <a class="external" href="https://prometheus.io/docs/alerting/configuration/#http_config">https://prometheus.io/docs/alerting/configuration/#http_config</a></p>
<p>Removing the endpoint is not a solution to be considered as ceph orchestrator is configuring every Alertmanager instance to talk to the receiver of the dashboard.</p>
<p>The receiver is at the moment the only part that can handle multiple Altermanger instances.</p> Dashboard - Bug #44224 (New): mgr/dashboard: Timeouts for rbd.py callshttps://tracker.ceph.com/issues/442242020-02-20T10:10:30ZStephan Müller
<p>As the corner cases are not implemented in many rbd.py methods, they can fail without a response on a specific pool (mostly bad pools).</p>
<p>If this is implemented remove the workaround that was implemented to fix <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: mgr/dashboard: Dashboard breaks on the selection of a bad pool (Resolved)" href="https://tracker.ceph.com/issues/43765">#43765</a>.</p>
<p>For details what known issue exists see <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: pybind/rbd: config_list hangs if given an pool with a bad pg state (Rejected)" href="https://tracker.ceph.com/issues/43771">#43771</a>.</p>
<p>For details about the discussion that was made look at the PR that fixed <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: mgr/dashboard: Dashboard breaks on the selection of a bad pool (Resolved)" href="https://tracker.ceph.com/issues/43765">#43765</a>.</p>
<p>Make sure that <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: pybind/rbd: config_list hangs if given an pool with a bad pg state (Rejected)" href="https://tracker.ceph.com/issues/43771">#43771</a> is still not addressed before starting with this issue.</p>
<p>For details how this was implemented in openATTIC look <a href="https://bitbucket.org/openattic/openattic/pull-requests/682/add-librados-command-name-to-external/diff" class="external">here</a></p> Dashboard - Bug #44223 (Duplicate): mgr/dashboard: Timeouts for rbd.py callshttps://tracker.ceph.com/issues/442232020-02-20T10:05:49ZStephan Müller
<p>As the corner cases are not implemented in many rbd methods, they can fail without a response on a specific pool (mostly bad pools).</p>
<p>If this is implemented remove the workaround that was implemented to fix <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: mgr/dashboard: Dashboard breaks on the selection of a bad pool (Resolved)" href="https://tracker.ceph.com/issues/43765">#43765</a>.</p>
<p>For details what known issue exists see <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: pybind/rbd: config_list hangs if given an pool with a bad pg state (Rejected)" href="https://tracker.ceph.com/issues/43771">#43771</a>.</p>
<p>For details about the discussion that was made look at the PR that fixed <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: mgr/dashboard: Dashboard breaks on the selection of a bad pool (Resolved)" href="https://tracker.ceph.com/issues/43765">#43765</a>.</p>
<p>Make sure that <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: pybind/rbd: config_list hangs if given an pool with a bad pg state (Rejected)" href="https://tracker.ceph.com/issues/43771">#43771</a> is still not addressed before starting with this issue.</p> rbd - Bug #43771 (Rejected): pybind/rbd: config_list hangs if given an pool with a bad pg statehttps://tracker.ceph.com/issues/437712020-01-23T16:53:11ZStephan Müller
<p>If the dashboard tries to get the configuration of RBDs on a pool basis with a pool in the pg state 'creating+incomplete', it will stop working waiting for a response of `config_list` in `rbd.pyx`.</p>
<p>The pg state 'creating+incomplete' is an edge case as it will only appear if one creates a pool that needs more buckets as the cluster can provide. The current workaround in the dashboard is to omit this call if a pool is in this state.</p>
<p>Here is the manual stack trace found by debugging:<br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/pybind/mgr/dashboard/controllers/pool.py#L206">https://github.com/ceph/ceph/blob/master/src/pybind/mgr/dashboard/controllers/pool.py#L206</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/pybind/mgr/dashboard/services/rbd.py#L104">https://github.com/ceph/ceph/blob/master/src/pybind/mgr/dashboard/services/rbd.py#L104</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/pybind/rbd/rbd.pyx#L2215">https://github.com/ceph/ceph/blob/master/src/pybind/rbd/rbd.pyx#L2215</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/pybind/rbd/rbd.pyx#L2935">https://github.com/ceph/ceph/blob/master/src/pybind/rbd/rbd.pyx#L2935</a></p> Dashboard - Bug #43384 (Duplicate): mgr/dashboard: Pool size is calculated with data with differe...https://tracker.ceph.com/issues/433842019-12-19T14:01:20ZStephan Müller
<p>Currently we use the following calculation in the dashboard to calculate the usage:</p>
<pre><code>const avail = stats.bytes_used.latest + stats.max_avail.latest;<br /> pool['usage'] = avail > 0 ? stats.bytes_used.latest / avail : avail;</code></pre>
<p>[pool-list.component.ts:253-4]</p>
<p>The problem is that "max_avail" is calculated somewhat strangely as it does not show the real available space as it divides the available space at least through the number of replications for a replicated and by "(m+k)/k" for an ec pool.</p>
<p>To look the calculation up go to the following locations:<br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6033">https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6033</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6040">https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6040</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6054">https://github.com/ceph/ceph/blob/master/src/osd/OSDMap.cc#L6054</a></p>
<p><a class="external" href="https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L909">https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L909</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L920">https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L920</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L924">https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L924</a><br /><a class="external" href="https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L947">https://github.com/ceph/ceph/blob/master/src/mon/PGMap.cc#L947</a></p>
<p>This problem was found out by a user who notified us about the percentage mismatch, here is the link to the mail:<br /><a class="external" href="http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-December/037680.html">http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-December/037680.html</a></p>
<p>Also found this thread on the new mailing list regarding the used percentage and max_avail topic:<br /><a class="external" href="https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/NH2LMMX5KVRWCURI3BARRUAETKE2T2QN/#JDHXOQKWF6NZLQMOGEPAQCLI44KB54A3">https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/NH2LMMX5KVRWCURI3BARRUAETKE2T2QN/#JDHXOQKWF6NZLQMOGEPAQCLI44KB54A3</a></p> Dashboard - Bug #42243 (Duplicate): mgr/dashboard: Fix unit test that is failing in a negative ti...https://tracker.ceph.com/issues/422432019-10-09T08:54:36ZStephan Müller
<p>Found a test that is failing in a negative timezone (Washington (-05:00))</p>
<pre>
● RbdSnapshotListComponent › snapshot modal dialog › should display suggested snapshot name
expect(received).toMatch(expected)
Expected pattern: /^image01_[\d-]+T[\d.:]+\+[\d:]+$/
Received string: "image01_2019-10-09T03:40:18.664-05:00"
204 | it('should display suggested snapshot name', () => {
205 | component.openCreateSnapshotModal();
> 206 | expect(component.modalRef.content.snapName).toMatch(
| ^
207 | RegExp(`^${component.rbdName}_[\\d-]+T[\\d.:]+\\+[\\d:]+\$`)
208 | );
209 | });
at src/app/ceph/block/rbd-snapshot-list/rbd-snapshot-list.component.spec.ts:206:51
at ZoneDelegate.Object.<anonymous>.ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:391:26)
at ProxyZoneSpec.Object.<anonymous>.ProxyZoneSpec.onInvoke (node_modules/zone.js/dist/proxy.js:129:39)
at ZoneDelegate.Object.<anonymous>.ZoneDelegate.invoke (node_modules/zone.js/dist/zone.js:390:52)
at Zone.Object.<anonymous>.Zone.run (node_modules/zone.js/dist/zone.js:150:43)
at Object.testBody.length (node_modules/jest-preset-angular/zone-patch/index.js:52:27)
</pre> mgr - Bug #41795 (New): mgr: Time series data of pool decreases itself when reducing the amount o...https://tracker.ceph.com/issues/417952019-09-12T14:18:54ZStephan Müller
<p>Time series data of pool decreases itself when reducing the amount of PGs of a pool.</p>
<p>Time series data should only increase, not decrease.</p>
<p>(I'm not sure if this is the right place for this bug.)</p> Dashboard - Bug #40331 (New): mgr/dashboard: Details should not display information that is shown...https://tracker.ceph.com/issues/403312019-06-13T12:31:31ZStephan Müller
<p>"Details" about table items should not display redundant information. Details should not be provided, if the table already displays all information available.</p> Dashboard - Bug #40328 (New): mgr/dashboard: Permanent notifications instead of repeated notifica...https://tracker.ceph.com/issues/403282019-06-13T12:25:30ZStephan Müller
<p>Need more "permanent" notifications for persisting issues instead of repeated popping up notifications (e.g. when the backend is unreachable)</p> Dashboard - Bug #39298 (New): mgr/dashboard: Monitors API should provide times in UTC that will b...https://tracker.ceph.com/issues/392982019-04-15T15:41:34ZStephan Müller
<p>Monitors 'monmap modified' attribute will provide the local server time instead UTC time</p> Dashboard - Bug #39294 (New): mgr/dashboard: Time handlinghttps://tracker.ceph.com/issues/392942019-04-15T15:28:10ZStephan Müller
<p>As I searched for similar issues like <a class="issue tracker-8 status-3 priority-4 priority-default closed child" title="Subtask: mgr/dashboard: New RBD snapshot names should be prefix with a local time bound ISO timestamp not UTC (Resolved)" href="https://tracker.ceph.com/issues/23858">#23858</a>, I found a few.</p>
<a name="My-setup"></a>
<h2 >My setup<a href="#My-setup" class="wiki-anchor">¶</a></h2>
<p>As my local time is set to Germany (<ins>2h) and my docker container as default is set to UTC (</ins>/- 0h), I decided to move the timezone of it to Chicago (-5h), in order to determine if the backend correctly only gives out UTC times that can easily be converted into the local time in the frontend.</p>
<a name="How-to-change-the-timezone"></a>
<h2 >How to change the timezone<a href="#How-to-change-the-timezone" class="wiki-anchor">¶</a></h2>
<p>To change the timezone in openSUSE or most other Linux distributions do the following:<br /><pre>
cd /etc
ln -sf ../usr/share/zoneinfo/America/Chicago localtime
</pre></p>
<a name="Found-Issues"></a>
<h2 >Found Issues<a href="#Found-Issues" class="wiki-anchor">¶</a></h2>
<ul>
<li><a class="issue tracker-1 status-3 priority-5 priority-high3 closed child" title="Bug: mgr/dashboard: Can't login with a bigger time difference between user and server or make auth tok... (Resolved)" href="https://tracker.ceph.com/issues/39300">#39300</a><br /> With the time difference of -7h to the backend, I couldn't log in. The log throw the error `AMT: user info changed after token was issued, iat=%s lastUpdate=%s` which can be found in line 150 in `dashboard/services/auth.py`. I removed as a quick fix line 146 in the same document which said that `user.lastUpdate <= token['iat']` has to be true in order to login.</li>
<li><a class="issue tracker-1 status-1 priority-4 priority-default child" title="Bug: mgr/dashboard: Pools API should provide times in UTC that will be converted into local time by An... (New)" href="https://tracker.ceph.com/issues/39299">#39299</a><br /> Pool -> details -> 'create_time' attribute will provide the local server time instead UTC time</li>
<li><a class="issue tracker-1 status-1 priority-4 priority-default child" title="Bug: mgr/dashboard: Monitors API should provide times in UTC that will be converted into local time by... (New)" href="https://tracker.ceph.com/issues/39298">#39298</a><br /> Monitors 'monmap modified' attribute will provide the local server time instead UTC time</li>
<li><a class="issue tracker-1 status-3 priority-4 priority-default closed child" title="Bug: mgr/dashboard: Logs provided by the API should provide timestamps in UTC in ISO 8601 format that ... (Resolved)" href="https://tracker.ceph.com/issues/39297">#39297</a><br /> Log timestamps will provide the local server time instead UTC time</li>
<li><a class="issue tracker-1 status-3 priority-4 priority-default closed child" title="Bug: mgr/dashboard: Alert details UTC times should be converted into local time by Angular (Resolved)" href="https://tracker.ceph.com/issues/39296">#39296</a><br /> Alert -> details -> 'endsAt' and 'startsAt' attributes provide a UTC time but are not converted into local time in the frontend</li>
<li><a class="issue tracker-1 status-3 priority-4 priority-default closed child" title="Bug: mgr/dashboard: RGW Bucket API should provide times in UTC that will be converted into local time ... (Resolved)" href="https://tracker.ceph.com/issues/39295">#39295</a><br /> RGW -> Bucket -> details -> 'modification time' attribute will provide the local server time instead UTC time</li>
<li><a class="issue tracker-8 status-3 priority-4 priority-default closed child" title="Subtask: mgr/dashboard: New RBD snapshot names should be prefix with a local time bound ISO timestamp not UTC (Resolved)" href="https://tracker.ceph.com/issues/23858">#23858</a><br /> The RBD snapshot creation modal will append a UTC timestamp to the name - but it's more convenient to use a local timestamp with TZ prefix instead.</li>
</ul>
<a name="Working-Dates"></a>
<h2 >Working Dates<a href="#Working-Dates" class="wiki-anchor">¶</a></h2>
<ul>
<li>RBD snapshot creation time column provide a UTC timestamp which is converted to local time in the frontend</li>
<li>RBD detail view "Created" attribute provide a UTC timestamp which is converted to local time in the frontend</li>
</ul> Dashboard - Bug #36445 (Resolved): Missing requirement "python-werkzeug" for running the dashboar...https://tracker.ceph.com/issues/364452018-10-15T14:31:45ZStephan Müller
<p>With a fresh build docker container I got the following message through <strong>ceph -s</strong> after sourcing <strong>run-backend-api-tests.sh</strong><br /><pre>
Module 'restful' has failed dependency: No module named 'werkzeug'
</pre></p>
<p>After that I found out that only the pip2 version of werkzeug was not installed. After I had installed it and recreated the cluster the message that lead to a warning state disappeared.</p> Dashboard - Bug #36360 (Resolved): Return error to subscriber of task-wrapperhttps://tracker.ceph.com/issues/363602018-10-09T13:55:31ZStephan Müller
<p>Currently the task wrapper is not returning a received error to the subscriber of the wrapper.</p> Dashboard - Bug #25139 (Resolved): Task wrapper should not call notifyTask if a task failshttps://tracker.ceph.com/issues/251392018-07-27T14:13:51ZStephan Müller
<p>Task wrapper should not call notifyTask if a task fails as this is done by the API interceptor, because of this you often get two error messages shown.</p>