Open Stack

Thanks for following up with this Devananda, I¹ve left a couple of
corrections to my proposal inline, unfortunately IRC isn¹t the best for
putting ideas this complex across :)

Sam

On 11/07/2016 21:57, "Devananda van der Veen" <devananda.vdv at gmail.com>
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.
>
>
>Background:
>
>- As proposed in the driver composition reform spec [2], each
>hardware_type
>class (eg, ilo_gen8) shall specify a set of allowable interface
>implementations
>(eg, noop, flat, neutron are all network_interfaces) for each interface
>type
>(eg, deploy_interface, power_interface, network_interface).
>- A hardware_type shall also indicate a default for each interface_type.
>(**
>this is what we debated ** )
>- There is no CONF option to specify a global default for each
>interface_type
>(eg, there is no CONF.default_power_interface setting, because it varies
>by
>hardware_type)
>- There will be a CONF option to enable ("allow") hardware classes and
>CONF
>options to enable ("allow") interface classes.
>
>
>Points raised in the meeting today:
>
>- in "most" cases, network_interface will depend more on the environment
>than a
>specific Node's hardware or out-of-band management device
>
>- in "exceptional" cases, a Node may only support specific
>network_interfaces
>(eg, certain Cisco hardware, a Blade enclosure)
>
>- maybe hardware_type should specify a default for some interfaces but not
>others? Example:
>  - the ilo_gen8 hardware class should specify power, deploy, and
>management
>interface defaults to ilo-specific interface classes
>  - but the operator should set the network interface as appropriate to
>their
>environment
>
>- if we were to force the operator to specify Node.network_interface (but
>not
>any other interface) when enrolling every node, this will be apoor
>experience.
>
>- we should add a global CONF setting to allow operators to set a default
>network interface for their environment.
>
>- words are hard. we shouldn't call network_interface an "interface" if it
>behaves differently than other interfaces.
>
>- we have two "types" of interfaces on drivers: hardware-types and
>environment-types. maybe we should treat them differently?
>
>- other things also depend on the environment (rather than the Node's
>hardware
>or BMC) such as deploy_interface and volume_interface.
>
>
>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

Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in
the meeting. In-tree hardware_types will list support for
network_interfaces according to their vendor¹s preference (I expect for
most/all drivers that will at least be [noop, flat, neutron]). And if in
the future as a vendor I want to, for example, push my hardware specific
network interface in tree, then my Cisco drivers will gain an additional
network_interface in their supported_network_interfaces list, [noop, flat,
neutron, cisco].

>- 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
>- if a(n out of tree) hardware_type declares a default_network_interface,
>this
>will take precedence over the CONF option

I believe that all hardware_types should specify their supported network
interfaces, but none should specify a default network interface, because
there is no way to define a sane default in the hardware_type without
knowing what environment its being deployed into.

>- a node created without specifying a network interface will check the
>hardware_type's supported_network_interfaces, and when that is empty,
>fall back
>to the CONF.default_network_interface, just as other interfaces fall back
>to the
>hardware_type's relevant default

A node created without specifying a specific network interface will get
the default specified by the CONF option, which we know is supported by
that hardware_type because of the validation on conductor start. Nodes
created with a network_interface specified work with the usual rules as
you've specified below.

>- 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.0
>0.log.html
>
>[2]
>http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-co
>mposition-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
>