Kevin --
Thanks for your thoughts; this seems possible, if ugly. My original
question remains, though: If there is meant to be an upgrade path from
nova-network (In L, or M, or whenever), what will my use case look like
after migration? Will it be this same setup that you suggest, or is a
proper flat-with-floating setup being added to Neutron in order to allow
for direct migrations?
Thanks.
-Andrew
On 12/22/14 5:42 PM, Kevin Benton wrote:
The shared network would have all of the VMs attached to it and would
just be private address space. The shared network would be connected
to a virtual router which would be connected to an external network
where all of your floating IPs come from. The floating IPs from there
would have the allocation, assignment, release features you are
looking for.
However, until the ARP poisoning protection is merged, shared networks
aren't very trustworthy across multiple tenants. So you should be able
to experiment with the Juno Neutron code in the topology I described
above to see if it meets your needs, but I wouldn't suggest a
production deployment until the L2 dataplane security features are
merged (hopefully during this cycle).
-------------------------
| Shared Network | <--- All tenant VMs attach here
-------------------------
|
------------
| Router |
------------
|
--------------------------
| External Network | <--- Floating IPs come from here
--------------------------
On Mon, Dec 22, 2014 at 1:46 AM, Andrew Bogott <abog...@wikimedia.org> wrote:
On 12/22/14 2:08 PM, Kevin Benton wrote:
Can't you simulate the same topology as the FlatDHCPManager + Floating IPs
with a shared network attached to a router which is then attached to an
external network?
Mmmmaybe? Floating IP support in nova-network is pretty great (allocation,
assignment, release, etc.) and allows us shuffle around a small number of
public IPs amongst a much larger number of instances. Your suggestion
doesn't address that, does it? Short of my implementing a bunch of custom
stuff on my own?
-A
On Sun, Dec 21, 2014 at 7:00 PM, Andrew Bogott <abog...@wikimedia.org>
wrote:
Greetings!
I'm about to set up a new cloud, so for the second time this year I'm
facing the question of Neutron vs. nova-network. In our current setup we're
using nova.network.manager.FlatDHCPManager with floating IPs. This config
has been working fine, and would probably be our first choice for the new
cloud as well.
At this point is there any compelling reason for us to switch to Neutron?
My understanding is that the Neutron flat network model still doesn't
support anything similar to floating IPs, so if we move to Neutron we'll
need to switch to a subnet-per-tenant model. Is that still correct?
I'm puzzled by the statement that " upgrades without instance downtime
will be available in the Kilo release"[1] -- surely for such a path to
exist, Kilo/Neutron would need to support all the same use cases as
nova-network. If that's right and Neutron is right on the verge of
supporting flat-with-floating then we may just cool our jets and wait to
build the new cloud until Kilo is released. I have no particular reason to
prefer Neutron, but I'd like to avoid betting on a horse right before it's
put down :)
Thanks!
-Andrew
[1]
http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
--
Kevin Benton
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
