Interfaces API Clean up

Registered by Troy Toman

As we've evolved how Nova interfaces and Melange interact. We've iterated over the API and now probably need to do some clean up before finalization. These change would apply to all REST verbs on the calls (not just POST but GET, DELETE, etc.) Here is the proposal:

Current API:

PUT /ipam/instances/{instance_id}/interfaces/
Expects a collection of interfaces in the request body. Optionally allocates ips if network details are present for each interface.
Repeated invocation will delete existing interfaces and add new ones.
Usecase is for allocating all interfaces of an instance when spinning up a new instance.

Proposed API:

POST /ipam/instances/{instance_id}/interfaces/
Expects a single interface in the request body. Optionally allocates ips.
Repeated invocation creates new interfaces.
Usecase is for existing instances to create new interfaces.

POST /ipam/instances/{instance_id}/interfaces/ip_addresses
Would allocate and additional ip from the block associated with the network this interface is connected to
Repeated invocations would add more IPs

Old APIs:

1) Interface API:
POST /ipam/interfaces.
Behavior is same as the proposed /ipam/instances/{insance_id}/interfaces, except that instance_id is taken through request body and is optional.

2) IpAllocations API:
POST /ipam/tenants/{network_owner_tenant}/networks/{network_id}/interface/{interface_id}/ip_allocations
Allocates ips for existing interfaces. If interface is not found, will create one on the fly.

API 1) is redundant once the proposed API is in place.
API 2) would still be necessary if we create interfaces without allocating ips and at a later stage allocate ips.

But I don't see the usecase for creating interfaces in melange and allocating ips later. Unless there is a reasonable usecase we can remove API 2)

Blueprint information

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Troy Toman
Direction:
Needs approval
Assignee:
Rajaram Mallya
Definition:
Approved
Series goal:
Accepted for essex
Implementation:
Implemented
Milestone target:
milestone icon 2012.1
Started by
Troy Toman
Completed by
Troy Toman

Related branches

Sprints

Whiteboard

I'm for all of this including the removal of the IpAllocations API. I think the only case anyone could come up with is that they want a bare interface. My answer to that is they could just create a "test" ipv6 network and ignore the ip address they get auto-assigned. - jkoelker

Just to clarify, with the proposed api, creating an instance with 2 networks would be a put, and then adding a 3rd network later would be a post? We need to retain the ability to manage the IPs associated with an interface, being able to add or remove them for ipv4 feature parity..
-tr3buchet

Gerrit topic: https://review.openstack.org/#q,topic:bp/interface-api-cleanup,n,z

Addressed by: https://review.openstack.org/4063
    New APIs as per blueprint interface-api-cleanup

Gerrit topic: https://review.openstack.org/#q,topic:interface-api-cleanup,n,z

Addressed by: https://review.openstack.org/4174
    Docs for API introduced due to bluepring interface-api-cleanup.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.