On 2020-04-07 12:03:53 +0200 (+0200), Dmitry Tantsur wrote:
> On Mon, Apr 6, 2020 at 4:45 PM Mohammed Naser <mnaser@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