I totally agree, I am also not in favor of complicating existing components (e.g. autoscaler).
However, I am not sure what the alternative might be to solve the requirements (e.g. item 1) mentioned below. The suggestion I made to enhance the autoscaler / rules are based on my understanding that the autoscaler already handles similar actions (e.g. VM startup, scaling and termination). It seems to me a logical extension to add additional knowledge to handle the boot sequencing, dependent scaling and dependent termination to the autoscaler defined by optional properties in the autoscaler policy. >From my current point of view, CAMP seems a fairly complex specification which >might require quite some changes to adopt. I do agree that alternatives might exist and should be discussed !? Alternatives ? Thanks Martin From: damitha kumarage [mailto:[email protected]] Sent: Sunday, March 30, 2014 7:59 AM To: [email protected] Subject: Re: [Discuss] Grouping of services (cartridges) Please see my inline comment, On Sat, Mar 29, 2014 at 11:53 AM, Isuru Haththotuwa <[email protected]<mailto:[email protected]>> wrote: Hi Martin, On Fri, Mar 28, 2014 at 11:19 PM, Martin Eppel (meppel) <[email protected]<mailto:[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). I see three things here 1) Grouping and resolve inter-dependancies between cartridges. 2) Composite Artifact deployment (May be if required, according to the above grouping and inter-dependancy( of cartridges. There can also be intra-dependancies inside a cartridge in case of artifact deployment) 3) Improved nonitoring and health check of above intricacies. Instead of adopt CAMP to solve above, I think it is better to discuss and find ways that fits most naturally to the existing Stratos architecture(Unless CAMP is widely adopted and we are compelled to adhere). Is there a way we can solve this without doing major changes to existing components? For example without complicating autoscaler policies/logic as suggested by Martin above? Damitha -- __________________________________________________________________ Damitha Kumarage http://people.apache.org/ __________________________________________________________________
