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 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
pgpgrCzmHnPRM.pgp
Description: PGP signature
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
