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