Open Stack

Hi,

On Fri, Jun 16, 2017 at 1:51 AM, Tristan Cacqueray <tdecacqu at redhat.com>
wrote:

> On June 14, 2017 1:10 pm, James E. Blair wrote:
>
>> Tristan Cacqueray <tdecacqu at redhat.com> writes:
>>
>> Hi,
>>>
>>> With the nodepool-drivers[0] spec approved, I started to hack a quick
>>> implementation[1]. Well I am not very familiar with the
>>> nodepool/zookeeper
>>> architecture, thus this implementation may very well be missing important
>>> bits... The primary goal is to be able to run ZuulV3 with static nodes,
>>> comments and feedbacks are most welcome.
>>>
>>
>> I've taken a general look and I think this is heading in the right
>> direction.  We should ask David Shrewsbury to look at it when he gets a
>> chance, and Tobias as well when he's back.  Thanks!
>>
>> Thanks! The first three changes mostly move code to the driver directory
> without changing the logic which seems like a sane thing to do before
> changing the interface. Since this is a pain to rebase, those should be the
> priority:
> * https://review.openstack.org/468748 : generic request handler
> * https://review.openstack.org/468749 : generic provider manager
> * https://review.openstack.org/468750 : move openstack bits to its own
> driver
>


Overall, these three seem ok after studying them for a bit. And tests pass,
so
that's a plus.



> A follow-up effort would be to also move openstack driver tests to their
> own
> files and the provider configuration to the driver module.
>
> Moreover, assuming this isn't too off-track, I'd like to propose an
>>> OpenContainer and a libvirt driver to diversify Test environment.
>>>
>>
>> I think the most important thing is the static node driver -- that's
>> part of the original scope for Zuul v3, and we need it for functional
>> parity with v2.
>>
>> An OpenContainer driver sounds fine to me, but I'm reluctant to add a
>> libvirt driver at the moment -- there is a lot of potential overlap with
>> OpenStack, as well as other potential drivers such as linch-pin.  Maybe
>> there are some compelling reasons to do so, but I'd rather defer that
>> for a while until we establish some guidelines around in-tree drivers.
>>
>> Since it's a scope expansion, we should consider anything beyond the
>> static driver to be a lower priority while we work to get Zuul v3
>> finished.
>>
>> Indeed, having static nodes is the primary goal, the extra drivers are
> mainly to exercise the interface for now. It's fine if they are not
> accepted in-tree, as long as we design a common interface.
>
> Cheers,
> -Tristan
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
David Shrewsbury (Shrews)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20170616/9879c13c/attachment.html>