On Fri, Sep 9, 2016 at 6:16 AM, Andreas Nilsson <lists(a)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:-Vis
ualize-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