Open Stack

Hi Julia,

Thanks for discussing with Sam and sending out this email. I like the 5 steps described below!

--ruby

On 2016-08-11, 1:37 PM, "Julia Kreger" <juliaashleykreger at gmail.com<mailto:juliaashleykreger at gmail.com>> wrote:

Yesterday as a group (jroll, rloo, dtantsur, matt128, devananda,
vdrok, and myself) discussed defaults for driver composition.

The options we discussed were:

* The existing specification[0] - Global and hardware_type
default_FOO_interface configuration, global enabled_FOO_interfaces in
configs, supported_FOO_interface in the hardware_type.

* Sambetts proposal[1] - To base any defaults on the intersection of
enabled_FOO_interfaces and the supported_FOO_interface lists taking
the first common option.

During the discussion the group came to the conclusion that if we were
to enable the ability to set defaults solely by list ordering, as put
forth in sambetts proposal, the question would then shift to who knows
best. The operator, or the vendor via the hardware_type. This further
evolved into substantial amounts of potential configuration which we
seemed to agree was confusing and unrealistic. We eventually circled
back to the original intent of the global configuration
default_FOO_interface which was to make an operator’s life easier by
allowing the definition of what would by in large be an explicitly
chosen environmental or operating default.

Circling back to the intent allowed us to focus the discussion further
and decide the following:

1. If the client creating the node does not set an explicit
FOO_interface, we must save whatever is determined as the default, in
node.FOO_interface.

2. To determine a default if one is not explicitly set via a
default_FOO_interface, the intersection between the hardware_type
definition supported_FOO_interfaces and the enabled_FOO_interfaces
global configuration would be used to determine the default.

Having determined the two preceding items, we reached a consensus that
the resulting default that is determined, must be present in
enabled_FOO_interfaces list. The result of this is that there should
be no implicit enablement of drivers, and the operator should be
selecting the interfaces possible for their environment in the
enabled_FOO_interfaces global configuration setting.

In following up with sambetts this morning and discussing the concerns
that drove his proposal initially, Sam and I determined that any
implicit enablement of drivers was not ideal, that an operator
explicit default override for its intended purpose seemed okay, and
that the determination of any default should come from the the
intersection of what is supported versus what is enabled, as the
larger group reached a consensus on.  That this would ultimately
result in default_FOO_interface dropping from the hardware_type and
only being present as global configuration option for an operator to
use if they so choose to do so.  This seems in-line with what the
group reached while on the call yesterday.

Conceptually, this leaves us with something that looks like the
following when nodes are created without a valid FOO_interface in the
initial API post.

1. The hardware_type's supported_FOO_interfaces is in order of
preference by the vendor, for example: supported_FOO_interface = [BAR,
CAR, DAR] this represents: if BAR enabled then use BAR else if CAR
enabled then use CAR else if DAR enabled then use DAR.

2. possible_FOO_interfaces to use for a hardware_type are calculated
by intersecting enabled_FOO_interfaces and the hardware_type's
supported_FOO_interfaces, order as in supported_FOO_interface is
maintained.

3. If configuration option default_FOO_interface is set AND
default_FOO_interface is in possible_FOO_interfaces THEN
node.FOO_interface is set to default_FOO_interface

4. If configuration option default_FOO_interface is set AND
default_FOO_interface is NOT in possible_FOO_interfaces THEN node
create fails

5. If configuration option default_FOO_interface is NOT set THEN
node.FOO_interface is set to the first interface in
possible_FOO_interface

Thank you Sam for typing out the above logic.  I think this means we
seem to have some consensus on the direction to move forward, at least
I hope. :)

-Julia

[0] http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/099257.html

On Mon, Aug 8, 2016 at 8:51 AM, Julia Kreger
<juliaashleykreger at gmail.com<mailto:juliaashleykreger at gmail.com>> wrote:
Thank you for sending the corrected link Mathieu!  I thought I fixed it
before I sent the email, but... *shrug*

Anyway!  Looking at the doodle, the mutually available time is 4 PM UTC on
this Wednesday (8/10/16).  If there are no objections, I guess we will hear
those seeking to discuss defaults on conferencing[0] bridge number 7777 at
that time.

-Julia

[0] https://wiki.openstack.org/wiki/Infrastructure/Conferencing

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160815/65aeefd9/attachment-0001.html>