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" <vd...@mirantis.com
<mailto:vd...@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
<mmitch...@internap.com <mailto:mmitch...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
