Open Stack

On December 7, 2017 3:06 pm, James E. Blair wrote:
> Tristan Cacqueray <tdecacqu at redhat.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20171208/543bcdde/attachment-0001.sig>