Open Stack

Hi,

On Thu, Apr 2, 2020 at 11:05 AM Thierry Carrez <thierry at openstack.org>
wrote:

> Dmitry Tantsur wrote:
> > [...]
> > TL;DR I’m proposing to make Ironic a top-level project under opendev.org
> > <http://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.
> > [...]
>
> I agree that in the current situation, you have to explain that
> OpenStack is a collection of tools and it's OK if you install just one,
> while a lot of people assume "OpenStack" means "lots of services". So I
> think I understand the problem you're trying to solve.
>

Exactly.

Going a bit philosophical, I wonder if we actually want people to see
OpenStack as a collection of tools. In my view, it may improve perception
of OpenStack if we start more clearly defining what it is and is not,
including promoting OpenStack as a set of services to build an IaaS
solution. Including drawing borders with weird citizens like Ironic.

I may be horribly wrong here, of course.


>
> The main risk I see here is the slippery slope. Other OpenStack projects
> can be run standalone (Cinder, Swift...), so under that same reason
> could also move to be their own top-level project.


I'm surprised that Swift hasn't done that, to be honest :)


> At which point we end
> up with a collection of projects under the OSF, very much like we
> currently have a collection of projects under the TC. The only
> difference will be that the integration between the various components
> (currently the role of the TC) will no longer be under the
> responsibility of anyone. I'm not really sure that with less
> integration, we'll be collectively better off as a result.
>

Cinder specifically is a much more inherent part of OpenStack than Ironic
is. Supporting volumes in a cloud is much more natural than supporting bare
metal machines. The fact that it can be used standalone is secondary here
(and, honestly, I wish more services could be used standalone - I even see
a case for standalone Nova!).

I don't quite agree that the integration right now is the responsibility of
the TC. For me it comes from the customer demand and will die out if such
demand diminishes, with or without TC. In Ironic we don't integrate with
Nova, Neutron, Glance, Cinder, Swift and Keystone because TC makes us. We
do it because our users want us to. We will continue while they do.

If at some point, say, Swift consumers stop caring about the rest of
OpenStack, I don't think any TC will or any official status will hold the
integration together for too long.


>
> So I think we need to dig deeper in the strategy for Ironic, the
> adoption obstacles we are trying to remove, and discuss the options.
>

Please count me in!


> Being set up as a separate top-level project is one option. But I feel
> like changing governance (i.e. no longer be under the TC) has a lot less
> impact to change the perception than, say, creating a separate ironic
> product website that explains Ironic completely outside of the OpenStack
> context (which we could do without changing governance).
>

This is a great idea, and I agree that we should do it irregardless of this
decision. However, if we do this and also the release management changes
you're talking about below, what will be left of our participation in
OpenStack?

Dmitry


>
> The release management issue is, I think, mostly a red herring. As swift
> has proven in the past, you can totally have a product strategy with the
> cycle-with-intermediary model. You can even maintain your own extra
> branches (think stable/2.0) if you want. The only extra limitations
> AFAIK in the integrated release are that (1) you also maintain stable
> branches at openstack common release points (like stable/train), and (2)
> that the openstack release management team has an opportunity to check
> the release numbering for semver sanity.
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200402/bf388080/attachment.html>