Open Stack

On Fri, Jul 17, 2015 at 10:43:37AM -0700, Jim Rollenhagen 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.

[0] https://github.com/rackerlabs/ironic-neutron-plugin

// jim

> 
> // 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