Open Stack

Hi,

On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2020-04-07 12:03:53 +0200 (+0200), Dmitry Tantsur wrote:
> > On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <mnaser at vexxhost.com>
> wrote:
> [...]
> > > First of all, it promotes even more bureaucracy within our community
> > > which is something that we're trying to split. "Ironic" and
> > > "OpenStack" becoming two separate pieces means that we've failed as a
> > > community to be able to deliver what OpenStack is. If we do this, we
> > > further promote the separation of our communities and that is not
> > > sustainable. With a dwindling contributor base, we'll find power in
> > > standing together in big groups, not by isolating ourselves to small
> > > islands.
> >
> > This sounds a bit like the "us vs them" mentality, which I think may be
> > hurting OpenStack now. I think we should be more open to the things that
> > happen outside of our control. This also goes back to my points about
> Oslo
> > and the bigger Python world.
> [...]
>
> The assertion that you can't include Ironic in OpenShift while it's
> still tainted with the OpenStack name seems like even more of an us
> vs them mentality, if I'm being totally honest. Can't we all just
> get along? Why *can't* OpenShift include OpenStack projects? I
> haven't seen this adequately explained.
>

It's less of a technical issue, but more of misunderstanding that including
an OpenStack project does not involve literally installing OpenStack. And
no matter what we think, for a lot of people OpenStack==Nova (another
marketing issue to address?).


>
> > Maybe rather than one "openstack" namespace we can have a
> > namespace per program? Like opendev.org/compute/nova, etc? This
> > may also solve a part of the problem with oslo libraries adoption
> > outside of OpenStack.
>
> This was in fact one of the options presented to the TC when we
> reorganized for the move from git.openstack.org to opendev.org, but
> the TC chose to have a single namespace for all official OpenStack
> deliverables. It can be revisited, though reshuffling every
> OpenStack deliverable repo at mass scale is going to be a nontrivial
> effort so is not something we should engage in without careful
> planning and consideration.
>
> > opendev.org/libs/stevedore doesn't suggest that it belongs to
> > openstack the same way as opendev.org/openstack/stevedore. And it
> > will provide an obvious link between code names and purposes! Who
> > can we talk to to make this happen?
> [...]
>
> This specific example likely won't work. Remember that OpenDev is
> shared by multiple communities, and so a "libs" namespace in OpenDev
> could be misleading if all the repositories within it are the
> product of a single community. On the other hand, something less
> generic like opendev.org/plugh/stevedore would be fine. (Side
> question, why not just the obvious opendev.org/oslo/stevedore? Is
> the name "Oslo" considered as tainted as "Openstack" by product
> managers?)
>

Not a product manager, but probably fine if we position "oslo"
appropriately (i.e. not as "libraries developed specifically for
OpenStack").


>
> > Note that I don't suggest a highly dynamic web site. More of a
> > consumer-oriented landing page like http://metal3.io/ and an
> > umbrella-neutral hosting for documentation like
> > http://tripleo.org/. I do agree with Thierry that it's doable
> > without the actual split, but then it needs cooperation from the
> > Foundation and the TC.
> [...]
>
> Apparently it doesn't need cooperation from the Foundation and the
> TC, since the TripleO team already did it without actually asking
> anyone whether they should.
>

Well, we'd prefer to do it in cooperation, if possible and reasonable.


>
> > 1) More frequent releases with a possibility of bug-fix support for them
> > (i.e. short-lived stable branches) and upgrades (time to ditch grenade?).
>
> Existence of extended maintenance mode for stable branches is
> evidence that distros (in particular) want fewer longer-lived stable
> branches, not more shorter-lived ones.
>

This problem is more complex than that.

On one hand, large distributions want us to have stable branches every year
or two. Even what we have is too much.

On the other - we have small consumers who could benefit from just pulling
the latest(ish) release and knowing that if a serous bug is found there,
they won't have to update to the next feature (and potentially major)
release.


>
> > 2) Stop release-to-release matching for interactions with other services
> > (largely achieved by microversioning).
>
> Deciding what integrations you test in upgrades will likely get very
> interesting here. The compatibility matrix between Ironic releases
> and Nova releases gets increasingly complex the more releases you're
> supporting at a different cadence. Elsewhere you draw comparisons to
> Libvirt, which is probably a similar situation. Does Libvirt
> actually test whether they'll break Nova? Or do they just make
> whatever changes they want (with deference to their API stability
> policies) and expect consumers like Nova to perform their own
> independent evaluation of new releases? I have a feeling if Ironic's
> release cadence drifts significantly from OpenStack's, then the
> situation for Nova will be closer to what it is in their
> relationship with Libvirt today.
>

I think microversions (as much as I'm sceptical about them) are
game-changing here. Nova can (and actually does) declare which
microversions of Ironic it supports. Assuming we're good at microversioning
(admittedly, we're not so much), this is all Nova ever has to care about.
There's no even need to talk about versions of *ironic* required, just
versions of the *API*.

Anecdotally, some consumers do use newer Ironic with older Nova. I think
CERN did that at some earlier point.

Dmitry


>
> > 3) Support for non-coordinated releases in installation tools (okay, this
> > one is fun, I'm not sure how to approach it).
> [...]
>
> This part might not be as hard as you think. Deployment projects
> already deal with lots of dependencies which are not released on the
> same schedule as OpenStack (Libvirt as already mentioned, but
> hundreds upon hundreds more beyond).
> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200408/e44c250f/attachment-0001.html>