Open Stack

Hi Devananda,

This is a good summary. I think the proposal makes a lot of sense.

We need to agree to this as soon as possible so that we can get the Ironic
patches merged by this Friday - to meet the timelines.

Can you set up the number for the voice call so that we can all dial in,
discuss, if further discussion is needed, and get this closed off.
Ideally, we can work to approve/modify the patches while we are all on the
call.

thoughts?

-Sukhdev


On Mon, Jul 11, 2016 at 3:03 PM, Sam Betts (sambetts) <sambetts at cisco.com>
wrote:

> 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
> >
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160711/c44bb87a/attachment.html>