Open Stack

Thanks Devananda and Dmitry and Sam!

From my point of view, I wanted to make sure that:

1. we agreed on  whether the 'network_interface' was, or was not, an interface that was similar to the existing power, deploy, ... interfaces so that it fit into the driver composition work
2. we agreed on having or not having the default_network_interface configuration option, and whether/how it fit into the driver composition work.

I think, because I haven't heard anyone disagree (yet), that the network_interface fits into the driver composition work and that we want the configuration option. It looks like we are trying to figure out *how* it fits into the driver composition work and hardware_types. To that end, I thought I'd put up a patch [1] that I hope captures everyone's suggestions. Maybe we can move to that patch to comment.

As far as the multi-tenant networking patches [2] go, as long as we're good with the above, I think we're good to continue. The details wrt how the network_interface and default configuration option is integrated with hardware_types can be worked out.

If you think otherwise, please let me know :)

--ruby

[1] https://review.openstack.org/#/c/341084/

[2] https://review.openstack.org/#/c/285852/


On 2016-07-12, 8:02 AM, "Dmitry Tantsur" <dtantsur at redhat.com<mailto:dtantsur at redhat.com>> wrote:

Thanks for writing this up, minor comments inline.

On 07/11/2016 10:57 PM, Devananda van der Veen 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.


<snip>


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 need supported_network_interfaces, otherwise you won't be able to
check compatibility. I think we should introduce a constant to use like
that:

  class MyHwType:
    supported_network_interfaces = ironic.network.ALL_INTERFACES

- 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

How do we distinguish between interfaces which have a default and which
don't? For example, I can see a use case for having defaults for deploy
and inspect (the latter would be used by tripleo for sure).

- 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

s/supported/default/ here?

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<mailto: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<mailto: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<mailto: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/20160712/e0ec740d/attachment.html>