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/ __________________________________________________________________
