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 ----- Original Message ----- > From: "Marek Libra" <[email protected]> > To: "Development discussion for the Cockpit Project" > <[email protected]> > Sent: Wednesday, September 14, 2016 2:22:52 PM > Subject: Re: idea/rfc: device screen in cockpit > And the picture ... > ----- Original Message ----- > > From: "Marek Libra" <[email protected]> > > > To: "Development discussion for the Cockpit Project" > > <[email protected]> > > > 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 > > > ----- Original Message ----- > > > > From: "Jeremy Eder" <[email protected]> > > > > > > To: "Development discussion for the Cockpit Project" > > > <[email protected]> > > > > > > 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 < [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:-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 > > > > > > [email protected] > > > > > > https://lists.fedorahosted.org/admin/lists/[email protected] > > > > > _______________________________________________ > > > cockpit-devel mailing list > > > [email protected] > > > https://lists.fedorahosted.org/admin/lists/[email protected] > > _______________________________________________ > cockpit-devel mailing list > [email protected] > https://lists.fedorahosted.org/admin/lists/[email protected]
_______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
