All of the OpenStack services are already running Mitaka, since they're all on Trusty hosts. We have several hosts (e.g. labspuppetmaster1001/1002) which are using OpenStack clients on Jessie, and those are still set to Liberty because we don't yet have things set up properly to install Mitaka packages on Jessie.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Andrew | T145919 Upgrade Labs to OpenStack Mitaka | |||
| Resolved | Andrew | T192162 Set up proper apt pinning for Mitaka on Jessie, upgrade Jessie hosts to Mitaka |
Change 426119 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] labpuppetmaster: force to Liberty
Change 426119 merged by Andrew Bogott:
[operations/puppet@production] labpuppetmaster: force to Liberty
Change 426891 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/puppet@production] cloudvps: add apt pinning for mitaka on jessie
A brand new Jessie VM with no special classes applied looks like this:
$ apt-cache madison python-novaclient python-novaclient | 2:3.3.1-3~bpo8+1 | http://mirrors.wikimedia.org/debian/ jessie-backports/main amd64 Packages python-novaclient | 2:3.3.1-3~bpo8+1 | http://apt.wikimedia.org/wikimedia/ jessie-wikimedia/backports amd64 Packages python-novaclient | 2:2.18.1-1 | http://httpredir.debian.org/debian/ jessie/main amd64 Packages python-novaclient | 2:3.3.1-3~bpo8+1 | http://mirrors.wikimedia.org/debian/ jessie-backports/main Sources
And the default version of python-novaclient that gets installed is:
$ dpkg --list | grep novaclient ii python-novaclient 2:3.3.1-3~bpo8+1 all client library for OpenStack Compute API - Python 2.7
So that's mitaka already, presumably coming from backports. I don't think I expected it to choose backports by default... I guess this means we're getting Mitaka on Jessie by default, which is probably fine.
My other question is -- does pinning to backports mean that we will always get the mitaka packages? Or will they update the version available in backports at some point in the future?
To get strict mitaka packages we would need to know the version of every single package and have a separate pinning for them.
It could be done, yeah, perhaps that would be more robust.
Change 426891 merged by Andrew Bogott:
[operations/puppet@production] cloudvps: add apt pinning for mitaka on jessie
Change 427429 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] labtestpuppetmaster: switch to default openstack version
Change 427429 merged by Andrew Bogott:
[operations/puppet@production] labtestpuppetmaster: switch to default openstack version
Change 427430 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] labpuppetmaster: switch to default openstack version
Change 427430 merged by Andrew Bogott:
[operations/puppet@production] labpuppetmaster: switch to default openstack version
Change 427443 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] Openstack: move remaining hosts to Mitaka
Change 427443 merged by Andrew Bogott:
[operations/puppet@production] Openstack: move remaining hosts to Mitaka
Change 427447 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] openstack::cloudrepo: Tentatively support Stretch + Ocata
Change 427447 merged by Andrew Bogott:
[operations/puppet@production] openstack::cloudrepo: Tentatively support Stretch + Ocata
Change 428023 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] openstack: Pin a bunch of packages for mitaka/jessie
Change 428023 merged by Andrew Bogott:
[operations/puppet@production] openstack: Pin a bunch of packages for mitaka/jessie
Now I see that we have possibly-conflicting solutions for this. Most Jessie hosts aren't getting Arturo's new pinning rules, rather they are getting Chase's openstack::backports class.
openstack::backports only mentions three files, so I'm inclined to discard it in favor of Arturo's openstack::jessie_mitaka_pinning. Would like input from @chasemp about this first in case somehow those three files are all we need.
Andrew the openstack::backports will do all of the same things as jessie_mitaka_pinning. openstack::backports is for cases where we are targeting backports as the release of choice, and jessie_mitaka_pinning is for when we only want to pin specific jessie client libs to backports. In the case of nova-compute here we need openstack::backports
openstack::backports is for cases where we are targeting backports as the release of choice, and jessie_mitaka_pinning is for when we only want to pin specific jessie client libs to backports.
I'm unclear on when we would want to specify jessie_backports and /not/ pin particular releases. We can't depend on backports containing just Mitaka and not spontaneously moving to Newton can we? (I'm pretty sure that Arturo asked the Debian people that a few days ago and their answer was why we pinned specific package versions in _pinning.)
To be fair, having more openstack releases in jessie-backports seems unlikely at this point. But in the other hand, having specific version pinning seems more robust (at the cost of having to update version by hand in case of changes)
I propose a two-pronged approach. For boxes that only need client libraries (e.g. python-openstackclient) we pin exact package versions via a to-be-created openstack::clientrepo. For boxes that are dedicated to running only OpenStack services, we just prefer backports across the board, by including openstack::cloudrepo which handles that for jessie/mitaka.
Change 429466 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] openstack: refactor 'cloudrepo' setup
Change 429466 merged by Andrew Bogott:
[operations/puppet@production] openstack: refactor 'cloudrepo' setup