On Fri, Dec 5, 2014 at 12:06 PM, Udara Liyanage wrote:
> Hi,
>
> It seems we are getting the identity.xml from carbon.core feature.
> However there are additional files in below places.
>
> ./products/stratos/conf/identity.xml
>
> ./features/manager/common/org.apache.stratos.common.server.feature
Yeah, let's remove the java agent from our code base.
Thanks.
On Fri, Dec 5, 2014 at 12:07 PM, Lakmal Warusawithana
wrote:
>
>
> On Fri, Dec 5, 2014 at 11:56 AM, Rajkumar Rajaratnam
> wrote:
>
>> Hi,
>>
>> While doing topology changes, noticed that the java agent is still there
>> in code base
Hi Manula,
Renaming feature won't solve the issue coz services will be there even if
component is renamed. Will remove service from services.xml
On Fri, Dec 5, 2014 at 12:50 PM, Manula Chathurika Thantriwatte <
manu...@wso2.com> wrote:
> Hi Udara,
>
> Yes, this should come from stratos.common fe
Hi Udara,
Yes, this should come from stratos.common feature. Shall we rename it to
another name. Then this problem could be solved. WDYT ?
Thanks !
On Thu, Dec 4, 2014 at 8:59 PM, Udara Liyanage wrote:
> Hi Manula,
>
> I get a similar issue after adding oAuth feature. The reason is two
> featu
Github user asfgit closed the pull request at:
https://github.com/apache/stratos/pull/136
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is ena
[
https://issues.apache.org/jira/browse/STRATOS-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14235173#comment-14235173
]
ASF GitHub Bot commented on STRATOS-1023:
-
Github user asfgit closed the pull re
Github user shirolk commented on the pull request:
https://github.com/apache/stratos/pull/134#issuecomment-65753486
Closing since a newer pull request has been submitted
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If
Github user shirolk closed the pull request at:
https://github.com/apache/stratos/pull/134
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
GitHub user shirolk opened a pull request:
https://github.com/apache/stratos/pull/137
Changes for group monitor on the event of application creation and scaleup
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shirolk/stratos late
Hi,
It seems we are getting the identity.xml from carbon.core feature.
However there are additional files in below places.
./products/stratos/conf/identity.xml
./features/manager/common/org.apache.stratos.common.server.feature/src/main/resources/conf/identity.xml
The file comes with carbon.core
On Fri, Dec 5, 2014 at 11:56 AM, Rajkumar Rajaratnam
wrote:
> Hi,
>
> While doing topology changes, noticed that the java agent is still there
> in code base.
>
> If we are not maintaining, we can remove this component from the code base
> right?
>
> Otherwise, we have to maintain it properly.
>
Hi,
While doing topology changes, noticed that the java agent is still there in
code base.
If we are not maintaining, we can remove this component from the code base
right?
Otherwise, we have to maintain it properly.
wdyt?
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software
Hi,
Stratos REST API is used by clients (CLI,UI and curl) to manage stratos
system. However metadata API is supposed to used by cartridge agents to
publish and fetch metadata across application instances. Thus we have two
contexts.
On Fri, Dec 5, 2014 at 10:57 AM, Shiroshica Kulatilake
wrote:
On Fri, Dec 5, 2014 at 10:33 AM, Gayan Gunarathne wrote:
>
> IMO if we use metaapi/metadataapi , it will be too long and also don't
> see any usage of maintain the two levels in the URL.
>
> Can't we use only metadataapi or metadataservice?
>
I meant metaapi or metadataapi, not metaapi/metadataa
HI Raj,
On Fri, Dec 5, 2014 at 8:20 AM, Rajkumar Rajaratnam
wrote:
> Okay.
>
> @Reka, Please let me know when are done with testing.
>
Sure..We are in the process of stabilising grouping feature in the master.
Will update once we have the complete flow working fine..
>
> I will make a diff in
On Fri, Dec 5, 2014 at 10:52 AM, Gayan Gunarathne wrote:
> Meta data service is developed as a separate component.It can work as a
> independent component and main idea of this to deploy the service without
> Stratos.So it is not bundle in the common root.
>
OK - but when it is bundled with Str
Meta data service is developed as a separate component.It can work as a
independent component and main idea of this to deploy the service without
Stratos.So it is not bundle in the common root.
On Fri, Dec 5, 2014 at 10:39 AM, Shiroshica Kulatilake
wrote:
> I have a bit of a different question
Just realized that you are referring to the context not the web app name.
On Fri, Dec 5, 2014 at 7:52 AM, Nirmal Fernando
wrote:
> Why not meta-data-service?
>
> On Fri, Dec 5, 2014 at 6:54 AM, Dakshika Jayathilaka
> wrote:
>
>> +1
>>
>> *Dakshika Jayathilaka*
>> Software Engineer
>> WSO2, Inc.
I have a bit of a different question
Since both of these are for stratos should we have a common root ?
On Fri, Dec 5, 2014 at 10:33 AM, Gayan Gunarathne wrote:
>
> IMO if we use metaapi/metadataapi , it will be too long and also don't
> see any usage of maintain the two levels in the URL.
>
>
IMO if we use metaapi/metadataapi , it will be too long and also don't see
any usage of maintain the two levels in the URL.
Can't we use only metadataapi or metadataservice?
On Fri, Dec 5, 2014 at 7:52 AM, Nirmal Fernando
wrote:
> Why not meta-data-service?
>
> On Fri, Dec 5, 2014 at 6:54 AM,
On Fri, Dec 5, 2014 at 10:03 AM, Martin Eppel (meppel)
wrote:
> So if I understand this correctly, partitions are now deployed together
> with the deployment policy ?
>
>
>
> Previously we had the following RestAPI to deploy partitions :
>
>
>
> https://127.0.0.1:9443/api/v4.1/policy/deployment/
So if I understand this correctly, partitions are now deployed together with
the deployment policy ?
Previously we had the following RestAPI to deploy partitions :
https://127.0.0.1:9443/api/v4.1/policy/deployment/partition
and to deploy deployment policies:
https://127.0.0.1:9443/api/v4.1/pol
Hi Raj,
Sure, I will do the changes related. Please notify this thread when the
changes are committed.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Fri, Dec 5, 2014 at 9:28 AM, Rajkumar Rajaratnam
wrote:
> Hi Chamila,
>
> Thanks for poin
Hi Chamila,
Thanks for pointing out this.
Will you be able to do this python changes, as I am not much aware of this
python stuff :)
Thanks.
On Fri, Dec 5, 2014 at 9:10 AM, Chamila De Alwis wrote:
> Hi Raj,
>
> This will also affect the Python agent behavior, where the Topology event
> deseri
Hi Raj,
This will also affect the Python agent behavior, where the Topology event
deserialization happens out of the Java based messaging component. So let's
include that task as well, as a dependent.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
Ok, I see - I think you are right, the sample in the below mentioned email
thread (Aplication_Gloabl_Dep_Policy.json) has the partitions, so I guess I
just need to deploy the definition as shown in the sample to get partitions
deployed, just wondering which API to use in StratosApiV41 ?
Thanks
Hi Martin,
To deploy a deployment policy you can use something like below; so path is,
POST /api/deploymentPolicies
curl -X POST -H "Content-Type: application/json" -d@'deployment-policy.json'
-k -v -u admin:admin https://localhost:9443/api/deploymentPolicies
On Fri, Dec 5, 2014 at 8:36 AM, Mart
Okay.
@Reka, Please let me know when are done with testing.
I will make a diff in meantime.
Thanks.
On Fri, Dec 5, 2014 at 8:08 AM, Lakmal Warusawithana
wrote:
> Sure, shall we do this after complete full work flow test in grouping.
>
> On Fri, Dec 5, 2014 at 8:00 AM, Rajkumar Rajaratnam
> w
Hi
On Fri, Dec 5, 2014 at 7:51 AM, Nirmal Fernando
wrote:
> Hi Martin,
>
> We do not deploy partitions alone any more right? Partitions are declared
> in deployment policy, aren't they?
>
>
Yes, thats correct. Sorry Martin for the confusion, there are lot of mail
discussion here and there, no on
Sure, shall we do this after complete full work flow test in grouping.
On Fri, Dec 5, 2014 at 8:00 AM, Rajkumar Rajaratnam
wrote:
> Hi,
>
> Please let me know the decision on this before code freeze. This is a
> simple change to do.
>
> Thanks.
>
> On Fri, Dec 5, 2014 at 1:41 AM, Rajkumar Rajara
Hi,
Please let me know the decision on this before code freeze. This is a
simple change to do.
Thanks.
On Fri, Dec 5, 2014 at 1:41 AM, Rajkumar Rajaratnam
wrote:
> Hi Devs,
>
> I have integrated multiple network interfaces support into the master
> branch and it is working fine.
>
> Now we sho
Hi Martin,
We do not deploy partitions alone any more right? Partitions are declared
in deployment policy, aren't they?
On Fri, Dec 5, 2014 at 7:37 AM, Martin Eppel (meppel)
wrote:
>
>
> Ok, I realized that we changed the RestAPIs for autoscale, deployment
> policy and service group deployment
Why not meta-data-service?
On Fri, Dec 5, 2014 at 6:54 AM, Dakshika Jayathilaka
wrote:
> +1
>
> *Dakshika Jayathilaka*
> Software Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Thu, Dec 4, 2014 at 11:26 PM, Udara Liyanage wrote:
>
>> Hi All,
>>
>> Similar to we rename St
Ok, I realized that we changed the RestAPIs for autoscale, deployment policy
and service group deployment, not sure however how a partition definition is
deployed, the ".../partitions" RestAPi is commented out ?
From: Martin Eppel (meppel)
Sent: Thursday, December 04, 2014 5:43 PM
To: dev@str
Hi,
I tried with the latest code from the master (Dec-04) to deploy autoscale, ,
deployment and partition policy but they all fail with an
"AccessDeniedException" exception as below. I understand that we will be moving
to a new format for application deployment (see email thread "Global Deploym
+1
*Dakshika Jayathilaka*
Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Thu, Dec 4, 2014 at 11:26 PM, Udara Liyanage wrote:
> Hi All,
>
> Similar to we rename Stratos => "api', shall we rename
> stratomedataservice => metaapi/metadataapi
> --
>
> Udara Liyanage
> Softwa
Hi Devs,
I have integrated multiple network interfaces support into the master
branch and it is working fine.
Now we should modify the topology to include list of private/public IP
addresses. Currently topology and topology events supports max of one
public IP and one private IP.
Can I go ahead
Udara Liyanage created STRATOS-1024:
---
Summary: Service already registered
Key: STRATOS-1024
URL: https://issues.apache.org/jira/browse/STRATOS-1024
Project: Stratos
Issue Type: Bug
Hi All,
Similar to we rename Stratos => "api', shall we rename stratomedataservice
=> metaapi/metadataapi
--
Udara Liyanage
Software Engineer
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware
web: http://udaraliyanage.wordpress.com
phone: +94 71 443 6897
[
https://issues.apache.org/jira/browse/STRATOS-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234327#comment-14234327
]
ASF GitHub Bot commented on STRATOS-1023:
-
GitHub user swgkg opened a pull reque
GitHub user swgkg opened a pull request:
https://github.com/apache/stratos/pull/136
Add the rest api operation for list cartridges based on the cartridge
provider
Related JIRA: STRATOS-1023
Please review and merge
You can merge this pull request into a Git repository by ru
Hi Nirmal,
Sorry for the late response.
Shall we keep the application alias, but remove the alias validation (we
check if the alias is provided, and if not throw an error) for now, so that
we can deploy applications without it? We can bring back the check once we
generate all aliases based on the
ConfUtil is updated to support multiple config file instance by maintaining
the map.Those changes are applied with PR #133 merge.
Thanks,
Gayan
On Wed, Dec 3, 2014 at 5:55 PM, Gayan Gunarathne wrote:
> Yeah. Seems like we need to maintain the map.Otherwise it returns the same
> instance every t
Hi Manula,
I get a similar issue after adding oAuth feature. The reason is two
features trying to register services with the same name. Suspect is
stratos.common feature.
ID: [0] [STRATOS] [2014-12-04 20:55:53,343] ERROR
{org.wso2.carbon.utils.MBeanRegistrar} - Could not register class
org.wso2.
Github user asfgit closed the pull request at:
https://github.com/apache/stratos/pull/135
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is ena
GitHub user swgkg opened a pull request:
https://github.com/apache/stratos/pull/135
Update the python agent event publisher with instance_id
Please review and merge
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gayangunarathne/s
Github user swgkg closed the pull request at:
https://github.com/apache/stratos/pull/133
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enab
Github user swgkg commented on the pull request:
https://github.com/apache/stratos/pull/133#issuecomment-65633972
This PR is merged hence closing the PR
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
[
https://issues.apache.org/jira/browse/STRATOS-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manula Chathurika Thantriwatte resolved STRATOS-1018.
-
Resolution: Fixed
> Support new group and application JS
[
https://issues.apache.org/jira/browse/STRATOS-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234193#comment-14234193
]
Manula Chathurika Thantriwatte commented on STRATOS-1018:
-
Fixed
Yes, I think we need to use the same variable name everywhere. At the
moment, different places use different names.
On Thu, Dec 4, 2014 at 11:33 AM, Lahiru Sandaruwan wrote:
> Seems it's still there, may be we need to change drools file as well.
>
> [2014-12-04 05:59:31,525] ERROR
> {org.apache.
Seems it's still there, may be we need to change drools file as well.
[2014-12-04 05:59:31,525] ERROR
{org.apache.stratos.autoscaler.monitor.cluster.VMClusterMonitor} - Cluster
monitor: Monitor failed.VMClusterMonitor [clusterId=mytomcat.tomcat.domain,
hasPrimary=false ]
java.lang.RuntimeExcepti
IMO we can live with oAuth.
On Wed, Dec 3, 2014 at 10:11 PM, Udara Liyanage wrote:
> Hi,
>
> Seems permission model we introduce for Stratos API is applied to metadata
> service too. Do we need it since authorization is done by oAuth.
>
> --
>
> Udara Liyanage
> Software Engineer
> WSO2, Inc.: h
Hi,
Seems permission model we introduce for Stratos API is applied to metadata
service too. Do we need it since authorization is done by oAuth.
--
Udara Liyanage
Software Engineer
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware
web: http://udaraliyanage.wordpress.com
phone: +94 71 443
Hi,
Noticed $subject.
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Hi All,
I'm working on the CEP 3.1.0 feature upgrade in Stratos 4.1.0. I'd be able
to upgrade CEP 3.1.0 features and now the CEP artifacts are activated
successfully. But when I start the Stratos single JVM setup I get the
following error. Seems like this happen because of
the org.apache.stratos.c
Hi Devs,
I have switched the master branch to use jclouds 1.8.1
I already have tested with 4.0.0 branch and it was working fine.
However, please let me know if you find issues in creating instances and
allocating resources (IP and volume) to them.
Thanks.
--
Rajkumar Rajaratnam
Committer & PM
I have removed '$' from all the variable to be consistent. It's fixed now.
Thanks.
On Thu, Dec 4, 2014 at 11:35 AM, Nirmal Fernando
wrote:
> Yes, I think we need to use the same variable name everywhere. At the
> moment, different places use different names.
>
> On Thu, Dec 4, 2014 at 11:33 AM,
Hi,
Currently facing following issue;
[2014-12-04 09:30:42,426] ERROR
{org.apache.stratos.autoscaler.monitor.cluster.KubernetesServiceClusterMonitor}
- KubernetesServiceClusterMonitor: Monitor
failed.KubernetesServiceClusterMonitor for [
clusterId=mytomcat.tomcat.domain]
java.lang.RuntimeExcept
Hi Hasitha,
You can find more information on the Node.js Stratos cartridge in
http://blog.lasindu.com/2014/08/apache-stratos-how-nodejs-cartridge.html
This uses the puppet-labs nodejs puppet module with some minor changes to
the cartridge agent extensions.
Thanks,
On Wed, Dec 3, 2014 at 11:47 AM
I've fixed this in 33f5576737e4a3455edfe3cdc3be7a5ffafb834e
On Thu, Dec 4, 2014 at 10:04 AM, Nirmal Fernando
wrote:
> Hi,
>
> Currently facing following issue;
>
> [2014-12-04 09:30:42,426] ERROR
> {org.apache.stratos.autoscaler.monitor.cluster.KubernetesServiceClusterMonitor}
> - KubernetesSer
[
https://issues.apache.org/jira/browse/STRATOS-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gayan Gunarathne updated STRATOS-1023:
--
Issue Type: Task (was: Bug)
> Adding the operation to the Stratos REST API to retriev
Gayan Gunarathne created STRATOS-1023:
-
Summary: Adding the operation to the Stratos REST API to retrieve
cartridges based on the provider name
Key: STRATOS-1023
URL: https://issues.apache.org/jira/browse/STRA
63 matches
Mail list logo
