Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160714/abfd0fc7/attachment.html>