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