Scott,
thanks for the feedback - comments inline.
On 08/21/2011 10:31 PM, Scott Seago wrote:
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.
ack
> 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".
ack on terminology
1.1 a deployment was detected faulty by a third party
1.2 An assembly instance was detected faulty by a third party
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?
In this model, global scope, meaning we register one monitor hook and it
is executed each time a state change occurs in the deployment or
assembly instance.
It is possible other components may have a use case for registering
monitors, indicating we should support multiple monitors in the api.
> 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
ack
So this is an api on conductor -- what will be posting -- pacemaker
or
some other monitor or some other entity?
yes pacemaker cloud or some other third party component (competitor to
pacemaker cloud, or user's custom code, etc)
> 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?
open to ideas here - ideally we want to cover all states that deltacloud
covers or more importantly that aeolus cares about and publish those to
the third party monitor api implemented by other projects.
general concept is that aeolus takes input from third parties (which
could be within the aeolus code base or external) and executes
policy/operations based upon that.
> 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?
yes conductor makes these calls whenver a state change is detected by
aeolus (either from the monitor api or internally). yes calls are sent
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
>wish to register monitors, meaning wish to register monitors, meaning
> 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
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel