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

Lee Yarwood lyarwood at redhat.com
Thu Oct 5 09:57:26 UTC 2017

On 05-10-17 09:33:29, Steven Hardy wrote:
> 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.

Thanks Steven, great point, I wanted to run through the full upgrade
somewhere in our RDO CI but for devs working on this deploying a Newton
overcloud from a master undercloud would be the quickest to get up and

I've just had a look through the current upgrade jobs and have copied
their approach of using config/release/*.yml to control this. I'll
report back if/when I've managed to sucessfully deploy this.


Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171005/5040b231/attachment.sig>

More information about the OpenStack-dev mailing list