[openstack-dev] [nova] [ironic] how to remove check-tempest-dsvm-ironic-pxe_ssh on Nova check

Sean Dague sean at dague.net
Tue Nov 25 15:16:52 UTC 2014


On 11/25/2014 10:07 AM, Jim Rollenhagen wrote:
> On Tue, Nov 25, 2014 at 08:02:56AM -0500, Sean Dague wrote:
>> When at Summit I discovered that check-tempest-dsvm-ironic-pxe_ssh is
>> now voting on Nova check queue. The reasons given is that the Nova team
>> ignored the interface contract that was being provided to Ironic, broke
>> them, so the Ironic team pushed for co-gating (which basically means the
>> interface contract is now enforced by a 3rd party outside of Nova / Ironic).
>>
>> However, this was all in vague term, and I think is exactly the kind of
>> thing we don't want to do. Which is use the gate as a proxy fight over
>> teams breaking contracts with other teams.
>>
>> So I'd like to dive into what changes happened and what actually broke,
>> so that we can get back to doing this smarter.
>>
>> Because if we are going to continue to grow as a community, we have to
>> co-gate less. It has become a crutch to not think about interfaces and
>> implications of changes, and is something we need to be doing a lot less of.
> 
> Completely agree here; I would love to not gate Nova on Ironic.
> 
> The major problem is that Nova's driver API is explicitly not stable.[0]
> If the driver API becomes stable and properly versioned, Nova should be
> able to change the driver API without breaking Ironic.
> 
> Now, this won't fix all cases where Nova could break Ironic. The
> resource tracker or scheduler could change in a breaking way. However, I
> think the driver API has been the most common cause of Ironic breakage,
> so I think it's a great first step.
> 
> // jim
> 
> [0] http://docs.openstack.org/developer/nova/devref/policies.html#public-contractual-apis

So we actually had a test in tree for that part of the contract...

We don't need the surface to be public contractual, we just need to know
what things Ironic is depending on and realize that can't be changed
without some compatibility code put in place.

Again... without knowing exactly what happened (I was on leave) it's
hard to come up with a solution. However, I think the co-gate was an
elephant gun that we don't actually want.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list