On 08/21/2011 11: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.
What pacemaker cloud needs today:
1 notifications that third parties modify a deployable state
1.1 A deployable was detected faulty by a third party
1.2 An assembly was detected faulty by a third party
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
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
POST api/monitors/deployable/assembly/id
inputs: version and START DETECTED or FAIL DETECTED
outputs: success or fail
Exported by the third party monitor API
---------------------------------------
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
Hi Steve,
Thanks for kicking this off and thanks Mark and Scott for the comments.
What you're proposing sounds good but I agree with Mark that actions
(add/delete), success/failure responses, etc. can be outsourced to the
HTTP protocol.
I created a wiki page for both APIs and I tried to put the ideas
together to create something that we can start implement:
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Pacemaker_Clou...
If there's data that Pacemaker Cloud should receive that isn't described
on the wiki, please let me know.
Throughout your proposal you kept mention some a version of some sort.
Could you describe in greater detail what you meant?
Everyone, please do point out things that are missing or wrong with this
updated proposal.
It's on the wiki, but I pasted it below so you can comment on specific
parts.
One last thing: I think that Mark confused the Pacemaker and Conductor
parts in his response so I'm using these terms explicitly.
Thomas
Pacemaker Cloud and Conductor Notification API
==============================================
We need to have a two-way communication between Conductor and Pacemaker
Cloud. Conductor will notify Pacemaker Cloud about the instances and
deployments that it launched, stopped, etc.
Pacemaker Cloud monitors these instances and deployments and will notify
Conductor on changes or appropriate actions that Conductor should do
(for instance, Pacemaker Cloud may ask Conductor to restart an entire
deployment if things go south).
It's entirely possible that there may be other services that would like
to receive Pacemaker Cloud notifications. Similarly, Conductor may use
its API to receive events from other sources than Pacemaker Cloud. In
order to avoid confusion however, we mention these two parties only.
Pacemaker Cloud API
-------------------
This is not a proper REST API, but the goal is to utilize the HTTP
verbs, content types, status codes, etc. in a way that a REST API would.
As such, the individual API calls will have most of the expected
semantics and behaviour while being fairly easy to implement.
We can extend this to full REST later if need be.
For each response, HTTP Status codes 2xx mean success, codes 4xx and 5xx
mean failure.
### Add a new hook ###
Conductor should be able to tell Pacemaker Cloud that it wants to
receive events:
POST /api/hooks HTTP/1.1
Content-type: application/xml
Accept: application/xml
<hook>
<
uri>https://aeolus-conductor.org/api/events</uri>
</hook>
---
HTTP/1.1 201 Created
Location:
https://pacemaker-cloud.org/api/hooks/f1e349df
Content-type: application/xml
<hook id="f1e349df" href="/api/hooks/f1e349df">
<
uri>https://aeolus-conductor.org/api/events</uri>
</hook>
### List existing hooks ###
GET /api/hooks HTTP/1.1
Accept: application/xml
---
HTTP/1.1 200 OK
Content-type: application/xml
<hooks>
<hook id="f1e349df" href="/api/hooks/f1e349df">
<
uri>https://aeolus-conductor.org/api/events</uri>
</hook>
<hook id="..." href="...">
<uri>...</uri>
</hook>
...
</hooks>
### Delete an existing hook ###
DELETE /api/hooks/f1e349df HTTP/1.1
---
HTTP/1.1 204 No Content
### Notify about deployment changes ###
When Conductor starts or stops a deployment, it will notify Pacemaker Cloud:
POST /api/events
Content-Type: application/xml
Date: Tue, 07 Sep 2011 08:12:26 GMT
<event>
<deployment id="1">
<instances>
<instance id="1" />
<instance id="2" />
<instance id="3" />
</instances>
<state>STARTED</state>
</deployment>
</event>
---
HTTP/1.1 200 OK
### Notify about instance changes ###
POST /api/events
Content-Type: application/xml
Date: Tue, 07 Sep 2011 08:12:31 GMT
<event>
<instance id="2">
<state>STARTED</state>
</instance>
</event>
---
HTTP/1.1 200 OK
Conductor Event Notification API
--------------------------------
All Pacemaker Cloud events are sent to single URL. It's the one that
Conductor registers in Pacemaker Clouds' hooks.
### Notify about deployment changes ###
POST /api/events
Content-Type: application/xml
Accept: application/xml
Date: Tue, 07 Sep 2011 08:12:26 GMT
<event>
<deployment id="1">
<state>STOPPED</state>
</deployment>
</event>
---
HTTP/1.1 201 Created
Content-Type: application/xml
Location: /api/events/3141
<event id="3141" href="/api/events/3141">
<deployment id="1" href="/api/deployments/1">
<state>STOPPED</state>
</deployment>
<datetime>2011-09-07T08:12:26Z</datetime>
</event>
### Notify on instance change ###
POST /api/events
Content-Type: application/xml
Accept: application/xml
Date: Tue, 07 Sep 2011 08:12:31 GMT
<event>
<instance id="2">
<state>STOPPED</state>
</instance>
</event>
---
HTTP/1.1 201 Created
Content-Type: application/xml
Location: /api/events/5926
<event id="5926" href="/api/events/5926">
<instance id="2"
href="/api/deployments/1/instances/2">
<state>STOPPED</state>
</instance>
<datetime>2011-09-07T08:12:31Z</datetime>
</event>
Authentication
--------------
We need to figure out how to securely authenticate Pacemaker Cloud to
Conductor.
IDs
---
The deployment and instance ID attributes are the Conductor IDs. They
are specified by Conductor when it sends requests to Pacemaker Cloud and
Pacemaker Cloud must use the same IDs when talking back to Conductor.