Open Stack

yes, I didn't go to that detail and missed the delete flag , that's exactly
what I am looking for, which is a little bit confusing...
Thanks for the info for know this...

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



From:	Matt Riedemann <mriedemos at gmail.com>
To:	openstack-dev at lists.openstack.org
Date:	09/20/2017 09:15 PM
Subject:	Re: [openstack-dev] [nova][api] why need
            PUT /servers/{server_id}/metadata/{key} ?



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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_master_nova_api_openstack_compute_server-5Fmetadata.py-23L80&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=1S1y1O0K2KOZgQd1wmx5_P8IhzNqf-i6d4IThx0yLrI&e=

>
> 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
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs&e=

>

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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_5bf1bb47c7e17c26592a699d07c2faa59d98bfb8_nova_compute_api.py-23L3830&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=AMY4S8Ux0G78V_Nu2H17kNivICkiKErqDzPj0eFsUgg&e=


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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170920/67ea02d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170920/67ea02d4/attachment.gif>