Open Stack

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 <openstack at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140714/14126d96/attachment.html>