Open Stack

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