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