Hello,
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
* physical address, * driver in use, * special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports), * iommu group (possibly clickable to reveal all devices in given group), * vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
* unbinding from host driver, binding it to specific one (useful for local vfio-pci testing), * reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention), * setting numvfs, vports, * ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
Thanks, mpolednik
Hi Martin,
I work in storage and I'm afraid I don't know that much about virtualization and its requirements.
I took a look at the output of nodedev-list on my current storage setup and it was pretty large:
[root@megadeth pydevDAG]# virsh nodedev-list | wc -l 425
My configuration is larger than a personal machine, but small for a customer setup.
Also, as a storage person I'm pretty biased, to me all those devices in the output of nodedev-list really only exist to connect to some physical storage medium :)
So, given that you had, say @400 devices, and you didn't want to click on all of them, could you give a specific use case from a virtualization point of view?
I know that you can filter the devices by capability with nodedev-list and I imagine that would be quite useful in Cockpit with 400 of them :)
- mulhern
----- Original Message -----
From: "Martin Polednik" mpolednik@redhat.com To: cockpit-devel@lists.fedorahosted.org Sent: Tuesday, March 22, 2016 10:22:10 AM Subject: idea/rfc: device screen in cockpit
Hello,
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
Thanks, mpolednik _______________________________________________ cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
On 22/03/16 15:37 -0400, Anne Mulhern wrote:
Hi Martin,
I work in storage and I'm afraid I don't know that much about virtualization and its requirements.
I took a look at the output of nodedev-list on my current storage setup and it was pretty large:
[root@megadeth pydevDAG]# virsh nodedev-list | wc -l 425
My configuration is larger than a personal machine, but small for a customer setup.
It is large even for customer setups we have seen over here. :)
Also, as a storage person I'm pretty biased, to me all those devices in the output of nodedev-list really only exist to connect to some physical storage medium :)
So, given that you had, say @400 devices, and you didn't want to click on all of them, could you give a specific use case from a virtualization point of view?
I know that you can filter the devices by capability with nodedev-list and I imagine that would be quite useful in Cockpit with 400 of them :)
Good point! Yes, it makes sense to filter them by capability of some sorts: PCI, USB, SCSI separation is the initial one. I would most likely think of some search on top of that, by lun, pci address, scsi host or similar.
The idea and virtualization use case is to really form something like more interactive lspci and sysfs control. Very specifically, when using direct device assignment (meaning, assigning *physical* hardware to *virtual* machine), the device must be bound to specific driver - vfio_pci in PCI's case. After destroying the machine, we have decided not to rebind the device back to host's driver due to possible issues (rebinding GPU can lead to host reboot).
This is where this cockpit extension could help us and our customers - cloudy management applications don't really want to deal with a single device on a host. But redirecting user to cockpit interface to handle the machine - that is more reasonable.
Similar case is SR-IOV or MR-IOV (afaik storage technology :) ). Users can configure number of virtual functions for physical devices and use them for direct assignment. SR-IOV is mostly seen in networking (splitting single NIC between multiple machines), where MR-IOV should be storage tech (haven't worked with that yet).
The use cases that I know of are mostly focused on PCI devices though, I'm not sure what SCSI/USB devices offer in sysfs space.
- mulhern
----- Original Message -----
From: "Martin Polednik" mpolednik@redhat.com To: cockpit-devel@lists.fedorahosted.org Sent: Tuesday, March 22, 2016 10:22:10 AM Subject: idea/rfc: device screen in cockpit
Hello,
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
Thanks, mpolednik _______________________________________________ cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
On 23.03.2016 15:34, Martin Polednik wrote:
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
I think this makes a lot of sense. It's the sort of functionality people expect when interacting with a specific server.
Is sysfs enough of an API to deliver a decent experience?
Cheers,
Stef
On 23/03/16 18:03 +0100, Stef Walter wrote:
On 23.03.2016 15:34, Martin Polednik wrote:
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
I think this makes a lot of sense. It's the sort of functionality people expect when interacting with a specific server.
Is sysfs enough of an API to deliver a decent experience?
Combination of sysfs and udev to be accurate. I haven't dug into cockpit internals (yet), but as long as bash access is available it is possible to gather all the required information.
Example (SR-IOV capable Intel 82576 NIC): # basic information # pwd /sys/bus/pci/devices/0000:05:00.0
# udevadm info $(pwd) P: /devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DRIVER=igb E: ID_MODEL_FROM_DATABASE=82576 Gigabit Network Connection (NC362i Integrated Dual port Gigabit Server Adapter) E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d000010C9sv0000103Csd0000323Fbc02sc00i00 E: PCI_CLASS=20000 E: PCI_ID=8086:10C9 E: PCI_SLOT_NAME=0000:05:00.0 E: PCI_SUBSYS_ID=103C:323F E: SUBSYSTEM=pci E: USEC_INITIALIZED=994474b
# SR-IOV control # ls sriov_* sriov_numvfs sriov_totalvfs
# cat sriov_numvfs 0
# cat sriov_totalvfs 7
# echo 5 > sriov_numvfs
# cat sriov_numvfs 5
# IOMMU group # readlink iommu_group ../../../../kernel/iommu_groups/15
# cat vendor 0x8086
# cat device 0x10c9
# driver for unbinding, we have all the required information (sorry, # I'm using that nic!) # readlink driver ../../../../bus/pci/drivers/igb
Additionally, the devices are exposed as a tree and can therefore be displayed that way (I'm not sure about UI/UX in that case).
This is pretty much what libvirt does when dealing with devices - making it more than enough to do anything virtualization and device management requires. Similar information can be gathered about SCSI and USB devices as far as I know.
Cheers,
Stef
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
On 23.03.2016 18:37, Martin Polednik wrote:
On 23/03/16 18:03 +0100, Stef Walter wrote:
On 23.03.2016 15:34, Martin Polednik wrote:
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
I think this makes a lot of sense. It's the sort of functionality people expect when interacting with a specific server.
Is sysfs enough of an API to deliver a decent experience?
Combination of sysfs and udev to be accurate. I haven't dug into cockpit internals (yet), but as long as bash access is available it is possible to gather all the required information.
Great. Do these change while running the server much? If so you probably want to find a way to detect that something has changed, wait a few seconds, and run things again to update the display.
Example (SR-IOV capable Intel 82576 NIC): # basic information # pwd /sys/bus/pci/devices/0000:05:00.0
# udevadm info $(pwd) P: /devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DRIVER=igb E: ID_MODEL_FROM_DATABASE=82576 Gigabit Network Connection (NC362i Integrated Dual port Gigabit Server Adapter) E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d000010C9sv0000103Csd0000323Fbc02sc00i00 E: PCI_CLASS=20000 E: PCI_ID=8086:10C9 E: PCI_SLOT_NAME=0000:05:00.0 E: PCI_SUBSYS_ID=103C:323F E: SUBSYSTEM=pci E: USEC_INITIALIZED=994474b
# SR-IOV control # ls sriov_* sriov_numvfs sriov_totalvfs
# cat sriov_numvfs 0
# cat sriov_totalvfs 7
# echo 5 > sriov_numvfs
# cat sriov_numvfs 5
# IOMMU group # readlink iommu_group ../../../../kernel/iommu_groups/15
# cat vendor 0x8086
# cat device 0x10c9
# driver for unbinding, we have all the required information (sorry, # I'm using that nic!) # readlink driver ../../../../bus/pci/drivers/igb
Additionally, the devices are exposed as a tree and can therefore be displayed that way (I'm not sure about UI/UX in that case).
Once you have a proof of concept working, it would be good to work on the design. Here's how new features land, in case you haven't seen it:
https://github.com/cockpit-project/cockpit/wiki/New-Features
Stef
This is pretty much what libvirt does when dealing with devices - making it more than enough to do anything virtualization and device management requires. Similar information can be gathered about SCSI and USB devices as far as I know.
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.
Thanks, Marek
----- Original Message -----
From: "Stef Walter" stefw@redhat.com To: "Development discussion for the Cockpit Project" cockpit-devel@lists.fedorahosted.org Sent: Thursday, March 24, 2016 1:59:52 PM Subject: Re: idea/rfc: device screen in cockpit
On 23.03.2016 18:37, Martin Polednik wrote:
On 23/03/16 18:03 +0100, Stef Walter wrote:
On 23.03.2016 15:34, Martin Polednik wrote:
I have an idea for cockpit, but before thinking it further, I'm interested in hearing your opinions. I am oVirt developer mostly dealing with system stuff and this is something that could be useful in virtualization while also providing utility for administrators using cockpit.
The idea is about new tab/plugin (not sure of the terminology) called 'devices', that would allow access to (hardware) devices as exposed by sysfs. The interface could be similar to 'Services' tab/plugin, showing a list of device names created from their physical location, similarly to libvirt's nodedev-list.
After clicking on the name, new screen would be presented, showing additional information such as
- physical address,
- driver in use,
- special capabilities (SR-IOV numvfs and totalvfs, NPIV max_vports, vports),
- iommu group (possibly clickable to reveal all devices in given group),
- vendor, vendor id, product, product id.
Additionally, it makes sense to allow some basic operations:
- unbinding from host driver, binding it to specific one (useful for local vfio-pci testing),
- reattaching it back (one use case is that oVirt does not reattach devices automatically due to possible issues, needs user intervention),
- setting numvfs, vports,
- ... ?
Do you find ideas above reasonable for cockpit? It is mostly in idea phase, and builds on development and requirements of oVirt. I personally believe that this could be useful for broader audience.
I think this makes a lot of sense. It's the sort of functionality people expect when interacting with a specific server.
Is sysfs enough of an API to deliver a decent experience?
Combination of sysfs and udev to be accurate. I haven't dug into cockpit internals (yet), but as long as bash access is available it is possible to gather all the required information.
Great. Do these change while running the server much? If so you probably want to find a way to detect that something has changed, wait a few seconds, and run things again to update the display.
Example (SR-IOV capable Intel 82576 NIC): # basic information # pwd /sys/bus/pci/devices/0000:05:00.0
# udevadm info $(pwd) P: /devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DEVPATH=/devices/pci0000:00/0000:00:09.0/0000:05:00.0 E: DRIVER=igb E: ID_MODEL_FROM_DATABASE=82576 Gigabit Network Connection (NC362i Integrated Dual port Gigabit Server Adapter) E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: MODALIAS=pci:v00008086d000010C9sv0000103Csd0000323Fbc02sc00i00 E: PCI_CLASS=20000 E: PCI_ID=8086:10C9 E: PCI_SLOT_NAME=0000:05:00.0 E: PCI_SUBSYS_ID=103C:323F E: SUBSYSTEM=pci E: USEC_INITIALIZED=994474b
# SR-IOV control # ls sriov_* sriov_numvfs sriov_totalvfs
# cat sriov_numvfs 0
# cat sriov_totalvfs 7
# echo 5 > sriov_numvfs
# cat sriov_numvfs 5
# IOMMU group # readlink iommu_group ../../../../kernel/iommu_groups/15
# cat vendor 0x8086
# cat device 0x10c9
# driver for unbinding, we have all the required information (sorry, # I'm using that nic!) # readlink driver ../../../../bus/pci/drivers/igb
Additionally, the devices are exposed as a tree and can therefore be displayed that way (I'm not sure about UI/UX in that case).
Once you have a proof of concept working, it would be good to work on the design. Here's how new features land, in case you haven't seen it:
https://github.com/cockpit-project/cockpit/wiki/New-Features
Stef
This is pretty much what libvirt does when dealing with devices - making it more than enough to do anything virtualization and device management requires. Similar information can be gathered about SCSI and USB devices as far as I know.
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
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. 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? 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-... 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
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:-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
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@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-...
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....
And the picture ...
----- Original Message -----
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
----- Original Message -----
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-...
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....
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
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" 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 ...
----- Original Message -----
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
----- Original Message -----
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-...
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....
cockpit-devel mailing list
cockpit-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
On 2016-10-05 11:06, Marek Libra wrote:
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
Hi, and sorry I didn't have time to look into it yet. I have a bunch of other stuff going on at the same time. I'll try to take a look either today or tomorrow. - Andreas
Hi,
I pushed PR with new Hardware Devices plugin [1].
Please note, it's recent purpose is to get early feedback, there's todo list to finish before ready to merge.
So far, there's support for PCI where I would like to finalize IOMMU Groups and (maybe) NUMA topology view. USB and (maybe) SCSI Bus are recently missing but are planed.
The code needs to be cleaned-up. Major focus is on functionality and UX now.
Thanks for your feedback! Marek
[1] https://github.com/cockpit-project/cockpit/pull/5523 [2] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices
----- Original Message -----
From: "Andreas Nilsson" lists@andreasn.se To: cockpit-devel@lists.fedorahosted.org Sent: Wednesday, October 5, 2016 11:13:50 AM Subject: Re: idea/rfc: device screen in cockpit
On 2016-10-05 11:06, Marek Libra wrote:
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
Hi, and sorry I didn't have time to look into it yet. I have a bunch of other stuff going on at the same time. I'll try to take a look either today or tomorrow.
- Andreas
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
Nice work! I did some review on the pull request. For me the fundamental things that need to happen before merging this initial implementation are:
* UX (review by a designer) * Monitoring for changes * Unit tests * Integration tests
Seems like IOMMU Grouups, Topology, USB, and SCSI could be follow up pull requests ... there are enough fundamentals above that will make this first Device pull request very big.
Stef
On 01.12.2016 16:04, Marek Libra wrote:
Hi,
I pushed PR with new Hardware Devices plugin [1].
Please note, it's recent purpose is to get early feedback, there's todo list to finish before ready to merge.
So far, there's support for PCI where I would like to finalize IOMMU Groups and (maybe) NUMA topology view. USB and (maybe) SCSI Bus are recently missing but are planed.
The code needs to be cleaned-up. Major focus is on functionality and UX now.
Thanks for your feedback! Marek
[1] https://github.com/cockpit-project/cockpit/pull/5523 [2] https://github.com/cockpit-project/cockpit/wiki/Feature:-Hardware-Devices
*From: *"Andreas Nilsson" <lists@andreasn.se> *To: *cockpit-devel@lists.fedorahosted.org *Sent: *Wednesday, October 5, 2016 11:13:50 AM *Subject: *Re: idea/rfc: device screen in cockpit On 2016-10-05 11:06, Marek Libra wrote: 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 Hi, and sorry I didn't have time to look into it yet. I have a bunch of other stuff going on at the same time. I'll try to take a look either today or tomorrow. - Andreas _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
cockpit-devel@lists.fedorahosted.org
-
Andreas Nilsson -
Anne Mulhern -
Jeremy Eder -
Marek Libra -
Martin Polednik -
Stef Walter