Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160711/a7d8512e/attachment.pgp>