Hi, On Fri, Jun 16, 2017 at 1:51 AM, Tristan Cacqueray <[email protected]> wrote:
> On June 14, 2017 1:10 pm, James E. Blair wrote: > >> Tristan Cacqueray <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > -- David Shrewsbury (Shrews)
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
