stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vanson Lim <v...@cisco.com>
Subject Re: [Discuss] Cartridge definition doesn't need "maxInstanceLimit" property anymore
Date Wed, 25 Mar 2015 02:47:22 GMT
Reply inline.  search for ##VL:


On 3/24/15, 9:08 PM, Imesh Gunaratne wrote:
> Hi Vanson,
>
> Please see my comments inline:
>
> On Wed, Mar 25, 2015 at 2:06 AM, Vanson Lim <vlim@cisco.com <mailto:vlim@cisco.com>>
wrote:
>
>     Reka/devs,
>
>     I am still a little bit confused about Group level and Cartridge level deployment
policies and looking forward to seeing some more
>     documentation on this.
>
>     If we are defining a group consisting of dissimilar cartridges, how can it work to
specify a single group level deployment policy
>     which applies to all cartridge members in that group.
>
>
> According to the current design if we define a deployment policy to a cartridge group
it will be applied to all the cartridges 
> underneath. Therefore if have a requirement to apply different deployment policies to
different cartridges in a cartridge group we will 
> need to apply them at cartridge level.

##VL:  Not clear what you are saying here.  Are you saying that I've just incorrectly defined
it or that currently implementation doesn't 
support what I need and it's a new requirement that needs to be implemented.   I don't think
I've defined a group level deployment policy 
in my current example.  I've included the json artifacts which I am using.   I don't make
use of a cartridge group,  the single cartridge 
is referenced in the application json.

>     It might be useful in terms of controlling which partitions cartridges pertaining
to an instance of a group gets launched in but
>     there are cases where one wants to control
>     the number of instances per cartridge type.
>
>     For example given a G1 which has cartridge members C1 and C2,
>
>     I might want to specify a policy such that there are 1-3 instances of C1 and 4 instances
C2.
>     What would be the setting of cartridgeMin in this case?
>
>     To achieve this cartridge member would have it's own deployment policy,  Ie: deployment
>     policy  C1 [partitionMin:1, partitionMax:3], deployment policy C2 [ partitionMin:4,
partitionMax:4]
>
> Yes this is correct.
>
>     It seems a cartridge should only inherit a group level policy if one has not been
defined at the cartridge level.
>
> Yes this is the current design.
##VL:  This statement seems to be the opposite of what you stated above:

           "if we define a deployment policy to a cartridge group it will be applied to all
the cartridges underneath."

>     I am not sure if there is a bug with the latest stratos, but I've been experimenting
with a simple application consisting of a single
>     cartridge, a single partition and can't seem to
>     coax the right number of instances of the cartridges to come up.
>
>     I've tried varying cartridgeMin and/or PartitionMin/Max with no luck.
>
> We will have a look at this. It would be great if you could post the Stratos artifacts
you used to test this scenario.

##VL:  I've included the json files I made use of in the attached tar file.  Let me know if
you need anything else.   I don't make use of a 
cartridge group definition in this case as the cartridge is referenced directly in the application.json.
>
>     Also, I notice that updating the deployment policy after an application is deployed
doesn't seem to have any effect on the number of
>     instances running.  Is this broken?
>
>  This should be a bug, we will verify it.

##VL:   okay,  we'll create a JIRA t track this.
>
>     Since there's no rest API for updating an application (specifically the cartridgeMin/Max
values), how does one dynamically update the
>     number of instances of cartridge in a group without having to delete and recreate
a new application?
>
> Yes, currently this is not possible, I agree that it is a valid requirement.
>
> The reason why we did not allow users to update the application is that the update process
can entirely change the application 
> definition. If so it would be difficult to adopt all the changes for an already deployed
application.

>
> Ideally I think properties like groupMinInstances, groupMaxInstances, cartridgeMin &
cartridgeMax should be defined in the deployment 
> policy and we should be able to update deployment policies without affecting the application
definition. This would also allow us to 
> reuse the application definition with the application template concept that we planning
to introduce in a later release.

##VL:  Understood why this isn't supported.    And agreed,  if we move any fields that need
to be tunable into the deployment policy, it 
eliminates the need to update the application definition.
>
> We had a similar discussion with Shaheed on this and thought that we could remove cartridgeMin,
cartridgeMax and only use partitionMin, 
> partitionMax. We have planned to do this change for 4.1.0-GA.
>
>     Here are some of the steps I've experimented with and the json payloads I've been
using:
>
>     1) create application with:  cartridgeMin=2, cartridgeMax=10000000  partitionMin/Max=1,
>     1 sample VM gets started.
>
>     - updated deployment policy, PartitionMax changed to 2,  stratos does NOT spin up
a second VM.
>     - updated deployment policy, PartitionMin changed to 2, stratos does NOT spin up
a second VM
>
>     2)  create application with cartridgeMin=1, cartridgeMax=10000000  partitionMin/Max=2,
  1 sample VM gets started.
>
>     3)  create application with cartridgeMin=2, cartridgeMax=10000000  partitionMin/Max=2,
  2 sample VM gets started
>     - updating deployment policy, PartitionMin/Max values (ie setting to 1) has no effect
on the 2 VMs that are active.
>
>
>     the third observation suggests that cartridgeMin controls the number of instances.
 What happens if I want define a second partitions
>     and want 2 instances in P1 and 3 instances in P2,  do I need to set CartridgeMin=5?
>
> No, currently this is not possible. Stratos would spin minimum number of cartridges (cartridgeMin)
in each partition. We cannot have two 
> different minimum values in two partitions. If this is required we could use partitionMin
(which we are planning to introduce in 
> 4.1.0-GA) to handle this logic.

##VL:  okay, this really makes using groups less flexible if you can't control minimum number
of instances per cartridge member type per 
partition.   Could I work around this by defining two groups, G1 consisting of cartridge C
with a deployment policy in P1, CartridgeMin=2,  
and G2 consisting of cartridge C with a deployment policy in P2, CartridgeMin=3. And having
a single application with G1 and G2 as members?

-Vanson

>
>     -Vanson
>
>
> Thanks
>
> -- 
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos


Mime
View raw message