Hi,

I'm resending to make sure we can agree on the stated scope and appropriateness of this new package for the Cockpit.

Thanks for your comments,
Marek


From: "Marek Libra" <mlibra@redhat.com>
To: "Development discussion for the Cockpit Project" <cockpit-devel@lists.fedorahosted.org>
Sent: Wednesday, September 14, 2016 2:22:52 PM
Subject: Re: idea/rfc: device screen in cockpit

And the picture ...


From: "Marek Libra" <mlibra@redhat.com>
To: "Development discussion for the Cockpit Project" <cockpit-devel@lists.fedorahosted.org>
Sent: Wednesday, September 14, 2016 2:21:50 PM
Subject: Re: idea/rfc: device screen in cockpit

Hi,

thanks for your comments!

I've updated the Feature wiki page.
The sketch of 'PCI-By Class view' is attached. It needs design, it's purpose is to better demonstrate this part of the UI.

Looking forward to hear you comments.

Marek


From: "Jeremy Eder" <jeder@redhat.com>
To: "Development discussion for the Cockpit Project" <cockpit-devel@lists.fedorahosted.org>
Sent: Friday, September 9, 2016 1:46:15 PM
Subject: Re: idea/rfc: device screen in cockpit

On Fri, Sep 9, 2016 at 6:16 AM, Andreas Nilsson <lists@andreasn.se> wrote:
On 2016-09-09 10:47, Marek Libra wrote:
Hi,

to follow-up this idea, I've created new Wiki page:
https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices

POC will follow.
Hi!
This is a great start!

So the goal of the feature is to provide a list of machine devices, but that sounds more like the end result on the screen rather than the user goal.

​The user goal at least from my POV would be to associate device(s)​ with a specific container (i.e. expose the --device flag that docker already provides).  This is happening in kubernetes as well:  https://github.com/kubernetes/features/issues/76

I'm missing some bits about what kind of workflows this enables, and for who.

What are some situations where you need to know this information? Is it for troubleshooting, for figuring out what replacement hardware to buy? etc. Why does the user want to detatch/reattach a particular device?

​I have a container with special requirements --  the application that will run needs (exclusive) access to some specialized hardware such as a dedicated NIC, HBA, SR-IOV VF, co-processor, GPU, etc.

For example, to run a high performance database, often NUMA topology comes into play.  When the PCI controller was moved inside the CPUs a few years ago, it means that PCI slots are associated with individual processor sockets.  We've used this tool to visualize:  https://www.open-mpi.org/projects/hwloc/

To run a trading platform application, I need to dedicate an FPGA to an application, and I need to know it's NUMA properties.

Some representation of which processor socket a PCI slot/device is attached to would be extremely useful as well in Cockpit (see the picture in the link above).
​​
 
In addition to the data listed in the Data Example, another feature that would be extremely useful is to know what module the device uses, and what the loaded module options are.  Being able to actually manipulate those module options and persist that would be really, really cool.​  And for NICs, output of ethtool -i eth0 and ethtool eth0, as well as IRQ information including any pinning (see /proc/irq/NNN/smp_affinity_list).


Some paragraphs about that would be awesome. I usually use made up sysadmin characters, and try to imagine their work scenarios.
If you need some inspiration, Aaron Weitekamp wrote some great user stories, their motivations and scenarios for the registry image signatures that really helped him, myself and Stef figure out some of the hard wrinkles of the problem.
https://github.com/cockpit-project/cockpit/wiki/Feature:-Visualize-registry-image-signatures
It doesn't need to be long like his examples, just a paragraph or two is probably enough.

The second part is about the design. Right now it's a bit hard to imagine how it would look, just based on the text.
Would it be possible to draw up a rough sketch of how it would look on the screen?

Again, thanks for getting this started. Looking forward to the end result!
- Andreas

_______________________________________________
cockpit-devel mailing list
cockpit-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted.org


_______________________________________________
cockpit-devel mailing list
cockpit-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted.org


_______________________________________________
cockpit-devel mailing list
cockpit-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted.org