[openstack-dev] [tripleo][quickstart][rdo] shipping python-virtualbmc in Newton to allow undercloud upgrades from Newton to Queens

Steven Hardy shardy at redhat.com
Thu Oct 5 09:33:29 UTC 2017

On Wed, Oct 4, 2017 at 1:08 PM, Lee Yarwood <lyarwood at redhat.com> wrote:
> Hello all,
> I'm currently working to get the tripleo-spec for fast-forward upgrades
> out of WIP and merged ahead of the Queens M-1 milestone next week. One
> of the documented pre-requisite steps for fast-forward upgrades is for
> an operator to linearly upgrade the undercloud from Newton (N) to Queens
> (N+3):
> https://review.openstack.org/#/c/497257/
> This is not possible at present with tripleo-quickstart deployed virtual
> environments thanks to our use of the pxe_ssh Ironic driver in Newton
> that has now been removed in Pike:
> https://docs.openstack.org/releasenotes/ironic/pike.html#id14
> I briefly looked into migrating between pxe_ssh and the new default of
> vbmc during the Ocata to Pike undercloud upgrade but I'd much rather
> just deploy Newton using vbmc. AFAICT the only issue here is packaging
> with the python-virtualbmc package not present in the Newton repos.
> With that in mind I've submitted the following changes that remove the
> various conditionals in tripleo-quickstart that block the use of vbmc in
> Newton and verified that this works by using the Ocata python-virtualbmc
> package:
> https://review.openstack.org/#/q/topic:allow_vbmc_newton+(status:open+OR+status:merged)
> FWIW I can deploy successfully on Newton with these changes and then
> upgrade the undercloud to Pike just fine.
> Would anyone be able to confirm *if* we could ship python-virtualbmc in
> the Newton relevant repos?

This sounds reasonable to me, but note another option for testing
fast-forward overcloud upgrades would be to deploy a trunk/pike
undercloud, then use it to deploy a newton overcloud (use newton
overcloud-full image and tripleo-heat-templates).

We already do a mixed version deploy like this if the upgrade CI jobs,
although those are only deploying the N-1 release not N-3, but I think
in theory it should work the same.


More information about the OpenStack-dev mailing list