[Starlingx-discuss] Train upgrade for openstack clients

[Dean Troyer]

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 at gmail.com