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 - 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 - 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 - 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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