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

Dmitry Tantsur dtantsur at redhat.com
Mon Apr 6 08:10:20 UTC 2020


Hi,

On Fri, Apr 3, 2020 at 9:35 AM Jean-Philippe Evrard <jean-philippe at evrard.me>
wrote:

> Hello,
>
> On Thu, 2020-04-02 at 12:38 +0200, Dmitry Tantsur wrote:
> > Hi,
> >
> > (snipped)
> >
> >
> > People do get surprised when they hear that Ironic can be used
> > standalone, yes. "A part of OpenStack" maps to "installed inside
> > OpenStack" rather than "is developed on the OpenStack platform".
>
> That's indeed what we need to change.
>
> >
> > > If you consider OpenStack taints this "standalone" part of Ironic,
> > > do you think that putting it as a top project of the **OpenStack
> > > Foundation ** will help? I don't think so. People will still see
> > > it's an OpenStack _related_ technology, with a history of being an
> > > OpenStack project, which is now a standalone project inside the
> > > OpenStack foundation. At best, it confuses people which are not
> > > really aware of all these details.
> > >
> >
> > Time to rename the Foundation? :) How is the same problem solved for
> > Zuul or Kata Containers?
>
> The first made me smile :)
>
> I would say that Kata and Zuul have a different history. To my eyes,
> Kata started as completely separated. How Zuul will eventually manage to
> detatch itself from the OpenStack name could be interesting. Please note
> that I have received the same questions (Do I need openstack? Is it a part
> of openstack?) when questioned about Zuul, in some events.
>
>
> (snipped)
>
> > As an aside, I don't think gnocchi fell victim of their split, but
> > rather shared the overall fate of the Telemetry project.
>
> I don't disagree.
>
> > I also think your suggestion goes against the idea of OpenDev, which
> > to me is to embrace a fast collection of Open Infrastructure
> > projects, related to OpenStack or not. If you say that anything going
> > to OpenDev will be seen as an OpenStack project, it defeats the
> > purpose of OpenDev.
>
> I wrongly worded this then. This is not my intent. OpenDev is a good
> name/good branding IMO. It feels detached from OpenStack. I can totally
> see many projects to be successful there without appearing to be
> attached to the OpenStack name. For people searching a little bit, it
> wouldn't take long to see that OpenStack was behind OpenDev, and
> therefore people can still attach the name if they want. I think that
> what matters is to be explicit in the project message.
>
> (snipped)
>
> > > Can't we work on the branding, naming, and message without the
> > > move? Why the hassle of moving things? Does that really bring value
> > > to your team? Before forging my final (personal) opinion, I would
> > > like more information than just gut feelings.
> > >
> >
> > It's not "just gut feelings", it's the summary of numerous
> > conversations that Julia and I have to hold when advocating for
> > Ironic outside of the Nova context. We do this "Ironic does not imply
> > OpenStack" explanation over and over, often enough unsuccessfully.
>
> Let me rephrase this: Do you have feedback from people not active in
> the project which would be happy to step up/in if Ironic was not an
> OpenStack project anymore? What could be changed from the OpenStack
> side to change that mindset?
>

In my case it's more about potential adoption rather than contributions.

Then there is this problem: I probably don't hear from a lot of people who
silently walk away assuming that "an OpenStack project" requires OpenStack.
We can try to educate people on a case-by-case basis, but to solve the
problem completely we may need to stop being "an OpenStack project" even if
we don't actually quit the OpenStack umbrella.


>
> > And then some people just don't like OpenStack...
>
> I don't disagree, sadly. I know it's a hard task, but I prefer tackling
> this. Make OpenStack (more) likeable. To me, that seems a better goal in
> itself. But that's maybe me :)
>
> > Now, I do agree that there are steps that can be taken before we go
> > all nuclear. We can definitely work on our own website, we can reduce
> > reliance on oslo, start releasing independently, and so on. I'm
> > wondering what will be left of our participation in OpenStack in the
> > end. Thierry has suggested the role of the TC in ensuring
> > integration. I'm of the opinion that if all stakeholders in Ironic
> > lose interest in Ironic as part of OpenStack, no power will prevent
> > the integration from slowly falling apart.
>
> I don't see it that way. I see this as an opportunity to make OpenStack
> more clear, more reachable, more interesting. For me, Ironic, Cinder,
> Manila (to only name a few), are very good example of datacenter/IaaS
> software that could be completely independent in their consumption, and
> additionally released together. For me, the strength of OpenStack was
> always in the fact it had multiple small projects that work well
> together, compared to a single big blob of software which does
> everything. We just didn't bank enough on the standalone IMHO. But I am
> sure we are aligned there... Wouldn't the next steps be instead to make
> it easier to consume standalone?
>

For us one of the problems, as I've mentioned already, is producing
releases more often. Now, the point of potential misunderstanding is this:
we can (and do) release more often than once in 6 months. These releases,
however, do not enjoy the same degree of support as the "blessed" releases,
especially when it comes to upgrades and longer-term support.

Partly related to that, most of the tooling to install and operate
OpenStack services seemingly:
1) Don't support non-coordinated releases.
2) Don't support standalone installation at all or make it a 2nd class
citizen.

Ironic provides Bifrost to partly cover this gap.


>
> Also, how is the reliance on oslo a problem? Do you want to use another
> library in the python ecosystem instead? If true, what about phasing
> out that part of oslo, so we don't have to maintain it? Just curious.
>

The problem is that oslo libraries are OpenStack-specific. Imagine metal3,
for example. When building our images, we can pull (most of) regular Python
packages from the base OS, but everything with "oslo" in its name is on us.
It's a maintenance burden.

With absolutely no disrespect meant to the awesome Oslo team, I think the
existence of Oslo libraries is a bad sign. I think as a strong FOSS
community we shouldn't invest into libraries that are either useful only to
us or at least are marketed this way. For example:
1) oslo.config is a fantastic piece of software that the whole python world
could benefit from. Same for oslo.service, probably.
2) oslo.utils as a catch-all repository of utilities should IMO be either
moved to existing python projects or decomposed into small generally
reusable libraries (essentially, each sub-module could be a library of its
own). Same for oslo.concurrency.
3) I'm genuinely not sure why oslo.log and oslo.i18n exist and which parts
of their functionality cannot be moved upstream.


>
>
> > (snipped) I'm referring to a very narrow sense of Nova+company. I.e.
> > a solution for providing virtual machines booting from virtual
> > volumes on virtual networks. Ironic does not clearly fit there, nor
> > does, say, Zuul.
>
> Got it. That's not my understanding of what OpenStack is, but I concede
> that I might have a different view than most.
>

It's not mine either. I wonder if it's a good thing. I wonder if OpenStack
would be (using your own words) more likeable if it was clearer what
OpenStack is.

Dmitry


>
>
>
> > > )snipped) Please note that I am still writing an idea in our ideas
> > > framework, proposing a change in the release cycles (that
> > > conversation again! but with a little twist), which I guess you
> > > might be interested in.
> > >
> >
> > Please let me know when it's ready, I really am.
>
> Will do!
>
> Regards,
> JP
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200406/4cd51bb6/attachment-0001.html>


More information about the openstack-discuss mailing list