Hi, On Tue, Apr 7, 2020 at 4:37 PM Jeremy Stanley <fungi@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@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