Open Stack

Hi Gabe

> Server should generate it if its not already provided too - I think that¹s
> what you mean, but just want to make sure.

Yes. Thank you for your pointing this.

>>
>>Body should be
>>{'code':200, 'message':"Log message"}
>>
>>200 -> Success
>>500 -> Internal Server error
>
> I'm not sure I understand what you mean here - when would we return this
> body?

So there are two way to return result of the request.

1) HTTP Response Header ( for synchronous API )
X-OpenStack-Transaction-ID
HTTP Response Code

2) Notification  ( for asynchronous API )
In this case, return will be json.

Body should be
{'code':200, 'message':"Log message"}

200 -> Success
500 -> Internal Server error

>>
>>If there are no other strong objections or options,
>>we will fix the review using this spec.
>>https://review.openstack.org/#/c/11018/
>>
>>Thanks
>>Nachi
>>
>>2012/8/10 Gabe Westmaas <gabe.westmaas at rackspace.com>:
>>>
>>>
>>> On 8/10/12 3:17 PM, "Nachi Ueno" <nachi at nttmcl.com> wrote:
>>>
>>>>Hi Gabe,folks
>>>>
>>>>We have discussed in request and transaction IDs across all projects
>>>>https://lists.launchpad.net/openstack/msg13082.html
>>>>
>>>>We would like to add to get Transaction ID for each project.
>>>>
>>>>At first, we proposed to make request_id configurable from outside.
>>>>https://review.openstack.org/#/c/11018/
>>>>
>>>>However I got comment from Vish.
>>>>"So we discussed having an Id that existed across projects, like
>>>>TRANSACTION-ID, which makes sense, and it should probably be put in
>>>>keystone somehow, but I don't like exposing the ability to set the
>>>>request id to the user."
>>>>
>>>>It is make sense, because originally request_id is not designed to be
>>>>configurable.
>>>>If it is configurable, we should manage request_id's and check it.
>>>>
>>>>So we need to agree the spec of TRANSACTION-ID.
>>>>
>>>>How about this spec?
>>>>
>>>>If the HTTP header X-OS-TRANSACTION-ID (uuid) is set, each openstack
>>>>components set the value in there internal transactions.
>>>>X-OS-TRANSACTION-ID is returned by client side.
>>>
>>> Maybe just do X-OpenStack-Transaction-ID.
>>>
>>>>
>>>>TransactionManager daemon ( This could be keystone ) handles the each
>>>>transaction,
>>>>and the each openstack components reports wether request is succeed or
>>>>not.
>>>
>>> I think we can just have any HTTP service check to see if the value is
>>> set, if it is, use that as you say.  If its not just set it at that
>>>point.
>>>  I wouldn't tie it to keystone in particular, as the request order is:
>>> 1) client > keystone
>>> 2) client > http service 1
>>> 3-N) http service 1 > http service X
>>>
>>> And thus the client would be responsible for carrying that transaction
>>>ID
>>> forward from keystone.  If you just leave it generic, then the client
>>>can
>>> provide a custom transaction ID, or we just rely on the first inbound
>>> service to set the value.
>>>
>>> Finally there's some work to be done to get it logged in the various
>>> services, though that can probably be done in later commits.
>>>
>>> Other than that I like it!  Sorry I never got around to writing anything
>>> up.
>>>
>>> Gabe
>>>
>>>>
>>>>Any thought?
>>>>Nachi NTT MCL
>>>
>