On 06/26/2013 01:21 AM, James E. Blair wrote: > Sean Dague <[email protected]> writes: > >> Cool proposed change coming in from the Heat folks - >> https://review.openstack.org/#/c/34278/ to use dib to build their base >> images in devstack. From a development perspective, will make >> experimenting with Heat a lot easier. >> >> However, this raises an issue as we look towards using this in the >> gate, because diskimage-builder isn't currently gated by >> devstack-gate. But if Heat wants to use it we're talking about pulling >> upstream master as part of the build. Which opens us up to an >> asymmetric gate where a dib change can land which breaks the gate, >> then all nova changes are blocked from merging until it gets in. >> >> I think we need to be really explicit that on the gate, every git tree >> we pull in is also gated, to ensure nothing breaks other projects >> ability to merge code. Asymmetric gating is no fun. 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 stackforge/os-refresh-config openstack/heat-cfntools Maybe gating on only gate-tempest-devstack-vm-full would be enough? > Agreed -- and in fact this is enforced by code (which is why 34278 is > currently failing). Devstack-gate sets the FAIL_ON_CLONE option in > devstack so that if devstack clones a repo that is not managed by > devstack-gate, the tests fail. I'm not intending on 34278 getting merged until all this is sorted (including any caching and timing issues). I'll mark it as WIP. I may not be able to progress though until diskimage-builder and tripleo-image-elements are loaded onto the devstack image: https://review.openstack.org/#/c/34295/ > Anyway, back to the issue -- yes asymmetric gating is not fun, so the > only way we should be incorporating code into the devstack gate is > either via another gated project, or packaged and released code (be it > an egg or an operating system package). I've talked to Robert and he is not against gating, I'd like to get confirmation from Clint too. >> This gets a little odder in that dib is out on stackforge and not as >> part of an openstack* github tree. Which on the one hand is just >> naming, on the other hand if heat's going to need that to get through >> the gate, maybe we should rethink it being on stackforge >> vs. openstack-dev? > It looks like the TC agreed that dib should be part of a tripleo > program, and the TC is currently working out the details of programs. > So it looks like there is unlikely to be a hurdle for having dib > officially recognized. We just need to decide where to put it. > I'm hoping that any dib rehousing can be decoupled from this current piece of work. cheers
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
