Open Stack

While I have a partisan preference for OVS, my vote is that until Neutron's
built-in network virtualisation suite (if we can it this way) supports both
linux bridge and open vswitch, both should be given equal coverage in gate
tests - and this is something we do not do currently.

I understand however default values are important because they will
determine the technology users will get if they just try and run devstack.
I think this is a non-issue too, but because of my partisan preference I
would like to default to OVS. Attila also makes some points that in my
opinion weigh more thatn Jens' counterargument - mostly because this
"complexity" will be handled by devstack and is going to be totally
transparent to the final user.
I believe devstack users will read at least the README files where they'll
learn how to enable OVS or LinuxBridge.

More inline.

Salvatore

On 10 April 2015 at 12:29, Attila Fazekas <afazekas at redhat.com> wrote:

>
>
>
>
> ----- Original Message -----
> > From: "Jens Rosenboom" <j.rosenboom at x-ion.de>
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> > Sent: Friday, April 10, 2015 10:18:38 AM
> > Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default
> in DevStack [was: Status of the nova-network
> > to Neutron migration work]
> >
> > 2015-04-10 9:05 GMT+02:00 Attila Fazekas < afazekas at redhat.com > :
> >
> >
> > Hi,
> >
> > I do not recommend Linux bridge as default for devstack.
> >
> > I think most developer does not have a switch configured with trunk
> ports,
> > or tricks for faking it in a visualized environment.
>

Back in the olden days before neutron, I had indeed to use on of those
cheap 30€ switches that do not even know what a tag is...


> >
> >
> > ​I would argue this to be a non issue. Most developers will only run
> single
> > node setups anyway.
> > If they setup multiple nodes connected with a switch that happens not to
> be
> > VLAN aware, it will
> > most likely still be VLAN transparent at the same time, so things still
> will
> > just work. This
> > also includes the propably most common case of multiple qemu instances
> > connected via a Linuxbridge
> > device on the host.
>

I'm not sure what case you're referring to here. Nested virtualization
where a bridge on the host acts as your physical bridge?

>
> It is for untagged traffic only.
>
> >
> >
> > I think adding some basic mtu and nat trick to devstack,
> > would make simpler to use the ml2/ovs/vxaln network
> > for devs who are not really familiar with networking.
> >
> >
> > ​IMHO "adding ... trick" and "​make simpler" is incompatible with each
> other.
> >
>
> The original complain was against single node, the vms does not sees the
> outside network.
> This can be solved just by a masquerade iptables rule.
>

I often configured such NAT rule myself, and patched devstack my local
devstack repo to add them.
However, I did not find these rules very useful for running gate tests, as
outbound connectivity was not required.
I do not recall exactly the reasons behind the original complains, but I
seem to recall the complain was about allowing users to spin up an
environment where instances would have internet connectivity with the
default configuration.
Since Neutron allocates IPs from the external network for router gateway
ports, without the masquerade rule mentioned by Attila this would require
the user to be in control of IP addressing on that network - which is often
untrue especially in corporate environments.


> For multi-node MTU https://review.openstack.org/#/c/112523/,
> with single node you do not really care.
>

>
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150410/62e665aa/attachment.html>