[tc] [ironic] Promoting ironic to a top-level opendev project?

Arkady.Kanevsky at dell.com Arkady.Kanevsky at dell.com
Thu Apr 9 15:30:48 UTC 2020

Thanks Dmitry.
Having Ironic elevated and have Ironic to be used independently from other parts of OpenStack makes perfect sense.
With better marketing and position will definitely help.

Still not clear what is the best place for Ironic to be if outside OpenStack foundation.

From: Dmitry Tantsur <dtantsur at redhat.com>
Sent: Wednesday, April 8, 2020 3:10 AM
To: openstack-discuss
Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?


On Tue, Apr 7, 2020 at 11:26 PM <Arkady.Kanevsky at dell.com<mailto:Arkady.Kanevsky at dell.com>> wrote:

From: Dmitry Tantsur <dtantsur at redhat.com<mailto:dtantsur at redhat.com>>
Sent: Tuesday, April 7, 2020 5:27 AM
To: openstack-discuss
Subject: Re: [tc] [ironic] Promoting ironic to a top-level opendev project?


2. Does being part of OpenStack slows or impede Ironic growth and adoption? I would argue that being part of OpenDev will provide more opportunities for growth.
3. If Ironic becomes OpenDev project what changes?

As Jeremy rightly noted, I'm using "OpenDev" in a sense that I wish existed, but doesn't exist currently. In the current reality it would be an OSF project outside of the OpenStack umbrella.

And I do apologize for the confusion I caused.

AK: Now it makes more sense. But that brings new set of questions. There is already Metal3 for Kubernetes. Why not combined them? To be fair Metal3 cannot exist in it current form without Ironic. But exposing each server/switch component to user, forcing them to choose which driver to use and then orchestrate ironic calls, including handling reboots, outtages and so on as Ironic does – is not simple.

Sorry, I don't quite get your point. Combine what with what?

Metal3 can potentially exist without Ironic, although I don't find it's a reasonable idea to try swapping the backend at this stage.

a. It will still be under the same governance, unless Ironic community want to create its own governances which will take velocity of developing new features. So expect that the current OpenStack governance rules will stay.

Please expand your question. The TC would no longer be in charge, the PTL-core structure would probably stay in place.
AK: I was assuming we are talking about OpenDev move. That means Ironic project will need its own TC, UC, election process, cadence and all the rest as independent project. If it goes outside OpenStack foundation umbrella it is still need to be handled which is a lot of overhead for little gain.

I don't think an independent Ironic would need a TC and UC. I'm even sceptical about PTL, but that's a whole different discussion. I do agree that the separation would involve more bureaucracy that we're successfully avoiding now.

b. Will the gate and other processes change? Do not think so since the current ones work reasonably well.

Not much or not at all.

c. Should Ironic be part of "integrated" openstack release and tested together with rest of openstack? - absolutely. It has a lot of benefit for a openstack community, including all derived distro products.

Should libvirt be part of the integrated OpenStack release? I think Nova's integration with libvirt is more developed than one with Ironic. Still, I keep hearing that the integration will fall apart if Ironic is no longer under OpenStack. Why is that? Haven't we invented microversions specifically to be able to further decouple service development?

That being said, there would be a certain level of release coordination. There would be Ironic deliverables matching a coordinated OpenStack release and supported accordingly.

AK: well stated.

d. Will Ironic change its release cadence if it is no longer part of OpenStack proper? Ironic is only as good as its underlying drivers. That means that all drivers, that are currently outside of OpenStack governance will have to follow.

It's part of the idea, really. I don't see a problem from the driver's perspective though. I thought the Dell team was actually interested in more frequent releases to be able to deliver driver features more often?

AK: Dell will be interested in more often driver releases including community ones. But that can be done with current model.

e. Will Ironic change the development platform? It currently use devstack.

We use devstack and bifrost, and we'll keep using them. We may reduce our reliance on devstack in the CI, but, to be clear, it's part of our plans irregardless of the outcome of this discussion.

f. All Ironic documentation follows OpenStack and is part of it.

And this may be one of the perception problems we're seeing. Our standalone documentation feels second-class, examples use Nova and OSC.

AK: that can be solved by having separate entry point for Ironic documentation.

4. If Ironic leaves OpenStack proper what stops some of the other projects, like Cinder, or Keystone. to leave? That worries me. As it may lead to disintegration of the community and the notion of what OpenStack is. Or it may transition OpenStack to federated model of projects.

Maybe we may indeed? Maybe if we change OpenStack itself there won't be a need for Ironic (Cinder, Keystone) to leave? It's a great question, thank you for raising it!

AK: Dmitry can you elaborate on it? What changes will help Ironic and other projects to stay in OpenStack?

I'm referring to treating OpenStack as a more federated model of projects. Which it sort of is, it's just not entirely obvious from our positioning. But that's probably diverging from the original thread. I don't think "what if Cinder also leaves" is a valid argument against the separation of Ironic.



So after saying all of it, I am leaning toward cleaning up and simplifying dependencies to make it easier to consume Ironic outside OpenStack, at least for Victoria cycle and revisit it at that cycle end.

Sorry for long stream of conscious.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200409/a74c6346/attachment-0001.html>

More information about the openstack-discuss mailing list