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" <jeder(a)redhat.com>
To: "Development discussion for the Cockpit Project"
<cockpit-devel(a)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(a)andreasn.se > wrote:
> On 2016-09-09 10:47, Marek Libra wrote:
> > Hi,
>
> > 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-regist...
> 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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahost...