Hi Martin, On Fri, Mar 28, 2014 at 11:19 PM, Martin Eppel (meppel) <[email protected]>wrote:
> Hi, > > > > I think this property will be a quite useful piece to solve the grouping > issue: > > > > I also would like to suggest to add the serviceGroup to the topology map > (in case it is not yet available in the topology map). This will help to > tie together cartridges (or services) in the autoscaler and , for example > enable synchronized auto scaling behavior of services within a service > group, like synchronized scaling, sequenced boot up, etc .... > > > > In addition the autoscaler should be enhanced to add additional (but > optional properties) in the auto scaling policy related to a service group > to govern the respective auto scaling behavior. > > > > For example, related properties should identify a service group and other > related properties to define dependencies between the various cartridges in > the service group like boot sequence, scale up / down ratios, termination > dependencies, etc ... . The property set (or json structure ) should be > fairly flexible as we are just about to explore this new feature and should > be easily expandable. > > > > I would think that these additions will also prove useful to integrate in > the long term with CAMP (or other spec) but will help to solve more > immediate requirements > Yes, these are very valid points in coming up with a proper grouping architecture for services. Thank you for bringing them up. As I understand, what Sajith has done here is enabling static grouping of services, by using a property for that in the cartridge deployment time. What we are trying to achieve in long term is dynamic grouping of services, so that we can group any available service at runtime seamlessly, according to CAMP specification (or some other suitable way). For that, we might need to do changes to the whole platform as required, and we might need to introduce the relevant changes that you have noted as well. > > > Btw, I am currently looking into this > Great! I too will look in to this. > > > What do you think ? > > > > Thanks > > > > Martin > > > > *From:* Jeffrey Nguyen (jeffrngu) > *Sent:* Thursday, March 27, 2014 8:23 AM > *To:* Sajith Kariyawasam > *Cc:* [email protected]; Martin Eppel (meppel) > > *Subject:* Re: [Discuss] Grouping of services (cartridges) > > > > > > Thank you Sajith. It seems we could leverage this grouping property as a > short term solution to manage cartridges while we're waiting for a longer > term solution. > > > > -Jeffrey > > > > *From: *Sajith Kariyawasam <[email protected]> > *Date: *Thursday, March 27, 2014 12:20 AM > *To: *jeffrngu <[email protected]> > *Cc: *"[email protected]" <[email protected]>, > "Martin Eppel (meppel)" <[email protected]> > *Subject: *Re: [Discuss] Grouping of services (cartridges) > > > > > > On Thu, Mar 27, 2014 at 1:38 AM, Jeffrey Nguyen (jeffrngu) < > [email protected]> 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? > > > > > > Hi Jeffrey, > > > > I added that property to allow simple grouping of cartridges. Cartridges > having the same group name will be displayed in a group in UI so that > subscriptions can be done to that group. > > > > Thanks, > Sajith > > > > Thanks, > > -Jeffrey > > > > > > > > *From: *Lakmal Warusawithana <[email protected]> > *Reply-To: *"[email protected]" < > [email protected]> > *Date: *Monday, March 17, 2014 8:17 PM > *To: *"[email protected]" <[email protected] > > > *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 <[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/ > > > > > > -- > > *Sajith Kariyawasam* > > *Senior Software Engineer; WSO2, Inc.* > > *AMIE (SL)* > > *Blog: http://sajithblogs.blogspot.com/ <http://sajithblogs.blogspot.com/>* > > *Mobile: +94772269575 <%2B94772269575>* > -- Thanks and Regards, Isuru H. +94 716 358 048
