Hi Alex,
Thanks for bringing up this. IFAIK, couple of devs looked at CAMP, and its
really comprehensive spec. But IMHO, fully adopting to CAMP may be bit
harder. Stratos has already implemented some of them and writing for CAMP
is not such easy. But we have looked at CAMP when we started this gro
Thanks for bringing this up Alex. There're few people in the list who had a
look at the CAMP spec.
I totally agree, that we should leverage existing implementations such as
Brooklyn.
On Mon, Jul 7, 2014 at 2:47 AM, Alex Heneveld <
alex.henev...@cloudsoftcorp.com> wrote:
>
> Hi folks,
>
> // cros
On Mon, Jul 7, 2014 at 8:05 AM, Udara Liyanage wrote:
> HI Lahiru,
>
> As I understood, SM sends the details to the CC via service call or event
> based, then CC update the topology and publish topology events.
>
If so, Autoscaler does not need to get any information from the event
published by
HI Lahiru,
As I understood, SM sends the details to the CC via service call or event
based, then CC update the topology and publish topology events.
On Mon, Jul 7, 2014 at 6:09 PM, Lahiru Sandaruwan wrote:
>
>
>
> On Sun, Jul 6, 2014 at 9:39 PM, Isuru Haththotuwa
> wrote:
>
>> Hi Imesh,
>>
>>
On Sun, Jul 6, 2014 at 9:39 PM, Isuru Haththotuwa wrote:
> Hi Imesh,
>
> Yes, completely agree. Should have the proper documentation for this. Will
> do that once we have the basic version of this feature done.
>
> Hi Lahiru,
>
> On Sun, Jul 6, 2014 at 7:50 PM, Lahiru Sandaruwan
> wrote:
>
>> Hi
Hi folks,
// cross-post stratos and brooklyn mailing lists
Two suggestions.
First one is that Stratos should look at adopting at least one of these
official specs -- CAMP or TOSCA -- now rather than later. Both have
matured a lot in recent months and would suit the purpose nicely from
what
Great Thanks
Martin
From: isu...@wso2.com [mailto:isu...@wso2.com] On Behalf Of Isuru Haththotuwa
Sent: Thursday, July 03, 2014 9:22 AM
To: dev
Cc: Martin Eppel (meppel); Lakmal Warusawithana
Subject: Re: Service Grouping and Composite Application Deployment
For the initial implementation for
Hi Imesh,
Yes, completely agree. Should have the proper documentation for this. Will
do that once we have the basic version of this feature done.
Hi Lahiru,
On Sun, Jul 6, 2014 at 7:50 PM, Lahiru Sandaruwan wrote:
> Hi Isuru,
>
> Any reason why we use MB for subscription event? We can use dire
Hi Isuru,
Any reason why we use MB for subscription event? We can use direct service
call to CC IMO.
Thanks.
On Mon, Jun 2, 2014 at 10:52 AM, Isuru Haththotuwa
wrote:
> Hi Devs,
>
> This is an addition to the discussion happened in the thread [1]. I have
> included a very basic sequence diagr
Hi Isuru,
Thanks for the quick response.
>However, as we go along we might find that we don't need everything in the
proposal/ there additional functionality required.
May be not in this document but IMO the complete Composite Application
Model should be there in the documentation.
Thanks
On
Hi Imesh,
On Fri, Jul 4, 2014 at 7:46 PM, Imesh Gunaratne wrote:
> [Added Sanjiva to the list]
>
> Hi All,
>
> IMO this composite application model is really important for the future of
> Stratos and it will become the foundation for all other features. Therefore
> we need to make sure that it
[Added Sanjiva to the list]
Hi All,
IMO this composite application model is really important for the future of
Stratos and it will become the foundation for all other features. Therefore
we need to make sure that it is simple, easy to understand, covers all
currently available requirements and ea
For the initial implementation for persisting Service Group Definitions,
the functionality will cover:
1. Nested Service Groups
2. Validation of the availability of referred Service Groups and Cartridges
I have copy-pasted two sample Service Group definitions [1, 2] below. [2]
is a nested group.
13 matches
Mail list logo
