Open Stack

On 08/11/2016 10:37 AM, Julia Kreger 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
> 

Thanks, Julia, for this excellent summary of the discussion.

This logic appears sound and, I believe, is as simple as possible, while not
unduly limiting operator or vendor choice.

+1

-Deva


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