Re: [OpenStack-Infra] Nodepool drivers

[James E. Blair]

Tristan Cacqueray  writes:

>>> 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 think that will be a nice thing to have, but I'd like to delay it (as
>> we have for Zuul) much further into the future.  I'd like to make a
>> couple of releases where we think the internal API is stable before we
>> consider making an external API.  In the mean time, I'd like to expand
>> the set of drivers we support in-tree.
>>
> Note that this help adding test and it makes rebase easier... How about
> we keep it for the internal API without supporting out of tree drivers?

If that's the case, I think it would be fine -- as long as it's not
exposed at all (we should remove the config file setting in favor of
direct imports, for example).

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

On December 7, 2017 3:06 pm, James E. Blair wrote:

Tristan Cacqueray  writes:


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 think we can probably perform the refactor after landing the static
driver with the current design (and we don't need to do this before the
v3.0 release).


Fair enough, either way is fine for me.


It will mean that folks can't request a static node as
part of a nodeset with dynamic nodes, but being able to just request
static nodes alone is a useful improvement.  So if we document the
caveat and indicate that we're working to lift the restriction in the
future, that should be sufficient.


Being able to use a nodeset with nodes from different providers isn't
actually addressed by this refactor, I think this needs a design discussion
on its own. To do that, we may need a label setting or something to indicate
a node can be added to a nodeset with foreign nodes, because right now, the
openstack driver enfore nodeset's nodes to be in the same az.


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 think that will be a nice thing to have, but I'd like to delay it (as
we have for Zuul) much further into the future.  I'd like to make a
couple of releases where we think the internal API is stable before we
consider making an external API.  In the mean time, I'd like to expand
the set of drivers we support in-tree.


Note that this help adding test and it makes rebase easier... How about
we keep it for the internal API without supporting out of tree drivers?

-Tristan


pgpZJsaQd4fNU.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

On December 7, 2017 2:28 pm, Paul Belanger wrote:

On Thu, Dec 07, 2017 at 09:34:50AM +, Tristan Cacqueray wrote:

[snip]

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?


Indeed, if you don't mind an extra requirement, stevedore would be a nice
addition.

-Tristan


pgp8KLAigCMJr.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[James E. Blair]

Tristan Cacqueray  writes:

> 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 think we can probably perform the refactor after landing the static
driver with the current design (and we don't need to do this before the
v3.0 release).  It will mean that folks can't request a static node as
part of a nodeset with dynamic nodes, but being able to just request
static nodes alone is a useful improvement.  So if we document the
caveat and indicate that we're working to lift the restriction in the
future, that should be sufficient.

> 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 think that will be a nice thing to have, but I'd like to delay it (as
we have for Zuul) much further into the future.  I'd like to make a
couple of releases where we think the internal API is stable before we
consider making an external API.  In the mean time, I'd like to expand
the set of drivers we support in-tree.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Paul Belanger]

On Thu, Dec 07, 2017 at 09:34:50AM +, 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  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
> > OpenStack-Infra@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

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


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  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
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


pgp52aONuUdui.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Clint Byrum]

Excerpts from corvus's message of 2017-12-01 16:08:00 -0800:
> Tristan Cacqueray  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
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[James E. Blair]

Tristan Cacqueray  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!

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

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


pgpx8UlxtPod_.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

Hi,

A quick follow-up on this spec:

Thank you for all the review, the first three patches that refactor the
openstack driver in its own module has been merged last week.

Regarding the static driver implementation, it seems like it can be
reworked to use long-lived znode instead of re-creating znode each time
a job has been run.

In the meantime, I worked on a couple of patch to move the provider
configuration management (load and validate) in the driver modules,
so that it's less confusing to define new settings for a driver.

For what it worth, I've been running a nodepool service with static
and oci drivers using the patch chain[1] without issues so far.

Regards,
-Tristan


[1]: https://review.openstack.org/#/q/topic:nodepool-drivers



pgpbVpWgoSQc4.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[James E. Blair]

Tristan Cacqueray  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!

> 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.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

On May 29, 2017 1:12 pm, Paul Belanger wrote:

On Mon, May 29, 2017 at 02:39:16AM +, 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.


I know in the past we talked about using kubernetes for this. But, that might be
a large dependency for testing environments.


Well since zuulV3 lost static nodes support, it already requires a working 
OpenStack
provider, Kubernetes may be easier to setup for testing environments...


A quick peak at the code makes me
wonder if we maybe shouldn't just turn the interface into an Ansible driver.
This gets the contain logic outside of nodepool and by using ansible, makes it
generic enough to use any container / serverless / something.

It could be possible, there is where something like linchpin comes in handy too.


Thank you for looking through this proposal, a generic interface would
be pretty neat indeed. Though I'm not sure it should be tied to
Ansible, once the interface is well defined we could have a boilerplate
driver that could be implemented with any systems, perhaps running
external commands such as linchpin or Ansible.

-Tristan




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





___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra





pgpYV6GnHFf6A.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


pgprL4VgNJTnd.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Clark Boylan]

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.
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).

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.

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.

Hope this helps,
Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Nodepool drivers

[Paul Belanger]

On Mon, May 29, 2017 at 02:39:16AM +, 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.
> 
I know in the past we talked about using kubernetes for this. But, that might be
a large dependency for testing environments.  A quick peak at the code makes me
wonder if we maybe shouldn't just turn the interface into an Ansible driver.
This gets the contain logic outside of nodepool and by using ansible, makes it
generic enough to use any container / serverless / something.

It could be possible, there is where something like linchpin comes in handy too.

> 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



> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Nodepool drivers

[Tristan Cacqueray]

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


pgpc4X9hx_KeD.pgp
Description: PGP signature
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra