On December 7, 2017 3:06 pm, James E. Blair wrote:
Tristan Cacqueray <tdeca...@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/526325Well 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/524620I 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
