Open Stack

On 02/24/2015 04:40 AM, Duncan Thomas wrote:
> 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.
> 
> 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.
Fair enough.

My concern is that by making it technically possible and permissible
from infra's side we are just opening up the projects to have to engage
in yet another game of whack-a-mole since driver testing ops can and
will try to turn it on.

Thanks,
Anita.

> 
> On 24 February 2015 at 10:30, Anita Kuno <anteaya at anteaya.info> wrote:
> 
>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
> 
> 
> 
> 
> 
> __________________________________________________________________________
> 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
>