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? > 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 <[email protected]> Distinguished Technologist HP Cloud Services _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
