<p dir="ltr">Having Nova make assumptions isn't the right way to do this though. To support this I would rather see an ML2 driver that informs Nova to pass tagging info to the instance via the port binding info. Only neutron knows which one is appropriate based on the network configuration. </p>
<div class="gmail_quote">On Jul 20, 2015 1:19 PM, "Devananda van der Veen" <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 18, 2015 at 5:42 AM Sam Stoelinga <<a href="mailto:sammiestoel@gmail.com" target="_blank">sammiestoel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>+1 on Kevin Benton's comments.</div>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.<div><br></div><div>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. </div></div></blockquote><div><br></div><div>I was previously of this opinion, and have changed my mind. </div><div><br></div><div>While I agree that this is true in a multi-tenant case and requires an SDN-capable TOR, there are users (namely, openstack-infra) asking us to support a single tenant with a statically-configured TOR, where cloud-init is used to pass in the (external, unchangeable) VLAN configuration to the bare metal instance.</div><div><br></div><div>-Deva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Unless an operator specifically configures a baremetal node to be vlan trunk.</div></div><div dir="ltr"><div><br></div><div>Sam Stoelinga</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 18, 2015 at 5:10 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><p dir="ltr">> 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.</p>
</span><p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<div class="gmail_quote"><span>On Jul 17, 2015 11:47 AM, "Jim Rollenhagen" <<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>> wrote:<br type="attribution"></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote:<br>
> Check out my comments on the review. Only Neutron knows whether or not an<br>
> instance needs to do manual tagging based on the plugin/driver loaded.<br>
><br>
> For example, Ironic/bare metal ports can be bound by neutron with a correct<br>
> driver so they shouldn't get the VLAN information at the instance level in<br>
> those cases. Nova has no way to know whether Neutron is configured this way<br>
> so Neutron should have an explicit response in the port binding information<br>
> indicating that an instance needs to tag.<br>
<br>
Agree. However, I just want to point out that there are neutron drivers<br>
that exist today[0] that support bonded NICs with trunked VLANs, which<br>
requires VLAN info to be pushed to the host. I keep hearing "bare metal<br>
will never need to know about VLANs" so I want to quash that ASAP.<br>
<br>
As far as Neutron sending the flag to decide whether the instance should<br>
tag packets, +1, I think that should work.<br>
<br>
// jim<br>
><br></span>
> On Fri, Jul 17, 2015 at 9:51 AM, Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>><span><br>
> wrote:<br>
><br>
> > On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote:<br></span><div><div>
> > > On 17 July 2015 at 11:23, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>> wrote:<br>
> > > > On 07/16/2015 06:06 PM, Sean M. Collins wrote:<br>
> > > >> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote:<br>
> > > >>> So it looks like there is a missing part in this feature. There<br>
> > should<br>
> > > >>> be a way to "hide" this information if the instance does not require<br>
> > to<br>
> > > >>> configure vlan interfaces to make network functional.<br>
> > > >><br>
> > > >> I just commented on the review, but the provider network API extension<br>
> > > >> is admin only, most likely for the reasons that I think someone has<br>
> > > >> already mentioned, that it exposes details of the phyiscal network<br>
> > > >> layout that should not be exposed to tenants.<br>
> > > ><br>
> > > > So, clearly, under some circumstances the network operator wants to<br>
> > > > expose this information, because there was the request for that<br>
> > feature.<br>
> > > > The question in my mind is what circumstances are those, and what<br>
> > > > additional information needs to be provided here.<br>
> > > ><br>
> > > > There is always a balance between the private cloud case which wants to<br>
> > > > enable more self service from users (and where the users are often also<br>
> > > > the operators), and the public cloud case where the users are outsiders<br>
> > > > and we want to hide as much as possible from them.<br>
> > > ><br>
> > > > For instance, would an additional attribute on a provider network that<br>
> > > > says "this is cool to tell people about" be an acceptable approach? Is<br>
> > > > there some other creative way to tell our infrastructure that these<br>
> > > > artifacts are meant to be exposed in this installation?<br>
> > > ><br>
> > > > Just kicking around ideas, because I know a pile of gate hardware for<br>
> > > > everyone to use is at the other side of answers to these questions. And<br>
> > > > given that we've been running full capacity for days now, keeping this<br>
> > > > ball moving forward would be great.<br>
> > ><br>
> > > Maybe we just need to add policy around who gets to see that extra<br>
> > > detail, and maybe hide it by default?<br>
> > ><br>
> > > Would that deal with the concerns here?<br>
> ><br>
> > I'm not so sure. There are certain Neutron plugins that work with<br>
> > certain virt drivers (Ironic) that require this information to be passed<br>
> > to all instances built by that virt driver. However, it doesn't (and<br>
> > probably shouldn't, as to not confuse cloud-init/etc) need to be passed<br>
> > to other instances. I think the conditional for passing this as metadata<br>
> > is going to need to be some combination of operator config, Neutron<br>
> > config/driver, and virt driver.<br>
> ><br>
> > I know we don't like networking things to be conditional on the virt<br>
> > driver, but Ironic is working on feature parity with virt for<br>
> > networking, and baremetal networking is vastly different than virt<br>
> > networking. I think we're going to have to accept that.<br>
> ><br>
> > // jim<br>
> ><br>
> > ><br>
> > > Thanks,<br>
> > > John<br>
> > ><br>
> > ><br>
> > __________________________________________________________________________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe:<br></div></div><span>
> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></span>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br></span><span>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></span>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Kevin Benton<br>
<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br></span><span>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></span>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br></span><span>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</span></blockquote></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>