[openstack-dev] [tripleo] Validations before upgrades and updates

Graeme Gillies ggillies at redhat.com
Wed May 24 01:09:16 UTC 2017

On 08/05/17 21:45, Marios Andreou wrote:
> Hi folks, after some discussion locally with colleagues about improving
> the upgrades experience, one of the items that came up was pre-upgrade
> and update validations. I took an AI to look at the current status of
> tripleo-validations [0] and posted a simple WIP [1] intended to be run
> before an undercloud update/upgrade and which just checks service
> status. It was pointed out by shardy that for such checks it is better
> to instead continue to use the per-service  manifests where possible
> like [2] for example where we check status before N..O major upgrade.
> There may still be some undercloud specific validations that we can land
> into the tripleo-validations repo (thinking about things like the
> neutron networks/ports, validating the current nova nodes state etc?).
> So do folks have any thoughts about this subject - for example the kinds
> of things we should be checking - Steve said he had some reviews in
> progress for collecting the overcloud ansible puppet/docker config into
> an ansible playbook that the operator can invoke for upgrade of the
> 'manual' nodes (for example compute in the N..O workflow) - the point
> being that we can add more per-service ansible validation tasks into the
> service manifests for execution when the play is run by the operator -
> but I'll let Steve point at and talk about those. 
> cheers, marios
> [0] https://github.com/openstack/tripleo-validations 
> [1] https://review.openstack.org/#/c/462918/
> [2]  https://github.com/openstack/tripleo-heat-templates/blob/stable/ocata/puppet/services/neutron-api.yaml#L197 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi Marios,

Forgive me if I misunderstand here, but it looks like part of this goal
is to do things like ensure the overcloud is in a decent state before an
upgrade/update is executed.

How would this work in a situation where I have hit an openstack bug
which causes my cinder service to stop working/fail, and I a fix has
been created/packaged, ready for me to update my overcloud with, but the
validations bomb out because cinder isn't running (and I can't update my
overcloud to the newest package with the fix because the validation fails?)



Graeme Gillies
Principal Systems Administrator
Openstack Infrastructure
Red Hat Australia

More information about the OpenStack-dev mailing list