Open Stack

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