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
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Scott
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Scott
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Sun, 2011-08-21 at 14:38 -0700, 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
I think you're missing a lot of background here. The basic idea is that conductor knows the state of deployments/instances and pacemaker wants to be notified of state changes? Pacemaker will have policy around how to react to state changes, e.g. it may restart an instance if it goes down?
A proposed API model follows:
It looks like you're aiming for this to be a RESTful API, so I'll make some suggestions based on that assumption
Also, this looks very much like an API for managing web hooks (webhooks.org) so I'd stick with the "hook" terminology and try to learn lessons from other web hook management APIs
Exported from the management system
POST api/monitors/add
Add a third party monitor to a list of monitors maintained by the management system
In RESTful API design terms, monitors are resources and you're modelling the creation of a new monitor resource in the monitors collection
You don't need to encode "add" in the URI, that's implicit in the HTTP POST method
inputs: internet protocol address, port, and version of a third party software component implementing the monitoring API
RESTful APIs are all about the representation of resources, so you should be POSTing a (XML/JSON/whatever) representation of the resource to the collection
outputs: monitor identifier and success or failure
Identifiers for resources in RESTful APIs are URIs. You'd return the URI of the newly created resource using the Location: header
And failure/success of any HTTP method should be indicated using HTTP status codes
Also, the POST response should contain a representation of the newly created resource
Bringing all that together, I'd suggest:
POST /api/hooks HTTP/1.1 Content-type: application/xml Accept: application/xml
<hook> <uri>http://thirdpartymonitor.org/api/event</uri> </hook>
HTTP/1.1 201 Created Location: http://myconductor.org/api/hooks/f1e349df Content-type: application/xml
<hook id="f1e349df" href="/api/hooks/f1e349df"> <uri>http://thirdpartymonitor.org/api/events</uri> </hook>
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
This should simply be:
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
Hi Steven,
(Sorry for fat fingers sending an unfinished draft of the mail earlier)
On Sun, 2011-08-21 at 14:38 -0700, 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
I think you're missing a lot of background here. The basic idea is that conductor knows the state of deployments/instances and pacemaker wants to be notified of state changes? Pacemaker will have policy around how to react to state changes, e.g. it may restart an instance if it goes down?
A proposed API model follows:
It looks like you're aiming for this to be a RESTful API, so I'll make some suggestions based on that assumption
Also, this looks very much like an API for managing web hooks (webhooks.org) so I'd stick with the "hook" terminology and try to learn lessons from other web hook management APIs
Exported from the management system
POST api/monitors/add
Add a third party monitor to a list of monitors maintained by the management system
In RESTful API design terms, monitors are resources and you're modelling the creation of a new monitor resource in the monitors collection
You don't need to encode "add" in the URI, that's implicit in the HTTP POST method
inputs: internet protocol address, port, and version of a third party software component implementing the monitoring API
RESTful APIs are all about the representation of resources, so you should be POSTing a (XML/JSON/whatever) representation of the resource to the collection
outputs: monitor identifier and success or failure
Identifiers for resources in RESTful APIs are URIs. You'd return the URI of the newly created resource using the Location: header
And failure/success of any HTTP method should be indicated using HTTP status codes
Also, the POST response should contain a representation of the newly created resource
Bringing all that together, I'd suggest:
POST /api/hooks HTTP/1.1 Content-type: application/xml Accept: application/xml
<hook> <uri>http://thirdpartymonitor.org/api/event</uri> </hook>
HTTP/1.1 201 Created Location: http://myconductor.org/api/hooks/f1e349df Content-type: application/xml
<hook id="f1e349df" href="/api/hooks/f1e349df"> <uri>http://thirdpartymonitor.org/api/events</uri> </hook>
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
This should simply be:
DELETE /api/hooks/f1e349df HTTP/1.1
HTTP/1.1 204 No Content
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
This would be:
GET /api/hooks HTTP/1.1 Accept: application/xml
<hooks> <hook id="f1e349df" href="/api/hooks/f1e349df"> <uri>http://thirdpartymonitor.org/api/events</uri> </hook> <hook id="290ceba7" href="/api/hooks/290ceba7"> <uri>http://thirdpartymonitor.org/api/events</uri> </hook> ... </hooks>
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
I'm not sure what you're modelling here - informing conductor that the state of deployment or instance has changed?
That would be e.g.
PUT /api/instances/1bde3254 HTTP/1.1 Content-Type: application/xml Accept: application/xml
<instance> <state>FAILED</state> </instance>
HTTP/1.1 200 OK Content-Type: application/xml
<instance id="1bde3254" href="/api/instances/1bde3254"> <name>foo</name> <state>FAILED</state> .... </instance>
Or perhaps you meant this as an API for triggering hooks for test purposes? In that case, I'd model it as creating a new event under a hook:
POST /api/hooks/f1e349df/events HTTP/1.1 Content-type: application/xml Accept: application/xml
<event> <instance id="1bde3254"/> <state>FAILED</state> </hook>
HTTP/1.1 201 Created Location: http://myconductor.org/api/hooks/50634f21 Content-type: application/xml
<event id="50634f21" href="/api/hooks/f1e349df/events/50634f21"> <instance id="1bde3254" href="/api/instances/1bde3254"/> <state>FAILED</state> </event>
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
I think we only need one entry-point here - a single URI where conductor will POST a representation of an event to a third part app, so e.g.
POST /api/events HTTP/1.1 Content-Type: application/xml
<event> <instance id="1bde3254" href="http://myconductor.org/api/hooks/f1e349df/events/50634f21"/> <state>FAILED</state> </hook>
HTTP/1.1 204 No Content
Cheers, Mark.
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@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_Cloud_a...
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.
aeolus-devel@lists.fedorahosted.org
-
Mark McLoughlin -
Scott Seago -
Steven Dake -
Tomas Sedovic