[openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

Sean Dague sean at dague.net
Thu Sep 11 17:25:24 UTC 2014


On 09/11/2014 11:14 AM, Gary Kotton wrote:
> 
> 
> On 9/11/14, 4:30 PM, "Sean Dague" <sean at dague.net> wrote:
> 
>> On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>>
>>>
>>> On 9/11/14, 2:55 PM, "Thierry Carrez" <thierry at openstack.org> wrote:
>>>
>>>> Sean Dague wrote:
>>>>> [...]
>>>>> Why don't we start with "let's clean up the virt interface and make it
>>>>> more sane", as I don't think there is any disagreement there. If it's
>>>>> going to take a cycle, it's going to take a cycle anyway (it will
>>>>> probably take 2 cycles, realistically, we always underestimate these
>>>>> things, remember when no-db-compute was going to be 1 cycle?). I don't
>>>>> see the need to actually decide here and now that the split is clearly
>>>>> at least 7 - 12 months away. A lot happens in the intervening time.
>>>>
>>>> Yes, that sounds like the logical next step. We can't split drivers
>>>> without first doing that anyway. I still think "people need smaller
>>>> areas of work", as Vish eloquently put it. I still hope that
>>>> refactoring
>>>> our test architecture will let us reach the same level of quality with
>>>> only a fraction of the tests being run at the gate, which should
>>>> address
>>>> most of the harm you see in adding additional repositories. But I agree
>>>> there is little point in discussing splitting virt drivers (or anything
>>>> else, really) until the internal interface below that potential split
>>>> is
>>>> fully cleaned up and it becomes an option.
>>>
>>> How about we start to try and patch gerrit to provide +2 permissions for
>>> people
>>> Who can be assigned Œdriver core¹ status. This is something that is
>>> relevant to Nova and Neutron and I guess Cinder too.
>>
>> If you think that's the right solution, I'd say go and investigate it
>> with folks that understand enough gerrit internals to be able to figure
>> out how hard it would be. Start a conversation in #openstack-infra to
>> explore it.
>>
>> My expectation is that there is more complexity there than you give it
>> credit for. That being said one of the biggest limitations we've had on
>> gerrit changes is we've effectively only got one community member, Kai,
>> who does any of that. If other people, or teams, were willing to dig in
>> and own things like this, that might be really helpful.
> 
> What about what Radoslav suggested? Having a background task running -
> that can set a flag indicating that the code has been approved by the
> driver ‘maintainers’. This can be something that driver CI should run -
> that is, driver code can only be approved if it has X +1’s from the driver
> maintainers and a +1 from the driver CI.

There is a ton of complexity and open questions with that approach as
well, largely, again because people are designing systems based on
gerrit from the hip without actually understanding gerrit.

If someone wants to devote time to that kind of system and architecture,
they should engage the infra team to understand what can and can't be
done here. And take that on as a Kilo cycle goal. It would be useful,
but there is no 'simply' about it.

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list