On Mon, Mar 31, 2014 at 7:47 AM, Martin Eppel (meppel) <[email protected]>wrote:
> 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. > Sorry I could not go through CAMP in detail. Should spend sometime. > > I do agree that alternatives might exist and should be discussed !? > Alternatives ? > +1 for alternatives, we should not take CAMP as it is, we should see how we can match with existing Stratos workflow IMO. > > > 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]> > wrote: > > 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). > > > 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/ > __________________________________________________________________ > -- Lakmal Warusawithana Software Architect; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
