On Thu, Dec 07, 2017 at 09:34:50AM +0000, Tristan Cacqueray wrote: > Hi, > > Top posting here to raise another complication. > James mentioned an API problem regarding the NodeRequestHandler > interface. Indeed the run_handler method should actually be part of the > generic code so that the driver's handler only implements the 'launch' method. > > Unfortunately, this is another refactor where we need to move and > abstract a good chunk of the openstack handler... I worked on a first > implementation that adds new handler interfaces to address the openstack > driver needs (such as setting az when a node is reused): > https://review.openstack.org/526325 > > Well I'm not sure what's the best repartition of roles between the > handler, the node_launcher and the provider, so feedback would be > appreciated. > > > I also proposed a 'plugin' interface so that driver are fully contained > in their namespace, which seems like another legitimate addition to this > feature: > https://review.openstack.org/524620 > I like the idea of some sort of plugin interface, only to allow for out of tree drivers to be maintained easier. I found using stevedore to be easy enough when I hadd to write some openstack plugins in the past, is that something we might look into reusing here?
> > Thanks, > -Tristan > > > On December 2, 2017 1:30 am, Clint Byrum wrote: > > Excerpts from corvus's message of 2017-12-01 16:08:00 -0800: > > > Tristan Cacqueray <[email protected]> writes: > > > > > > > Hi, > > > > > > > > Now that the zuulv3 release is approaching, please find below a > > > > follow-up on this spec. > > > > > > > > The current code could use one more patch[0] to untangle the common > > > > config from the openstack provider specific bits. The patch often needs > > > > to be manualy rebased. Since it looks like a good addition to what > > > > has already been merged, I think we should consider it for the release. > > > > > > > > Then it seems like new drivers are listed as 'future work' on the > > > > zuul roadmap board, though they are still up for review[1]. > > > > They are fairly self contained and they don't require further > > > > zuul or nodepool modification, thus they could be easily part of a > > > > future release indeed. > > > > > > > > However I think we should re-evaluate them for the release one more > > > > time since they enable using zuul without an OpenStack cloud. > > > > Anyway I remain available to do the legwork. > > > > > > > > Regards, > > > > -Tristan > > > > > > > > [0]: https://review.openstack.org/488384 > > > > [1]: https://review.openstack.org/468624 > > > > > > I think getting the static driver in to the 3.0 release is reasonable -- > > > most of the work is done, and I think it will make simple or test > > > deployments of Zuul much easier. That can make for a better experience > > > for users trying out Zuul. > > > > > > I'd support moving that to the 3.0 roadmap, but reserving further > > > drivers for later work. Thanks! > > > > +1. The static driver has come up a few times in my early experiments > > and I keep bouncing off of it. > > > > _______________________________________________ > > OpenStack-Infra mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
