MaaS/JuJu contrail and contrail-ha deployers

Konger, Chris ckonger at vt.edu
Tue Jan 24 16:06:03 UTC 2017


Michael Iatrou (Canonical) recommended that I cross-post this to the JuJu mailing list, just in case folks in that forum can provide input about vnc - middleware - keystone communication breakage ... and the specific version of packages that are known to work with the charms. Any details/feedback/redirects are welcome!

From: Konger, Chris
Sent: Monday, January 23, 2017 9:24 PM
To: 'dev at lists.opencontrail.org' <dev at lists.opencontrail.org>
Subject: MaaS/JuJu contrail and contrail-ha deployers

We have been testing MaaS/JuJu here and have been very impressed ... running OpenStack (Mitaka/Xenial).

Some in our networking group really like Juniper switches, so we decided to try the ML2 plugins as well as Contrail deployers (rolling back to Mitaka/Trusty for the latter).

There was some measure of success testing the ML2 plugin with MaaS/JuJu  ... we basically had to manually change files post-install (no charm ... which makes it impractical because Juju wants to try to overwrite the things that make it work). Apparently Juniper wants to create a charm to avoid that situation, but that may be a long ways off.

That led to us trying some of the Contrail deployer charms (including the HA version released just a few days ago). There seem to be MAJOR incompatibilities with vnc - middleware - keystone communication.  Calls to routines which earlier existed in keystone/middleware that no longer exist (they are now in keystonemiddleware where they have been repositioned ... if they exist at all!)  Reverting back to earlier keystone/middleware fixes some issues but creates others.

I should give praise where due: the new HA deployer charm is quite impressive. Some of the errors we saw earlier (mostly oslo related) appear to have been fixed. But all those redundant services is kinda moot if Openstack fails to spin up ... because Contrail refuses to spin up ... because of Middleware incompatibilities!  :(

Some things are quite obvious. Like /usr/lib/python2.7/dist-packages/vnc_cfg_api_server/vnc_auth_keystone.py line 19 changing ...
  <     from keystoneclient.middleware import auth_token
  >     from keystonemiddleware import auth_token

Down on lines 198 and 229 there exists "get_admin_token()" which was deprecated/axed ... it no longer seems to exist in keystonemiddleware. For that one it's not a simple quick one-line mod (at least I haven't figured it out). There _are_ similar routines like "get_token()" but those pass a different number of parameters and it's not obvious [to me] how to fix this.

If anyone has successfully used the Contrail deployer charms and know the "secret handshake" of what versions of keystoneclient or keystonemiddleware are compatible ... that would be GREATLY APPRECIATED! We're at wits end here (fortunately we have another pilot starting up with a different off-the-shelf solution for the network component ... so there may be an alternative if we can't get this working).

Thanks!!!

Chris Konger / Virginia Tech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170124/a2a0fb05/attachment.html>


More information about the Juju mailing list