On 08/21/2011 05:38 PM, Steven Dake wrote:
As has been previously discussed on this mailing list and irc, there
are
gaps between what deltacloud provides and what higher level management
systems (such as Aeolus) have interest. Deltacloud provides a great
low-level interface to various cloud providers objects, but doesn't
enforce any particular policy or organization on these low level objects.
In the Aeolus project we are interested in enforcing organization and
policy. The question becomes do we want to create a coherent set of
APIs that model the Aeolus system. My answer to this is yes, we do, and
to kick that process off, I'll propose a few APIs that we need exposed
from aeolus to support the pacemaker-cloud[1] project.
For the most part, the starting point for the Aeolus API will be the
actions that we currently support in the Conductor Web UI -- actions on
instances, deployments, pools, providers, etc. I'm sure we'll come with
additional API actions that are not currently part of this UI, which
will be added as well.
What pacemaker cloud needs today:
1 notifications that third parties modify a deployable state
Repeating myself here,
but it's an important point. We've got to be
consistent on terminology here. A deployable is _not_ a collection of
running instances, it's a reusable description of what a collection of
running instances might look like. In other words, it's a collection of
_images_ with configuration associated with each which describe what
will be launched (some config filled in in the deployable, other bits
not populated until we go to launch.
A _deployment_ is a collection of running instances -- from what I'm
reading below, I'm going to assume that when you say "deployable" you
really mean "deployment". So for a given deployable, there may be many
deployments, each running in a separate pool, on a separate back end
cloud, but each containing the same set of base images and similar
configuration.
1.1 A deployable was detected faulty by a third party
1.2 An assembly was detected faulty by a third party
Along similar lines, an
assembly belongs to a deployable -- it's
essentially a reusable image along with some configuration specs, but
not necessarily a complete configuration -- and certainly not a running
instance. A deployable contains semi-configured assemblies. A deployment
contains instances. So I'm assuming that where you say "assembly" here
you really mean "instance".
Deployments and instances may be started and stopped -- Deployables and
Deployments may not.
1.3 A deployable was started by a third party
1.4 A deployable was stopped by a third party
2 third party notification involving deployable state monitoring
2.1 Active monitoring has determined that an assembly has failed
2.2 Active monitoring has determined that a deployable has failed
A proposed API model follows:
Exported from the management system
-----------------------------------
POST api/monitors/add
Add a third party monitor to a list of monitors maintained by the
management system
inputs: internet protocol address, port, and version of a third party
software component implementing the monitoring API
outputs: monitor identifier and success or failure
Are these monitors scoped by instance, deployment, pool, provider, etc
-- or are they global?
Are all monitors equal, or are they scoped by purpose/functionality/etc?
POST api/monitors/remove
Remove a third party monitor from the list of monitors maintained by the
management system
inputs: internet protocol address, port, version, and identifier of a
third party software component implementing the monitoring API
outputs: monitor identifier and success or failure
GET api/monitors/list
Retrieve a list of third party monitors from the management system
inputs: version
outputs: list of monitors including internet protocol address, port, and
version
POST api/monitors/deployable/id
inputs: version and START DETECTED or FAIL DETECTED
outputs: success or fail
s/deployable/deployment/ for here and all below API calls
So this is an api on conductor -- what will be posting -- pacemaker or
some other monitor or some other entity?
POST api/monitors/deployable/assembly/id
s/assembly/instance for this and any subsequent calls
inputs: version and START DETECTED or FAIL DETECTED
outputs: success or fail
How should conductor interpret START DETECTED for a deployment or
instance? If conductor just started it, we'll know it's started -- or is
this to handle cases where something started an existing instance
outside of conductor?
What about FAIL DETECTED? Does conductor simply update internal state to
FAILED from RUNNING or something more advanced?
Exported by the third party monitor API
---------------------------------------
So should conductor make these calls? When
are calls required? Do we
make calls to all registered monitors?
POST api/deployable/id
inputs: version, deployment ID, and state (START DETECTED, FAIL
DETECTED, STOP DETECTED), deployable metadata
outputs: success or fail
POST api/deployable/assembly/id
inputs: version, assebmly ID, deployable metadata, and state (START
DETECTED, STOP DETECTED, FAIL DETECTED)
outputs: success or fail
Regards
-steve
[1]
http://pacemaker-cloud.org
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel Scott