<div dir="ltr"><div>For cinder, we don't want to gate on drivers, and will be unhappy if that gets turned on, so the story hasn't changed, Anita.<br><br></div>I think Jim was pointing out the technical possibility, which is a fine and valid thing to point out. Cinder core are likely to continue not to want it, for the foreseeable future.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 February 2015 at 10:30, Anita Kuno <span dir="ltr"><<a href="mailto:anteaya@anteaya.info" target="_blank">anteaya@anteaya.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 02/23/2015 07:00 PM, James E. Blair wrote:<br>
> Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> writes:<br>
><br>
>>>    The other thing is that we don't have the zuul code to vote with<br>
>>>    a different account deployed/merged yet. So initially you could run<br>
>>>    your<br>
>>>    job but it wouldn't vote against, say, cinder.»<br>
>> The stack that adds the necessary zuul stuff ends with<br>
>> <a href="https://review.openstack.org/#/c/121528/" target="_blank">https://review.openstack.org/#/c/121528/</a><br>
><br>
> I don't believe that we have any current plans to use that code in<br>
> infra.  I don't believe that it makes sense for us to create multiple<br>
> accounts in Gerrit for our single system.  It's quite a bit of overhead,<br>
> and I don't believe it is necessary.<br>
><br>
> To be clear, I think any policy that says that drivers must have<br>
> "third-party CI" is an oversight.  I believe that it's fine to require<br>
> them to have "CI", but if the CI can be provided by infra, it should be.<br>
> I believe this misunderstanding comes from the fact that most<br>
> out-of-tree drivers require specialized hardware, or non-free software,<br>
> that can not be run in our system.<br>
><br>
> As mentioned elsewhere, we're generally quite happy to have any open<br>
> source component tested in the upstream infrastructure.  Since this<br>
> qualifies, I think the quickest and simplest way to proceed is to create<br>
> a job that runs on the driver repo, and then create a non-voting version<br>
> to run on the cinder repo.<br>
><br>
> Additionally, if it proves stable, the Cinder developers could certainly<br>
> choose to gate on this job as well.<br>
</div></div>I'd like to make sure that if Infra is saying that CI jobs on drivers<br>
can gate that this is a substantial difference from what I have been<br>
saying for a year, specifically that they can't and won't.<br>
<br>
Every CI system/job author/operator that I have interacted with for the<br>
past year has been trying to figure out how to be in the gate. Since<br>
that implies a relationship in which development on the service can't<br>
proceed without a driver's say so (by passing the test in the gate) this<br>
is exactly the relationship I have been trying to ensure doesn't happen.<br>
By stating that driver jobs can gate on the service, this opens the<br>
flood gates of every CI operator increasing pressure to be in the gate<br>
as well (the pressure never stopped, it just took different forms).<br>
<br>
I disagree with the relationship where a service's development can only<br>
proceed at the speed of a driver (or driver's because where there is<br>
one, there are plenty more).<br>
<br>
Thanks,<br>
Anita.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> That's entirely up to them, but<br>
> there's no policy or technical reason it can not.<br>
><br>
> -Jim<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>