Hi Sean,
Great to see you taking the initiative on this.
I think the starting point we’d have to work from with the way the builds are
executed now would be to have the upgrade job execute in a periodic pipeline
that has a longer timeout. While it would be ideal to do on-commit tests it’s
just untenable right now as it would severely slow down the workflow.
In terms of using a ‘cached’ or pre-built container rootfs, pre-build wheels
and venvs, etc this is something that we at Rackspace are working on already
and are hoping to share some experience with at the Pike PTG. The initial work
is a bit of a hack job, but we’re hoping to learn enough to share and are
hoping to collaborate to put together something that can be used by a broader
community and contributed to by a broader community.
Right now, however, I think we need some sort of upgrade tests on a regular
basis more than we need to implement an alternative emans of deploying. Our
choices are therefore, as far as I can see, to have this done in External CI or
to use OpenStack-Infra’s periodic jobs. Once we have something in place we can
work towards improving the execution speed (using whatever means available) to
get to the point where we can usefully execute the jobs on-commit.
J
IRC: odyssey4me
On 1/11/17, 11:03 PM, "Sean M. Collins" <s...@coreitpro.com> wrote:
OK - with https://review.openstack.org/#/c/418521/ we have at least a
working POC of what we can do.
The issue is that we're running into the Zuul timeout.
Depending on how quickly the AIO is built, we can get to the point where
we run the upgrade script[2].
However in some runs we don't get to the end of the AIO build[3].
So, the question is, how do we proceed? I'm not a real LXC expert but if
we could somehow cache stable builds of the LXC containers, so that
bootstrapping the AIO just means downloading and launching them, so that
we can use the majority of the Zuul runtime to execute the upgrade
script, that'd be great.
I know he have diskimage builder that does something sort of like this,
maybe we can do something similar for the LXC containers?
[1]:
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_16_114022
[2]:
http://logs.openstack.org/21/418521/7/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/6704087/console.html#_2017-01-11_05_13_24_895056
[3]:
http://logs.openstack.org/21/418521/8/experimental/gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv/ac09458/console.html#_2017-01-11_21_13_55_572404
--
Sean M. Collins
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
________________________________
Rackspace Limited is a company registered in England & Wales (company
registered number 03897010) whose registered office is at 5 Millington Road,
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
contain confidential or privileged information intended for the recipient. Any
dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by
e-mail at ab...@rackspace.com and delete the original message. Your cooperation
is appreciated.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
