Good summary. I would also add that in A1 the schedulers (e.g., in Nova
and Cinder) could talk to each other to coordinate. Besides defining the
policy, and the user-facing APIs, I think we should also outline those
cross-component APIs (need to think whether they have to be user-visible,
or can be admin).
Regards,
Alex
From: Mike Spreitzer <mspre...@us.ibm.com>
To: "Yathiraj Udupi (yudupi)" <yud...@cisco.com>,
Cc: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org>
Date: 09/10/2013 08:46 AM
Subject: Re: [openstack-dev] [scheduler] APIs for Smart Resource
Placement - Updated Instance Group Model and API extension model - WIP
Draft
Thanks for the clue about where the request/response bodies are
documented. Is there any convenient way to view built documentation for
Havana right now?
You speak repeatedly of the desire for "clean" interfaces, and nobody
could disagree with such words. I characterize my desire that way too. It
might help me if you elaborate a little on what "clean" means to you. To
me it is about minimizing the number of interactions between different
modules/agents and the amount of information in those interactions. In
short, it is about making narrow interfaces - a form of simplicity.
To me the most frustrating aspect of this challenge is the need for the
client to directly mediate the dependencies between resources; this is
really what is driving us to do ugly things. As I mentioned before, I am
coming from a setting that does not have this problem. So I am thinking
about two alternatives: (A1) how clean can we make a system in which the
client continues to directly mediate dependencies between resources, and
(A2) how easily and cleanly can we make that problem go away.
For A1, we need the client to make a distinct activation call for each
resource. You have said that we should start the roadmap without joint
scheduling; in this case, the scheduling can continue to be done
independently for each resource and can be bundled with the activation
call. That can be the call we know and love today, the one that creates a
resource, except that it needs to be augmented to also carry some pointer
that points into the policy data so that the relevant policy data can be
taken into account when making the scheduling decision. Ergo, the client
needs to know this pointer value for each resource. The simplest approach
would be to let that pointer be the combination of (p1) a VRT's UUID and
(p2) the local name for the resource within the VRT. Other alternatives
are possible, but require more bookkeeping by the client.
I think that at the first step of the roadmap for A1, the client/service
interaction for CREATE can be in just two phases. In the first phase the
client presents a topology (top-level InstanceGroup in your terminology),
including resource definitions, to the new API for registration; the
response is a UUID for that registered top-level group. In the second
phase the client "creates" the resources as is done today, except that
each creation call is augmented to carry the aforementioned pointer into
the policy information. Each resource scheduler (just nova, at first) can
use that pointer to access the relevant policy information and take it
into account when scheduling. The client/service interaction for UPDATE
would be in the same two phases: first update the policy&resource
definitions at the new API, then do the individual resource updates in
dependency order.
I suppose the second step in the roadmap is to have Nova do joint
scheduling. The client/service interaction pattern can stay the same. The
only difference is that Nova makes the scheduling decisions in the first
phase rather than the second. But that is not a detail exposed to the
clients.
Maybe the third step is to generalize beyond nova?
For A2, the first question is how to remove "user-level" create-time
dependencies between resources. We are only concerned with the
"user-level" create-time dependencies here because it is only they that
drive intimate client interactions. There are also create-time
dependencies due to the nature of the resource APIs; for example, you can
not attach a volume to a VM until after both have been created. But
handling those kinds of create-time dependencies does not require intimate
interactions with the client. I know of two software orchestration
technologies developed in IBM, and both have the property that there are
no "user-level" create-time dependencies between resources; rather, the
startup code ("userdata") that each VM runs handles dependencies (using a
library for cross-VM communication and synchronization). This can even be
done in plain CFN, using wait conditions and handles (albeit somewhat
clunkily), right? So I think there are ways to get this nice property
already. The next question is how best to exploit it to make cleaner
APIs. I think we can have a one-step client/service interaction: the
client presents a top-level group (including leaf resource definitions) to
the new service, which registers it and proceeds to
create/schedule/activate the resources.
Regards,
Mike_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
