Hi folks,
// cross-post stratos and brooklyn mailing lists
Two suggestions.
First one is that Stratos should look at adopting at least one of these
official specs -- CAMP or TOSCA -- now rather than later. Both have
matured a lot in recent months and would suit the purpose nicely from
what I see. "Cartridges" seem to map fairly neatly into CAMP components
/ TOSCA nodes, and "dependencies" to
requirements/characteristics/relationships.
Disclaimer: I am on the TC for these specs, but mainly because I don't
like different, proprietary formats unless there is a real need for it,
hence making this suggestion! It would also have the nice benefit of
aligning Apache Stratos with OpenStack projects Heat and Solum as well
as neighbouring Apache (incubating) project Brooklyn [1].)
Second suggestion is that Stratos could leverage some of the work we've
been doing in Apache-incubating Brooklyn.
Last week CAMP support was officially contributed -- both YAML
description and REST API (although a slightly out-of-date version, to be
updated soon!). We're expecting to have TOSCA simple profile YAML
support developed this year.
Brooklyn is Java-based, lower level than Stratos, designed to support
exactly the type of service composition designed here, so I think it
could be a good fit saving a lot of headaches and wheel-reinvention.
There is some overlap but essentially Brooklyn does NOT try to be the
services, it is great and composition, management, and clouds, but
agnostic about the things Stratos cares most about, at least from what I
understand.
Another disclaimer: I am on PPMC for Brooklyn. That said, if we in the
Brooklyn community can help, please let us know. Some of you may know
us from lots of jclouds contributions or early Stratos discussions.
We're also on IRC at #brooklyncentral.
Best
Alex
[1] http://brooklyn.incubator.apache.org/
On 04/07/2014 15:16, Imesh Gunaratne wrote:
[Added Sanjiva to the list]
Hi All,
IMO this composite application model is really important for the
future of Stratos and it will become the foundation for all other
features. Therefore we need to make sure that it is simple, easy to
understand, covers all currently available requirements and easy to
extend. At some point we might need to add extensions to support well
known similar specifications such as CAMP, CloudML and TOSCA.
At present I do not see much feedback from the community on this.
Shall we walk through this and suggest refinements? I had some
concerns and added them to the below document [1]. @IsuruH: Is the
document up to date?
[1]
https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit#
Thanks
On Thu, Jul 3, 2014 at 12:22 PM, Isuru Haththotuwa <isu...@apache.org
<mailto:isu...@apache.org>> wrote:
For the initial implementation for persisting Service Group
Definitions, the functionality will cover:
1. Nested Service Groups
2. Validation of the availability of referred Service Groups and
Cartridges
I have copy-pasted two sample Service Group definitions [1, 2]
below. [2] is a nested group.
[1].
{
"name": "group1",
"cartridges": [
"mysql", "mongoDB"
],
"dependencies": {
"killBehaviour": "kill-none"
}
}
[2].
{
"name": "group2",
"subGroups": [
"group1"
],
"cartridges": [
"php"
],
"dependencies": {
"startupOrder": [
{
"start": "group.group1",
"after": "cartridge.php"
}
],
"killBehaviour": "kill-dependents"
}
}
On Mon, Jun 2, 2014 at 10:52 AM, Isuru Haththotuwa
<isu...@apache.org <mailto:isu...@apache.org>> wrote:
Hi Devs,
This is an addition to the discussion happened in the thread
[1]. I have included a very basic sequence diagram to show the
flow of how Service Grouping would happen for the initial
implementation.
composite_app_1.png
<https://docs.google.com/a/wso2.com/file/d/0B4pCC9A49FwCRDhqQ0JDRl9tQjA/edit?usp=drive_web>
Short description of the flow:.
1, 2 & 3. Deploy Components' Definitions that would be
included in the top level Composite Application. Typically, a
component would map to a single cartridge. For sample JSON
definitions of a component, please refer [1].
4. Deploy a Group Definition, which would logically group the
relevant components. This would include information on the
Startup Order of each component, and how to handle the
termination/error situations as well (Kill Behavior).
5. Deploy a Nested Group Definition, which would contain
one/more of Components and Groups.
6. Deploy the Composite Application Definition. This would map
to the operation 'Subscription' which we have currently, when
spinning up a single cartridge instance. As per the discussion
that took place in the above mentioned thread, this was
decided to be called the 'Composite Application Definition'
deployment, rather than a Subscription.
For the initial version, we can restrict this Composite
Application Definition only to contain information for each
group/component, such as aliases, git repositories and
relevant info as required, etc., and not allow further
grouping at this level.
A typical basic Composite Application Definition, in JSON
format, would be as follows:
{
"name": "group2",
"alias": "<group2_alias>",
"components": [
{
"name": "component2",
"alias": "<component2_alias>",
"repoUrRL": "<repo_url>"
}
],
"groups": [
{
"name": "group1",
"alias": "group1_alias",
"components": [
{
"name": "component1",
"alias": "<component1_alias>",
"xxx": "<xxx>"
},
{
"name": "component3",
"alias": "<component3_alias>",
"yyy": "<yyy>"
}
]
}
]
}
More information is available in the above mentioned mail
thread and in [2]. Please share your feedback on this.
[1]. [Discuss] Grouping of services (cartridges)
[2].
https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit#
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PPMC Member, Apache Stratos
