[Starlingx-discuss] Train upgrade for openstack clients

Bailey, Henry Albert (Al) Al.Bailey at windriver.com
Thu Oct 17 14:47:02 UTC 2019


I think the puppet 5 upgrade ends up being one of the more complicated parts of this activity.

It looks like for 5.0.x you need to be cautious about is all the deprecated features in 4 that were removed in 5.  It would not surprise me if we were still using some of those deprecated parts.
https://github.com/puppetlabs/docs-archive/blob/master/puppet/5.0/release_notes.markdown

Puppet 5 also uses a newer ruby.   We ship ruby 2.0 now.  The notes for 5.0 indicate ruby 2.4, which is extra work and can take a while if existing ruby code needs to be changed.

Puppet 5 also claims to have hiera 5 built in.  I don't know what that means, we ship hiera 1.3.4 separarately, so there may be packaging concerns there as well.

Last time when I upversioned puppet from puppet 3 to 4 the most unexpected thing was not the code changes required, but the runtime behavior was different.
Example:
https://opendev.org/starlingx/integ/src/branch/master/config/puppet-4.8.2/centos/patches/1005-Set-strict_variables-and-basemodulepath-in-puppet.co.patch


Experiment with installing train keystone/barbican/horizon with the existing puppet modules.
If a  config value is incompatible,  then it may require a local change, or an upversion.

Al


From: Jones, Bruce E [mailto:bruce.e.jones at intel.com]
Sent: Thursday, October 17, 2019 9:43 AM
To: Chen, Yan; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Train upgrade for openstack clients

Yan, thank you for making this very clear.

As I read this, the puppet modules we use for the openstack clients are several releases old and the update to the Train version would be painful, er I mean lots of fun.

I think we need some input from the broader community.

What are the costs / risks of upgrading to puppet 5.0?

Should we try to upgrade the client puppet modules ourselves (and contribute the changes upstream)?  Or is there a better long way we should launch these clients, e.g. should we just write Ansible installers for them?

My thanks to Dean for helping me understand what questions to ask :)

         brucej

From: Chen, Yan [mailto:yan.chen at intel.com]
Sent: Tuesday, October 15, 2019 10:43 PM
To: starlingx-discuss at lists.starlingx.io
Subject: [Starlingx-discuss] Train upgrade for openstack clients

Hi,

I'm now trying to upgrade the openstack clients installed on StarlingX to Train version.
Currently I see the clients are Stein version, but the puppet packages (for those modules that we need to config on StarlingX host) are still old versions. [See the list below.]
But for Train, I met a problem when I wanted to upgrade python-openstackclient/keystone to Train (4.0.0), the old puppet packages cannot work with Train clients and failed when running puppet-manifest-apply.sh.
See from Stein keystone log, some of the deprecated cmds and options are planned to be removed in Train.

If we want to make Train clients work, we may need to do the following steps:

  1.  Upgrade puppet itself (required 5.x by Train)
  2.  Upgrade all the OpenStack related puppet packages accordingly, and update StarlingX patches.
  3.  If flock puppet pkgs are based on puppet 4.8.2, we also need to upgrade our code.
  4.  If other puppet pkgs are based on puppet 4.8.2, we also need to upgrade those pkgs.

So is it possible that we keep on using Stein clients with limited test now (need test with Train images, but suppose old functions should still work)?

Here's the list of the puppet packages and StarlingX patches (for Stein it should be 14.1.0 - 14.4.0, and for Train 15.0.0 - 15.4.0):
Pkg

Current Version

Train
Upgrade to

Meta Patch

Patch

puppet

4.8.2

5.x

2

5

puppet-keystone

11.3.0

15.x

6

5

puppet-oslo

11.3.0

15.x

3

2

puppet-openstacklib

11.5.0

15.x

2

1

puppet-horizon

11.5.0

15.x

2

1

puppet-barbican

11.3.0

15.x

0

0


Stein Keystone client logs:
keystone:log 2019-10-10 10:04:44.050 111346 WARNING keystone.server.flask.request_processing.middleware.auth_context [-] The use of the '[DEFAULT] admin_token' configurationoption presents a significant security risk and should not be set. This option is deprecated in favor of using 'keystone-manage bootstrap' and will be removed in a future release.

Yan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20191017/130f198f/attachment.html>


More information about the Starlingx-discuss mailing list