On 07/14/2016 12:52 PM, Sam Betts (sambetts) wrote:
There have been several discussions brought about by new interface types
and how they fit into the existing driver composition spec. Network and
Volume connector interfaces are examples of two interfaces who’s
implementations can depend highly on the environment they are being used
in, as well as the piece of hardware they are being used with. For
example the neutron network interface requires neutron to exist to operate.
<snip>
After considering several different ways to handle hardware_type
interfaces so that we can ensure that deployers maintain fine control
over which interfaces are enabled in their environment, but continue to
provide sane defaults for all the different types of interfaces for
convenience of the user when enrolling nodes and also have all interface
types defined in a consistent way for developers of hardware types. I
would like to propose this solution:
- Remove single hardware_type default for all interface types
- Make hardware_type supported_FOO_interfaces a list of supported
implementations in order of preference by that hardware type’s vendor
- Have Ironic resolve the possible_FOO_interfaces by intersecting
enabled_FOO_interfaces with supported_FOO_interfaces maintaining the
order of preference
- Use the first possible_FOO_interface as the default this hardware_type
I haven't thought much about the idea, but at first glance I like it.
It's somewhat less explicit, but we still can return the calculated
default interface in /v1/drivers API, so it might be OK.
An example of this in operation:
In the deployer’s environment, implementation RAR, HAH and GAR will
work, BAR will not.
The deployer wants to enable two different hardware_types X and Y.
hardware_type X:
# BAR is recomended over RAR and RAR over GAR if available in
this deployment
supported_FOO_interface: [BAR, RAR, GAR]
hardware_type Y:
supported_FOO_interface: [HAH]
The deployer knowing that BAR will not work, does not include BAR in the
list of enabled_FOO_interfaces.
Deployers config file:
enabled_FOO_interfaces = RAR, HAH, GAR
The Ironic user creates a node using hardware_type X, but doesn’t
specify any interfaces.
ironic node-create -d X
Ironic calculates prioritied list of possible interfaces:
possible_FOO_interfaces = [BAR, RAR, GAR] intersect [RAR, HAH, GAR]
= [RAR, GAR]
Ironic creates node with the first interface out of ordered list of
possible interfaces.
Node:
hardware_type: X
FOO_interfaces: RAR
The user now has a node with interfaces that are guaranteed by the
deployer to work in this environment.
This solution does mean that based on which environment you enroll a
node in you might get a different set of interfaces. So in order to find
out which interface is going to be the default FOO_interface for this
hardware_type in this environment, you can use the discovery API, which
returns a default_FOO_interface field, and also the
possible_FOO_interfaces, if you want to know which other interfaces
are available to you.
I believe this is a good fit for treating all interfaces in a
standardised way, please let me know your opinions so we can solve this
issue in a way that is convenient for our users as well as keeps
things consistent for developing core Ironic code, and hardware_types
both in and out of tree.
Sam
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
