big ack, this is a great addition to the api. Only comment is *make
sure* we can fit this model the way gogrid 'do ip addresses' before you
push.
re Mark's comments on the 'subcollection' - this is an intuitive
approach and a good fit for the way ec2 'does ip addresses'. In fact we
already use subcollections for the blobstore (blobs only exist as a
subcollection of a given bucket). What about having our cake and eating
it too - having a toplevel /api/collection for the whole set, and then
/api/instances/instance/sub_collection for the subset that belongs to a
given instance? Is this crazy talk/blasphemy - ?
marios
On 08/12/10 14:34, [email protected] wrote:
Hi,
This patch will bring support for 'Addresses' collection to API,
which means that you can set a public/private IP address to your
instance if backend provider support that.
For now I added support only to EC2 driver and once this patch will
be ACKed, i'll add support for the addresses to GoGrid driver.
So basic notes of how this thing work:
* GET /api/addresses
List of IP addresses you have
* POST /api/addresses
Create a new address (in EC2, allocate a new Elastic IP address)
* DELETE /api/addresses/:id
Destroy IP address (release in EC2)
* PUT /api/addresses/:id/associate
Get 'instance_id' parameter (means it will associate given IP address
with given instance)
* POST /api/addresses/:id/release
'Disassociate' IP address from the instance.
To test this stuff, you can go to /api/addresses and hit 'Create'
button. New IP address should be spawned immediatelly. You can get
XML representation by including ?format=xml in URI.
After you click on IP, you can associate a running instance to it.
'RUNNING' is important here, otherwise you will get backend error.
Let me know what do you thing.
-- Michal
