On Fri, Sep 9, 2016 at 6:16 AM, Andreas Nilsson <[email protected]> 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
_______________________________________________ cockpit-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
