Open Stack

On 06/26/2013 10:44 AM, Robert Collins wrote:
> 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?
tie heat-cfntools depends on os-apply-config and os-refresh-config,
which seems inverted to me. This whole area may change soon anyway with
Clint's current work.
>> 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
>
>