Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2020-06-04T08:09:20ZCeph
Redmine Ceph - Documentation #45874 (Fix Under Review): doc: Extend resolving conflict section in "Submit...https://tracker.ceph.com/issues/458742020-06-04T08:09:20ZStephan Müller
<p>Currently it's not clear how to easily continue with the backport script when a conflict is encountered.</p> Dashboard - Feature #44621 (Pending Backport): mgr/dashboard: Automatic preselection of failure d...https://tracker.ceph.com/issues/446212020-03-16T12:12:19ZStephan Müller
<p>Use the automatic preselection of the crush rule creation form inside the erasure code profile form to prevent wrong configured ec profiles which can't be used in the end.</p> Dashboard - Documentation #41396 (Resolved): mgr/dashboard: Add a dashboard specific endpoint whi...https://tracker.ceph.com/issues/413962019-08-22T15:09:47ZStephan Müller
<p>Currently there is no defined way how to create a dashboard specific endpoint that consumes existing endpoints.</p> Dashboard - Bug #39034 (Resolved): mgr/dashboard: Queue notifications as defaulthttps://tracker.ceph.com/issues/390342019-03-29T14:34:58ZStephan Müller
<p>All notifications should be queued for a short amount of time, like the current notifications from Prometheus.</p>
<p>This will allow notifications with the same header to be combined and it can filter out duplicated notifications.</p> Dashboard - Tasks #37585 (Closed): mgr/dashboard/docker: Add Alertmanager and rules to docker env...https://tracker.ceph.com/issues/375852018-12-10T14:35:24ZStephan Müller
<p>Add Alertmanager and Prometheus rules to the <a href="https://github.com/ricardoasmarques/ceph-dev-docker" class="external">ceph-docker</a> environment which is used for dashboard development.</p> Dashboard - Documentation #37468 (Resolved): mgr/dashboard: Document custom RESTController endpo...https://tracker.ceph.com/issues/374682018-11-29T12:30:21ZStephan Müller
<p>Extend HACKING.rst by the fact how to extend a RESTController with a custom endpoint which has all permissions preserved.</p> Dashboard - Tasks #37291 (Resolved): mgr/dashboard: Add a command to easily test e2e test with a ...https://tracker.ceph.com/issues/372912018-11-16T15:52:25ZStephan Müller
<p>To achieve this I currently need to run `npm run e2e -- --dev-server-target` which is a bit long and not everybody knows about this option.</p> Dashboard - Tasks #36467 (Resolved): mgr/dashboard: Add a unit test form helper to easily test formshttps://tracker.ceph.com/issues/364672018-10-16T14:48:07ZStephan Müller
Things it should do:
<ul>
<li>Check for an specific error for a form field</li>
<li>Set a form field</li>
<li>Validate if a change is ok to make</li>
<li>Control if the form element is shown in the template</li>
</ul> Dashboard - Feature #36357 (Resolved): Allow custom badges within badges componenthttps://tracker.ceph.com/issues/363572018-10-09T12:54:00ZStephan Müller
<p>Allow custom badges and badges filtering in badges component so that it looks like the tag filter from github.</p> Dashboard - Feature #25166 (New): mgr/dashboard: Add cache pool supporthttps://tracker.ceph.com/issues/251662018-07-30T14:47:06ZStephan Müller
<p>Ceph provides a concept of <a href="http://ceph.com/docs/master/dev/cache-pool/" class="external">cache pools</a>. It should be possible for an administrator to define such a cache pool and assign it to an existing pool via dashboard:</p>
<a name="Purpose"></a>
<h3 >Purpose<a href="#Purpose" class="wiki-anchor">¶</a></h3>
<p>Use a pool of fast storage devices (probably SSDs) and use it as a cache for an existing slower and larger pool.</p>
<p>Use a replicated pool as a front-end to service most I/O, and destage cold data to a separate erasure coded pool that does not currently (and cannot efficiently) handle the workload.</p>
<p>We should be able to create and add a cache pool to an existing pool of data, and later remove it, without disrupting service or migrating data around.</p>
<a name="See-also"></a>
<h3 >See also:<a href="#See-also" class="wiki-anchor">¶</a></h3>
<p><a class="external" href="http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-October/013880.html">http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-October/013880.html</a><br /><a class="external" href="http://docs.ceph.com/docs/master/rados/operations/cache-tiering/">http://docs.ceph.com/docs/master/rados/operations/cache-tiering/</a><br /><a class="external" href="https://www.packtpub.com/packtlib/book/Application-Development/9781784393502/8/ch08lvl1sec91/Creating%20a%20pool%20for%20cache%20tiering">https://www.packtpub.com/packtlib/book/Application-Development/9781784393502/8/ch08lvl1sec91/Creating%20a%20pool%20for%20cache%20tiering</a></p> Dashboard - Tasks #25162 (New): API interceptor should handle client and server side offline statushttps://tracker.ceph.com/issues/251622018-07-30T14:25:02ZStephan Müller
<p>API interceptor should handle client and server side offline status</p> Dashboard - Cleanup #25161 (Resolved): Every keystroke for the username in the RGW user form trig...https://tracker.ceph.com/issues/251612018-07-30T14:23:26ZStephan Müller
<p>Every keystroke for the username in the RGW user form triggers an API call, this should be minimized to at max 2 requests.</p> Dashboard - Feature #25159 (New): mgr/dashboard: Add CRUSH ruleset management to CRUSH viewerhttps://tracker.ceph.com/issues/251592018-07-30T14:07:19ZStephan Müller
<p>Add support to view / create / update / delete a crush ruleset in the CRUSH map viewer.</p> Dashboard - Feature #25158 (Resolved): Add pool cache tiering details tabhttps://tracker.ceph.com/issues/251582018-07-30T14:05:31ZStephan Müller
<ul>
<li>Show the cache tiers as an indented pool in the data table.</li>
<li>Don't show cache tiering tab, if there is no cache tier.</li>
</ul> Dashboard - Tasks #24460 (Resolved): Make notification and tasks look more human readablehttps://tracker.ceph.com/issues/244602018-06-08T15:05:20ZStephan Müller
<p>Currently the notification and tasks don't look alike and are not the nicest way to present information as it is often pretty redundant.</p>
<p>The idea is the following have 3 kinds of message types.</p>
<p>1. One runn*ing* message<br /><pre>
Creating ....
</pre></p>
<p>2. One finish*ed* message<br /><pre>
Created ...
</pre></p>
<p>3. One *fail*ure message with description<br /><pre>
Creation ... failed
error description
</pre></p>
<p>Currently our messages look like this:<br /><pre>
Create ...
description message for running/finished and failure
</pre></p>