On 06/26/2013 10:44 AM, Robert Collins wrote: > On 26 June 2013 09:43, Steve Baker <[email protected]> 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 > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
