<div dir="ltr">IMHO, the non-subnet port can be created in the technique.<div style>This is quite useful especially when there is some special appliance, e.g., some firewall appliance without any IP necessarily.</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 1:18 AM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Funnily enough, when I first reported this bug I was actually trying to run Openstack in VMs on Openstack. This works better now (not well; just better) in that there's L3 networking options, but the basic L2-VLAN networking option has never worked (fascinating we can't eat our own dogfood on this).<br>
<br></div>Brent, to answer your point: networks with subnets don't work, and the reason they don't work is ports with 0 addresses don't work. I've been thinking about this a long time, and there's two things here:<br>
<br></div>- we want ports without addresses (specifically: without antispoof; actually, it makes reasonable sense to leave security groups on) to work<br></div>- when people set up a network with no subnet, 99.99% of the time they do it it's an accident - and booting a machine on that network with no address and no firewalling is almost certainly not a helpful thing to be doing.<br>
<br></div>In summary, I think we need a way to make no-subnet cases work (and, for what it's worth, the unaddressed interface blueprint in there changed tack, it's more about firewalling now for almost exactly that reason), I think it's reasonable to put one hurdle between the advanced user and their intent to avoid shooting the common user in the foot. I would suggest that we want port-no-address cases to work when someone has explicitly disabled the antispoof on the port - and not otherwise. This works with portsecurity right now. <br>
<br>My beef with the portsecurity BP is that it targets OVS - this is no use for NFV people, because OVS plugins don't work with VLAN tags) and it assumes that security groups and antispoof are related when they aren't, which is a fundamental issue of portsecurity and makes it annoying to use. It's also annoying when you get portsecurity errors when it's not even enabled, but I think we got past that point ;)<span class="HOEnZb"><font color="#888888"><br>
-- <br></font></span></div><span class="HOEnZb"><font color="#888888">Ian.<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 July 2014 15:36, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, I believe TripleO will need this if we're going to be able to do<br>
<a href="https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack" target="_blank">https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack</a><br>
<br>
Being able to have instances without IPs assigned is basically required<br>
for that.<br>
<span><font color="#888888"><br>
-Ben<br>
</font></span><div><div><br>
On 07/11/2014 04:41 PM, Brent Eagles wrote:<br>
> Hi,<br>
><br>
> A bug titled "Creating quantum L2 networks (without subnets) doesn't<br>
> work as expected" (<a href="https://bugs.launchpad.net/nova/+bug/1039665" target="_blank">https://bugs.launchpad.net/nova/+bug/1039665</a>) was<br>
> reported quite some time ago. Beyond the discussion in the bug report,<br>
> there have been related bugs reported a few times.<br>
><br>
> * <a href="https://bugs.launchpad.net/nova/+bug/1304409" target="_blank">https://bugs.launchpad.net/nova/+bug/1304409</a><br>
> * <a href="https://bugs.launchpad.net/nova/+bug/1252410" target="_blank">https://bugs.launchpad.net/nova/+bug/1252410</a><br>
> * <a href="https://bugs.launchpad.net/nova/+bug/1237711" target="_blank">https://bugs.launchpad.net/nova/+bug/1237711</a><br>
> * <a href="https://bugs.launchpad.net/nova/+bug/1311731" target="_blank">https://bugs.launchpad.net/nova/+bug/1311731</a><br>
> * <a href="https://bugs.launchpad.net/nova/+bug/1043827" target="_blank">https://bugs.launchpad.net/nova/+bug/1043827</a><br>
><br>
> BZs on this subject seem to have a hard time surviving. The get marked<br>
> as incomplete or invalid, or in the related issues, the problem NOT<br>
> related to the feature is addressed and the bug closed. We seem to dance<br>
> around actually getting around to implementing this. The multiple<br>
> reports show there *is* interest in this functionality but at the moment<br>
> we are without an actual implementation.<br>
><br>
> At the moment there are multiple related blueprints:<br>
><br>
> * <a href="https://review.openstack.org/#/c/99873/" target="_blank">https://review.openstack.org/#/c/99873/</a> ML2 OVS: portsecurity<br>
> extension support<br>
> * <a href="https://review.openstack.org/#/c/106222/" target="_blank">https://review.openstack.org/#/c/106222/</a> Add Port Security<br>
> Implementation in ML2 Plugin<br>
> * <a href="https://review.openstack.org/#/c/97715" target="_blank">https://review.openstack.org/#/c/97715</a> NFV unaddressed interfaces<br>
><br>
> The first two blueprints, besides appearing to be very similar, propose<br>
> implementing the "port security" extension currently employed by one of<br>
> the neutron plugins. It is related to this issue as it allows a port to<br>
> be configured indicating it does not want security groups to apply. This<br>
> is relevant because without an address, a security group cannot be<br>
> applied and this is treated as an error. Being able to specify<br>
> "skipping" the security group criteria gets us a port on the network<br>
> without an address, which is what happens when there is no subnet.<br>
><br>
> The third approach is, on the face of it, related in that it proposes an<br>
> interface without an address. However, on review it seems that the<br>
> intent is not necessarily inline with the some of the BZs mentioned<br>
> above. Indeed there is text that seems to pretty clearly state that it<br>
> is not intended to cover the port-without-an-IP situation. As an aside,<br>
> the title in the commit message in the review could use revising.<br>
><br>
> In order to implement something that finally implements the<br>
> functionality alluded to in the above BZs in Juno, we need to settle on<br>
> a blueprint and direction. Barring the happy possiblity of a resolution<br>
> beforehand, can this be made an agenda item in the next Nova and/or<br>
> Neutron meetings?<br>
><br>
> Cheers,<br>
><br>
> Brent<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#999999">Best wishes!<br>Baohua<br></font>
</div>