Open Stack

On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:
> Agree with this.
> 
> Though I am an optimist,  I believe that this time, we can avoid
> calling multiple services in one request that depend on each other.
> About the multiple users at once, this should be solved inside the
> API calls of the services.
> 
> So I think we should forbid building these complex API calls
> composites in the Tuskar-API. If we will want something like this,
> we should implement
> it properly inside the services itself. If we will not be able to
> convince the community about it, maybe it's just not that good
> feature. :-D
> 

It's worth adding that in the particular case Radomir sites (the
"Deploy" button), even with all the locks in the world, the resources
that we have supposedly requisitioned in the undercloud for the user may
have already been allocated to someone else by Nova -- because Nova
currently doesn't allow reservation of resources. (There is work under
way to allow this but it is quite a way off.) So we could find ourselves
claiming for the user that we're going to deploy an overcloud at a
certain scale and then find ourselves unable to do so.

Frankly I think the whole multi-user case for Tuskar is far enough off
that I would consider wrapping a single-login restriction around the
entire thing and calling it a day... except that that would be
crazy. I'm just trying to make the point that making these operations
really safe for multiple users is way harder than just putting a lock on
the tuskar API.

--H

> 
> On 12/12/2013 02:35 PM, Jiří Stránský wrote:
> >On 12.12.2013 14:26, Jiří Stránský wrote:
> >>On 12.12.2013 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.
> >>>
> >>
> >>You're right that we should strive for atomicity, but I'm afraid putting
> >>the complex operations (which call other services) into tuskar-api will
> >>not solve the problem for us. (Jay and Ladislav already discussed the
> >>issue.)
> >>
> >>If we have to do multiple API calls to perform a complex action, then
> >>we're in the same old situation. Should i get back to the rack creation
> >>example that Ladislav posted, it could still happen that Tuskar API
> >>would return error to the UI like: "We haven't created the rack in
> >>Tuskar because we tried to modifiy info about 8 nodes in Ironic, but
> >>only 5 modifications succeeded. So we've tried to revert those 5
> >>modifications but we only managed to revert 2. Please figure this out
> >>and come back." We moved the problem, but didn't solve it.
> >>
> >>I think that if we need something to be atomic, we'll need to make sure
> >>that one operation only "writes" to one service, where the "single
> >>source of truth" for that data lies, and make sure that the operation is
> >>atomic within that service. (See Ladislav's example with overcloud
> >>deployment via Heat in this thread.)
> >>
> >>Thanks :)
> >>
> >>Jirka
> >>
> >
> >And just to make it clear how that relates to locking: Even if i
> >can lock something within Tuskar API, i cannot lock the related
> >data (which i need to use in the complex operation) in the other
> >API (say Ironic). Things can still change under Tuskar API's
> >hands. Again, we just move the unpredictability, but not remove
> >it.
> >
> >Jirka
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Senior Engineering Manager, Cloud Engineering                   ==
== Tuskar: Elastic Scaling for OpenStack                           ==
== http://github.com/tuskar                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey