Hi Devs,
I have now implemented the cloud controller coordinator management logic
and improved distributed locking functionality, the changes are now in
master branch.
*Cloud Controller (CC) Coordinator:*
- There will be only one coordinator for the cloud controller cluster at a
given time.
- Coo
Hi Devs,
I have now completed the initial implementation of $subject and pushed
those changes to master branch.
Thanks
On Fri, Nov 28, 2014 at 1:49 PM, Gayan Gunarathne wrote:
> Hi,
>
> On Fri, Nov 28, 2014 at 1:00 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> Accord
Hi,
On Fri, Nov 28, 2014 at 1:00 PM, Akila Ravihansa Perera
wrote:
> Hi,
>
> According to this design Autoscaler (AS)/Stratos Manager (SM) will talk to
>>> Cloud Controller (CC) via the Cloud Controller Service endpoint exposed via
>>> the load balancer.
>>>
>>> *Data Replication*
>>> When a req
Hi,
According to this design Autoscaler (AS)/Stratos Manager (SM) will talk to
>> Cloud Controller (CC) via the Cloud Controller Service endpoint exposed via
>> the load balancer.
>>
>> *Data Replication*
>> When a request comes into one of the CC instances it will execute the
>> necessary actions
Hi,
On Wed, Nov 26, 2014 at 1:16 PM, Imesh Gunaratne wrote:
> Hi Devs,
>
> This is to discuss the clustering model of the cloud controller:
>
>
>
>
> As shown in the above diagram the idea is to have a coordinator node to
> handle data persistence logic and message publishing (topology, insta
Hi Imesh,
Thank you for the explanations.
I'm +1 for the overall model.
Thanks.
On 27 Nov 2014 07:19, "Imesh Gunaratne" wrote:
> Hi,
>
> On Wed, Nov 26, 2014 at 5:27 PM, Udara Liyanage wrote:
>
>> Reading from registry frequently might be more expensive than distributed
>> locking since a num
Hi,
On Wed, Nov 26, 2014 at 5:27 PM, Udara Liyanage wrote:
> Reading from registry frequently might be more expensive than distributed
> locking since a number of database queries are executed.
> +1 for distributed collections.
>
> Are we going to use Hazlecast or any other framework ?
>
We are
Hi Imesh,
> - The time it takes to propagate a modificaiton from one instance to
> another would be higher compared to using a distributed map (instance 1
> persist changes, send a cluster message to invalidate the cache, other
> instances read changes from registry database, refresh in memory
Hi Imesh,
Reading from registry frequently might be more expensive than distributed
locking since a number of database queries are executed.
+1 for distributed collections.
Are we going to use Hazlecast or any other framework ?
On Wed, Nov 26, 2014 at 4:53 PM, Lakmal Warusawithana
wrote:
>
>
>
On Wed, Nov 26, 2014 at 4:49 PM, Imesh Gunaratne wrote:
> Hi Akila,
>
> The goal we are trying to achieve here is to replicate the state of the
> cloud controller. IMO registry based approach might not be appropriate for
> state replication due to the following reason:
>
> - The time it takes to
Hi Akila,
The goal we are trying to achieve here is to replicate the state of the
cloud controller. IMO registry based approach might not be appropriate for
state replication due to the following reason:
- The time it takes to propagate a modificaiton from one instance to
another would be higher
Hi Imesh,
According to the model you've described, we will have to use a distributed
lock to synchronize read/write operations into the topology data structure.
This could be expensive.
I'd like to propose that we actually store and read the topology from the
registry. And to optimize the perform
+1 Yes a good point Lakmal, to reduce the latency for a modification to
propagate to all the instances we might need to replicate topology as well.
Thanks
On Wed, Nov 26, 2014 at 2:44 PM, Lakmal Warusawithana
wrote:
>
>
> On Wed, Nov 26, 2014 at 1:16 PM, Imesh Gunaratne wrote:
>
>> Hi Devs,
>
On Wed, Nov 26, 2014 at 1:16 PM, Imesh Gunaratne wrote:
> Hi Devs,
>
> This is to discuss the clustering model of the cloud controller:
>
>
>
>
> As shown in the above diagram the idea is to have a coordinator node to
> handle data persistence logic and message publishing (topology, instance
>
Hi Devs,
This is to discuss the clustering model of the cloud controller:
As shown in the above diagram the idea is to have a coordinator node to
handle data persistence logic and message publishing (topology, instance
status, etc). The coordinator will be selected randomly and at a given ti
15 matches
Mail list logo
