Satish, it's already there: https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html#install... On Sun, Nov 5, 2023 at 4:14 AM Satish Patel <satish.txt@gmail.com> wrote:

Can we add this in an official document somewhere for advisory? - https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

On Thu, Nov 2, 2023 at 9:16 AM Sven Kieske <kieske@osism.tech> wrote:

...

Hi there!

I have seen many issues[0] over the past weeks because people still do "pip install kolla-ansible" or "pip install kolla- ansible==16.1.0".

Please don't do that! We currently lack the workforce to do regular releases to pypi, but bugs get fixed in git, so you might miss important fixes!

Please use the documented installation procedure[0], e.g. this:

"pip install git+https://opendev.org/openstack/kolla-ansible@stable/2023.1"

Thanks

[0]:

https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [1]:

https://docs.openstack.org/kolla-ansible/2023.1/user/quickstart.html#install...

-- Sven Kieske Senior Cloud Engineer

Mail: kieske@osism.tech Web: https://osism.tech

OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139

-- Regards, Maksim Malchuk

On Thu, Nov 2, 2023, at 9:17 AM, Sven Kieske wrote:

Am Donnerstag, dem 02.11.2023 um 07:14 -0700 schrieb Jay Faulkner:

...

A stable release is usually as basic as a single commit patch to the releases team repo that their automation usually makes trivial. Is there something about kolla-ansible which makes releases more difficult? Or just trying not to add another item to the todo list, no matter how small?

Just curious!

I think it's the latter, as the process is even documented here:

https://docs.openstack.org/kolla/latest/contributor/release-management.html#...

although the branch names are currently out of date there.

On the plus side, I was contacted off list by a volunteer who want's to help in that area, so maybe we can soon see the return of stable releases to pip.

the nature of our integration project still is, that many integrated third party software projects tend to break rather often in various new and exiting ways.

Most of the time these are fixed rather quick in git.

But even if we would have monthly stable releases with all fixes - and all backports merged, which is another issue due to core reviewer capacity - it's possible you have to wait 4 weeks or even more until a fix hits pypi.org.

I would argue that need rather than time dictate when you push releases. An issue like this that appears to be affecting users broadly preventing them from using kolla at all should probably get a release sooner than later. You can still do scheduled time based releases to catch up for any other smaller issues. Or skip them entirely. But if users can't use the software at all unless they pull from master maybe a release is in order. Does make you wonder if releases are necessary at all. Perhaps the biggest reason to have releases is to give users a bit of a helping hand in being brave enough to upgrade? Even if we tell everyone to pull latest some will avoid doing so and releases give them permission to update.

I guess for most of the experienced users it's just simpler to install via the git source branch.

after all pypi is just that git branch with extra steps, imho.

This might be true for certain projects. You're asserting that kolla should be installable at any point in time. I'll say the same thing about Zuul. This is great, but not universally true of packages hosted on pypi or even within our ecosystem. The key is to communicate this expectation to users. The kolla docs currently imply it through the use of installation from git, but maybe make it explicit too. Add something like: "Kolla performs pre merge CI and the expectation is every commit landed to Kolla is usable in production. Please continuously deploy kolla from source using the appropriate branch for your OpenStack deployment."

Are there any other projects out there that maybe have automated this kind of release management in CI already (proposing patches to the release repo)?

-- Sven Kieske Senior Cloud Engineer

Mail: kieske@osism.tech Web: https://osism.tech

OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139