Open Stack

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