Open Stack

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 <blak111 at gmail.com> 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" <jim at jimrollenhagen.com>
> > 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 <
> >> jim at jimrollenhagen.com>
> >> > wrote:
> >> >
> >> > > On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote:
> >> > > > On 17 July 2015 at 11:23, Sean Dague <sean at dague.net> 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:
> >> > > 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
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Kevin Benton
> >>
> >> >
> >> __________________________________________________________________________
> >> > 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