[MidoNet-dev] population of the Mac-learning table - api proposal

Ishimoto, Ryu ryu at midokura.com
Thu Feb 21 09:13:10 UTC 2013


Hi Rossella,

Thanks for your clarification.

On Wed, Feb 20, 2013 at 8:26 PM, Rossella Sblendido <rossella at midokura.jp>wrote:

>
> Yes Dan you're right, thanks for correcting me and sorry for the
> confusion. It's not VM migration, I meant something like "MAC migration"
> but that's probably unclear. Let me explain...
> I'm not an expert of restful application anyway my idea was to use bridges/bridge_id/macPortTable
> as URI. A GET against it returns Collection<DtoMacPort> that is the whole
> map with MAC-vportID associations. PUT or DELETE add or remove items from
> the collection. POST is not implemented. A POST against bridges/bridge_id/macPortTable
> should provide the whole map.
>
> We use PUT both for adding a new entry and for updating an old entry. A
> use case for updating an entry would be a MAC previously assigned to a VM,
> gets assigned to a new VM, that's why the association MAC-vportID changes,
> that's what I meant. It's probably not so common.
>
>  I think this design choice hinges on whether we want this operation to
be idempotent.  PUT is supposed to be idempotent and POST is not.  Do we
always want PUT to set the mapping?  Personally, I prefer POST to create
and PUT to update(which is probably not even necessary, as Joe mentioned),
but I can certainly see your point for having PUT doing the creation AND
update.  What does it mean when a client tries to create a mapping for a
mac that already exists in the table?  Is it important that the client gets
an error for this?  IMHO, I think it would be good to send back an error in
this case since this operation should not be allowed, and it would be a
useful information for the client to know that someone else (or itself)
already added this mapping earlier.  When I think of the operations for
mac-port mapping, I think 'create' and 'delete' (POST and DELETE) make the
most sense.   What do you think?

Ryu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130221/afa60f49/attachment.html>


More information about the MidoNet-dev mailing list