Open Stack

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.

> 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?)

> 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.

> 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.

> 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.

> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200407/e6c97595/attachment.sig>