Thanks Robert, for your very detailed response. We knew we were missing something.
Both our Canonical and Juniper account teams suggested the solution would most likely require upgrading from OpenContrail to Contrail (which they are in the process of getting us a copy ... just to make sure it works). The local repository info was especially useful (we have discussed this here ... that we needed to make sure known charms and packages were used to avoid future incompatibilities). We'll give this a try ... and I'll report back to the lists with the results. Much appreciated!! Chris Konger / Virginia Tech -----Original Message----- From: Robert Ayres [mailto:robert.ay...@canonical.com] Sent: Thursday, January 26, 2017 9:41 AM To: Konger, Chris <ckon...@vt.edu> Cc: j...@lists.ubuntu.com Subject: Re: MaaS/JuJu contrail and contrail-ha deployers Hi Chris, Thanks for evaluating our stack! I assume you're trying to use OpenContrail with Mitaka. The current stable version of OpenContrail available in Juniper's PPA is still 2.21 (and our Contrail charms will use by default), which only supports as far as Juno. If you want to deploy Mitaka with Contrail you need to use commercial Contrail packages (https://www.juniper.net/support/downloads/?p=contrail#). These will require a Juniper account and license. Contrail 3.1 is the first release to support Mitaka and the commercial packages have been verified with charm deployments. When you have the package file ('contrail-install-packages_3.1.0.0-25~mitaka_all.deb'), you can alter our bundle to point to a local Contrail package repo by following these instructions: # bundle, needs to be pointed to local Contrail package repo http://bazaar.launchpad.net/~sdn-charmers/+junk/contrail-deployer/view/head:/bundles/contrail-trusty-mitaka.yaml # juniper's instructions for setting up package repo https://github.com/tonyliu0592/opencontrail/blob/master/juju/juju-contrail.md#12-contrail-repository Thanks, Rob PS. tcp cloud run their own OpenContrail PPA which has 3.0.3 packages in it, which you can point our Contrail charms at (using 'install-sources'/'install-keys' config options). Our Contrail charms aren't validated against these packages so YMMV. Additionally, 3.0.3 will only support as far as Liberty. On 24/01/17 16:06, Konger, Chris wrote: > 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@lists.opencontrail.org' <dev@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 > > > _______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
