stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Haththotuwa <isu...@wso2.com>
Subject Re: [Discuss] Grouping of services (cartridges)
Date Thu, 27 Mar 2014 07:41:31 GMT
Hi,

Great work Imesh.

I myself did some research on this some time back. As Imesh had explained,
CAMP spec defines a uniform way to represent platforms (platform
resources), services (assembly resources)  and their relationships (in this
case, grouping/composition). I too will send a detailed mail with what I
found.


On Thu, Mar 27, 2014 at 7:33 AM, Martin Eppel (meppel) <meppel@cisco.com>wrote:

>  Great,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Imesh Gunaratne [mailto:imesh@apache.org]
> *Sent:* Wednesday, March 26, 2014 6:43 PM
> *To:* dev@stratos.incubator.apache.org
> *Cc:* sajith@wso2.com; Martin Eppel (meppel)
>
> *Subject:* Re: [Discuss] Grouping of services (cartridges)
>
>
>
> Hi,
>
>
>
> Actually I did some research on composite service deployment support in
> CAMP specification [1] during past few weeks.
>
>
>
> I will send a separate mail with detailed information, to add a brief
> description to this discussion, CAMP provides a domain model for defining
> relationships among Platforms, Plans, Services, Components, Assemblies,
> etc. Based on this domain model CAMP defines an archive file format called
> Platform Deployment Package (PDP) which could be used for defining
> composite service definitions which ensures portability across platforms.
>
>
>
> A PDP would contain a plan definition which internally defines a set of
> services which will be deployed for the given plan:
>
>
>
> Plan Definition:
>
> {
>
>   "uri": URI,
>
>   "name": String,
>
>   "type": "plan",
>
>   "description": String ?,
>
>   "tags": String[] ?,
>
>   "representation_skew": String ?,
>
>   "camp_version": String,
>
>   "origin": String ?,
>
>   "artifacts": [
>
>     {
>
>       "name": String ?,
>
>       "description": String ?,
>
>       "tags": String[] ?,
>
>       "artifact_type": String,
>
>       "content": { "href": URI },
>
>       "requirements": [
>
>         {
>
>           "requirement_type": String,
>
>           "fulfillment": {
>
>             "name": String ?,
>
>             "description": String ?,
>
>             "tags": String[] ?,
>
>             "id": String ?,
>
>             "href": URI ?,
>
>             "characteristics": {
>
>               characteristic: String +
>
>             }
>
>           } ?
>
>         } +
>
>       ] ?,
>
>     } +
>
>   ] ?,
>
>   "services": [
>
>     {
>
>       "name": String ?,
>
>       "description": String ?,
>
>       "tags": String[] ?,
>
>       "id": String ?,
>
>       "href": URI ?,
>
>       "characteristics": {
>
>         characteristic: String +
>
>       }
>
>     } +
>
>   ] ?
>
> }
>
>
>
> If we compare this model with what we currently use in Stratos 4.0.0 for
> deploying services I think we could adapt CAMP specification without much
> of a problem.
>
>
>
> I'm currently looking into this, will post more information soon.
>
>
>
> [1] https://issues.apache.org/jira/browse/STRATOS-519
>
>
>
> Thanks
>
>
>
> On Wed, Mar 26, 2014 at 4:08 PM, Jeffrey Nguyen (jeffrngu) <
> jeffrngu@cisco.com> wrote:
>
> Hi Martin,
>
>
>
> I just saw this commit *e20b3ea41b9f692f16567cce4e8cc7dc241e5ce6* (Adding
> internal repo based cartridge subscription. Adding service group property
> to Cartridge definition) today.   Looks like Sajith just added an
> enhancement to allow grouping of services.
>
>
>
> Sajith,
>
>
>
> Can you comment on the use of the new service group property?
>
>
>
> Thanks,
>
> -Jeffrey
>
>
>
>
>
>
>
> *From: *Lakmal Warusawithana <lakmal@wso2.com>
> *Reply-To: *"dev@stratos.incubator.apache.org" <
> dev@stratos.incubator.apache.org>
> *Date: *Monday, March 17, 2014 8:17 PM
> *To: *"dev@stratos.incubator.apache.org" <dev@stratos.incubator.apache.org
> >
> *Subject: *Re: [Discuss] Grouping of services (cartridges)
>
>
>
> Hi Martin,
>
>
>
> As Nirmal mention, we can looked at CAMP support for composite application
> deployment. It is great if you can do some R&D on it. We have to focus on
> following, which came to my mind at this point
>
>    - How we can group cartridges (cartridge type, versioning etc.)
>    - Need to identifying cupeling pattens. loosely coupled or tiredly
>    coupled. For eg. some scenario we have to group application cartridge with
>    data cartridges, in that case best is run in single network partition. This
>    is somewhat tiredly coupled. So scaling them into deferent region, we have
>    to maintain these coupling. (sometime we have to maintain ratio of the
>    cartridge dependency)
>    - How can we deploy composite application artifacts into relevant
>    cartridges. (single repository maintain artifacts for all group cartridges.
>    Artifact distribution coordinator which reside in SM need to distribute
>    among dependance cartridges)
>    - think about scale up/down scenarios
>    - Start dependancies
>
>
>
> IMO we can bring this support on 4.1.0/4.2.0 release.
>
>
>
> thanks
>
>
>
> On Tue, Mar 18, 2014 at 7:57 AM, Nirmal Fernando <nirmal070125@gmail.com>
> wrote:
>
> Hi Martin,
>
> Sometime back Paul suggested Stratos to use the CAMP specification
> http://www.infoq.com/news/2012/08/CAMP-PaaS
>
> May be you can get some ideas out of it.
>
>
>
> On Mon, Mar 17, 2014 at 4:55 PM, Martin Eppel (meppel) <meppel@cisco.com>
> wrote:
>
> Hi,
>
> I am looking into some enhancements to the stratos controller that would
> allow us to group cartridges (= services) together and have them behave in
> synch like a group.
>
> Examples would be
> - maintaining a boot sequence (e.g. for service A to boot up service B
> needs to be up, etc ...),
> - scaling of a group of services (if service A needs to scale up, service
> B and C also need to scale up)
> - restart (e.g. based on health monitoring, e.g. if service B is unhealthy
> restart service B and A)
>
> Some idea which comes to mind is to define the dependencies and extend
> current autoscaler rules to handle the various scenarios or define a new
> message type which could trigger specific rules.
>
> Any thoughts on that how to support this ?
>
> Thanks
>
> Martin
>
>
>
>   --
>
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
>
>
> Blog: http://nirmalfdo.blogspot.com/
>
>
>
>
>
> --
>
> Lakmal Warusawithana
>
> Software Architect; WSO2 Inc.
>
> Mobile : +94714289692
>
> Blog : http://lakmalsview.blogspot.com/
>
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PPMC Member, Apache Stratos
>



-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* <http://wso2.com/>*

Mime
View raw message