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