Open Stack

Thanks for writing this up, minor comments inline.

On 07/11/2016 10:57 PM, Devananda van der Veen wrote:
> We spent the majority of today's weekly IRC meeting [1] discussing the finer
> points of this question. I agreed to post a summary of those to the list (it's
> below the break).
>
> tldr;
>
> * we don't know if network_interface should behave like other hardware
> interfaces, but...
> * we need to come to an agreement on it this week, so we can proceed with the
> network integration work.
>
>
<snip>
>
>
> There was a proposal from sambetts towards the end of the meeting, which I've
> edited for clarity (please correct if I misunderstood any of your points). This
> seems to capture/address most of the points above and proposes a way forward,
> while keeping within the intent of our driver composition reform spec. It was
> the only clear suggestion during the meeting.
>
> - in-tree hardware_types declare supported_network_interfaces to be empty [4]
> and declare no default_network_interface

We need supported_network_interfaces, otherwise you won't be able to 
check compatibility. I think we should introduce a constant to use like 
that:

  class MyHwType:
    supported_network_interfaces = ironic.network.ALL_INTERFACES

> - we add a CONF option for default_network_interface, with a sane default value
> - this CONF option is validated on conductor load to be supported by all loaded
> hardware_types, and the conductor refuses to start if this CONF option is set to
> a value not supported by one or more enabled_hardware_types

How do we distinguish between interfaces which have a default and which 
don't? For example, I can see a use case for having defaults for deploy 
and inspect (the latter would be used by tripleo for sure).

> - if a(n out of tree) hardware_type declares a default_network_interface, this
> will take precedence over the CONF option
> - a node created without specifying a network interface will check the
> hardware_type's supported_network_interfaces, and when that is empty, fall back

s/supported/default/ here?

> to the CONF.default_network_interface, just as other interfaces fall back to the
> hardware_type's relevant default
> - operators can override a specific node's network_interface, which follows the
> usual rules for setting an interface on a Node (ie, the interface must be in
> hardware_type.supported_network_interfaces AND in CONF.enabled_network_interfaces)
>
>
> If anyone else has other clear suggestions that address all the issues here,
> please reply with them.
>
> I'm going to make myself available tomorrow at 1700 UTC, in both IRC and by
> voice [3] (conference line # TBD) to discuss this with anyone. If we need to
> discuss it again on Wednesday, we can.
>
>
> Thanks much,
> --devananda
>
>
>
> [1] starting at 17:20
>
> http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-07-11-17.00.log.html
>
> [2]
> http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html
>
> [3] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>
> [4] I think we may need to have in-tree drivers declare
> supported_network_interfaces to be [noop, flat, neutron], but that is not what
> Sam suggested during the meeting
>
>
>
> On 06/28/2016 08:32 AM, Dmitry Tantsur wrote:
>> Hi folks!
>>
>> I was reviewing https://review.openstack.org/317391 and realized I don't quite
>> understand why we want to have node.network_interface. What's the real life use
>> case for it?
>>
>> Do we expect some nodes to use Neutron, some - not?
>>
>> Do we expect some nodes to benefit from network separation, some - not? There
>> may be a use case here, but then we have to expose this field to Nova for
>> scheduling, so that users can request a "secure" node or a "less secure" one. If
>> we don't do that, Nova will pick at random, which makes the use case unclear again.
>> If we do that, the whole work goes substantially beyond what we were trying to
>> do initially: isolate tenants from the provisioning network and from each other.
>>
>> Flexibility it good, but the patches raise upgrade concerns, because it's
>> unclear how to provide a good default for the new field. And anyway it makes the
>> whole thing much more complex than it could be.
>>
>> Any hints are welcome.
>>
>> __________________________________________________________________________
>> 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
>
>
>
> __________________________________________________________________________
> 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
>