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.

The current solution for handling defaults with hardware_types removes much of 
the control from the deployer over which interfaces are enabled in their 
environment. For example:

- A deployer wants to use a hardware_type that specifies neutron as the default 
network_interface in a Ironic standalone deployment.
- As a deployer they know that the neutron network interface is not going to 
work but they can’t disable it because its a hardware_type default which are 
automatically enabled.
- This means that nodes can be created using that hardware_type with a known 
not to work interface implementation, and if not overridden during node 
creation the network_interface for that node will be automatically configured 
to use the neutron interface because its the default, resulting in a broken 
node by default.

To address this issue meetings and discussions on IRC considered several 
different solutions but all more or less resulted in either removing special 
case interfaces like network from the hardware_type, or treating these 
interfaces as special cases in some form or other with no default, or new 
config options to manage them.

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

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to