Re: [openstack-dev] [ironic] Driver composition defaults call

[Devananda van der Veen]

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
>  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 

Re: [openstack-dev] [ironic] Driver composition defaults call

[Loo, Ruby]

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" 
> 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
> 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  at
that time.

-Julia

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

Re: [openstack-dev] [ironic] Driver composition defaults call

[Julia Kreger]

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
 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  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

Re: [openstack-dev] [ironic] Driver composition defaults call

[Julia Kreger]

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  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

Re: [openstack-dev] [ironic] Driver composition defaults call

[Mathieu Mitchell]

On 2016-08-01 3:25 PM, Julia Kreger wrote:

Greetings!

As discussed in our meeting today[0], we would like to try and schedule a
time for a VoIP call so we can discuss driver composition[1] defaults with
the goal of reaching a consensus on defaults.


Reading a January meeting log surprised me, so here's the right link: 
http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-08-01-17.00.log.html



Mathieu

__
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-dev] [ironic] Driver composition defaults call

[Julia Kreger]

Greetings!

As discussed in our meeting today[0], we would like to try and schedule a
time for a VoIP call so we can discuss driver composition[1] defaults with
the goal of reaching a consensus on defaults.

Given that there are several facets, and multiple people in multiple
timezones who need to be included, I've proposed times from 2 PM to 5 PM
GMT on August 9th, 10th, or 11th. The link to the doodle poll is below[2].

If none of the times work, please let me know and I'll gladly update the
poll.

-Julia

[0]
http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-01-04-17.00.log.html
[1]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html
[2] http://doodle.com/poll/ayga9ppc6d2mrd9n
__
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