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