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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
