Open Stack

Agree with this.

Though I am an optimist,  I believe that this time, we can avoid calling 
multiple services in one request that depend on each other.
About the multiple users at once, this should be solved inside the API 
calls of the services.

So I think we should forbid building these complex API calls composites 
in the Tuskar-API. If we will want something like this, we should implement
it properly inside the services itself. If we will not be able to 
convince the community about it, maybe it's just not that good feature. :-D

Ladislav

On 12/12/2013 02:35 PM, Jiří Stránský wrote:
> On 12.12.2013 14:26, Jiří Stránský wrote:
>> On 12.12.2013 11:49, Radomir Dopieralski wrote:
>>> On 11/12/13 13:33, Jiří Stránský wrote:
>>>
>>> [snip]
>>>
>>>> TL;DR: I believe that "As an infrastructure administrator, Anna 
>>>> wants a
>>>> CLI for managing the deployment providing the same fundamental 
>>>> features
>>>> as UI." With the planned architecture changes (making tuskar-api 
>>>> thinner
>>>> and getting rid of proxying to other services), there's not an obvious
>>>> way to achieve that. We need to figure this out. I present a few 
>>>> options
>>>> and look forward for feedback.
>>>
>>> [snip]
>>>
>>>> 2) Make a thicker tuskar-api and put the business logic there. 
>>>> (This is
>>>> the original approach with consuming other services from 
>>>> tuskar-api. The
>>>> feedback on this approach was mostly negative though.)
>>>
>>> This is a very simple issue, actualy. We don't have any choice. We need
>>> locks. We can't make the UI, CLI and API behave in consistent and
>>> predictable manner when multiple people (and cron jobs on top of that)
>>> are using them, if we don't have locks for the more complex operations.
>>> And in order to have locks, we need to have a single point where the
>>> locks are applied. We can't have it on the client side, or in the UI --
>>> it has to be a single, shared place. It has to be Tuskar-API, and I
>>> really don't see any other option.
>>>
>>
>> You're right that we should strive for atomicity, but I'm afraid putting
>> the complex operations (which call other services) into tuskar-api will
>> not solve the problem for us. (Jay and Ladislav already discussed the
>> issue.)
>>
>> If we have to do multiple API calls to perform a complex action, then
>> we're in the same old situation. Should i get back to the rack creation
>> example that Ladislav posted, it could still happen that Tuskar API
>> would return error to the UI like: "We haven't created the rack in
>> Tuskar because we tried to modifiy info about 8 nodes in Ironic, but
>> only 5 modifications succeeded. So we've tried to revert those 5
>> modifications but we only managed to revert 2. Please figure this out
>> and come back." We moved the problem, but didn't solve it.
>>
>> I think that if we need something to be atomic, we'll need to make sure
>> that one operation only "writes" to one service, where the "single
>> source of truth" for that data lies, and make sure that the operation is
>> atomic within that service. (See Ladislav's example with overcloud
>> deployment via Heat in this thread.)
>>
>> Thanks :)
>>
>> Jirka
>>
>
> And just to make it clear how that relates to locking: Even if i can 
> lock something within Tuskar API, i cannot lock the related data 
> (which i need to use in the complex operation) in the other API (say 
> Ironic). Things can still change under Tuskar API's hands. Again, we 
> just move the unpredictability, but not remove it.
>
> Jirka
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev