[tc] [ironic] Promoting ironic to a top-level opendev project?
From: Dmitry Tantsur <dtantsur at redhat.com>
Sent: Tuesday, April 7, 2020 5:27 AM
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.
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.
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?
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...