Open Stack

On 12/12/13 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.
> 

Ok, it seems that not everyone is convinced that we will actually need
locks, transactions, sessions or some other way of keeping the
operations synchronized, so I will give you a couple of examples. For
clarity, I will talk about what we have in Tuskar-UI right now, not
about something that is just planned. Please don't respond with "but we
will do this particular thing differently this time". We will hit the
same issue again in a different place, because the whole nature of
Tuskar is to provide large operations that abstract away the smaller
operations that could be done without Tuskar.

One example of which I spoke already is the Resource Class creation
workflow. In that workflow in the first step we fill in the information
about the particular Resource Class -- its name, kind, network subnet,
etc. In the second step, we add the nodes that should be included in
that Resource Class. Then we hit "OK" the nodes are created, one by one,
then the nodes are assigned to the newly created Resource Class.

There are several concurrency-related problems here if you assume that
multiple users are using the UI:
* In the mean time, someone can create a Resource Class with the same
  name, but different ID and different set of nodes. Our new nodes will
  get created, but creating the resource class will fail (as the name
  has to be unique) and we will have a bunch of unassigned nodes.
* In the mean time, someone can add one of our nodes to a different
  Resource Class. The creation of nodes will fail at some point (as
  the MAC addresses need to be unique), and we will have a bunch of
  unassigned nodes, no Resource Class, and lost user input for the
  nodes that didn't get created.
* Someone adds one of our nodes to a different Resource Class, but does
  it in a moment between our creating the nodes, and creating the
  Resource Class. Hard to tell in which Resource Class the nodes is now.

The only way around such problem is to have a critical section there.
This can be done in multiple ways, but they all require some means of
synchronization and would be preferably implemented in a single place.
The Tuskar-API is that place.

Another example is the "deploy" button. When you press it, you are
presented with a list of undeployed nodes that will be deployed, and are
asked for confirmation. But if any nodes are created or deleted in
the mean time, the list you saw is not the list of nodes that actually
are going to be deployed -- you have been lied to. You may accidentally
deploy nodes that you didn't want.

This sort of problem will pop up again and again -- it's common in user
interfaces. Without a single point of synchronization where we can check
for locks, sessions, operation serial numbers and state, there is no way
to solve it. That's why we need to have all operations go through
Tuskar-API.

-- 
Radomir Dopieralski