Open Stack

Hi Nachi,

On 8/10/12 6:00 PM, "Nachi Ueno" <nachi at nttmcl.com> wrote:

>Hi Gabe
>
>Thank you for your reply
>
>I'm +1 for make the client can provide a custom transaction ID.
>OK let's take more generic way.
>
>- Client send HTTP response.
>X-OpenStack-Transaction-ID.
>
>- Server ( Nova,Glance,Keystone,Quantum,Cinder etc..)
>Returns X-OpenStack-Transaction-ID using HTTP response or notification.
>HTTP response or notification has HTTP code which map to the status of
>the transaction

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

>
>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?

>
>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
>>