<div dir="ltr">Ed, Jay,<div><br></div><div>Thanks for the responses. We wanted to make sure we weren't breaking any community wide API guidelines</div><div><br></div><div>Regards</div><div><br></div><div>Miguel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 25, 2019 at 11:26 AM Ed Leafe <<a href="mailto:ed@leafe.com">ed@leafe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Feb 25, 2019, at 7:36 AM, Akihiro Motoki <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>> wrote:<br>
> <br>
> It sounds nice to me to support tagging when creating a resource to address the above problem.<br>
> What in my mind is to specify 'tags' attribute in a body of POST request like:<br>
> <br>
>  {'port':<br>
>     {'name': 'foo',<br>
>      'network_id': <network-id>,<br>
>      'tags': ['red', 'blue']<br>
>      }<br>
>   }<br>
> <br>
> I don't know the reason why the current API-SIG recommended tagging API does<br>
> not support this model. The current tagging API defines "tags" as a subresource.<br>
> Is there any reason this model was adopted?<br>
<br>
Tags are strings attached to resources, so there really should be no difference when creating a resource with tags than when creating a resource with a name. The part of the guideline for modifying tags assumes that the resource already exists.<br>
<br>
We could certainly add additional wording that clarifies that resources can be created with tags; there certainly isn’t anything in the current guideline that says they can’t.<br>
<br>
<br>
-- Ed Leafe<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>