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" <juliaashleykre...@gmail.com<mailto:juliaashleykre...@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 <juliaashleykre...@gmail.com<mailto: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<mailto: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
