Rubyipmi has been around for over a decade, and it’s definitely showing its age. The project started back in the 2010 era to support Foreman and a Puppet module I wrote at the time. Since then, it’s continued to live on, largely within the Red Hat ecosystem (Satellite and related tooling), and likely in places I’m not even aware of.
A few important bits of context up front:
• Ruby 2.x support has been dropped
• I no longer actively use rubyipmi myself
• Ongoing fixes and features now come almost entirely from the community
That puts us at a natural inflection point.
A 1.0 release gives us a clean opportunity to make breaking changes, modernize the codebase, and reset expectations, without forcing anyone to upgrade if they don’t want to. Since I’m no longer the primary consumer of this library, I don’t want to guess what “modern” should look like.
So I’m asking the community directly.
What should change in a 1.0 release?
If you’re using rubyipmi today (or have in the past), I’d really like to hear from you:
• What’s painful or fragile today?
• What feels outdated or confusing?
• What technical debt should finally be paid down?
• Are there features or behaviors you rely on that must not break?
• What would make this library easier to maintain or safer to use going forward?
Bigger question: should Redfish be part of this project?
IPMI itself hasn’t meaningfully evolved beyond IPMI 2.0 there is no IPMI 3.0, and the protocol is largely in maintenance mode. Over the last decade, the industry’s direction has shifted toward Redfish, a modern, RESTful management API defined by the DMTF:
https://www.dmtf.org/standards/redfish
That raises an important question for the future of this project:
Should Redfish support be added as part of rubyipmi’s next major release?
If yes:
• Should it live in this project or a companion gem?
• Which Redfish features actually matter (power control, sensors, inventory, firmware, etc.)?
• Would a shared abstraction over IPMI + Redfish be useful?
If no:
• Should rubyipmi explicitly remain an IPMI-only, legacy-focused library?
• Should we document Redfish as the recommended path forward and keep this project scoped?
There’s no wrong answer here I just don’t want to make that decision in a vacuum.
Final thoughts
This next major release should reflect what the current users and maintainers actually need not what made sense in 2010.
If you’re reading this, please leave your feedback. Even short comments are valuable.
This is the moment where the community gets to help decide what rubyipmi becomes next.
Rubyipmi has been around for over a decade, and it’s definitely showing its age. The project started back in the 2010 era to support Foreman and a Puppet module I wrote at the time. Since then, it’s continued to live on, largely within the Red Hat ecosystem (Satellite and related tooling), and likely in places I’m not even aware of.
A few important bits of context up front:
• Ruby 2.x support has been dropped
• I no longer actively use rubyipmi myself
• Ongoing fixes and features now come almost entirely from the community
That puts us at a natural inflection point.
A 1.0 release gives us a clean opportunity to make breaking changes, modernize the codebase, and reset expectations, without forcing anyone to upgrade if they don’t want to. Since I’m no longer the primary consumer of this library, I don’t want to guess what “modern” should look like.
So I’m asking the community directly.
What should change in a 1.0 release?
If you’re using rubyipmi today (or have in the past), I’d really like to hear from you:
• What’s painful or fragile today?
• What feels outdated or confusing?
• What technical debt should finally be paid down?
• Are there features or behaviors you rely on that must not break?
• What would make this library easier to maintain or safer to use going forward?
Bigger question: should Redfish be part of this project?
IPMI itself hasn’t meaningfully evolved beyond IPMI 2.0 there is no IPMI 3.0, and the protocol is largely in maintenance mode. Over the last decade, the industry’s direction has shifted toward Redfish, a modern, RESTful management API defined by the DMTF:
https://www.dmtf.org/standards/redfish
That raises an important question for the future of this project:
Should Redfish support be added as part of rubyipmi’s next major release?
If yes:
• Should it live in this project or a companion gem?
• Which Redfish features actually matter (power control, sensors, inventory, firmware, etc.)?
• Would a shared abstraction over IPMI + Redfish be useful?
If no:
• Should rubyipmi explicitly remain an IPMI-only, legacy-focused library?
• Should we document Redfish as the recommended path forward and keep this project scoped?
There’s no wrong answer here I just don’t want to make that decision in a vacuum.
Final thoughts
This next major release should reflect what the current users and maintainers actually need not what made sense in 2010.
If you’re reading this, please leave your feedback. Even short comments are valuable.
This is the moment where the community gets to help decide what rubyipmi becomes next.