[ironic] Stop maintaining sushy as a separate project, let's move it into ironic
Hello everyone! During the PTG yesterday, we discussed stop maintaining sushy as a separate project. For those who don't know what sushy is: a Python library to communicate with Redfish based systems and is limited to what Ironic supports. The library was never intended for others to consume, yet that has happened, and it being a library has been a noted hurdle to quickly resolving user issues, because it requires releasing a new version. But before we move this forward, we would like to hear from you what are your thoughts. Thanks! -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core - Ironic Event Liaison (DPL)* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory@gmail.com <iurygregory@gmail.com>*
Although i have not been able to work with Sushy yet, it is the first library / package i have found that allows me to simulate redfish so i don't have to spend large amounts of money on different types of hardware. There is a serious lack of hardware focusses software, so any and all solutions i have come across seem to be vendor specific or not maintained or used. it would be a loss to the overal opensource and development community if this tool would join that list.
Hi s.osenga, When you say simulate redfish are you talking about sushy-tools https://opendev.org/openstack/sushy-tools/ ? If that is the case, this is not going anywhere =) Em qui., 30 de out. de 2025 às 12:14, <s.osenga@fairbanks.nl> escreveu:
Although i have not been able to work with Sushy yet, it is the first library / package i have found that allows me to simulate redfish so i don't have to spend large amounts of money on different types of hardware. There is a serious lack of hardware focusses software, so any and all solutions i have come across seem to be vendor specific or not maintained or used. it would be a loss to the overal opensource and development community if this tool would join that list.
-- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic Core* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory@gmail.com <iurygregory@gmail.com>*
Hi iurygregory, Thanks for the clarification, I recently became aware of the Sushy toolset, so my knowledge on the individual components is still limited. Looking at what you have linked does indeed seem to be the set of tools that I was looking at, good to know this is not part of the project. Regards, Sven Osenga From: Iury Gregory <iurygregory@gmail.com> Date: Thursday, 30 October 2025 at 16:51 To: Sven Osenga <s.osenga@fairbanks.nl> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [ironic] Stop maintaining sushy as a separate project, let's move it into ironic Hi s.osenga, When you say simulate redfish are you talking about sushy-tools https://opendev.org/openstack/sushy-tools/ ? If that is the case, this is not going anywhere =) Em qui., 30 de out. de 2025 às 12:14, <s.osenga@fairbanks.nl<mailto:s.osenga@fairbanks.nl>> escreveu: Although i have not been able to work with Sushy yet, it is the first library / package i have found that allows me to simulate redfish so i don't have to spend large amounts of money on different types of hardware. There is a serious lack of hardware focusses software, so any and all solutions i have come across seem to be vendor specific or not maintained or used. it would be a loss to the overal opensource and development community if this tool would join that list. -- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Ironic Core Senior Software Engineer at Red Hat Brazil Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com<mailto:iurygregory@gmail.com>
So I’ll be the contrarian. I’ll agree that it’s not a library intended for consumption outside of Ironic however: 1. During the PTG we identified 10+ external repos depending on it which have OpenStack involvment 2. We’ve not had a lot of maintenance burden of it but have gotten outside contributions to it. 3. The only example during PTG for resolving a user issue was around exception handling inside of Ironic and working around hardware that was being done inside of Ironic. The library could be released on a more frequent basis and be one central version to have hardware abstraction / quirks and it could fix up multiple versions of Ironic in one release instead of backporting to multiple versions of Ironic. 4. It’s useful for troubleshooting hardware and doing “pip install sushy” which could still work with a “pip install ironic” but then are we saying that sushy-tools depends on ironic? https://github.com/metal3-io/ironic-image?tab=readme-ov-file#custom-source-for-ironic-software metal3-io/ironic-image: Container image to run OpenStack Ironic as part of Metal³ github.com is an example where one of the referenced downstreams having an issue has made an easy way to use alternate versions of sushy. Which again could be a way to centralize fixes for hardware and allow different versions of ironic to pick uop the fix. Per https://docs.openstack.org/ironic/latest/contributor/releasing.html#non-clie... we could release it more often to catch up quirks. So I was asked to put my comments to the ML during the PTG so that’s what this is. I won’t actually stand in the way of the change. I just think its better to collapse sushy-oem-idrac and the parts of proliantutils that are needed into sushy and keep it and but the quirk logic into it rather than Ironic directly. — Doug
On Oct 29, 2025, at 7:33 AM, Iury Gregory <iurygregory@gmail.com> wrote:
Hello everyone!
During the PTG yesterday, we discussed stop maintaining sushy as a separate project. For those who don't know what sushy is: a Python library to communicate with Redfish based systems and is limited to what Ironic supports.
The library was never intended for others to consume, yet that has happened, and it being a library has been a noted hurdle to quickly resolving user issues, because it requires releasing a new version. But before we move this forward, we would like to hear from you what are your thoughts.
Thanks!
-- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Ironic Core - Ironic Event Liaison (DPL) Senior Software Engineer at Red Hat Brazil Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com <mailto:iurygregory@gmail.com>
So I’ll be the contrarian. I’ll agree that it’s not a library intended for consumption outside of Ironic however: 1. During the PTG we identified 10+ external repos depending on it which have OpenStack involvment 2. We’ve not had a lot of maintenance burden of it but have gotten outside contributions to it. 3. The only example during PTG for resolving a user issue was around exception handling inside of Ironic and working around hardware that was being done inside of Ironic. The library could be released on a more frequent basis and be one central version to have hardware abstraction / quirks and it could fix up multiple versions of Ironic in one release instead of backporting to multiple versions of Ironic. 4. It’s useful for troubleshooting hardware and doing “pip install sushy” which could still work with a “pip install ironic” but then are we saying that sushy-tools depends on ironic? https://github.com/metal3-io/ironic-image?tab=readme-ov-file#custom-source-for-ironic-software metal3-io/ironic-image: Container image to run OpenStack Ironic as part of Metal³ github.com https://github.com/metal3-io/ironic-image?tab=readme-ov-file#custom-source-f... is an example where one of the referenced downstreams having an issue has made an easy way to use alternate versions of sushy. Which again could be a way to centralize fixes for hardware and allow different versions of ironic to pick uop the fix. Per https://docs.openstack.org/ironic/latest/contributor/releasing.html#non-clie... we could release it more often to catch up quirks. So I was asked to put my comments to the ML during the PTG so that’s what this is. I won’t actually stand in the way of the change. I just think its better to collapse sushy-oem-idrac and the parts of proliantutils that are needed into sushy and keep it and but the quirk logic into it rather than Ironic directly. — Doug
On Oct 29, 2025, at 7:33 AM, Iury Gregory <iurygregory@gmail.com> wrote:
Hello everyone!
During the PTG yesterday, we discussed stop maintaining sushy as a separate project. For those who don't know what sushy is: a Python library to communicate with Redfish based systems and is limited to what Ironic supports.
The library was never intended for others to consume, yet that has happened, and it being a library has been a noted hurdle to quickly resolving user issues, because it requires releasing a new version. But before we move this forward, we would like to hear from you what are your thoughts.
Thanks!
-- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Ironic Core - Ironic Event Liaison (DPL) Senior Software Engineer at Red Hat Brazil Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com <mailto:iurygregory@gmail.com>
On 10/29/25 1:33 PM, Iury Gregory wrote:
Hello everyone!
During the PTG yesterday, we discussed stop maintaining sushy as a separate project. For those who don't know what sushy is: a Python library to communicate with Redfish based systems and is limited to what Ironic supports.
The library was never intended for others to consume, yet that has happened, and it being a library has been a noted hurdle to quickly resolving user issues, because it requires releasing a new version. But before we move this forward, we would like to hear from you what are your thoughts.
Thanks!
From my Debian package maintainer perspective, nobody else than Ironic and Proliantutils is using that library, so it'd be fine to remove it from Debian. Cheers, Thomas Goirand (zigo)
participants (6)
-
Doug Goldstein
-
Doug Goldstein
-
Iury Gregory
-
s.osenga＠fairbanks.nl
-
Sven Osenga
-
Thomas Goirand