Open Stack

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-drivers
> 
> I'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
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20170601/e030344c/attachment.sig>