Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 11:27 PM, Dmitry Sotnikov wrote: > My point is that for serverless architecture, if load balancer can deal > with the "0" situation (no containers are running, requests come in, a > container is spun up and gets the request), then 1 also works. > Yes. >

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

My point is that for serverless architecture, if load balancer can deal with the "0" situation (no containers are running, requests come in, a container is spun up and gets the request), then 1 also works. 2 as the minimum for HA configuration is a good approach for the server-oriented model. On

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 10:22 PM, Dmitry Sotnikov wrote: > Not for transactional stuff, right? If this is just a mediation or proxy > service request and the host fails - the request would not automatically go > to a second node anyway, right? > Load balancer is the entry point

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 4:46 PM, Kasun De Silva wrote: > Hi Lakmal, > > This is on demand. we do not create an HPA kind for each application / >> service version that user creates. > > > ​This means we initially provide a settings level config to enable > autoscaling for an

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

Wouldn't minimum be set to 0 in true serverless experience? On Wed, Nov 2, 2016 at 9:16 AM, Deependra Ariyadewa wrote: > > > On Wed, Nov 2, 2016 at 1:04 PM, Kasun De Silva wrote: > >> Hi All, >> >> Past couple of days I was working on a POC for the $subject. >>

Re: [Architecture] Feature Management of IoT Server

> > That was the my concern as well. However we can consider the device-model > instead of the device instance because ultimately all the supported > features of a device will be dictated by the device model & vendor. By that > way we can avoid lots of duplicate data. We can get this information

Re: [Architecture] Feature Management of IoT Server

Hi Ayyoob, That was the my concern as well. However we can consider the device-model instead of the device instance because ultimately all the supported features of a device will be dictated by the device model & vendor. By that way we can avoid lots of duplicate data. We can get this information

Re: [Architecture] Feature Management of IoT Server

I had an offline discussion and got an explanation from chathuraD. The problem here could be explained with a simple use case: Android has a set of features but an instance of an android device doesn't have the feature that is definied in the device type definition(eg: *Android OS supports

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

Not for transactional stuff, right? If this is just a mediation or proxy service request and the host fails - the request would not automatically go to a second node anyway, right? On Wed, Nov 2, 2016 at 9:41 AM, Deependra Ariyadewa wrote: > > > On Wed, Nov 2, 2016 at 9:48 PM,

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 9:48 PM, Dmitry Sotnikov wrote: > Wouldn't minimum be set to 0 in true serverless experience? > Yes, in the initial stage replica count should be 0 but in the running state we have to have two copies of each instance to face server failures. > > On Wed,

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 1:04 PM, Kasun De Silva wrote: > Hi All, > > Past couple of days I was working on a POC for the $subject. > > Following is the current model that AppCloud use to create application / > services. Basically for each application / service AppCloud will create

Re: [Architecture] Policy management for IoT Server

Hi Harshan & Geeth, Thanks for the pointing out above scenarios. @Harshan, According to your scenario having set of devices of users who is with particular role can be consider as a group. If you aware with the device grouping implementation it's sharing model is also based on roles which is in

Re: [Architecture] RDBMS based coordinator election algorithm for MB

Hi, On Wed, Nov 2, 2016 at 3:14 PM, Asanka Abeyweera wrote: > Hi Anjana, > > Currently, the implementation is part of the MB code (not a common > component). > Okay, can we please get it as a common component. Cheers, Anjana. > > On Wed, Nov 2, 2016 at 3:00 PM, Anjana

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

Hi Lakmal, This is on demand. we do not create an HPA kind for each application / > service version that user creates. ​This means we initially provide a settings level config to enable autoscaling for an application rather than creating an HPA for each application / service user creates. We

Re: [Architecture] Feature Management of IoT Server

Yes.. in the feature definition xml I sketched out, there are multiple criteria under tag. On Wed, Nov 2, 2016 at 2:55 PM, Chathura Dilan wrote: > Hi Chathura, > > How about having multiple criteria under one feature so we can better > address all the scenarios. > > > On

Re: [Architecture] RDBMS based coordinator election algorithm for MB

Hi Anjana, Currently, the implementation is part of the MB code (not a common component). On Wed, Nov 2, 2016 at 3:00 PM, Anjana Fernando wrote: > Hi Asanka/Ramith, > > So for C5 based Streaming Analytics solution, we need coordination > functionality there as well. Is the

Re: [Architecture] RDBMS based coordinator election algorithm for MB

Hi Asanka/Ramith, So for C5 based Streaming Analytics solution, we need coordination functionality there as well. Is the functionality mentioned here created as a common component or baked in to the MB code? .. if so, can we please get it implemented it as a generic component, so other products

Re: [Architecture] Feature Management of IoT Server

Hi Chathura, How about having multiple criteria under one feature so we can better address all the scenarios. On Wed, Nov 2, 2016 at 12:36 PM, Chathura Ekanayake wrote: > Regarding sensors, we can consider them as features, where the action they > support is "read value".

Re: [Architecture] Horizontal autoscaling of containers in AppCloud

On Wed, Nov 2, 2016 at 1:04 PM, Kasun De Silva wrote: > Hi All, > > Past couple of days I was working on a POC for the $subject. > > Following is the current model that AppCloud use to create application / > services. Basically for each application / service AppCloud will create

Re: [Architecture] Feature Management of IoT Server

Hi Dilan, +1 for the idea. But we also need to consider the device model when comes to the features. For example there may be Android devices where some sensors like barometer is not present. This will be mostly applicable to the mobile device types because IOT devices will have their own plugin

[Architecture] Feature Management of IoT Server

Hi All, Operation can be descried as set of actions that can be carried out on a device. As an example if we take 'Camera Operation'; enabling and disabling camera can be carried out on a device. Without the actions we are calling it 'Camera Feature'. There could be several features which is

[Architecture] Horizontal autoscaling of containers in AppCloud

Hi All, Past couple of days I was working on a POC for the $subject. Following is the current model that AppCloud use to create application / services. Basically for each application / service AppCloud will create a *Deployment >> ReplicaSet >> Pod* in Kubernetes cluster. At this point each

Re: [Architecture] Feature Management of IoT Server

I think we can define a feature (or an operation) with: A) Feature code - to identify the feature B) Filtering criteria - to identify devices which can perform the operation C) Operation parameters - Additional details needed by the operation Restriction criteria such as device type, group ID,

Re: [Architecture] Feature Management of IoT Server

@Harshan, sensors are not part of features(correct me if I am wrong), This is why there was a requirement raised for sensor management as part of device management and we had an implementation to support this(from shabir) which is not merged yet. [1]

Re: [Architecture] Feature Management of IoT Server

Regarding sensors, we can consider them as features, where the action they support is "read value". If we are using polling method to trigger operations, read operation can have a parameter with an endpoint to send sensor reading. - Chathura On Wed, Nov 2, 2016 at 12:30 PM, Chathura Ekanayake

Re: [Architecture] Feature Management of IoT Server

Hi Ayyoob, Yes you are correct. But I took the barometer as an example. However there may be real scenarios where some devices does not have GPS so that we can't access the location info. In such cases we need to disable "Location" operation for those devices. Thanks, Harshan Liyanage EMM/IoT