Open Stack

On 20/12/13 12:25, Ladislav Smola wrote:
> May I propose we keep the conversation Icehouse related. I don't think
> we can make any sort of locking
> mechanism in I.

By getting rid of tuskar-api and putting all the logic higher up, we are
forfeiting the ability to ever create it. That worries me. I hate to
remove potential solutions from my toolbox, even when the problems they
solve may as well never materialize.

> Though it would be worth of creating some WikiPage that would present it
> whole in some consistent
> manner. I am kind of lost in these emails. :-)
> 
> So, what do you thing are the biggest issues for the Icehouse tasks we
> have?
> 
> 1. GET operations?
> I don't think we need to be atomic here. We basically join resources
> from multiple APIs together. I think
> it's perfectly fine that something will be deleted in the process. Even
> right now we join together only things
> that exists. And we can handle when something is not. There is no need
> of locking or retrying here AFAIK.
> 2. Heat stack create, update
> This is locked in the process of the operation, so nobody can mess with
> it while it is updating or creating.
> Once we will pack all operations that are now aside in this, we should
> be alright. And that should be doable in I.
> So we should push towards this, rather then building some temporary
> locking solution in Tuskar-API.
> 
> 3. Reservation of resources
> As we can deploy only one stack now, so I think it shouldn't be a
> problem with multiple users there. When
> somebody will delete the resources from 'free pool' in the process, it
> will fail with 'Not enough free resources'
> I guess that is fine.
> Also not sure how it's now, but it should be possible to deploy smartly,
> so the stack will be working even
> with smaller amount of resources. Then we would just heat stack-update
> with numbers it ended up with,
> and it would switch to OK status without changing anything.
> 
> So, are there any other critical sections you see?

It's hard for me to find critical sections in a system that doesn't
exist, is not documented and will be designed as we go. Perhaps you are
right and I am just panicking, and we won't have any such critical
sections, or can handle the ones we do without any need for
synchronization. You probably have a much better idea how the whole
system will look like. Even then, I think it still makes sense to keep
that door open an leave ourselves the possibility of implementing
locking/sessions/serialization/counters/any other synchronization if we
need them, unless there is a horrible cost involved. Perhaps I'm just
not aware of the cost?

As far as I know, Tuskar is going to have more than just GETs and Heat
stack operations. I seem to remember stuff like resource classes, roles,
node profiles, node discovery, etc. How will updates to those be handled
and how will they interact with the Heat stack updates? Will every
change trigger a heat stack update immediately and force a refresh for
all open tuskar-ui pages?

Every time we will have a number of operations batched together -- such
as in any of those wizard dialogs, for which we've had so many
wireframes already, and which I expect to see more -- we will have a
critical section. That critical section doesn't begin when the "OK"
button is pressed, it starts when the dialog is first displayed, because
the user is making decisions based on the information that is presented
to her or him there. If by the time he finished the wizard and presses
OK the situation has changed, you are risking doing something else than
the user intended. Will we need to implement such interface elements,
and thus need synchronization mechanisms for it?

I simply don't know. And when I'm not sure, I like to have an option.

As I said, perhaps I just don't understand that there is a large cost
involved in keeping the logic inside tuskar-api instead of somewhere
else. Perhaps that cost is significant enough to justify this difficult
decision and limit our options. In the discussion I saw I didn't see
anything like that pointed out, but maybe it's just so obvious that
everybody takes it for granted and it's just me that can't see it. In
that case I will rest my case.
-- 
Radomir Dopieralski