[openstack-dev] Transaction across the OpenStack projects

Gurjar, Unmesh Unmesh.Gurjar at nttdata.com
Mon Aug 20 07:15:19 UTC 2012


Hi All,

I  have added a comment on Aug 13 to https://review.openstack.org/#/c/11018/.
Can you please go through it and let me know your thoughts on the same.

Thanks & Regards,
Unmesh Gurjar | Lead Engineer | NTT DATA Global Technology Services Private Limited | w. +91.20.6604.1500 x 379 | m. +91.982.324.7631 | unmesh.gurjar at nttdata.com | Learn more at nttdata.com/americas


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

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding



More information about the OpenStack-dev mailing list