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).
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: - we want ports without addresses (specifically: without antispoof; actually, it makes reasonable sense to leave security groups on) to work - 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. 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. 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 ;) -- Ian. On 11 July 2014 15:36, Ben Nemec <openst...@nemebean.com> wrote: > FWIW, I believe TripleO will need this if we're going to be able to do > https://blueprints.launchpad.net/tripleo/+spec/tripleo-on-openstack > > Being able to have instances without IPs assigned is basically required > for that. > > -Ben > > On 07/11/2014 04:41 PM, Brent Eagles wrote: > > Hi, > > > > A bug titled "Creating quantum L2 networks (without subnets) doesn't > > work as expected" (https://bugs.launchpad.net/nova/+bug/1039665) was > > reported quite some time ago. Beyond the discussion in the bug report, > > there have been related bugs reported a few times. > > > > * https://bugs.launchpad.net/nova/+bug/1304409 > > * https://bugs.launchpad.net/nova/+bug/1252410 > > * https://bugs.launchpad.net/nova/+bug/1237711 > > * https://bugs.launchpad.net/nova/+bug/1311731 > > * https://bugs.launchpad.net/nova/+bug/1043827 > > > > BZs on this subject seem to have a hard time surviving. The get marked > > as incomplete or invalid, or in the related issues, the problem NOT > > related to the feature is addressed and the bug closed. We seem to dance > > around actually getting around to implementing this. The multiple > > reports show there *is* interest in this functionality but at the moment > > we are without an actual implementation. > > > > At the moment there are multiple related blueprints: > > > > * https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity > > extension support > > * https://review.openstack.org/#/c/106222/ Add Port Security > > Implementation in ML2 Plugin > > * https://review.openstack.org/#/c/97715 NFV unaddressed interfaces > > > > The first two blueprints, besides appearing to be very similar, propose > > implementing the "port security" extension currently employed by one of > > the neutron plugins. It is related to this issue as it allows a port to > > be configured indicating it does not want security groups to apply. This > > is relevant because without an address, a security group cannot be > > applied and this is treated as an error. Being able to specify > > "skipping" the security group criteria gets us a port on the network > > without an address, which is what happens when there is no subnet. > > > > The third approach is, on the face of it, related in that it proposes an > > interface without an address. However, on review it seems that the > > intent is not necessarily inline with the some of the BZs mentioned > > above. Indeed there is text that seems to pretty clearly state that it > > is not intended to cover the port-without-an-IP situation. As an aside, > > the title in the commit message in the review could use revising. > > > > In order to implement something that finally implements the > > functionality alluded to in the above BZs in Juno, we need to settle on > > a blueprint and direction. Barring the happy possiblity of a resolution > > beforehand, can this be made an agenda item in the next Nova and/or > > Neutron meetings? > > > > Cheers, > > > > Brent > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
