Ceph » mgr » Dashboard

One comment from orchestrator developers: do not allow creating filestore OSD anymore.

Nice work on the mockups, Kiefer. Lgtm!
Is there anything about the mockups that you would like to discuss in detail?

Hi Kiefer,
Nice work - will be great to see something like this in the dashboard!

A few questions;

1. Does the table need a rotates column, if it has a type (hdd or ssd)?
2. do you think there should be some 'eye-catcher' symbol to show free devices in the table? Maybe the table has a disk icon that uses blue/red/amber/green states; green=free, inuse
3. does the inventory table allow multiple select?
4. do we track/show freespace on nvme/ssd used for db/wal?
5. do you think it makes sense to make the entry point for creating an OSD simpler. For example, maybe the first question is collocated or not, and if not reveal the options for db/wal...or instead just ask for the backing device, and collocated or not and decide for the user, which flash device to use if applicable. It would be great to hide the complexity if we can - after all users can always have full control at the command line!

Paul Cuzner wrote:

Hi Kiefer,
Nice work - will be great to see something like this in the dashboard!

Thanks for reviewing, I'll reply in the comments.

A few questions;

1. Does the table need a rotates column, if it has a type (hdd or ssd)?

Sorry, I can't understand, can you give me an example about rotated column? Do you mean different icons for different types of devices?

2. do you think there should be some 'eye-catcher' symbol to show free devices in the table? Maybe the table has a disk icon that uses blue/red/amber/green states; green=free, inuse

From frontend's perspective, this can be achieved. But right now I can only get if a device is available from orchestrator. Also, we should not allow users to create OSDs from unavailable(occupied) devices.

3. does the inventory table allow multiple select?

Ideally, we should. My thought is to keep it simple on the inventory page for now. If a user wants bulk creation, he can use the step-by-step wizard on OSD page. Normally we need this operation when adding a new host and want all devices on it to be new OSDs.
Also, this will depend on a on-going PR for allowing multiple selections in Dashbaord tables.

4. do we track/show freespace on nvme/ssd used for db/wal?

Not possible now. Orchestrator doesn't return this information.

5. do you think it makes sense to make the entry point for creating an OSD simpler. For example, maybe the first question is collocated or not, and if not reveal the options for db/wal...or instead just ask for the backing device, and collocated or not and decide for the user, which flash device to use if applicable. It would be great to hide the complexity if we can - after all users can always have full control at the command line!

Agree, I will see if the flow can be simplified. Users can configure complex configurations with CLI or DriveGroupSpec.

The mockups look really nice. I just have one comment about the DriveGroup part.

I think instead of having separate pages for input and preview, they should be on one page with live preview.

By altering the json/yaml(which I prefer) it should give you a table(or something else) representation of the drives.

Although your mockup clearly didn't include any static drives in the DriveGroup, I wanted to highlight again that
the DriveGroup spec mustn't have static drive names. The 'by drive' OSD creation would happen outside of the DriveGroups.

First off, thank you for the terrific job mocking up the Create OSDs workflow as this is not a trivial workflow. It's great to have this as a starting point for discussion and to get some alignment around this workflow.

I've listed some comments/thoughts below:

Page 1
- Cluster >> Inventory — Should we consider changing “Inventory” to “Devices” as “Devices” would be more descriptive as to what the UI will present? Note: I had trouble trying to figure out where to look for Devices and then stumbled on them in Inventory.
- It means changing the breadcrumb and menu label
- Also Devices on top of the table is not needed (which is consistent in other pages where a table is presented). If we do want to show a label, then it should be called Devices List (and in a tab if applicable).
- Should we call it Create OSDs? (Plural)
- Should we consider an easy button/filter to see available devices, so user knows which devices are available without having to filter (Available = true) to look for them or put them in another tab?
- Do we want to invest in 2 workflows (Create OSDs and Create), i.e. where user has pre-selected some devices OR only provide 1 workflow (Create) where it does not require pre-selecting some devices?
- My recommendation is to start with 1 workflow to reduce complexity and reduce the number of ways to do it. I’d suggest going with what you’re calling “Create” but instead calling it “Create OSDs.”

(I skipped Page 2-5 which covers pre-selected devices)

