openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2012/1/2 Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>:
>> > In the context of this discussion, that means that OpenStack needs
>> > to work in DHCP-free environments, because we already know of many.
>> The only one I'm familiar with is Rackspace where I think (and please
>> do correct me if I'm wrong) DHCP isn't used only because Windows
>> instances can't be configured with DHCP if they have multiple
>> interfaces.
> DHCP may be forbidden because:

> * it has been deemed less reliable than pushing fixed IP addresses
> from an asset database.  If you already have a comprehensive asset
> database, why push the addresses to a DHCP server to have it push them
> to your hosts when you can push them to the host directly?

Because Nova isn't likely to interface with your asset database. It
maintains has its own database for these things.

Also, how do you push something from an asset database, if you don't
have network connectivity?

> * it has been deemed less reliable than pushing addresses from the
> virt layer.

By whom and for what reasons?  Every single operating system of any
relevance at all understands DHCP. It's an extremely widely used system.
It may not be perfect, but that will hold true for any replacement we
decide to build. You'll simply be replacing the bugs, problems and
idiosyncracies with a different set of bugs, problems and
idiosyncracies.

> Why go to the effort of making a DHCP service highly available, and
> making sure that the failover is quicker than the timeout that causes
> guests to decide to take zeroconf addresses instead?

Just set the lease time to a couple of weeks. If you can't manage to fix
a dead dnsmasq within that timeframe, that's probably the least of your
problems.

> * it has been deemed a security risk.  Compromising the DHCP server
> gives you all sorts of easy attacks.

The DHCP server runs on the network controller. If your network
controller is compromised, you're pretty screwed anyway, afaics.

> This one actually seems like a very reasonable concern in the case of
> tenant networks in a cloud.   Pushing the address from the virt layer
> takes away that attack vector altogether.

...and replaces it with another.

> * the guy who is installing the cloud doesn't control the network, and
> so the DHCP server isn't his and/or he's not allowed to run one of his
> own.  This seems likely in an academic environment or pilots within an
> enterprise.

a) This isn't a reason. It's just repeating the original non-problem:
"it's not allowed".

b) There are several ways in which we can ensure that our DHCP stuff
doesn't bleed into the rest of the network. dnsmasq already won't
respond to requests from mac addresses that it doesn't know about, but
if that isn't good enough (why would this be? what's so darned special
about dhcp requests anyway?), we can add extra strict filtering in a
couple of places.

> Note that none of these has to be specifically a decision about
> OpenStack or clouds in general.  They might just be blanket policies
> from simpler times.  That doesn't make them any easier to change.

I can't tell you how to run your business. All I know is that if a
client of mine gave me a functional requirement specification that would
be perfectly met by DHCP, but they had a piece of paper from the
mid-90's that said "DHCP isn't allowed. Just because." on which they
refused to budge, I'd pass on the contract. I personally don't want to
facilitate stupid policies. That's my policy.

> Regardless of those four, your one seems like a complete deal-breaker
> to me.  If that's true (and it's not something that I'm aware of one
> way or another) then we shouldn't even be having this discussion.  We
> can't build a solution that can't reliably configure Windows VMs.

a) I don't think we should generally limit ourselves to whatever Windows
can support. (Much like how I don't think we should have a hard
dependency on hypervisors that have a Xenstore-like backdoor into the
guest)

b) I don't think I've heard any reason why we couldn't just configure
one of the NIC's over DHCP, and then fetch the remaining network config
from a network-connected metadata service.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/