Open Stack

Back in 2017 when Gnocchi moved out from OpenStack governance [1], in a review
Dean Troyer wrote "This actually feels like a graduation, and I have a hunch it
will not be the last one we see this year".  I feel the same about Ironic moving
beyond OpenStack governance.  

When OpenStack was riding high we created the big tent in order to accomodate
new projects that desired entry.  Now as OpenStack is later in it's lifecycle I
think we should be just as accomodating for projects that see a brighter future
in separation.  When you think of the top open source projects for bootstrapping
bare metal like Foreman or Cobbler, a datacenter automation engineer's first
thought isn't "oh, isn't that part of some other thing I'm not interested in?"
I think Ironic should be free to take it's place next to those other tools and
be considered in it's own right. 

Since this proposal represents the collective will of the Ironic team, based on
the endorsement of their elected team lead, I support the decision.  

[1] https://review.opendev.org/#/c/447438/


On Wed, Apr 01, 2020 at 07:03:47PM +0200, Dmitry Tantsur wrote:
> Hi everyone!
> 
> This topic should not come as a huge surprise for many, since it has been
> raised numerous times in the past years. I have a feeling that the end of
> Ussuri, now that we’ve re-acquired our PTL and are on the verge of
> selecting new TC members, may be a good time to propose it for a formal
> discussion.
> 
> TL;DR I’m proposing to make Ironic a top-level project under opendev.org
> and the OpenStack Foundation, following the same model as Zuul. I don’t
> propose severing current relationships with other OpenStack projects, nor
> making substantial changes in how the project is operated.
> 
> (And no, it’s not an April 1st joke)
> 
> Background
> =========
> 
> Ironic was born as a Nova plugin, but has grown way beyond this single case
> since then. The first commit in Bifrost dates to February 2015. During
> these 5 years (hey, we forgot to celebrate!) it has developed into a
> commonly used data center management tool - and still based on standalone
> Ironic! The Metal3 project uses standalone Ironic as its hardware
> management backend. We haven’t been “just” a component of OpenStack for a
> while now, I think it’s time to officially recognize it.
> 
> And before you ask: in no case do I suggest scaling down our invaluable
> integration with Nova. We’re observing a solid growth of deployments using
> Ironic as an addition to their OpenStack clouds, and this proposal doesn’t
> try to devalue this use case. The intention is to accept publicly and
> officially that it’s not the only or the main use case, but one of the main
> use cases. I don’t think it comes as a surprise to the Nova team.
> 
> Okay, so why?
> ===========
> 
> The first and the main reason is the ambiguity in our positioning. We do
> see prospective operators and users confused by the perception that Ironic
> is a part of OpenStack, especially when it comes to the standalone use
> case. “But what if I don’t need OpenStack” is a question that I hear in
> most of these conversations. Changing from “a part of OpenStack” to “a FOSS
> tool that can integrate with OpenStack” is critical for our project to keep
> growing into new fields. To me personally it feels in line with how OpenDev
> itself is reaching into new areas beyond just the traditional IaaS. The
> next OpenDev even will apparently have a bare metal management track, so
> why not a top-level project for it?
> 
> Another reason is release cadence. We have repeatedly expressed the desire
> to release Ironic and its sub-projects more often than we do now. Granted,
> *technically* we can release often even now. We can even abandon the
> current release model and switch to “independent”, but it doesn’t entirely
> solve the issue at hand. First, we don’t want to lose the notion of stable
> branches. One way or another, we need to support consumers with bug fix
> releases. Second, to become truly “independent” we’ll need to remove any
> tight coupling with any projects that do integrated releases. Which is,
> essentially, what I’m proposing here.
> 
> Finally, I believe that our independence (can I call it “Irexit” please?)
> has already happened in reality, we just shy away from recognizing it. Look:
> 1. All integration points with other OpenStack projects are optional.
> 2. We can work fully standalone and even provide a project for that.
> 3. Many new features (RAID, BIOS to name a few) are exposed to standalone
> users much earlier than to those going through Nova.
> 4. We even have our own mini-scheduler (although its intention is not and
> has not been to replace the Placement service).
> 5. We make releases more often than the “core” OpenStack projects (but see
> above).
> 
> What we will do
> ============
> 
> This proposal involves in the short term:
> * Creating a new git namespace: opendev.org/ironic
> * Creating a new website (name TBD, bare metal puns are welcome).
>    * If we can have https://docs.opendev.org/ironic/, it may be just fine
> though.
> * Keeping the same governance model, only adjusted to the necessary extent.
> * Keeping the same policies (reviews, CI, stable).
> * Defining a new release cadence and stable branch support schedule.
> 
> In the long term we will consider (not necessary do):
> * Reshaping our CI to rely less on devstack and grenade (only use them for
> jobs involving OpenStack).
> * Reducing or removing reliance on oslo libraries.
> * Stopping using rabbitmq for messaging (we’ve already made it optional).
> * Integrating with non-OpenStack services (kubernetes?) and providing
> lighter alternatives (think, built-in authentication).
> 
> What we will NOT do
> ================
> 
> At least this proposal does NOT involve:
> * Stopping maintaining the Ironic virt driver in Nova.
>    * Stopping running voting CI jobs with OpenStack services.
> * Dropping optional integration with OpenStack services.
> * Leaving OpenDev completely.
> 
> What do you think?
> ===============
> 
> Please let us know what you think about this proposal. Any hints on how to
> proceed with it, in case we reach a consensus, are also welcome.
> 
> Cheers,
> Dmitry