Great! Thanks for the clarification! The term "replicas" was bit confusing,
that's why.
On Tue, Sep 23, 2014 at 1:26 PM, Nirmal Fernando
wrote:
> Hi Imesh,
>
> On Tue, Sep 23, 2014 at 12:00 PM, Imesh Gunaratne
> wrote:
>
>> Regarding health monitoring in containers, as discussed the best approa
Hi Imesh,
On Tue, Sep 23, 2014 at 12:00 PM, Imesh Gunaratne wrote:
> Regarding health monitoring in containers, as discussed the best approach
> would be to use a well-known docker container monitoring tool such as
> cAdvisor coupled with a cartridge agent instance per controller node.
>
Yes, u
Regarding health monitoring in containers, as discussed the best approach
would be to use a well-known docker container monitoring tool such as
cAdvisor coupled with a cartridge agent instance per controller node.
Why do we use the term "replicas" for the Kubernetes control node
instances? Are we
AFAIS Autoscaler's task is very simple in the container case. It just need
to create a kubernetes replication controller with the minimum number of
replicas initially via CC and need to update the number of replicas of the
same kubernetes replication controller (again via CC) based on the health
st
On Tue, Sep 16, 2014 at 3:54 PM, Akila Ravihansa Perera
wrote:
> Hi,
>
> I think we lost that control once we decided to use Kubernetes to
> manage containers. The whole idea of using Kubernetes is to starting,
> destroying and maintaining HA within container cluster.
>
> As for the agent health
Hi,
I think we lost that control once we decided to use Kubernetes to
manage containers. The whole idea of using Kubernetes is to starting,
destroying and maintaining HA within container cluster.
As for the agent health stats, there can be situations where
application level monitoring is required
On Tue, Sep 16, 2014 at 3:20 PM, Lahiru Sandaruwan wrote:
>
>
> On Tue, Sep 16, 2014 at 2:57 PM, Lakmal Warusawithana
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 1:53 PM, Lahiru Sandaruwan
>> wrote:
>>
>>> Hi Akila,
>>>
>>>
>>>
>>> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
>>>
On Tue, Sep 16, 2014 at 2:57 PM, Lakmal Warusawithana
wrote:
>
>
> On Tue, Sep 16, 2014 at 1:53 PM, Lahiru Sandaruwan
> wrote:
>
>> Hi Akila,
>>
>>
>>
>> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Raj,
>>>
>>> We can use the same CEP stream
Hi Akila,
On Tue, Sep 16, 2014 at 2:39 PM, Akila Ravihansa Perera
wrote:
> Hi Raj,
>
> We need to change the stream definition since CEP component now reads
> those parameters from the topology.
So currently CEP is reading these parameters from the topology? Or it has
to be done? I guess, CEP
On Tue, Sep 16, 2014 at 2:58 PM, Lahiru Sandaruwan wrote:
>
>
> On Tue, Sep 16, 2014 at 2:54 PM, Lakmal Warusawithana
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
>> raviha...@wso2.com> wrote:
>>
>>> Hi Raj,
>>>
>>> We can use the same CEP stream to publish cart
On Tue, Sep 16, 2014 at 2:54 PM, Lakmal Warusawithana
wrote:
>
>
> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Raj,
>>
>> We can use the same CEP stream to publish cartridge agent health stats.
>> We can identify the instance type (container or
On Tue, Sep 16, 2014 at 1:53 PM, Lahiru Sandaruwan wrote:
> Hi Akila,
>
>
>
> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi Raj,
>>
>> We can use the same CEP stream to publish cartridge agent health stats.
>> We can identify the instance type (co
On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera wrote:
> Hi Raj,
>
> We can use the same CEP stream to publish cartridge agent health stats. We
> can identify the instance type (container or VM type) by retrieving member
> properties from the topology. But I don't think we should be doin
On Tue, Sep 16, 2014 at 2:39 PM, Akila Ravihansa Perera
wrote:
> Hi Raj,
>
> We need to change the stream definition since CEP component now reads
> those parameters from the topology. This is possible since we have
> added messaging component dependency to the CEP. So no point of
> sending netwo
Hi Raj,
We need to change the stream definition since CEP component now reads
those parameters from the topology. This is possible since we have
added messaging component dependency to the CEP. So no point of
sending network_partition_id, partition_id etc parameters in the
message payload. Only me
Hi Akila,
On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera wrote:
> Hi Raj,
>
> We can use the same CEP stream to publish cartridge agent health stats. We
> can identify the instance type (container or VM type) by retrieving member
> properties from the topology. But I don't think we sho
On Tue, Sep 16, 2014 at 11:30 AM, Reka Thirunavukkarasu
wrote:
> Hi
>
> On Mon, Sep 15, 2014 at 3:23 PM, Rajkumar Rajaratnam
> wrote:
>
>> Hi,
>>
>> I am working on monitoring docker container clusters. It will perform
>> min/max check per service cluster and scale up/down containers periodicall
Hi Akila,
On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera wrote:
> Hi Raj,
>
> We can use the same CEP stream to publish cartridge agent health stats. We
> can identify the instance type (container or VM type) by retrieving member
> properties from the topology. But I don't think we s
Hi Raj,
We can use the same CEP stream to publish cartridge agent health stats. We
can identify the instance type (container or VM type) by retrieving member
properties from the topology. But I don't think we should be doing that.
IMO, we should not publish cartridge agent health stats from each
Hi
On Mon, Sep 15, 2014 at 3:23 PM, Rajkumar Rajaratnam
wrote:
> Hi,
>
> I am working on monitoring docker container clusters. It will perform
> min/max check per service cluster and scale up/down containers periodically
> based on the autoscale policy, instance health and requests in flight.
>
Hi,
Please see my comments inline.
On Mon, Sep 15, 2014 at 3:23 PM, Rajkumar Rajaratnam
wrote:
> Hi,
>
> I am working on monitoring docker container clusters. It will perform
> min/max check per service cluster and scale up/down containers periodically
> based on the autoscale policy, instance
Hi,
I am working on monitoring docker container clusters. It will perform
min/max check per service cluster and scale up/down containers periodically
based on the autoscale policy, instance health and requests in flight.
I figured out the implementations/changes to be done in order to support
doc
In the docker scenario, we can have either docker image name or docker file
in the cartridge definition, if docker file provided, we should build and
push to docker registry and if docker image name provided, can assume,
docker image manually build and already in the docker registry. Main
reason, s
On Thu, Aug 28, 2014 at 12:50 PM, chris snow wrote:
> On Thu, Aug 28, 2014 at 3:44 AM, Lakmal Warusawithana
> wrote:
> > Hi devs,
> >
> > I did some research on $subject and IMO kurburnetes integration going to
> be
> > worthwhile thing. Below is the possible way of integration and some
> > bene
On Thu, Aug 28, 2014 at 12:08 PM, Nirmal Fernando
wrote:
>
>
>
> On Thu, Aug 28, 2014 at 8:14 AM, Lakmal Warusawithana
> wrote:
>
>> Hi devs,
>>
>> I did some research on $subject and IMO kurburnetes integration going to
>> be worthwhile thing. Below is the possible way of integration and some
>
On Thu, Aug 28, 2014 at 3:44 AM, Lakmal Warusawithana wrote:
> Hi devs,
>
> I did some research on $subject and IMO kurburnetes integration going to be
> worthwhile thing. Below is the possible way of integration and some
> benefits.
>
> Kuburnetes provide docker provisioning (orchestration), sche
On Thu, Aug 28, 2014 at 8:14 AM, Lakmal Warusawithana
wrote:
> Hi devs,
>
> I did some research on $subject and IMO kurburnetes integration going to
> be worthwhile thing. Below is the possible way of integration and some
> benefits.
>
> Kuburnetes provide docker provisioning (orchestration), sch
Hi devs,
I did some research on $subject and IMO kurburnetes integration going to be
worthwhile thing. Below is the possible way of integration and some
benefits.
Kuburnetes provide docker provisioning (orchestration), scheduling across
docker host cluster, Self-healing mechanisms, such as auto-r
28 matches
Mail list logo
