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