Open Stack

On 12/20/2013 01:04 PM, Radomir Dopieralski wrote:
> 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.
>

Well, I expect that there will be decisions whether we should not land
a feature because it's not ready or we should make some temporary hack
that will make it work.

I am just little worried to have some temporary hacks in stable version,
cause then the update to the next version will be hard. And we will most 
likely
have to support these hacks as a backwards compatibility.

I wouldn't say we are forfeiting the ability to create it. I would say 
we are
forfeiting the ability to create hacked together temporary solutions, that
might go against how upstream wants to do it. That is a good thing I 
think. :-)

>> 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?

Well yeah I guess for some J features, we might need to do
something like this. I have no idea right now. So the doors are
always open. :-)

>
> 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?

resource classes: it's definitely J, are we are not yet sure how it will 
look like

node_profiles: it's nova flavor in I and it will stay that way because 
of scheduler
 From start we will have just one flavor. Even when we had more flavors, 
I think
I don't see issues here.
This heavily relies on how we are going to build the Heat Template. But 
adding
flavors should be separated form creating or updating a heat template.

creating and updating heat template: seems like we will be doing this in 
Tuskar-API
do you see any potential problems here?

node-discovery: will be in Ironic. Should be also a separate operation. 
So I don't see problems
here.


> 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?

Well we should avoid putting more of operations into one Wizard.
And i think we can do that at least for I.
If we are going to do that, I agree, we have to do it properly.

> 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.

Well I think the main concern is, we should not get from Openstack way
too much. That means we should use Openstack services and contribute
to Openstack services. We don't want to recreate something in Tuskar-API
if it is being build somewhere else. Sure there will be special things 
for our case,
then the Tuskar-API comes in.

I think it's wanted that you will remain vigilant and shout anytime you
don't like anything. That will prevent us to do the bad things. :-)

Ladislav