Open Stack

On Tue, Dec 7, 2021 at 4:42 PM Jean-Philippe Evrard
<openstack at a.spamming.party> wrote:

> Hello,
>
> On Sat, Dec 4, 2021, at 15:56, Thierry Carrez wrote:
> > Jean-Philippe Evrard wrote:
> >> [...]
> >> Here is what I read:
> >> 1) Many want more releases, not less. I haven't seen a complaint about
> tagging more releases.
> >> 2) More than one person is proposing to abandon the integrated release,
> and nobody has complained about it.
> >
> > Here are a few drawbacks of abandoning the integrated release (which is
> > really a "synchronized release"):
> >
> > - You would no longer have a baseline of components that are heavily
> > tested together which we do community QA on and (collectively) clearly
> > sign off on, so downstream integrators are on their own and have much
> > more work to do
>
> I don't think so. We can still have that without the synchronized release.
> We decide what we test together.
> (Maybe the TC can define that?). For example, with Zuul, we can test the
> master branch of all projects together to ensure the latest branch always
> work according to the set criteria. (No change there!)
>
> Then, what becomes "openstack version x" is just about a manifest of the
> SHAs or the tags of the projects, tested together. (No change again).
> (Let's call this proposition 1)
>
> We don't have multiple "synchronized" releases of stable branches, so we
> don't even have to bring any "openstack version x.y". Still, it doesn't
> prevent us to define any "openstack version x.y" if we want to, with an
> updated manifest compared to "version x.0"
>
> Technically proposition 1 looks like we run a deploy tool + tempest before
> release, based on the manifest.
> It's literally no new technology. I am relatively sure many (if not all)
> deployment tools can do that.
>
> What makes more sense for me is that we define "openstack version x" in
> terms of APIs, and that we have the test tooling to ensure that software
> wanted to be integrated into "version x" are passing said tests. (Let's
> call this proposition 2)
> It allows alternative implementation of the software, if someone is crazy
> enough to do that.
>
> I agree it might look like "We are abandonning the branches, what will we
> do for people deploying regularily on a single branch?". Well it doesn't
> change much: Those are currently consuming the manifests of releases,
> bumping the SHAs from a "stable" branch of a repo. If a project/repo
> _decides to branch_ for a very critical reason, then it can still happen.
> If there is no reason to branch, then you would still bump the latest
> branch available. Still no issue there.
>
> > - You would no longer have clearly-comparable points between
> > distributions. Everyone knows what "running Ussuri" means, which
> > facilitates communication and bug report handling in the community.
>
> I am not sure what "running Ussuri" means. Is that when the branch was
> cut, or the latest sha of all the projects' Ussuri branches? Having
> "OpenStack version Ussuri 1" corresponding to a manifest of project SHAs
> and or APIs versions is far more clear to me.
>
> > - You would no longer have clear community support commitments. We
> > currently maintain and fix bug reports from people running vanilla
> > "Ussuri"... but do we want to care about every combination of components
> > under the sun? (maybe we do already)
>
> We don't stop maintainers for contributing by being clearer in what we
> release and how we branch...
> If people want to maintain some old version and _need to branch a
> project_, I feel it's still possible. But it's now in the power of the
> project to decide whether it makes sense to do so, instead of being forced
> to manage something that might be stretching the teams thin.
>
> > - You would no longer have "OpenStack" released, so you miss the regular
> > marketing opportunity to remind the rest of the world that it still
> > exists. The OpenStack brand fades, and it gets more complicated to get
> > development resources to work on it.
>
> Again, it's wording. Please see my proposal above.
> I understand why it's a concern for the foundation however ;)
>
> > Without the synchronized release, OpenStack essentially becomes a
> > rolling distribution of cloud components on which we make very limited
> > guarantees. I guess it is suitable to build maintained distributions on,
> > but it really is no longer directly usable beyond development. Is that
> > what we want?
>
> We would indeed be more "rolling", but it doesn't prevent tagging/point in
> time testing and quality assurance.
> Also, if we have integrated testing during the cycle and before the
> tagging, then it doesn't remove any guarantee, does it?
>
> I disagree it's not usable beyond development. Here is my reasoning:
> 1) I don't see it as removing any guarantee if we test things out :)
> 2) Users of openstack are most likely using a deployment tooling (based on
> configuration management tool of choice) to deploy their clouds, not a
> manual deployment. This seems to be confirmed by the user survey. Do you
> mean that a change in the model of branching would irreversibly break all
> those tools, and make the ecosystem "no longer directly usable beyond
> development"?
>
> Keep in mind I see those deploy toolings as part of openstack. Not only
> because they are part of the ecosystem, but because some are under
> OpenStack governance (OpenStack charms, openstack-chef, puppet openstack,
> osa, openstack-helm, kolla, tripleO).
>
> Hence I consider that OpenStack would still be usable beyond development.
> I know at least a company that would continue to believe in OpenStack ;)
>
> >> 3) Many people seem eager to carry "stable branches" for "critical
> patches", but no new definition of such criticality was done.
> >
> > Note that a common stable branch cut is *exactly* the same thing as a
> > synchronized release... So I see 2 and 3 as being opposed views.
>
> I agree with you there on common stable branch = synchronized release,
> especially if "criticality" = "Whenever we decide to cut a release". I
> still wanted to mention what was said, for the reader.
>
> It doesn't mean that everyone agree on the definition of criticality yet,
> or maybe I am wrong? ;)
>
> Next to this, I have questions:
> A) Am I the only one wanting to act on this?
>
Probably

> B) Am I the only one caring?
>
Nope

> C) What should be the next steps if I want to change this model?
> D) Should I propose a change in governance, sync with release management
> team? As this goes deep into the foundation's model, I feel like we need a
> proper coordination to make this happen.
>
Likely a patches to gov repos are needed (ref C & D)

> E) Do you consider all the energy spent to change things does not bring
> enough positive reward for the whole ecosystem?
>
Absolutely, as someone who needs to think both upstream and downstream
aspects of the release and has cared a lot about stable maintenance of
OpenStack for years, what you're proposing here is literally pushing all
our stable maintenance work to downstream and not even trying to share the
efforts with the rest of the community. I also feel like this would turn
really quickly to the point where if you're not following master on your
deployment or using our product directly, I'd be happy to avice you to
upgrade to the latest release and see if your problem still exists or go
and talk to your deployment tool guys if they have seen the issue with
whatever hashes they happen to deploy.

I could have seen this as a tempting model 8-9 years ago when the
competition was who is trailing master the closest and everyone was
focusing on getting the next absolutely necessary feature set in to make
OpenStack usable. Not now when we have matured considerably and are looking
to provide stable production environments rather than rolling new code into
production on a weekly basis. I'm not sure I even managed to grasp your
proposal fully, but it really feels like half a step forward and mile, mile
and half backwards.

>
> I see people talking about changing releases for years now, I haven't seen
> a single change in our behaviour. (or maybe I missed something?). Is that
> stockholm syndrome? ;)
>
> I see this as a matter that handful few want to bring up every few months
(for years now, we've had this discussion probably close to dozen times)
and I have a feeling that the majority of the community is just tired of
copypasting the same arguments every round to avoid breaking what works and
genuinely is waiting for the thread being buried for the next few months so
they can get back to work.

- Erno "jokke" Kuvaja


> JP
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211208/181c3265/attachment.htm>