nova team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

Hi everyone,

I've been looking at implementing the IP sharing functionality in the
Rackspace API and want to try to combine what the current nova/ec2
API already does. There is actually a bit of a mismatch between the
two APIs, so I thought I'd explain the differences and propose a
solution to get some feedback.

A shared IP address is one that can float between running
instances. They are commonly used for high availability configurations
where an instance can take over an IP address should its peer go down.

The ec2 API has four functions: allocate/deallocate a shared IP address
for use with your account, and associate/disassociate an allocated IP
address with an instance. Shared IPs can be used with any instances
in your account, which means the networking layer must be able to
handle routing/switching regardless of where the instance lives for
that cluster.

The Rackspace API takes shared IPs a step further and provides
groups. You can optionally start VMs as part of a named group (the
back-end needs to know this to make sure it's within proper network
boundaries for sharing) and IP addresses can be shared between all
instances within a group. While you can share IPs in a group, the
API currently has no way to allocate new IP addresses. From what I
understand the only way to add an IP address is through a support
request (it's done this way to prevent abuse).

Given that both APIs provide functions the other does not, we'll
probably want to create a superset of the capabilities and have groups,
allocation, and sharing functions. The ec2 API can use a hard-coded
'default' shared IP group to put all instances in for a given account,
and the Rackspace API can disable allocation functions if they should
not be exposed to the public.

Since the network back-ends are pluggable and some may be more
restrictive in IP sharing than others, they will need to take into
account whether sharing is possible between instances and where group
boundaries lie. The instance scheduler will also need to be aware of
the shared IP groups to place instances close to each other if needed
(close in terms of network topology).

I'm going to start adding in the shared IP group functionality into the
Rackspace API, but due to all the other pieces that need logic added,
they may not be fully functional for Austin feature freeze (Thursday).

Does anyone have other thoughts or opinions on how to approach the
IP sharing functionality?

Thanks,
-Eric