<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/26/2013 01:21 AM, James E. Blair
      wrote:<br>
    </div>
    <blockquote cite="mid:87zjueba2j.fsf@shiprock.lan" type="cite">
      <pre wrap="">Sean Dague <a class="moz-txt-link-rfc2396E" href="mailto:sean@dague.net"><sean@dague.net></a> writes:

</pre>
      <blockquote type="cite">
        <pre wrap="">Cool proposed change coming in from the Heat folks - 
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/34278/">https://review.openstack.org/#/c/34278/</a> 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.
</pre>
      </blockquote>
    </blockquote>
    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.<br>
    <br>
    Projects which are not currently gated which will need to be are:<br>
    stackforge/
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    diskimage-builder<br>
    stackforge/tripleo-image-elements<br>
    stackforge/
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    os-config-applier<br>
    stackforge/os-refresh-config<br>
    openstack/heat-cfntools<br>
    <br>
    Maybe gating on only gate-tempest-devstack-vm-full would be enough? 
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <blockquote cite="mid:87zjueba2j.fsf@shiprock.lan" type="cite">
      <pre wrap="">
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.
</pre>
    </blockquote>
    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.<br>
    <br>
    I may not be able to progress though until diskimage-builder and
    tripleo-image-elements are loaded onto the devstack image:<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="https://review.openstack.org/#/c/34295/">https://review.openstack.org/#/c/34295/</a><br>
    <br>
    <blockquote cite="mid:87zjueba2j.fsf@shiprock.lan" type="cite">
      <pre wrap="">
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).
</pre>
    </blockquote>
    <br>
    I've talked to Robert and he is not against gating, I'd like to get
    confirmation from Clint too.<br>
    <br>
    <blockquote cite="mid:87zjueba2j.fsf@shiprock.lan" type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">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?
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
    </blockquote>
    I'm hoping that any dib rehousing can be decoupled from this current
    piece of work.<br>
    <br>
    cheers<br>
  </body>
</html>