Open Stack

On 26 June 2013 09:43, Steve Baker <sbaker at redhat.com> wrote:

> I've been mulling on the implications of this too.  We use dib elements
> which install software on images from git too, which makes the list of
> projects that need to be gated even longer.
>
> Projects which are not currently gated which will need to be are:
> stackforge/ diskimage-builder
> stackforge/tripleo-image-elements

> stackforge/ os-config-applier

This is not pulled in from git - we consume releases of it. We'd want
to make sure tripleo images using it are gated on bumping to a new
version, but I don't think we need to gate it's own changes on
tempest.

> stackforge/os-refresh-config

Likewise, we're about to move to consuming this as releases rather
than git. Ditto...

What elements are you using, that you're dragging in these two
components for your tempest test image?

> openstack/heat-cfntools
>
> Maybe gating on only gate-tempest-devstack-vm-full would be enough?

> I've talked to Robert and he is not against gating, I'd like to get
> confirmation from Clint too.

Stronger than this - I'm very pro knowing that our images boot and are
usable, for a number of key configurations. There is a combinatorial
problem, which means we can't test everything with the current gate
structure, perhaps ever, but we can guarantee that any image
combination built for use in the gate still works.

> I'm hoping that any dib rehousing can be decoupled from this current piece
> of work.

Ditto.

One thing we could do really easily is start making releases of dib
and tie; you could consume those in the gate, and any rev to them
would be gated. That decouples things quite effectively and wouldn't
have any impact on dib/tie test times etc.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services