Open Stack

IMHO, the non-subnet port can be created in the technique.
This is quite useful especially when there is some special appliance, e.g.,
some firewall appliance without any IP necessarily.


On Tue, Jul 15, 2014 at 1:18 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/a14008b0/attachment.html>