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 <v...@cisco.com <mailto:v...@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
stratos_sample_config.tar
Description: Unix tar archive
