Open Stack

On 02/23/2015 07:00 PM, James E. Blair wrote:
> Clark Boylan <cboylan at sapwetik.org> writes:
> 
>>>    The other thing is that we don't have the zuul code to vote with 
>>>    a different account deployed/merged yet. So initially you could run
>>>    your 
>>>    job but it wouldn't vote against, say, cinder.»
>> The stack that adds the necessary zuul stuff ends with
>> https://review.openstack.org/#/c/121528/
> 
> I don't believe that we have any current plans to use that code in
> infra.  I don't believe that it makes sense for us to create multiple
> accounts in Gerrit for our single system.  It's quite a bit of overhead,
> and I don't believe it is necessary.
> 
> To be clear, I think any policy that says that drivers must have
> "third-party CI" is an oversight.  I believe that it's fine to require
> them to have "CI", but if the CI can be provided by infra, it should be.
> I believe this misunderstanding comes from the fact that most
> out-of-tree drivers require specialized hardware, or non-free software,
> that can not be run in our system.
> 
> As mentioned elsewhere, we're generally quite happy to have any open
> source component tested in the upstream infrastructure.  Since this
> qualifies, I think the quickest and simplest way to proceed is to create
> a job that runs on the driver repo, and then create a non-voting version
> to run on the cinder repo.
> 
> Additionally, if it proves stable, the Cinder developers could certainly
> choose to gate on this job as well.
I'd like to make sure that if Infra is saying that CI jobs on drivers
can gate that this is a substantial difference from what I have been
saying for a year, specifically that they can't and won't.

Every CI system/job author/operator that I have interacted with for the
past year has been trying to figure out how to be in the gate. Since
that implies a relationship in which development on the service can't
proceed without a driver's say so (by passing the test in the gate) this
is exactly the relationship I have been trying to ensure doesn't happen.
By stating that driver jobs can gate on the service, this opens the
flood gates of every CI operator increasing pressure to be in the gate
as well (the pressure never stopped, it just took different forms).

I disagree with the relationship where a service's development can only
proceed at the speed of a driver (or driver's because where there is
one, there are plenty more).

Thanks,
Anita.


> That's entirely up to them, but
> there's no policy or technical reason it can not.
> 
> -Jim
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>