Open Stack

On 06/29/2016 12:08 PM, Sam Betts (sambetts) wrote:
> My use case is supporting mixed hardware environments with hardware that
> has greater network capabilities and hardware without these capabilities
> without limiting my all my equipment to the lowest common feature set.
> The use case I’m describing will have some nodes configured with the
> neutron multi-tenant driver (generic hardware, smart switch) and some
> nodes configured with a custom neutron multi-tenant+cisco magic network
> driver (cisco hardware, smart switch).
>
> Perhaps a it’ll be clearer to understand why we need the driver in the
> patches if I give a description of the network drivers and why we’re
> adding them, and how I see the the current patches working in an upgrade
> scenario:
>
> *Flat*
> This matches the existing networking implementation in Ironic today, but
> with added validation on conductor start to ensure that Ironic is
> configured correctly (cleaning_network_uuid set) to support this feature.
>
> *None*

Python value None means the default, here we're using a string "none", 
and I suggest using something else to avoid confusion. Maybe "manual"?

> This is what standalone users have been faking by setting the DHCP
> provider to None for a long time. The reason this worked before is
> because DHCP providers did more than just set DHCP options and actually
> started configuring the cleaning network, this job is now superseded by
> the network provider, so we need a true no-op driver for when
> configuring cleaning networks is deprecated out of the DHCP provider
> interface.
>
> *Neutron*
> Multi-tenant neutron network support
>
> The problem I see is that the existing networking behaviour in Ironic is
> implicit and affected by different things (DHCP Provider, cleaning
> enabled/disabled etc, what driver I’ve configured on the node). I
> believe that the upgrade process can be handled in a sane way by doing a
> data migration as part of the upgrade and maintaining awareness about
> what configuration options a user has set and what that means their
> previous configuration actually was, for example:
>
> DHCP Provider: None -> No neutron integration -> Configure existing
> nodes to None to match what they’ve actually been getting because of
> their configuration
> DHCP Provider: Neutron -> Existing neutron integration -> Configure
> existing nodes to Flat to match what they’ve been getting because of
> their configuration
>
> That was the easy part, to make existing nodes continue to work as
> before. Now we have to consider what happens when we create a new node
> in Ironic after we’ve upgraded, and I think that Ironic should behave as
> such:
>
> DHCP Provider: None,  No network interface in request -> Still no
> expressed neutron integration -> Configure node to None because no
> neutron integration expressed
> DHCP Provider: Neutron, No network interface in request -> Basic neutron
> integration implied by DHCP provider -> Configure node to Flat to match
> how Ironic works today
> DHCP Provider: Neutron, network interface in request -> Basic neutron
> integration implied by DHCP provider, but network interface in request
> takes priority -> Configure node to requested network interface
>
> I suggest we maintain this behaviour for at least a cycle to allow for
> people to upgrade and maintain current functionality and then we can
> work out what we want to do with DHCP providers and the default network
> interface configuration.
>
> I personally hate the current DHCP provider concept and once we
> introduce the new network interfaces and deprecate cleaning from the
> existing DHCP providers I believe we should consider the DHCP provider's
> usefulness. We have to maintain the current driver interface as it is
> today for backward compatibility for those who have out of tree DHCP
> providers. But I believe that it is heavily tied to both the network
> interface you pick for a node, and also the PXE boot interface (we do
> not need DHCP options set for virtual media boot for example). I
> personally have been considering whether it should actually be
> configured has part of the driver_info when a node is configured for PXE
> boot or have the logic merged into the network interfaces itself.
>
> Sam
>
> On 28/06/2016 18:28, "Vladyslav Drok" <vdrok at mirantis.com
> <mailto:vdrok at mirantis.com>> wrote:
>
>     Thanks for bringing this up Dmitry, here are my thoughts on this.
>
>     Another case is an out-of-tree network driver, that can basically do
>     whatever an operator needs to, and may have some parameters defined
>     in driver_info as is the case for most of other interfaces ironic
>     drivers have.
>
>     I think neutron and flat drivers coexistence in the same deployment
>     is unlikely, but neutron and none or flat and none seems to be valid
>     case. As for nova, this might be as easy as adding an availability
>     zone with nodes that have network isolation enabled.
>
>     Also, with all the driver composition work, I think we don't want to
>     have some weird things like dhcp providers anymore and go further
>     with interfaces. And if it is an interface, it should be considered
>     as such (the basic spec containing most of the requirements is
>     merged, and we can use it to make network interface as close to the
>     spec as possible, while not going too far, as multitenancy slipping
>     another release would be very bad). There might be some caveats with
>     backwards compatibility in this particular case, but they're all
>     solvable.
>
>     Thanks,
>     Vlad
>
>     On Tue, Jun 28, 2016 at 7:08 PM, Mathieu Mitchell
>     <mmitchell at internap.com <mailto:mmitchell at internap.com>> wrote:
>
>         Following discussion on IRC, here are my thoughts:
>
>         The proposed network_interface allows choosing a "driver" for
>         the network part of a node. The values could be something like
>         "nobody", "neutron-flat networking" and "neutron-tenant separation".
>
>         I think this choice should be left per-node. My reasoning is
>         that you could have a bunch of nodes for which you have complete
>         Neutron support, through for example an ML2 plugin. These nodes
>         would be configured using one of the "neutron-*" modes.
>
>         On the other hand, that same Ironic installation could also
>         manage nodes for which the switches are unmanaged, or manually
>         configured. In such case, you would probably want to use the
>         "nobody" mode.
>
>         An important point is to expose this "capability" to Nova as you
>         might want to offer nodes with neutron integration differently
>         from "any node". I am unsure if the capability should be the
>         value of the network_interface or a boolean "neutron
>         integration?". Thoughts?
>
>         Mathieu
>
>
>         On 2016-06-28 11: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://OpenStack-dev-request@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://OpenStack-dev-request@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
>