osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Hi,

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

>
>
>
>
> *From:* Dmitry Tantsur <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?
>
>
>
> [EXTERNAL EMAIL]
>
> â?¦
>
> 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.

Dmitry


>
>
> Dmitry
>
>
>
>
> 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.
> Arkady
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200408/3a1d4dd8/attachment.html>