Hi Martin,
Please find my comments inline:
On Fri, Oct 17, 2014 at 11:38 PM, Martin Eppel (meppel)
wrote:
> I would like to discuss what it would take to achieve 100% uptime for
> stratos in a production environment (aiming high to reach the five nines)
> - if it had been discussed before ple
Imesh Gunaratne created STRATOS-897:
---
Summary: Write a Guideline for Providing HA for Stratos in Single
JVM Mode
Key: STRATOS-897
URL: https://issues.apache.org/jira/browse/STRATOS-897
Project: Stra
+1 Definitely, we need to do this.
On Fri, Oct 17, 2014 at 9:47 PM, Martin Eppel (meppel)
wrote:
> +1
>
>
>
> *From:* Udara Liyanage [mailto:ud...@wso2.com]
> *Sent:* Thursday, October 16, 2014 10:26 PM
> *To:* dev
> *Cc:* Isuru Haththotuwa; Reka Thirunavukkarasu; Martin Eppel (meppel)
> *Subje
Hi,
@Raj: What I pointed out is a design issue. Each time we introduce a new
feature we should not introduce new persistence logic unless unavoidable,
rather persistence should happen centrally.
In this scenario when we update the subscription it should go through a
common flow and update the in
Imesh Gunaratne created STRATOS-896:
---
Summary: A New Feature to Update Autoscaling & Deployment Policies
in Runtime
Key: STRATOS-896
URL: https://issues.apache.org/jira/browse/STRATOS-896
Project: S
Github user imesh commented on the pull request:
https://github.com/apache/stratos/pull/93#issuecomment-59599713
Great work! I still think we can improve this further by keeping the
process ids at the server startup and use them to execute the termination
process. Otherwise there coul
Hi Imesh,
'Pre Terminate" and "Ready to terminate" seems confusing for a user, isn't
it so?
On Sat, Oct 18, 2014 at 10:40 AM, Imesh Gunaratne wrote:
> Hi Isuru,
>
> I have done some changes to the Member Lifecycle and also added events:
>
>
> Things changed:
> - I have introduced a new state ca
Hi Isuru,
I have done some changes to the Member Lifecycle and also added events:
Things changed:
- I have introduced a new state called Inactive. Currently we detect
members as Inactive but it is not reflected in topology, rather we
straightway consider those as Faulty members and terminate the
Hi Martin,
Thanks for reporting this. Fixed it in commit
f6c0cfcb5e66912ca92a296d0ade55b2c5d08d64.
On Sat, Oct 18, 2014 at 2:23 AM, Martin Eppel (meppel)
wrote:
> I just updated the source to the 4.0.0-grouping branch and encountered
> the following build error, do you see the same ?
>
>
>
> T
Hi Chamila,
Great work, your approach seems to work but it would be better if we keep
the process ids at the server startup and then use those to terminate.
Otherwise there is a possibility that other Carbon servers or ActiveMQ
instances running in the same host.
Thanks.
On Wed, Oct 15, 2014 at
I just updated the source to the 4.0.0-grouping branch and encountered the
following build error, do you see the same ?
Thanks
Martin
BUILD FAILURE
[INFO]
[INFO] Total time: 9:14.204s
[INFO] Finished at: Fri Oct 17 13:32:3
I would like to discuss what it would take to achieve 100% uptime for stratos
in a production environment (aiming high to reach the five nines) - if it had
been discussed before please point me to the email thread.
The goal is to identify recommended deployment scenarios and possible
shortcomi
Jeffrey Nguyen created STRATOS-895:
--
Summary: Stratos only includes max of one private IP and one
public IP in topology events
Key: STRATOS-895
URL: https://issues.apache.org/jira/browse/STRATOS-895
+1
From: Udara Liyanage [mailto:ud...@wso2.com]
Sent: Thursday, October 16, 2014 10:26 PM
To: dev
Cc: Isuru Haththotuwa; Reka Thirunavukkarasu; Martin Eppel (meppel)
Subject: [Grouping] Shall we clean unused code block
Hi,
There are considerable amount of unused code block. There are places wher
This is not only related to manual scaling, we should have some mechanism
to persist associate polices (and run time changes) with cartridge
subscription. Currently it does not required because we did not allow to
change policies (run time update for policies) per subscription. But since
we are pla
Great work Chamila!
On Fri, Oct 17, 2014 at 6:07 PM, Chamila De Alwis wrote:
> Hi,
>
> I wrote a blog post[1] on the Thrift communication in Stratos, based on
> the stuff I've read and come across in the code. Please let me know if
> there are any corrections to be made.
>
> [1] -
> http://code.
Hi,
I wrote a blog post[1] on the Thrift communication in Stratos, based on the
stuff I've read and come across in the code. Please let me know if there
are any corrections to be made.
[1] -
http://code.chamiladealwis.com/blog/2014/10/10/thrift-communication-in-apache-stratos/
Regards,
Chamila
Hi all,
I do agree that there might be many changes that we need for this state
diagram. That will need to be developed as we go on. The idea is to discuss
the use of validating state changes, for any state diagram that we come
upon.
On Fri, Oct 17, 2014 at 3:09 PM, Udara Liyanage wrote:
> Hi,
Hi,
Could you mention what events/actions causes the state transition from
Activate to Terminate?
My next question is what happens when member diapered when it is in
In-Maintaince mode? Does this state transition is applicable to obsolete
members also.
On Fri, Oct 17, 2014 at 2:55 PM, Chamila D
Hi,
In the container based scenario, aren't the members immediately terminated
without going in to the maintenance mode?
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Fri, Oct 17, 2014 at 1:11 PM, Manula Chathurika Thantriwatte <
manu...@ws
Hi Isuru,
IMO is we need to verify the life cycle in between Activated and Terminated
modes. We not need to verify the created and started, because without
started members want come to activated state.
Thanks !
On Fri, Oct 17, 2014 at 12:46 PM, Isuru Haththotuwa
wrote:
> Hi Devs,
>
> The purpo
Hi Devs,
The purpose of this thread is to discuss $subject.
Currently, even though the topology elements (Members, Clusters, etc) go
through a life cycle, we do not validate the transitions. For an example, a
Member can have the following life cycle:
[image: Inline image 1]
IMHO its important t
22 matches
Mail list logo
