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 <[email protected]>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) 
> <[email protected]>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/

Reply via email to