On Sat, Jul 18, 2015 at 08:39:23PM +0800, Sam Stoelinga wrote: > +1 on Kevin Benton's comments. > Ironic should have integration with switches where the switches are SDN > compatible. The individual bare metal node should not care which vlan, > vxlan or other translation is programmed at the switch. The individual bare > metal nodes just knows I have 2 nics and and these are on Neutron network > x. The SDN controller is responsible for making sure the baremetal node > only has access to Neutron Network x through changing the switch > configuration dynamically. > > Making an individual baremetal have access to several vlans and let the > baremetal node configure a vlan tag at the baremetal node itself is a big > security risk and should not be supported. Unless an operator specifically > configures a baremetal node to be vlan trunk.
Right, trunking is the main use case here, and I think we should support it. :) To be clear, I'm not advocating that we always send the VLAN to the instance. I agree that this patch isn't the right way to do it. But I do think we need to consider that there are cases where we do need to expose the VLAN, and we should support this. For a little background, this patch came from code that is running in production today, where we're trunking two VLANs down to the host -- it isn't a theoretical use case. // jim > > Sam Stoelinga > > On Sat, Jul 18, 2015 at 5:10 AM, Kevin Benton <[email protected]> wrote: > > > > which requires VLAN info to be pushed to the host. I keep hearing "bare > > metal will never need to know about VLANs" so I want to quash that ASAP. > > > > That's leaking implementation details though if the bare metal host only > > needs to be on one network. It also creates a security risk if the bare > > metal node is untrusted. > > > > If the tagging is to make it so it can access multiple networks, then that > > makes sense for now but it should ultimately be replaced by the vlan trunk > > ports extension being worked on this cycle that decouples the underlying > > network transport from what gets tagged to the VM/bare metal. > > On Jul 17, 2015 11:47 AM, "Jim Rollenhagen" <[email protected]> > > wrote: > > > >> On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote: > >> > Check out my comments on the review. Only Neutron knows whether or not > >> an > >> > instance needs to do manual tagging based on the plugin/driver loaded. > >> > > >> > For example, Ironic/bare metal ports can be bound by neutron with a > >> correct > >> > driver so they shouldn't get the VLAN information at the instance level > >> in > >> > those cases. Nova has no way to know whether Neutron is configured this > >> way > >> > so Neutron should have an explicit response in the port binding > >> information > >> > indicating that an instance needs to tag. > >> > >> Agree. However, I just want to point out that there are neutron drivers > >> that exist today[0] that support bonded NICs with trunked VLANs, which > >> requires VLAN info to be pushed to the host. I keep hearing "bare metal > >> will never need to know about VLANs" so I want to quash that ASAP. > >> > >> As far as Neutron sending the flag to decide whether the instance should > >> tag packets, +1, I think that should work. > >> > >> // jim > >> > > >> > On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen < > >> [email protected]> > >> > wrote: > >> > > >> > > On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote: > >> > > > On 17 July 2015 at 11:23, Sean Dague <[email protected]> wrote: > >> > > > > On 07/16/2015 06:06 PM, Sean M. Collins wrote: > >> > > > >> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote: > >> > > > >>> So it looks like there is a missing part in this feature. There > >> > > should > >> > > > >>> be a way to "hide" this information if the instance does not > >> require > >> > > to > >> > > > >>> configure vlan interfaces to make network functional. > >> > > > >> > >> > > > >> I just commented on the review, but the provider network API > >> extension > >> > > > >> is admin only, most likely for the reasons that I think someone > >> has > >> > > > >> already mentioned, that it exposes details of the phyiscal > >> network > >> > > > >> layout that should not be exposed to tenants. > >> > > > > > >> > > > > So, clearly, under some circumstances the network operator wants > >> to > >> > > > > expose this information, because there was the request for that > >> > > feature. > >> > > > > The question in my mind is what circumstances are those, and what > >> > > > > additional information needs to be provided here. > >> > > > > > >> > > > > There is always a balance between the private cloud case which > >> wants to > >> > > > > enable more self service from users (and where the users are > >> often also > >> > > > > the operators), and the public cloud case where the users are > >> outsiders > >> > > > > and we want to hide as much as possible from them. > >> > > > > > >> > > > > For instance, would an additional attribute on a provider network > >> that > >> > > > > says "this is cool to tell people about" be an acceptable > >> approach? Is > >> > > > > there some other creative way to tell our infrastructure that > >> these > >> > > > > artifacts are meant to be exposed in this installation? > >> > > > > > >> > > > > Just kicking around ideas, because I know a pile of gate hardware > >> for > >> > > > > everyone to use is at the other side of answers to these > >> questions. And > >> > > > > given that we've been running full capacity for days now, keeping > >> this > >> > > > > ball moving forward would be great. > >> > > > > >> > > > Maybe we just need to add policy around who gets to see that extra > >> > > > detail, and maybe hide it by default? > >> > > > > >> > > > Would that deal with the concerns here? > >> > > > >> > > I'm not so sure. There are certain Neutron plugins that work with > >> > > certain virt drivers (Ironic) that require this information to be > >> passed > >> > > to all instances built by that virt driver. However, it doesn't (and > >> > > probably shouldn't, as to not confuse cloud-init/etc) need to be > >> passed > >> > > to other instances. I think the conditional for passing this as > >> metadata > >> > > is going to need to be some combination of operator config, Neutron > >> > > config/driver, and virt driver. > >> > > > >> > > I know we don't like networking things to be conditional on the virt > >> > > driver, but Ironic is working on feature parity with virt for > >> > > networking, and baremetal networking is vastly different than virt > >> > > networking. I think we're going to have to accept that. > >> > > > >> > > // jim > >> > > > >> > > > > >> > > > Thanks, > >> > > > John > >> > > > > >> > > > > >> > > > >> __________________________________________________________________________ > >> > > > 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 > >> > > > >> > > >> > > >> > > >> > -- > >> > Kevin Benton > >> > >> > > >> __________________________________________________________________________ > >> > 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
