[openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?
Matt Riedemann
mriedemos at gmail.com
Wed Sep 20 13:14:53 UTC 2017
On 9/20/2017 12:48 AM, Chen CH Ji wrote:
> in analyzing other code, found seems we don't need PUT
> /servers/{server_id}/metadata/{key} ?
>
> as the id is only used for check whether it's in the body and we will
> honor the whole body (body['meta'] in the code)
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80
>
> looks like it's identical to
> PUT /servers/{server_id}/metadata
>
> why we need this API or it should be something like
>
> PUT /servers/{server_id}/metadata/{key}but we only accept a value to
> modify the meta given by {key} in the API side?
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM at IBMCN Internet: jichenjc at cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
This API is a bit confusing, and the code is too since it all goes down
to some common code, and I think you're missing the 'delete' flag:
https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a699d07c2faa59d98bfb8/nova/compute/api.py#L3830
If delete=False, as it is in this case, we only add/update the existing
metadata with the new metadata from the request body. If delete=True,
then we overwrite the instance metadata with whatever is in the request.
Does that answer your question?
This API is problematic and we have bugs against it since it's not
atomic, i.e. two concurrent requests will overwrite one of them. We
should really have a generation ID or etag on this data to be sure it's
atomically updated.
--
Thanks,
Matt
More information about the OpenStack-dev
mailing list