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