On Mon, May 8, 2017 at 7:45 AM, Marios Andreou <mandr...@redhat.com> 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.
It looks like a good idea to me. I don't think our operators want to update / upgrade OpenStack if the cloud is not in a consistent working state before. Here's the things we could test: - Pacemaker cluster health - Ceph health - Database - APIs healthcheck - RabbitMQ health > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __________________________________________________________________________ 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
