Open Stack

> 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
with the network interface being environment- (binding a node to a
particular Switch type) rather than HW-dependent, I've got an impression it
is directed a bit against the driver composition spec in these two points:

* "Make vendors in charge of defining a set of supported interface
implementations and the default implementation to be used." [1]
* "The list of hardware interfaces is still hardcoded in the Python code
and cannot be extended by plugins."[2]

Therefore having network_interface part of hardware_type might effectively
prevent competition  (mixing and matching switches with nodes) if HW vendor
X decides to blacklist Switch vendor Y by not including Y's Switches in
X.supported_network_interfaces list.

Moreover if the default-interface logic is "For *hardware types* setting
<interface_name>_interface field to None means using the *vendor* default
defined in the *hardware type*. If the *vendor* default is None, the
interface will be disabled."[3] the HW vendor will have difficulties to
express they don't care what switch their node is supposed to be connected
to; should they list all possible switch vendors from within the tree in
supported_network_interfaces? What about out of tree vendors? Wouldn't this
lead to the driver naming the driver reform spec is supposed to prevent
(e.g  to have X_node_Y_switch, X_node_Z_switch in enabled_hardware_types)?

I'd therefore suggest against network_interface being part of the
hardware_type.

Cheers,
milan

[1] section "With this spec we are going to achieve the following goals:"
first bullet,
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#introduction
[2] second bullet in the list:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#configuration
[3] second bullet in the list:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/driver-composition-reform.html#database-and-rest-api


út 12. 7. 2016 v 18:58 odesílatel Loo, Ruby <ruby.loo at intel.com> napsal:

> 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> 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?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
>
>
>
>
>
>
>
> __________________________________________________________________________
>
> 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/20160713/585269ec/attachment.html>