Re: [Discussion] [STRATOS-680] Allow users to install stratos from distribution binaries

2014-07-07 Thread Isuru Perera
Can we have separate git repos for Puppet files and installer? On Mon, Jul 7, 2014 at 7:44 PM, Nirmal Fernando wrote: > > > > On Sun, Jul 6, 2014 at 6:36 AM, Dakshika Jayathilaka > wrote: > >> Hi, >> >> Before we fix $subject[1] we need to have proper discussion on $subject. >> This comes to l

Re: servicegroup filed

2014-07-07 Thread Sajith Kariyawasam
Hi Martin, serviceGroup was introduced to achieve simple cartridge grouping in the commit e20b3ea41b9f692f16567cce4e8cc7dc241e5ce6 According to your exception, it seems to me that the CloudControllerService.wsdl in your org.apache.stratos.cloud.controller.stub bundle is different from what's ther

Re: Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Dakshika Jayathilaka
+1 for having proper back end error mechanism for end users, but when we are designing it has to adhere some proper standard, coz this is community project and many contributors may take part on this. If we loosed the concepts on starting point that will deviate whole concept of having standardiza

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Lakmal Warusawithana
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

Re: Has stratos ever used AMQP?

2014-07-07 Thread Dinesh Bandara
Hi Chris, To use AMQP with stratos, we have to use client library [1] but it will be a barrier to use another Message Broker other than ActiveMQ. I did some basic tests with RabbitMQ python clients and further need to find out the compatibility with ActiveMQ. [1] http://activemq.apache.org/amqp.

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Nirmal Fernando
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

Re: [Discussion] [STRATOS-680] Allow users to install stratos from distribution binaries

2014-07-07 Thread Nirmal Fernando
On Sun, Jul 6, 2014 at 6:36 AM, Dakshika Jayathilaka wrote: > Hi, > > Before we fix $subject[1] we need to have proper discussion on $subject. > This comes to live due to initial email discussion[2] [3].Chris proposed > some of the suggestions as below. > > Proposed changes: > > 1) Rename /tools/

[DISCUSS] Apache Stratos Board Report for July 2014

2014-07-07 Thread Lakmal Warusawithana
Hi Folks, Please find the prepared board report for July. Please let me know if anything missed here. Apache Stratos Report for July 2014 === Apache Stratos is a highly-extensible Platform-as-a-Service (PaaS) framework that helps run Apache Tomcat, PHP, and MySQ

Re: [Discussion] [STRATOS-680] Allow users to install stratos from distribution binaries

2014-07-07 Thread chris snow
Hi Devs, does anyone have a view on these changes? On Sun, Jul 6, 2014 at 2:36 PM, Dakshika Jayathilaka wrote: > Hi, > > Before we fix $subject[1] we need to have proper discussion on $subject. > This comes to live due to initial email discussion[2] [3].Chris proposed > some of the suggestions as

Re: Stratos-701 : References to 'incubator' in the code base

2014-07-07 Thread chris snow
Hi Rajkumar, >From [1]: "An archive which contains the standard Apache Incubator disclaimer." - I would say that this can be removed. Cheers, Chris --- [1] http://mvnrepository.com/artifact/org.apache/apache-incubator-disclaimer-resource-bundle On Mon, Jul 7, 2014 at 7:41 AM, Rajkumar Rajaratna

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Lahiru Sandaruwan
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

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Udara Liyanage
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, >> >>

Re: Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Udara Liyanage
Hi Dakshita, I am really worried about the structure of the response rather than what values it should output. What I wanted to tell is every API call should send response adhering to that format regardless of the fields it has. For a REST client for Stratos, http status code is important in very

servicegroup filed

2014-07-07 Thread Martin Eppel (meppel)
I merged our experimental code with the 4.0.0 apache stratos and I am getting an exception related to the (new ?) field serviceGroup, any clue what is missing or expected in the subscription ? Thanks Martin TID: [0] [STRATOS] [2014-07-07 14:14:19,508] ERROR {org.apache.stratos.manager.manag

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Lahiru Sandaruwan
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

Re: Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Dakshika Jayathilaka
There are some instances we need to have HTTP status + attribute details on body. ex: *409 conflict: *can return in different scenarios, so we need to implement some differentiation mechanism if you check HTTP/1.1[1] spec its clearly mention this: The response body SHOULD include enough informa

[jira] [Comment Edited] (STRATOS-702) HAProxy Extension won't update it's member list

2014-07-07 Thread Dinesh Bandara (JIRA)
[ https://issues.apache.org/jira/browse/STRATOS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053544#comment-14053544 ] Dinesh Bandara edited comment on STRATOS-702 at 7/7/14 10:59 AM: --

[jira] [Commented] (STRATOS-702) HAProxy Extension won't update it's member list

2014-07-07 Thread Dinesh Bandara (JIRA)
[ https://issues.apache.org/jira/browse/STRATOS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053544#comment-14053544 ] Dinesh Bandara commented on STRATOS-702: Changes committed 4.0.0 - 37372c2e78e17

Re: Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Imesh Gunaratne
Udara, there are few other important points: * Introduce versioning to the API and preserve v1.0 released with Stratos 4.0.0 for a certain time period. * introduce token based authentication. May be we could do these with separate tasks. Thanks On Monday, July 7, 2014, Imesh Gunaratne wrote

Re: Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Imesh Gunaratne
+1 Definitely, we need to do this. Jsend spec looks good, but I wonder whether we need a status attribute since HTTP status code already does that. One other important fact is that we need to document the API definition very well with samples. Thanks On Monday, July 7, 2014, Udara Liyanage wro

Re: Service Grouping and Composite Application Deployment

2014-07-07 Thread Alex Heneveld
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

Consistent Response structure for Stratos REST APIs

2014-07-07 Thread Udara Liyanage
HI, Currently different REST API methods sends response in different formats. Some API methods have Response as the return type and some have Response. IMO it is better if all the API methods fallow the same format. For instance [1] discuss a simple response format. [1] http://labs.omniti.com/lab

RE: Composite Application Definition with Reference to Deployed Service Groups

2014-07-07 Thread Martin Eppel (meppel)
Hi Isuru, I think this is a good idea: question regarding the json format below, in a previous email I think we discussed to split the “subscribables” into “groups” (nested groups) and “cartridges”, is this still correct (see sample below) ? Also, I am not sure how the dependencies are describe

RE: Composite Application Deployment and Subscription - Single Alias for a Group

2014-07-07 Thread Martin Eppel (meppel)
HI Isuru, I agree, what about using the cartridge type ? If we have a single alias for each group do you mean for each cartridge type or for all cartridges, independently of the cartridge type of them (The question then would be how would we define our dependencies) ? Thanks Martin From: is

RE: Service Grouping and Composite Application Deployment

2014-07-07 Thread Martin Eppel (meppel)
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 per