Open Stack

Yup. And Designate works very well. :)

But DNSaaS is not always an option to "the powers that be".... floating ip's are a much easier sell.

Also Designate does have a restriction of wanting to manage a whole domain itself. When you have existing infrastructure you want your vms to merge into, its a problem.

Thanks,
Kevin
________________________________
From: Assaf Muller [amuller at redhat.com]
Sent: Tuesday, September 15, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model



On Tue, Sep 15, 2015 at 5:09 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:
Unfortunately, I haven't had enough chance to play with ipv6 yet.

I still think ipv6 with floating ip's probably makes sense though.

In ipv4, the floating ip's solve one particular problem:

End Users want to be able to consume a service provided by a VM. They have two options:
1. contact the ip directly
2. use DNS.

DNS is preferable, since humans don't remember ip's very well. IPv6 is much harder to remember then v4 too.

DNS has its own issues, mostly, its usually not very quick to get a DNS entry updated.  At our site (and I'm sure, others), I'm afraid to say in some cases it takes as long as 24 hours to get updates to happen. Even if that was fixed, caching can bite you too.

I'm curious if you tried out Designate / DNSaaS.


So, when you register a DNS record, the ip that its pointing at, kind of becomes a set of state. If it can't be separated from a VM its a bad thing. You can move it from VM to VM and your VM is not a pet. But, if your IP is allocated to the VM specifically, as non Floating IP's are, you run into problems if your VM dies and you have to replace it. If your unlucky, it dies, and someone else gets allocated the fixed ip, and now someone else's server is sitting on your DNS entry! So you are very unlikely to want to give up your VM, turning it into a pet.

I'd expect v6 usage to have the same issues.

The floating ip is great in that its an abstraction of a contactable address, separate from any VM it may currently be bound to.

You allocate a floating ip. You can then register it with DNS, and another tenant can not get accidentally assigned it. You can move it from vm to vm until your done with it. You can Unregister it from DNS, and then it is safe to return to others to use.

To me, the NAT aspect of it is a secondary thing. Its primary importance is in enabling things to be more cattleish and helping with dns security.

Thanks,
Kevin






________________________________________
From: Clark Boylan [cboylan at sapwetik.org<mailto:cboylan at sapwetik.org>]
Sent: Tuesday, September 15, 2015 1:06 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On Tue, Sep 15, 2015, at 11:00 AM, Fox, Kevin M wrote:
> We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
Maybe this would be better expressed as "just run it on an existing
public network" then?
>
> I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you
> don't, the ip that gets assigned to the vm helps it become a pet. you
> can't replace the vm and get the same IP. Floating IP's and load
> balancers can help prevent pets. It also prevents security issues with
> DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x or
> more the number of instances that are on the private network. Sure its
> easy to put everything on the public network, but it provides much better
> security if you only put what you must on the public network. Consider
> the internet. would you want to expose every device in your house
> directly on the internet? No. you put them in a private network and poke
> holes just for the stuff that does. we should be encouraging good
> security practices. If we encourage bad ones, then it will bite us later
> when OpenStack gets a reputation for being associated with compromises.
There are a few issues with this. Neutron IPv6 does not support floating
IPs. So now you have to use two completely different concepts for
networking on a single dual stacked VM. IPv4 goes on a private network
and you attach a floating IP. IPv6 is publicly routable. If security and
DNS and not making pets were really the driving force behind floating
IPs we would see IPv6 support them too. These aren't the reasons
floating IPs exist, they exist because we are running out of IPv4
addresses and NAT is everyones preferred solution to that problem. But
that doesn't make it a good default for a cloud; use them if you are
affected by an IP shortage.

Nothing prevents you from load balancing against public IPs to address
the DNS and firewall rule concerns (basically don't make pets). This
works great and is how OpenStack's git mirrors work.

It is also easy to firewall public IPs using Neutron via security groups
(and possibly the firewall service? I have never used it and don't
know). All this to say I think it is reasonable to use public shared
networks by default particularly since IPv6 does not have any concept of
a floating IP in Neutron so using them is just odd unless you really
really need them and you aren't actually any less secure.

Not to get too off topic, but I would love it if all the devices in my
home were publicly routable. I can use my firewall to punch holes for
them, NAT is not required. Unfortunately I still have issues with IPv6
at home. Maybe one day this will be a reality :)
>
> I do consider making things as simple as possible very important. but
> that is, make them as simple as possible, but no simpler. There's danger
> here of making things too simple.
>
> Thanks,
> Kevin
>

Clark

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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://OpenStack-dev-request@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/20150916/80a0a2e0/attachment.html>