On May 31, 2017 7:40 pm, Clark Boylan wrote:
On Sun, May 28, 2017, at 07:39 PM, Tristan Cacqueray wrote: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. Moreover, assuming this isn't too off-track, I'd like to propose an OpenContainer and a libvirt driver to diversify Test environment. Thanks in advance, -Tristan [0]: http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-drivers.html [1]: https://review.openstack.org/#/q/topic:nodepool-driversI've briefly looked through the stack and left some comments on changes.
Thank you for looking through this proposal!
Would help if the nodepool-drivers topic is on all the changes (I didn't update the topics as I wasn't sure if this was intentional or not).
Oops, topic got reset on patch update, it wasn't intentional.
Overall this looks good. There are a few things that come up though. I think we need to clearly define what the handlers and providers do so that it is clear in the implementation. Right now it appears that they share a lot of responsibility and you end up with different drivers splitting those two classes differently.
Indeed, so far the driver interface is: NodeRequestHandler.run_handler() : Process node request provides abstraction for polling over PoolWorker. Implementation have access to self.provider, self.pool, self.zk and self.manager NodeLaunchManager.launch(): Asynchronous node launcher provides abstraction for request handler's thread creation. ProviderManager: provides abstraction for provider configuration and management start, stop, join(): Manage the provider labelReady(): Query the provider for label availability listNodes(): List nodes cleanupNodes()/waitForNodeCleanup(): Node management
We also need to clearly communicate the behavior of different drivers when it comes to running multiple launchers. Do we expect that each launcher is a standalone spof and manages resources completely independent of the other launchers or do we want to allow for coordination between launchers via zookeeper so that we have redundancy. I don't think we need to solve redundancy right away, we just need to be clear to users (and devs modifying drivers) what the expectation is for each driver.
As far as I can tell, RequestHandler are independent and they decline requests it can't fullfill. Not sure how they could coordinate between each others though.
Hope this helps, Clark
It helped, thanks! -Tristan
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
pgprL4VgNJTnd.pgp
Description: PGP signature
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
