On 10/17/19 1:51 PM, Jones, Bruce E wrote:
We discussed this topic at the Release meeting today. The conclusion was that we do not want to upgrade puppet or ruby for this release. It's too risky.
Agreed there.
As one of the last features gating our 3.0 release there is some urgency in figuring out the right approach to this upgrade.
Where we need help is figuring out if it is possible to divide the OpenStack world into two parts and treat each part separately.
Most of the OpenStack services running in StarlingX are in containers and should not depend on puppet at all. The 3 services that are not in containers (keystone, barbican and horizon) do depend on puppet.
I still want to be really clear here, the services themselves do not depend on Puppet, the StarlingX deployment of them does.
Is it possible / practical to run the Train versions of the containerized services, while still running the Stein versions of keystone, barbican and horizon in the platform layer?
I thought we had already decided to do that, but I may be behind in my news. OpenStack clients are all written with serious backward-compatibility in mind at the REST level. OSC and the SDK both are known to still work on juno clouds for example, not all of the python-*client libs go that far back but most do. Forward compatibility is also reliable for most APIs, those that use microversioning especially so (Cinder, Ironic, Nova, etc). In the list at play here, Horizon is itself a client so it needs to be considered the same as the CLIs not as a service. That leaves Barbican and Keystone. I do not know much about the Barbican API other than it is not under heavy development. I would be shocked if it did not work rolling forward a version or two. Keystone also has a mostly-stable API, the risks here are if we need to make use of anything new in Keystone Train specifically around the distcloud functionality. I thought I saw a decision to wait on Train for the platform components until CentOS had packaging for Train available. Is that approach of just installing those packages a possibility? dt -- Dean Troyer dtroyer@gmail.com