The floating ip only on external netwoks thing has always been a little odd to
me...
Floating ip's are very important to ensure a user can switch out one instance
with another and keep 'state' consistent (the other piece being cinder
volumes). But why can't you do this on a provider network? It really is the
same thing. You can force the fixed ip to whatever you want, but its a
completely different mechanism.
On the subject of, we don't need the rest of user defined networking, just
provider networks, I'd add this:
One of the things I see long term as beneficial that cloud will provide is a
catalog of open source "cloud applications". As a user, you go to the catalog,
search for... trac for example, and hit launch. easy, done...
As a developer of such templates, its a real pain to have to deal with neutron
networking vs nova networking, let alone the many different ways of configuring
neutron. On top of that, one of the great features of NaaS is that you can push
isolation to the network layer and not have to deal so much with
authentication. Take ElasticSearch for example. It has no concept of
authentication since is a backend service. You put it on its own network that
only the webservers can get to. But that means you can't write a template that
will work on anything but proper NaaS securely.
So, short term, your not wanting to deal with the "complication" of a more
featureful neutron, but your really just pushing the complication to the cloud
users/app developers, slowing down development of cloud apps, and therefore
your users experience is diminished since their selection of apps is restricted
with all sorts of caviots. "This application works only if your service
provider setup up NaaS". Really, the way I see it, its the cloud admin's job to
deal with complication so that the end users don't have to. Its one of the
things that makes being a cloud user so great. A few skilled cloud admins can
make it possible for many many less experienced folks to do amazing things on
top. The cloud and cloud amdin hides all the complexity from the user.
Lets reduce the fragmentation as much as we can here. it will actually make the
app ecosystem and user experience much better in the long run.
Thanks,
Kevin
________________________________________
From: Sean Dague [s...@dague.net]
Sent: Friday, March 27, 2015 4:11 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to
Neutron migration work
On 03/27/2015 05:22 AM, Thierry Carrez wrote:
<snip>
> Part of it is corner (or simplified) use cases not being optimally
> served by Neutron, and I think Neutron could more aggressively address
> those. But the other part is ignorance and convenience: that Neutron
> thing is a scary beast, last time I looked into it I couldn't make sense
> of it, and nova-network just works for me.
>
> That is why during the Ops Summit we discussed coming up with a
> migration guide that would explain the various ways you can use Neutron
> to cover nova-network use cases, demystify a few dark areas, and outline
> the step-by-step manual process you can go through to migrate from one
> to the other.
>
> We found a dev/ops volunteer for writing that migration guide but he was
> unfortunately not allowed to spend time on this. I heard we have new
> volunteers, but I'll let them announce what their plans are, rather than
> put words in their mouth.
>
> This migration guide can happen even if we follow the nova-net spinout
> plan (for the few who want to migrate to Neutron), so this is a
> complementary solution rather than an alternative. Personally I doubt
> there would suddenly be enough people interested in nova-net development
> to successfully spin it out and maintain it. I also agree with Russell
> that long-term fragmentation at this layer of the stack is generally not
> desirable.
I think if you boil everything down, you end up with 3 really important
differences.
1) neutron is a fleet of services (it's very micro service) and every
service requires multiple and different config files. Just configuring
the fleet is a beast if it not devstack (and even if it is)
2) neutron assumes a primary interesting thing to you is tenant secured
self service networks. This is actually explicitly not interesting to a
lot of deploys for policy, security, political reasons/restrictions.
3) neutron open source backend defaults to OVS (largely because #2). OVS
is it's own complicated engine that you need to learn to debug. While
Linux bridge has challenges, it's also something that anyone who's
worked with Linux & Virtualization for the last 10 years has some
experience with.
(also, the devstack setup code for neutron is a rats nest, as it was
mostly not paid attention to. This means it's been 0 help in explaining
anything to people trying to do neutron. For better or worse devstack is
our executable manual for a lot of these things)
so.... that being said, I think we need to talk about "minimum viable
neutron" as a model and figure out how far away that is from n-net. This
week at the QA Sprint, Dean, Sean Collins, and I have spent some time
hashing it out, hopefully with something to show the end of the week.
This will be the new devstack code for neutron (the old lib/neutron is
moved to lib/neutron-legacy).
Default setup will be provider networks (which means no tenant
isolation). For that you should only need neutron-api, -dhcp, and -l2.
So #1 is made a bunch better. #2 not a thing at all. And for #3 we'd
like to revert back to linux bridge for the base case (though first code
will probably be OVS because that's the happy path today).
Mixin #1: NEUTRON_BRIDGE_WITH=OVS
First optional layer being flip from linuxbridge -> ovs. That becomes
one bite sized thing to flip over once you understand it.
Mixin #2: self service networks
This will be off in the default case, but can be enabled later.
... and turtles all the way up.
Provider networks w/ Linux bridge are really close to the simplicity on
the wire people expected with n-net. The only last really difference is
floating ips. And the problem here was best captured by Sean Collins on
Wed, Floating ips in nova are overloaded. They are both elastic ips, but
they are also how you get public addresses in a default environment.
Dean shared that that dual purpose is entirely due to constraints of the
first NASA cloud which only had a /26 of routable IPs. In neutron this
is just different, you don't need floating ips to have public addresses.
But the mental model has stuck.
Anyway, while I'm not sure this is going to solve everyone's issues, I
think it's a useful exercise anyway for devstack's neutron support to
revert to a minimum viable neutron for learning purposes, and let you
layer on complexity manually over time. And I'd be really curious if a
n-net -> provider network side step (still on linux bridge) would
actually be a more reasonable transition for most environments.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
