Open Stack

On Thu, 2020-04-02 at 11:40 +0200, Riccardo Pittau wrote:
> TL;DR thanks Dmitry, I'm glad to see this concretize after all the talks :)
> 
> On Wed, Apr 1, 2020 at 7:08 PM Dmitry Tantsur <dtantsur at redhat.com> 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.
> 
> I can definitely confirm, being deeply involved in Metal3 and Openshift
> on the hardware management side, having ironic as an "independent"
> product from the top will probably simplify the road ahead, and maybe
> save some of what has left of my sanity :)
given that ironci can already change to release cycle independt and release as offten as it like and give it is already
deployable standalone with bifrost i dont think it will actully make any difference if it a seperate top level project
in regards to openshift integration.

also we generally dont use the term product upstream. products are sold and have supprot implications, project
are collaberations of like mined folk trying to solve common problems and helping each other out.

that said im not against the idea or ironic being used standalone. i have use bifrost for personal use in the past
and love the kaobe/kolla-ansible approch of using standalone ironic via bifrost to manage your hardware and then kolla-
ansbile to deploy your cloud.

doing the same thing with metal3 is also great im not sure if a governace change will help but i agree that the seperate
marketing page for ironic an related services to better cater for that usecase which is mentioned else where in this
mail is a good idea.
> 
> 
> > 
> > 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?
> 
> Since I joined the ironic team this is probably *the* recurrent question from
> former colleagues and operators in general:
> how can I manage my infrastructure with ironic standalone?
> The need of integration with Openstack comes after that, it's definitely
> a plus and a convenience, but not the first thought.
> 
> 
> > 
> > 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.
> 
> Again can definitely confirm the latest two points, we saw a lot of features
> being included in Metal3 as "finished product", from hardware management
> perspective, than generally available in a current Openstack distribution.
given we have not had a lot of specs or blueprints propsoed to consume new ironic feature for nova
is that because no one cares about those features in a nova context, no one has had time to work on it
or the nova team does not know about them. from my perspecitive of someone who works on nova and does take
an active interst in review the nova-spec repo i have not had much visablity into what feature were added for metal3
that are not supproted by nova. i suspect that a lot of them are just not comunicated well. for example i know many
redhat folks have contiubted to meltal3 but i dont think many of them have reached out the too the compute dfg to tell
use what new feature they are adding or asking for use to support them in nova so im not sure this is beause its harder
to integrate in nova so much as no one has done the work. it is harder to integrate with nova but that is beside the
point.
> 
> > 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).
> 
> This is unavoidable and much needed!
given that kuryr exists i dont think there is anything preventing openstack service form integrating with non openstack
service today. nova and other serivce have plugin for auth. granted the only production one is keystone but i dont see
any reason that ironic could not have a plugin for native kubernets auth or some other light weight alternivie although
since kubernets already support integreating with keystone using keystone auth is praobly still the better approch.

of all of the service in openstack keystone is proably one of the lightest weight services there is. placment might be
slightly lighter but both are not exactuly combersum to deploy standalone and consume with ironic/bifrost.
> 
> > 
> > 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
> 
>