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
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
+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
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
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.
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 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/
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
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
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
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,
>>
>>
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
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
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
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
[
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:
--
[
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
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
+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
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
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
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
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
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
25 matches
Mail list logo
