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" <[email protected]> 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: >>[email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
