Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2020-04-28T13:11:52ZCeph
Redmine Dashboard - Feature #45306 (New): mgr/dashboard: asynchronous back-end: Use HTTP2 or websocketshttps://tracker.ceph.com/issues/453062020-04-28T13:11:52ZStephan Müller
<p>In order to determine what we want to use in future. I will compare both HTTP2 and websockets.</p>
<p>First a bunch of information.</p>
<p>Currently we use the protocol HTTP1.1, which only allows one request per connection.</p>
<p>With HTTP2 and websockets it is possible to allow an unlimited amount of request per connection.</p>
<p>What does one request per connection mean? For example a client asks the server for a file, this will open a connection telling the server GET me something, the server will respond and close the connection. As our dashboard does not only consist of one file, a lot of connections are made. To meet the demand of any modern site of so many connections all modern browsers will do 8 connections simultaneously. On every connection also the same header is send.</p>
<p>What does unlimited amount of requests per connection mean? For example a client asks for a (whole) website. The client sends the first request like in HTTP1.1, the server responds with an HTTP1.1 Upgrade header, client and server negotiate which protocol to use (handshake). A connection is established and left open for requests. The client sends requests for multiple files while the server already responds with the files. This maxes out the established connection, as both participants can send at the same time (for example a video chat). As the connection is left open the server can PUSH data to the client even if he had not explicitly asked for (removes polling). To save data, only the headers during the handshake are send, they will not be send multiple times.</p>
<p>Whats the difference between HTTP2 (released as standard 2015) and websockets (released as standard 2011)?<br />Both only need one connection. Websockets can run insecure using port 80 and both can run secure using port 443. Websockets use a different URL prefix <strong>ws://</strong> for insecure connections or <strong>wss://</strong> for secure ones, HTTP2 uses only <strong>https://</strong> as prefix. If HTTP2 is used data will automatically be compressed and the handshake is easier to implement than with websockets.</p>
<p>Sure HTTP2 is the better one as the protocol is much newer, but can we use it with cherrypy?<br />Currently I only found a <a href="https://docs.cherrypy.org/en/latest/advanced.html#websocket-support" class="external">plugin</a> for cherrypy to allow websockets.<br />I've not found one for HTTP2 yet but I'm still collecting information.</p> Dashboard - Bug #44617 (New): mgr/dashboard: Some notifications are not shown in the notification...https://tracker.ceph.com/issues/446172020-03-16T10:02:31ZStephan Müller
<p>Some notifications are only popping up, but are not stored in the notifications table.<br />Observed the behavior for the erasure code profile creation and deletion as well for the crush rule creation and deletion.<br />It's possible that this affects also other pages.</p> Dashboard - Documentation #42350 (New): mgr/dashboard: The reason to testhttps://tracker.ceph.com/issues/423502019-10-17T12:33:33ZStephan Müller
<p>Give an interesting introduction into our tests.</p>
<p>This task should be split in the following subtasks</p>
<p>1. Describe the benefits of the different tests.</p>
<p>2. Describe consideration that are to be made to decide where I use the one or the other.</p>
<p>3. Show the benefits of different testing strategies (Test first / TDD)</p>
<p>4. Add some best practice links and showcase good tests in our code base.</p>
<p>The benefit of this should be that everybody should be capable of writing tests with the different test scopes in mind.</p> Dashboard - Cleanup #41397 (New): mgr/dashboard: Convert dashboard specific endpoints into UiApiC...https://tracker.ceph.com/issues/413972019-08-22T15:28:05ZStephan Müller
<p>Currently I only know of the pools _info endpoint.</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 - Cleanup #38936 (New): mgr/dashboard: Unify polling behaviorhttps://tracker.ceph.com/issues/389362019-03-25T13:41:58ZStephan Müller
<p>Unify the polling behavior means that all API calls should be handled similar on failure.</p>
<p>The idea is that the dashboard can recover from connection issues automatically, but it should not send out notification on every failure after the initial or it should raise the polling time on each failure.</p>
<p>INHO muting notifications that would be triggered after the initial failure sounds like the best idea.</p> Dashboard - Tasks #38072 (New): mgr/dashboard: Reflect RBD QoS setting values in formshttps://tracker.ceph.com/issues/380722019-01-29T10:58:04ZStephan Müller
<p>It would be great to see the global or pool values reflected as default parameters in the forms, you could use a toggle icon to show the default and the user specific value. IMHO a `link` and `unlink` icon would suite it best.</p>
<p>As discussed in <a class="external" href="https://github.com/ceph/ceph/pull/25233/">https://github.com/ceph/ceph/pull/25233/</a></p> Dashboard - Tasks #25167 (New): mgr/dashboard: Display useful popovers in formshttps://tracker.ceph.com/issues/251672018-07-30T14:49:33ZStephan Müller
<p>Add useful popovers to each form attribute, for inexperienced users.</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 - Feature #25164 (New): mgr/dashboard: Display basic performance/utilization metrics of...https://tracker.ceph.com/issues/251642018-07-30T14:30:23ZStephan Müller
<p>When clicking on a pool in the list of pools, the pool details should show graphs of the pool's performance and utilization.</p> Dashboard - Tasks #25163 (New): mgr/dashboard: Extend the Ceph pool by configurationshttps://tracker.ceph.com/issues/251632018-07-30T14:26:53ZStephan Müller
<p>The ceph pool details found on /api/pools aren't complete yet and shall be extended by the missing configurations listed in <a class="external" href="http://docs.ceph.com/docs/master/rados/operations/pools/#get-pool-values">http://docs.ceph.com/docs/master/rados/operations/pools/#get-pool-values</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 - Feature #25160 (New): mgr/dashboard: Create a "Create Ceph Cluster Pool Configuration...https://tracker.ceph.com/issues/251602018-07-30T14:19:56ZStephan Müller
<p>This issue is a port from this openATTIC <a href="https://tracker.openattic.org/browse/OP-1072" class="external">issue</a>.<br />For all comments and pictures please look at the original issue.</p>
<p>This Wizard should consist of these three steps:</p>
<ol>
<li>Provide a check list of options that this cluster will be used for. e.g. "openstack", "iSCSI", RGW, CephFS. Also, ask for the expected final size of this cluster.</li>
<li>Generate a dialog similar to the ceph PG calculator, which contains a table of all pools that will be created. each pool should be editable and removable.</li>
<li>Apply</li>
</ol>
<p>This wizard will only be useful, if the cluster is newly created.</p>
<p>Original Description for creating a single pool:</p>
<blockquote>
<p>Once the basic/generic functionality for creating a Ceph Pool exists (e.g. the required REST API call), we should consider creating a "Create Pool" Wizard, that guides the user through the required steps.</p>
<p>Some rough notes about this that were gathered during a call with SUSE about this:</p>
<p>First step after installation - creation of a Crush map depending if there is just one set of disks (one size, all rotational) vs. rotating disk plus SSDs (likely two different sizes?)<br />(<strong>Not</strong> for SSDs used as journal devices)</p>
<p>Crush Map creation? All your disks in one rule set, or use two separate groupings? Reason: to constrain what disks a pool can use (e.g. for creating a cache pool)<br />Can I query an OSD for the size of its disk?<br />Propose a grouping based on what is reported.</p>
<p>Create a pool for one of the following purposes</p>
<p>- Replicated or Erasure Coded? => Explain the pros and cons in sidebar<br />- Cache tiering (only if there are separate rule sets)</p>
<p>If Erasure Coded: Propose k/m values e.g. 5/3 4/2 (dropdown showing existing profiles), algorithm</p>
<p>- Suggest conservative Placement Group Number (use pgcalc algorithm?) (Hint that it can't be decreased and depends on the estimated number of Pools, probably propose a conservative number)<br />Maybe a Checkbox? "Do you intend to create additional pools?"</p>
<p>- Block devices (iSCSI), Virtual Machine Images<br />- Generic object storage</p>
<p>Note: (Cache tiering does not work with RBDs)</p>
<p>- (CephFS)</p>
</blockquote>
<p>Also Seel: <a class="external" href="http://ceph.com/pgcalc/">http://ceph.com/pgcalc/</a></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>