Page 6 (Create OSDs - Step 1)
- Has the Ceph Dashboard community decided on which direction to go with for wizards? I think this also has a bit to do with whether we’re staying with the horizontal navigation or going to a vertical navigation. I’ll note that for the RGW workflows that I had suggested a wizard with horizontal steps at the top (see http://tracker.ceph.com/issues/39478), but this probably is a broader discussion which pattern to go with for wizards.
- Some rewording e.g.
- “Create OSDs using available devices” (vs. “Creating OSDs by…”)
- “Specify drive group” (vs. “Drive Group specification)
- “Provide Drive Group specification in JSON” (vs. “Manually entering…”)
- I suggest not using “Next” but to say “Create x” or rather describe what it’s going to do.
- Regarding Drive Group specification, it might be better to separate this workflow from this wizard to a higher level, i.e. at the same level as “Create OSDs” on the Devices (aka Inventory) page. E.g. “Import Drive Group Specification” or something to that effect.

Page 7 (Create OSDs - Step 2)
- Nice choice for filters but they can take a lot of space if that is a concern. There’s a lot of different options we can go with for filtering including what you suggested, http://openshift.github.io/openshift-origin-design/web-console/old/homepage/search-filter.html, https://dribbble.com/shots/5709089-Data-Grid-Filter-UI — any of these can work but would defer to the community / you on which to go with.
- Would it show all available devices selected by default when first entering this step?

Page 8 (Create OSDs - Step 3)
- Would we want to make come before device selection?
- What would be the default selection, e.g. bluestone?

Page 9 (Create OSDs - Step 3 - Data device configuration)
- Considering wording of “Use” vs. “Configure”

Page 10 & 11 (Create OSDs - Step 4 and 5)
- Would we suggest available SSDs when entering this step?

Page 12 (Create OSDs - Step 6 Preview)
- Preview seems to be missing items from Step 3 (Data device configuration) but not sure how critical this is to show
- It might be nice to know how much capacity is being added (total) for data, db, and was

Page 13 (Create OSDs - Step 7 Completed Bluestore)
- Can user see a transaction log of this request? If not, perhaps tell the user the request has been submitted and to go Background Task/Notifications to see the activity? OR not have this step 7.

Page 18 (Create OSDs - Input Drive Group Specification)
- As previously mentioned, I’d separate this workflow to another button action on the Device (aka Inventory) page.
- This hopefully makes reduces the complexity of the wizard (hopefully).
- So user just uploads or cuts-n-paste the JSON, and maybe a toggle button/link to switch between JSON and table preview mode. Thoughts?

+1 to not needing the “Rotates” column as the Type should indicate this.

+1 on asking if colocated is being used to hide a lot of the complexity.

Thanks again for doing all this work!

Thanks Ju Lim for so many comments.

Page 1
- Cluster >> Inventory — Should we consider changing “Inventory” to “Devices” as “Devices” would be more descriptive as to what the UI will present? Note: I had trouble trying to figure out where to look for Devices and then stumbled on them in Inventory.
- It means changing the breadcrumb and menu label
- Also Devices on top of the table is not needed (which is consistent in other pages where a table is presented). If we do want to show a label, then it should be called Devices List (and in a tab if applicable).

In Orchestrator, inventory of a host contains various resources on it (Although currently only "devices" are supported). That's the reason I called the page Inventory and use Devices label in case in the future there are more type of resource should be displayed on the page. But be honestly my original design was just a `Deivces` page. I can revert this if no new components under inventory are foreseen in the near future.

- Should we call it Create OSDs? (Plural)

Yes. If we allow selecting multiple devices to create multiple OSDs in this page.

- Should we consider an easy button/filter to see available devices, so user knows which devices are available without having to filter (Available = true) to look for them or put them in another tab?
- Do we want to invest in 2 workflows (Create OSDs and Create), i.e. where user has pre-selected some devices OR only provide 1 workflow (Create) where it does not require pre-selecting some devices?
- My recommendation is to start with 1 workflow to reduce complexity and reduce the number of ways to do it. I’d suggest going with what you’re calling “Create” but instead calling it “Create OSDs.”

We discussed this in stand-up and think the `Create OSD` flow should become one part of `Create (wizard)` flow. Basically I want to invest more on `Cluster->OSD` page because we have features like OSD replacement that also has device selection involved in backlog.

(I skipped Page 2-5 which covers pre-selected devices)

Page 6 (Create OSDs - Step 1)
- Has the Ceph Dashboard community decided on which direction to go with for wizards? I think this also has a bit to do with whether we’re staying with the horizontal navigation or going to a vertical navigation. I’ll note that for the RGW workflows that I had suggested a wizard with horizontal steps at the top (see http://tracker.ceph.com/issues/39478), but this probably is a broader discussion which pattern to go with for wizards.

Not yet. I follow vertical direction in patternfly v4 and didn't aware the RGW mockups. After viewing your mockups, I think horizontal navigation should look nicer because we are going to display tables. It would be nice if we have more horizontal space for tables.

- Some rewording e.g.
- “Create OSDs using available devices” (vs. “Creating OSDs by…”)
- “Specify drive group” (vs. “Drive Group specification)
- “Provide Drive Group specification in JSON” (vs. “Manually entering…”)
- I suggest not using “Next” but to say “Create x” or rather describe what it’s going to do.
- Regarding Drive Group specification, it might be better to separate this workflow from this wizard to a higher level, i.e. at the same level as “Create OSDs” on the Devices (aka Inventory) page. E.g. “Import Drive Group Specification” or something to that effect.

Page 7 (Create OSDs - Step 2)
- Nice choice for filters but they can take a lot of space if that is a concern. There’s a lot of different options we can go with for filtering including what you suggested, http://openshift.github.io/openshift-origin-design/web-console/old/homepage/search-filter.html, https://dribbble.com/shots/5709089-Data-Grid-Filter-UI — any of these can work but would defer to the community / you on which to go with.

These look awesome, especially DataGrid one. But I was reminded that we already have a filter-by-column table on Cluster->Configuration page. I should leverage this first. What's your take?

- Would it show all available devices selected by default when first entering this step?

Yes.

Page 8 (Create OSDs - Step 3)
- Would we want to make come before device selection?
- What would be the default selection, e.g. bluestone?

I'm going to remove this option. (Default to bluestore). filestore OSDs can still be created from CLI.

Page 9 (Create OSDs - Step 3 - Data device configuration)
- Considering wording of “Use” vs. “Configure”

Page 10 & 11 (Create OSDs - Step 4 and 5)
- Would we suggest available SSDs when entering this step?

Sure.

Page 12 (Create OSDs - Step 6 Preview)
- Preview seems to be missing items from Step 3 (Data device configuration) but not sure how critical this is to show
- It might be nice to know how much capacity is being added (total) for data, db, and was

Great suggestion. For raw capacity, we can just count capacity sum of data devices.

Page 13 (Create OSDs - Step 7 Completed Bluestore)
- Can user see a transaction log of this request? If not, perhaps tell the user the request has been submitted and to go Background Task/Notifications to see the activity? OR not have this step 7.

Actually no. OSD creation is a simple call to orchestrator. Depends on the orchestrator backend, the operation might be completed immediately. There will be a background task, but the completion of the task doesn't mean the new OSDs are ready. It just means the request for creation is dispatched to orchestrator backend.

Page 18 (Create OSDs - Input Drive Group Specification)
- As previously mentioned, I’d separate this workflow to another button action on the Device (aka Inventory) page.
- This hopefully makes reduces the complexity of the wizard (hopefully).
- So user just uploads or cuts-n-paste the JSON, and maybe a toggle button/link to switch between JSON and table preview mode. Thoughts?

With these discussion so far I wonder if we need to provide this feature. After all DriveGroupSpec can be input from CLI. We should provide some common cases only on GUI.

+1 to not needing the “Rotates” column as the Type should indicate this.

Sure.

+1 on asking if colocated is being used to hide a lot of the complexity.

Sure. If you don't mind can you elaborate this more? (Like flow) Simply asked if a user want to colocate WAL/DB with data devices? And if yes, try to pairs SSDs with HDDs then display the preview? Don't even ask users for WAL/DB devices?

Thanks again for doing all this work!

Comments from today's stand-up:
Lenz: Make two entry points to the same flow. Focus on OSD page first. Creating OSDs from disks on new-added host is a common case.
Ricardo Dias: Make it simple and focus on OSD page first. Also in the future we might need to consider CRUSH map when creating OSDs, like adjust weightings of OSDs.

Per our discussion during today's dashboard sync call:
- Let's start with a single entry point (from the OSD List only), and discuss other entry points later
- We should use a single form, instead of a wizard
- Drive Group Specification is part of a separate discussion, we will not implement it for now

Kiefer -- nice work in updating the workflow to not using the wizard!

Based on looking at https://tracker.ceph.com/attachments/download/4467/dashboard_osd_creation_2019-10-04.pdf, here are my comments:

• This looks to be only available on deployments using bluestone. Does Create OSDs become disabled with Filestore, or are we allowing co-existence?
• Page 3 - OSD ID column - can we hide this column if we’re not needing it here?
• Page 4 - seems like selection is based on filters. It should be consistent with how selection is done elsewhere in the application, meaning user should have to do some kind of row selection; otherwise, it may get confusing. +1 then “Add” button should only be enabled when there is a selection.
• When selecting Shared Devices, what happens if there are no available devices? Specifically, what if you selected all available devices to be used for data devices?
• What does “x Clear” button do in the Data/WAL devices section? Does it remove entire table of devices selected?
• Is there a way to remove a single row in the data devices, i.e. What if you make a mistake and want to swap out a single row (device)? Can you still go back and add/remove a data device (when you’ve completed the Data devices?
• Any thoughts about doing it all in a single table and having a column in the table that allows you to designate the device as data/wal/db
• How do you do co-located, or is this assumed through only data device selection? Do we need to expose a co-located option that allow lets you pick data devices (which get co-located)?
• +1 Preview button — what does that look like?

Thanks Ju!

Ju Lim wrote:

Kiefer -- nice work in updating the workflow to not using the wizard!

Based on looking at https://tracker.ceph.com/attachments/download/4467/dashboard_osd_creation_2019-10-04.pdf, here are my comments:

• This looks to be only available on deployments using bluestone. Does Create OSDs become disabled with Filestore, or are we allowing co-existence?

This was discussed before, we thought we should not allow creating filestore OSDs anymore. If a user really wants it, he can still create filestore OSDs via CLI.

• Page 3 - OSD ID column - can we hide this column if we’re not needing it here?

Yes, thanks.

• Page 4 - seems like selection is based on filters. It should be consistent with how selection is done elsewhere in the application, meaning user should have to do some kind of row selection; otherwise, it may get confusing. +1 then “Add” button should only be enabled when there is a selection.

To create OSDs we need to pass drive group to orchestrator. Basically, attributes in drive group are like filters, that's the reason we can not let the user select drives arbitrarily. Please see https://docs.ceph.com/docs/master/mgr/orchestrator_modules/#ceph.deployment.drive_group.DriveGroupSpec for more information.

• When selecting Shared Devices, what happens if there are no available devices? Specifically, what if you selected all available devices to be used for data devices?

The button will be disabled if there are no devices left.

• What does “x Clear” button do in the Data/WAL devices section? Does it remove entire table of devices selected?

Yes. For the clear button in data devices, it clears the selection of Data/WAL/DB devices. For clear button in WAL or DB section, it clears corresponding shared devices only.

• Is there a way to remove a single row in the data devices, i.e. What if you make a mistake and want to swap out a single row (device)? Can you still go back and add/remove a data device (when you’ve completed the Data devices?

The operation has to be based on filtering. The user needs to clear the selection and bring up the modal to select devices again.

• Any thoughts about doing it all in a single table and having a column in the table that allows you to designate the device as data/wal/db

Hmm..In-table-editing/selection looks natural, I think it's a bit difficult to implement this because we rely on filtering.

• How do you do co-located, or is this assumed through only data device selection? Do we need to expose a co-located option that allow lets you pick data devices (which get co-located)?

Yes, if you select only data devices, WAL/DB will be colocated on those devices. I can add more information about this to help tooltips.

• +1 Preview button — what does that look like?

It will display a table that summarizes all OSDs will be created. Each row should represent an OSD, and if there is any WAL/DB device selected for that OSD, it will be included in that row too.