Open Stack

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?
B) Am I the only one caring?
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.
E) Do you consider all the energy spent to change things does not bring enough positive reward for the whole ecosystem?

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

JP