You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by "Martin Eppel (meppel)" <me...@cisco.com> on 2015/07/22 05:55:26 UTC
4.1 Stratos testig: clarifying application update API
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy "static-2") with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy "static-1" (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy "static-2" ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc ...) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application "update", please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image001.png@01D0C3AF.38DAC960]
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Thanks for the clarification
From: Pubudu Gunatilaka [mailto:pubudug@wso2.com]
Sent: Tuesday, July 21, 2015 11:00 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image001.png@01D0C45F.79CB05B0]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Can you also check on whether the member-id of one of the existing member
is equal to member-id of the member which belongs to the removed group
instance?
Thanks,
Reka
On Mon, Jul 27, 2015 at 9:53 AM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Hi Martin,
>
> Can you share the logs for this specific case? These group instances have
> been isolated unit according to the implementation. Was there any scale-up
> happened after the removal of a group instance?
>
> Thanks,
> Reka
>
>
> On Sat, Jul 25, 2015 at 12:17 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
>> One interesting observation I made when decrementing the groupMax is
>> that, at least for a transitionary period of time, the VM of the group
>> which is being removed as part of updating the groupMax is “moved” to a
>> surviving group (shows 2 members although min/max = 1), see the sequence
>> below. However note that eventually the VM is being removed as expected.
>>
>>
>>
>> Before update:
>>
>>
>>
>> {"alias": "sub-app-update-5", "applicationId": "sub-app-update-5",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-5-2", "groupMaxInstances": 2,
>> "groupMinInstances": 2, "alias": "application-update-5-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>>
>>
>> [image: cid:image004.png@01D0C53E.35D91DD0]
>>
>> Updated json:
>>
>>
>>
>> {"alias": "sub-app-update-5", "applicationId": "sub-app-update-5",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-5-2", "groupMaxInstances": 1,
>> "groupMinInstances": 1, "alias": "application-update-5-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>> After update:
>>
>>
>>
>> [image: cid:image005.png@01D0C53F.8FC3A6C0]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Eventually, the VM in the group is being removed (no picture)
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com]
>> *Sent:* Friday, July 24, 2015 5:09 AM
>> *To:* dev
>> *Cc:* Mariangela Hills
>>
>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Shaheed,
>>
>> Found another good reference documentation page[1] and updated with the
>> points for the application.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+Artifacts+that+Correspond+to+a+Deployed+Application
>>
>>
>>
>> On Fri, Jul 24, 2015 at 5:15 PM, Reka Thirunavukkarasu <re...@wso2.com>
>> wrote:
>>
>> Hi Shaheed,
>>
>> Sorry for the confusion..Application update didn't work properly when the
>> application is in CREATED state. It didn't bring up the correct topology
>> even the existing application got updated. We will fix this in the next
>> release. So, the points that you have mentioned are correct. Please keep
>> these points as the working items for the 4.1.0.
>>
>> 1. The Deployment policy “max” can be updated as needed.
>>
>> a. This controls the overall limit on the maximum number of
>> cartridges on a region+partition basis for each cartridge using this policy.
>>
>> 2. The Application can only be updated when in deployed state.
>>
>> 3. The supported changes are to cartridgeMin/cartridgeMax and/or
>> groupMinInstances/groupMaxInstances.
>>
>> a. For the groupMinInstances/groupMaxInstances to be usable, the
>> initial setting must be such that Max > 1, otherwise the group scaling is
>> disabled permanently.
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>>
>>
>> On Fri, Jul 24, 2015 at 4:41 PM, Reka Thirunavukkarasu <re...@wso2.com>
>> wrote:
>>
>> Thanks Shaheed for summarizing it..There is a small correction. Sorry..my
>> bad..I gave wrong point earlier. I have checked the code and verified the
>> functionality. Even application update is implemented when the application
>> is in added state.
>>
>>
>>
>> On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <
>> shahhaqu@cisco.com> wrote:
>>
>> So, let me see if I can summarise the rules:
>>
>>
>>
>> Is this correct? Did I miss something? If this is OK, I’d like to find
>> a home for this information in the docs, but I did not see an obvious page.
>> Can somebody kindly suggest one? (Maybe under the Advanced User Guide
>> section?)
>>
>>
>>
>> We have only following page currently. We will include the points that
>> you have mentioned here also to the page.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
>>
>> [2]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>> Thanks, Shaheed
>>
>>
>>
>> *From:* Martin Eppel (meppel)
>> *Sent:* 23 July 2015 17:25
>> *To:* dev@stratos.apache.org
>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Thanks Reka for the clarification, I’ll update my test case accordingly
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>>
>> *Sent:* Wednesday, July 22, 2015 11:50 PM
>> *To:* dev
>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Martin,
>>
>> As we tested the scenario along with your sample, we found out that in
>> the initial application, you were using groupMinInstances=1 and
>> groupMaxInstances=1 which means that stratos took that decision saying
>> groupScaling is disabled for this particular group. After that when you
>> update this particular group with groupMinInstances=2 and
>> groupMaxInstances=2, stratos should take the decision back that
>> groupScaling is enabled for this group which is not possible at the moment.
>> Stratos can't change the groupScaling decision dynamically due to the
>> design.
>>
>> But you can achieve group update, if you use the groupMinInstances=1 and
>> groupMaxInstances=2 for the initial application and then if you update with
>> groupMinInstances=2 and groupMaxInstances=2, it will bring one additional
>> group instance.
>>
>> Please note that GroupScaling is decided by stratos as true only when
>> groupMaxInstances > 1
>>
>>
>>
>> Hope you understand how the group instance update works. Please let me
>> know, if you need more clarification on this.
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>> On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
>> wrote:
>>
>> Sorry, forgot to attach the log file …
>>
>>
>>
>> *From:* Martin Eppel (meppel)
>> *Sent:* Wednesday, July 22, 2015 2:41 PM
>> *To:* dev@stratos.apache.org
>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Reka, Pubudu
>>
>>
>>
>> I tested a scenario where I update group groupMinInstances/groupMaxInstances
>> (which according the email thread should ?!).
>>
>> However, what I observed is that after updating groupMinInstances/groupMaxInstances
>> (from 1 to 2) no new group is created.
>>
>>
>>
>> Here are the application definitions and log is attached
>> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099]
>> INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
>> Adding application: [application-id] sub-app-update-4)
>>
>>
>>
>> Application deployed (groupMin/Max = 1):
>>
>>
>>
>> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
>> Application:
>>
>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
>> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
>> sub-app-update-4 state Deployed after 0 s
>>
>> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
>> [application] sub-app-update-4
>>
>>
>>
>>
>>
>> Updated application (groupMin/Max = 2):
>>
>>
>>
>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
>> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
>> u'Application updated successfully: [application] sub-app-update-4'}
>>
>>
>>
>> Application after update:
>>
>>
>>
>>
>>
>> This is what I would have expected after the application update:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Please let me know if there is an issue or updating runtime
>> groupMinInstances/groupMaxInstances is currently not supported,
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>>
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>>
>> *Sent:* Tuesday, July 21, 2015 11:25 PM
>> *To:* dev
>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Martin,
>>
>> As Pubudu explained, those are the expected steps and the result of the
>> application update. *Application Runtime* can only be updated with
>> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
>> Even if you update other parameters, it will get ignored by the back end.
>>
>> Please note that you can update application only when it is in deployed
>> mode. After application is created, if you need to update, then you will
>> have to delete the application and create it again. Currently application
>> update is not available when the application is in created mode.
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
>> wrote:
>>
>> Hi Martin,
>>
>>
>>
>> You can update only carridgeMin and cartridgeMax at runtime in
>> application update. Even you can update the deployment policy which uses
>> the application. But you cannot change the deployment policy in application
>> at runtime.
>>
>>
>>
>> In your case, as you have used two different deployment policies, it
>> won't work. It will use the previous deployment policy. I have tested
>> following scenario.
>>
>>
>>
>> 1. Use the deployment policy with partition max as 1.
>>
>> 2. Deploy the application with cartridgeMin 1.
>>
>> 3. Update the same deployment policy with partition max 2.
>>
>> 4. Update application at runtime to cartridgeMin 2.
>>
>> 4. Another instance spawned successfully.
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
>> wrote:
>>
>> Hi,
>>
>>
>>
>> I am currently testing the API to update an application (most notably to
>> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
>> policy).
>>
>>
>>
>> My main question is which are the parameters which are currently
>> supported to be updated as part of application update.
>>
>>
>>
>> I have tested updating (increasing the value) of cartridge cartridgeMin /
>> cartridgeMax of a cartridge policy which works fine, as long as the
>> cartridge deployment policy is correspondingly configured:
>>
>>
>>
>> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
>> “static-2”) with a partitionMax set to 2.
>>
>>
>>
>> However, updating the deployment policy either not supported or fails to
>> work.
>>
>>
>>
>> For example, if I start initially with cartridgeMin / cartridgeMax = 1
>> and a deployment policy “static-1” (with a partitionMax set to 1) and
>> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
>> deployment policy “static-2” ( with a partitionMax set to 2) the
>> cartridge instances are not properly spun up to 2.
>>
>>
>>
>> I am not sure if updating the deployment policy (or any other parameters
>> beyond min / max in the cartridge policy, e.g min / max in group policy etc
>> …) is currently supported or not, which brings me back to my initial
>> question which parameters are supported as part of application “update”,
>> please clarify.
>>
>>
>>
>> Also, is the case supported when decreasing the values, e.g. updating
>> the cartridgeMin / cartridgeMax = 2 to 1 ?
>>
>>
>>
>> Just in case I attached the policy files and log to the email,
>> application, cartridge group json see below inline
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>> Before application update:
>>
>> Application json:
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
>> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>> Cartridge-group.json:
>>
>> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
>> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>>
>>
>>
>> application update json:
>>
>>
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
>> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>>
>>
>> Deployment policies (attached):
>>
>>
>>
>> static-1.json, static-2.json
>>
>>
>>
>> Application (before / after update):
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> *Pubudu Gunatilaka*
>>
>> Software Engineer
>>
>> WSO2, Inc.: http://wso2.com
>>
>> lean.enterprise.middleware
>>
>> mobile: +94 77 4078049
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>
>
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Martin,
Can you share the logs for this specific case? These group instances have
been isolated unit according to the implementation. Was there any scale-up
happened after the removal of a group instance?
Thanks,
Reka
On Sat, Jul 25, 2015 at 12:17 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> One interesting observation I made when decrementing the groupMax is
> that, at least for a transitionary period of time, the VM of the group
> which is being removed as part of updating the groupMax is “moved” to a
> surviving group (shows 2 members although min/max = 1), see the sequence
> below. However note that eventually the VM is being removed as expected.
>
>
>
> Before update:
>
>
>
> {"alias": "sub-app-update-5", "applicationId": "sub-app-update-5",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-5-2", "groupMaxInstances": 2,
> "groupMinInstances": 2, "alias": "application-update-5-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
>
>
> [image: cid:image004.png@01D0C53E.35D91DD0]
>
> Updated json:
>
>
>
> {"alias": "sub-app-update-5", "applicationId": "sub-app-update-5",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-5-2", "groupMaxInstances": 1,
> "groupMinInstances": 1, "alias": "application-update-5-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> After update:
>
>
>
> [image: cid:image005.png@01D0C53F.8FC3A6C0]
>
>
>
>
>
>
>
>
>
> Eventually, the VM in the group is being removed (no picture)
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com]
> *Sent:* Friday, July 24, 2015 5:09 AM
> *To:* dev
> *Cc:* Mariangela Hills
>
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Shaheed,
>
> Found another good reference documentation page[1] and updated with the
> points for the application.
>
> [1]
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+Artifacts+that+Correspond+to+a+Deployed+Application
>
>
>
> On Fri, Jul 24, 2015 at 5:15 PM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
> Hi Shaheed,
>
> Sorry for the confusion..Application update didn't work properly when the
> application is in CREATED state. It didn't bring up the correct topology
> even the existing application got updated. We will fix this in the next
> release. So, the points that you have mentioned are correct. Please keep
> these points as the working items for the 4.1.0.
>
> 1. The Deployment policy “max” can be updated as needed.
>
> a. This controls the overall limit on the maximum number of
> cartridges on a region+partition basis for each cartridge using this policy.
>
> 2. The Application can only be updated when in deployed state.
>
> 3. The supported changes are to cartridgeMin/cartridgeMax and/or
> groupMinInstances/groupMaxInstances.
>
> a. For the groupMinInstances/groupMaxInstances to be usable, the
> initial setting must be such that Max > 1, otherwise the group scaling is
> disabled permanently.
>
> Thanks,
>
> Reka
>
>
>
>
>
> On Fri, Jul 24, 2015 at 4:41 PM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
> Thanks Shaheed for summarizing it..There is a small correction. Sorry..my
> bad..I gave wrong point earlier. I have checked the code and verified the
> functionality. Even application update is implemented when the application
> is in added state.
>
>
>
> On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <
> shahhaqu@cisco.com> wrote:
>
> So, let me see if I can summarise the rules:
>
>
>
> Is this correct? Did I miss something? If this is OK, I’d like to find a
> home for this information in the docs, but I did not see an obvious page.
> Can somebody kindly suggest one? (Maybe under the Advanced User Guide
> section?)
>
>
>
> We have only following page currently. We will include the points that you
> have mentioned here also to the page.
>
> [1]
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
>
> [2]
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
>
> Thanks,
>
> Reka
>
>
>
> Thanks, Shaheed
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* 23 July 2015 17:25
> *To:* dev@stratos.apache.org
> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>
>
>
> Thanks Reka for the clarification, I’ll update my test case accordingly
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>
> *Sent:* Wednesday, July 22, 2015 11:50 PM
> *To:* dev
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Martin,
>
> As we tested the scenario along with your sample, we found out that in the
> initial application, you were using groupMinInstances=1 and
> groupMaxInstances=1 which means that stratos took that decision saying
> groupScaling is disabled for this particular group. After that when you
> update this particular group with groupMinInstances=2 and
> groupMaxInstances=2, stratos should take the decision back that
> groupScaling is enabled for this group which is not possible at the moment.
> Stratos can't change the groupScaling decision dynamically due to the
> design.
>
> But you can achieve group update, if you use the groupMinInstances=1 and
> groupMaxInstances=2 for the initial application and then if you update with
> groupMinInstances=2 and groupMaxInstances=2, it will bring one additional
> group instance.
>
> Please note that GroupScaling is decided by stratos as true only when
> groupMaxInstances > 1
>
>
>
> Hope you understand how the group instance update works. Please let me
> know, if you need more clarification on this.
>
> Thanks,
>
> Reka
>
>
>
> On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Sorry, forgot to attach the log file …
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Wednesday, July 22, 2015 2:41 PM
> *To:* dev@stratos.apache.org
> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Reka, Pubudu
>
>
>
> I tested a scenario where I update group groupMinInstances/groupMaxInstances
> (which according the email thread should ?!).
>
> However, what I observed is that after updating groupMinInstances/groupMaxInstances
> (from 1 to 2) no new group is created.
>
>
>
> Here are the application definitions and log is attached
> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Adding application: [application-id] sub-app-update-4)
>
>
>
> Application deployed (groupMin/Max = 1):
>
>
>
> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
> Application:
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
> sub-app-update-4 state Deployed after 0 s
>
> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
> [application] sub-app-update-4
>
>
>
>
>
> Updated application (groupMin/Max = 2):
>
>
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
> successfully: [application] sub-app-update-4
>
> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
> u'Application updated successfully: [application] sub-app-update-4'}
>
>
>
> Application after update:
>
>
>
>
>
> This is what I would have expected after the application update:
>
>
>
>
>
>
>
>
>
>
>
> Please let me know if there is an issue or updating runtime
> groupMinInstances/groupMaxInstances is currently not supported,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>
> *Sent:* Tuesday, July 21, 2015 11:25 PM
> *To:* dev
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Martin,
>
> As Pubudu explained, those are the expected steps and the result of the
> application update. *Application Runtime* can only be updated with
> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
> Even if you update other parameters, it will get ignored by the back end.
>
> Please note that you can update application only when it is in deployed
> mode. After application is created, if you need to update, then you will
> have to delete the application and create it again. Currently application
> update is not available when the application is in created mode.
>
> Thanks,
>
> Reka
>
>
>
> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
> wrote:
>
> Hi Martin,
>
>
>
> You can update only carridgeMin and cartridgeMax at runtime in application
> update. Even you can update the deployment policy which uses the
> application. But you cannot change the deployment policy in application at
> runtime.
>
>
>
> In your case, as you have used two different deployment policies, it won't
> work. It will use the previous deployment policy. I have tested following
> scenario.
>
>
>
> 1. Use the deployment policy with partition max as 1.
>
> 2. Deploy the application with cartridgeMin 1.
>
> 3. Update the same deployment policy with partition max 2.
>
> 4. Update application at runtime to cartridgeMin 2.
>
> 4. Another instance spawned successfully.
>
>
>
> Thank you!
>
>
>
>
>
> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Hi,
>
>
>
> I am currently testing the API to update an application (most notably to
> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
> policy).
>
>
>
> My main question is which are the parameters which are currently
> supported to be updated as part of application update.
>
>
>
> I have tested updating (increasing the value) of cartridge cartridgeMin /
> cartridgeMax of a cartridge policy which works fine, as long as the
> cartridge deployment policy is correspondingly configured:
>
>
>
> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
> “static-2”) with a partitionMax set to 2.
>
>
>
> However, updating the deployment policy either not supported or fails to
> work.
>
>
>
> For example, if I start initially with cartridgeMin / cartridgeMax = 1
> and a deployment policy “static-1” (with a partitionMax set to 1) and
> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
> deployment policy “static-2” ( with a partitionMax set to 2) the
> cartridge instances are not properly spun up to 2.
>
>
>
> I am not sure if updating the deployment policy (or any other parameters
> beyond min / max in the cartridge policy, e.g min / max in group policy etc
> …) is currently supported or not, which brings me back to my initial
> question which parameters are supported as part of application “update”,
> please clarify.
>
>
>
> Also, is the case supported when decreasing the values, e.g. updating the
> cartridgeMin / cartridgeMax = 2 to 1 ?
>
>
>
> Just in case I attached the policy files and log to the email,
> application, cartridge group json see below inline
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> Before application update:
>
> Application json:
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
> Cartridge-group.json:
>
> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>
>
>
> application update json:
>
>
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
>
>
> Deployment policies (attached):
>
>
>
> static-1.json, static-2.json
>
>
>
> Application (before / after update):
>
>
>
>
>
>
>
>
>
> --
>
> *Pubudu Gunatilaka*
>
> Software Engineer
>
> WSO2, Inc.: http://wso2.com
>
> lean.enterprise.middleware
>
> mobile: +94 77 4078049
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
One interesting observation I made when decrementing the groupMax is that, at least for a transitionary period of time, the VM of the group which is being removed as part of updating the groupMax is “moved” to a surviving group (shows 2 members although min/max = 1), see the sequence below. However note that eventually the VM is being removed as expected.
Before update:
{"alias": "sub-app-update-5", "applicationId": "sub-app-update-5", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-5-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-5-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
[cid:image004.png@01D0C53E.35D91DD0]
Updated json:
{"alias": "sub-app-update-5", "applicationId": "sub-app-update-5", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-5", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-5-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-5-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-5-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
After update:
[cid:image005.png@01D0C53F.8FC3A6C0]
Eventually, the VM in the group is being removed (no picture)
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Friday, July 24, 2015 5:09 AM
To: dev
Cc: Mariangela Hills
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Shaheed,
Found another good reference documentation page[1] and updated with the points for the application.
[1] https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+Artifacts+that+Correspond+to+a+Deployed+Application
On Fri, Jul 24, 2015 at 5:15 PM, Reka Thirunavukkarasu <re...@wso2.com>> wrote:
Hi Shaheed,
Sorry for the confusion..Application update didn't work properly when the application is in CREATED state. It didn't bring up the correct topology even the existing application got updated. We will fix this in the next release. So, the points that you have mentioned are correct. Please keep these points as the working items for the 4.1.0.
1. The Deployment policy “max” can be updated as needed.
a. This controls the overall limit on the maximum number of cartridges on a region+partition basis for each cartridge using this policy.
2. The Application can only be updated when in deployed state.
3. The supported changes are to cartridgeMin/cartridgeMax and/or groupMinInstances/groupMaxInstances.
a. For the groupMinInstances/groupMaxInstances to be usable, the initial setting must be such that Max > 1, otherwise the group scaling is disabled permanently.
Thanks,
Reka
On Fri, Jul 24, 2015 at 4:41 PM, Reka Thirunavukkarasu <re...@wso2.com>> wrote:
Thanks Shaheed for summarizing it..There is a small correction. Sorry..my bad..I gave wrong point earlier. I have checked the code and verified the functionality. Even application update is implemented when the application is in added state.
On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <sh...@cisco.com>> wrote:
So, let me see if I can summarise the rules:
Is this correct? Did I miss something? If this is OK, I’d like to find a home for this information in the docs, but I did not see an obvious page. Can somebody kindly suggest one? (Maybe under the Advanced User Guide section?)
We have only following page currently. We will include the points that you have mentioned here also to the page.
[1] https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
[2] https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
Thanks,
Reka
Thanks, Shaheed
From: Martin Eppel (meppel)
Sent: 23 July 2015 17:25
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: 4.1 Stratos testig: clarifying application update API
Thanks Reka for the clarification, I’ll update my test case accordingly
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Wednesday, July 22, 2015 11:50 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As we tested the scenario along with your sample, we found out that in the initial application, you were using groupMinInstances=1 and
groupMaxInstances=1 which means that stratos took that decision saying groupScaling is disabled for this particular group. After that when you update this particular group with groupMinInstances=2 and groupMaxInstances=2, stratos should take the decision back that groupScaling is enabled for this group which is not possible at the moment. Stratos can't change the groupScaling decision dynamically due to the design.
But you can achieve group update, if you use the groupMinInstances=1 and groupMaxInstances=2 for the initial application and then if you update with groupMinInstances=2 and groupMaxInstances=2, it will bring one additional group instance.
Please note that GroupScaling is decided by stratos as true only when groupMaxInstances > 1
Hope you understand how the group instance update works. Please let me know, if you need more clarification on this.
Thanks,
Reka
On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Sorry, forgot to attach the log file …
From: Martin Eppel (meppel)
Sent: Wednesday, July 22, 2015 2:41 PM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: 4.1 Stratos testig: clarifying application update API
Hi Reka, Pubudu
I tested a scenario where I update group groupMinInstances/groupMaxInstances (which according the email thread should ?!).
However, what I observed is that after updating groupMinInstances/groupMaxInstances (from 1 to 2) no new group is created.
Here are the application definitions and log is attached
(scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} - Adding application: [application-id] sub-app-update-4)
Application deployed (groupMin/Max = 1):
2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format Application:
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added successfully: [application] sub-app-update-4
2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application sub-app-update-4 state Deployed after 0 s
2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:39,826 root INFO: Application deployed successfully: [application] sub-app-update-4
Updated application (groupMin/Max = 2):
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated successfully: [application] sub-app-update-4
2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message': u'Application updated successfully: [application] sub-app-update-4'}
Application after update:
[cid:image008.png@01D0C606.81510B60]
This is what I would have expected after the application update:
[cid:image009.png@01D0C606.81510B60]
Please let me know if there is an issue or updating runtime groupMinInstances/groupMaxInstances is currently not supported,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Tuesday, July 21, 2015 11:25 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the application update. Application Runtime can only be updated with cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances. Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed mode. After application is created, if you need to update, then you will have to delete the application and create it again. Currently application update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>> wrote:
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image010.png@01D0C606.81510B60]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049<tel:%2B94%2077%204078049>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Shaheed,
Found another good reference documentation page[1] and updated with the
points for the application.
[1]
https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+Artifacts+that+Correspond+to+a+Deployed+Application
On Fri, Jul 24, 2015 at 5:15 PM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Hi Shaheed,
>
> Sorry for the confusion..Application update didn't work properly when the
> application is in CREATED state. It didn't bring up the correct topology
> even the existing application got updated. We will fix this in the next
> release. So, the points that you have mentioned are correct. Please keep
> these points as the working items for the 4.1.0.
>
> 1. The Deployment policy “max” can be updated as needed.
>>
>> a. This controls the overall limit on the maximum number of
>> cartridges on a region+partition basis for each cartridge using this policy.
>>
>> 2. The Application can only be updated when in deployed state.
>>
> 3. The supported changes are to cartridgeMin/cartridgeMax and/or
>> groupMinInstances/groupMaxInstances.
>>
>> a. For the groupMinInstances/groupMaxInstances to be usable, the
>> initial setting must be such that Max > 1, otherwise the group scaling is
>> disabled permanently.
>>
> Thanks,
> Reka
>
>
> On Fri, Jul 24, 2015 at 4:41 PM, Reka Thirunavukkarasu <re...@wso2.com>
> wrote:
>
>> Thanks Shaheed for summarizing it..There is a small correction. Sorry..my
>> bad..I gave wrong point earlier. I have checked the code and verified the
>> functionality. Even application update is implemented when the application
>> is in added state.
>>
>> On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <
>> shahhaqu@cisco.com> wrote:
>>
>>> So, let me see if I can summarise the rules:
>>>
>>>
>>>
>> Is this correct? Did I miss something? If this is OK, I’d like to find a
>>> home for this information in the docs, but I did not see an obvious page.
>>> Can somebody kindly suggest one? (Maybe under the Advanced User Guide
>>> section?)
>>>
>>
>> We have only following page currently. We will include the points that
>> you have mentioned here also to the page.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
>>
>> [2]
>> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
>>
>> Thanks,
>> Reka
>>
>>>
>>>
>>> Thanks, Shaheed
>>>
>>>
>>>
>>> *From:* Martin Eppel (meppel)
>>> *Sent:* 23 July 2015 17:25
>>> *To:* dev@stratos.apache.org
>>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>>
>>>
>>>
>>> Thanks Reka for the clarification, I’ll update my test case accordingly
>>>
>>>
>>>
>>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>>> *Sent:* Wednesday, July 22, 2015 11:50 PM
>>> *To:* dev
>>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>>
>>>
>>>
>>> Hi Martin,
>>>
>>> As we tested the scenario along with your sample, we found out that in
>>> the initial application, you were using groupMinInstances=1 and
>>> groupMaxInstances=1 which means that stratos took that decision saying
>>> groupScaling is disabled for this particular group. After that when you
>>> update this particular group with groupMinInstances=2 and
>>> groupMaxInstances=2, stratos should take the decision back that
>>> groupScaling is enabled for this group which is not possible at the moment.
>>> Stratos can't change the groupScaling decision dynamically due to the
>>> design.
>>>
>>> But you can achieve group update, if you use the groupMinInstances=1 and
>>> groupMaxInstances=2 for the initial application and then if you update with
>>> groupMinInstances=2 and groupMaxInstances=2, it will bring one additional
>>> group instance.
>>>
>>> Please note that GroupScaling is decided by stratos as true only when
>>> groupMaxInstances > 1
>>>
>>>
>>>
>>> Hope you understand how the group instance update works. Please let me
>>> know, if you need more clarification on this.
>>>
>>> Thanks,
>>>
>>> Reka
>>>
>>>
>>>
>>> On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
>>> wrote:
>>>
>>> Sorry, forgot to attach the log file …
>>>
>>>
>>>
>>> *From:* Martin Eppel (meppel)
>>> *Sent:* Wednesday, July 22, 2015 2:41 PM
>>> *To:* dev@stratos.apache.org
>>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>>
>>>
>>>
>>> Hi Reka, Pubudu
>>>
>>>
>>>
>>> I tested a scenario where I update group groupMinInstances/groupMaxInstances
>>> (which according the email thread should ?!).
>>>
>>> However, what I observed is that after updating groupMinInstances/groupMaxInstances
>>> (from 1 to 2) no new group is created.
>>>
>>>
>>>
>>> Here are the application definitions and log is attached
>>> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099]
>>> INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
>>> Adding application: [application-id] sub-app-update-4)
>>>
>>>
>>>
>>> Application deployed (groupMin/Max = 1):
>>>
>>>
>>>
>>> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
>>> Application:
>>>
>>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
>>> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
>>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>>
>>>
>>>
>>> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
>>> successfully: [application] sub-app-update-4
>>>
>>> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
>>> successfully: [application] sub-app-update-4
>>>
>>> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
>>> sub-app-update-4 state Deployed after 0 s
>>>
>>> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
>>> successfully: [application] sub-app-update-4
>>>
>>> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
>>> [application] sub-app-update-4
>>>
>>>
>>>
>>>
>>>
>>> Updated application (groupMin/Max = 2):
>>>
>>>
>>>
>>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
>>> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
>>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>>
>>>
>>>
>>> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
>>> successfully: [application] sub-app-update-4
>>>
>>> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
>>> u'Application updated successfully: [application] sub-app-update-4'}
>>>
>>>
>>>
>>> Application after update:
>>>
>>>
>>>
>>>
>>>
>>> This is what I would have expected after the application update:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Please let me know if there is an issue or updating runtime
>>> groupMinInstances/groupMaxInstances is currently not supported,
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>>>
>>> *Sent:* Tuesday, July 21, 2015 11:25 PM
>>> *To:* dev
>>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>>
>>>
>>>
>>> Hi Martin,
>>>
>>> As Pubudu explained, those are the expected steps and the result of the
>>> application update. *Application Runtime* can only be updated with
>>> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
>>> Even if you update other parameters, it will get ignored by the back end.
>>>
>>> Please note that you can update application only when it is in deployed
>>> mode. After application is created, if you need to update, then you will
>>> have to delete the application and create it again. Currently application
>>> update is not available when the application is in created mode.
>>>
>>> Thanks,
>>>
>>> Reka
>>>
>>>
>>>
>>> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
>>> wrote:
>>>
>>> Hi Martin,
>>>
>>>
>>>
>>> You can update only carridgeMin and cartridgeMax at runtime in
>>> application update. Even you can update the deployment policy which uses
>>> the application. But you cannot change the deployment policy in application
>>> at runtime.
>>>
>>>
>>>
>>> In your case, as you have used two different deployment policies, it
>>> won't work. It will use the previous deployment policy. I have tested
>>> following scenario.
>>>
>>>
>>>
>>> 1. Use the deployment policy with partition max as 1.
>>>
>>> 2. Deploy the application with cartridgeMin 1.
>>>
>>> 3. Update the same deployment policy with partition max 2.
>>>
>>> 4. Update application at runtime to cartridgeMin 2.
>>>
>>> 4. Another instance spawned successfully.
>>>
>>>
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I am currently testing the API to update an application (most notably to
>>> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
>>> policy).
>>>
>>>
>>>
>>> My main question is which are the parameters which are currently
>>> supported to be updated as part of application update.
>>>
>>>
>>>
>>> I have tested updating (increasing the value) of cartridge cartridgeMin
>>> / cartridgeMax of a cartridge policy which works fine, as long as the
>>> cartridge deployment policy is correspondingly configured:
>>>
>>>
>>>
>>> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
>>> “static-2”) with a partitionMax set to 2.
>>>
>>>
>>>
>>> However, updating the deployment policy either not supported or fails to
>>> work.
>>>
>>>
>>>
>>> For example, if I start initially with cartridgeMin / cartridgeMax = 1
>>> and a deployment policy “static-1” (with a partitionMax set to 1) and
>>> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and
>>> the deployment policy “static-2” ( with a partitionMax set to 2) the
>>> cartridge instances are not properly spun up to 2.
>>>
>>>
>>>
>>> I am not sure if updating the deployment policy (or any other parameters
>>> beyond min / max in the cartridge policy, e.g min / max in group policy etc
>>> …) is currently supported or not, which brings me back to my initial
>>> question which parameters are supported as part of application “update”,
>>> please clarify.
>>>
>>>
>>>
>>> Also, is the case supported when decreasing the values, e.g. updating
>>> the cartridgeMin / cartridgeMax = 2 to 1 ?
>>>
>>>
>>>
>>> Just in case I attached the policy files and log to the email,
>>> application, cartridge group json see below inline
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>> Before application update:
>>>
>>> Application json:
>>>
>>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
>>> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias":
>>> "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy":
>>> "economyPolicy"}}], "groups": []}]}}
>>>
>>>
>>>
>>> Cartridge-group.json:
>>>
>>> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
>>> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>>>
>>>
>>>
>>> application update json:
>>>
>>>
>>>
>>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
>>> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias":
>>> "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy":
>>> "economyPolicy"}}], "groups": []}]}}
>>>
>>>
>>>
>>>
>>>
>>> Deployment policies (attached):
>>>
>>>
>>>
>>> static-1.json, static-2.json
>>>
>>>
>>>
>>> Application (before / after update):
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Pubudu Gunatilaka*
>>>
>>> Software Engineer
>>>
>>> WSO2, Inc.: http://wso2.com
>>>
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 77 4078049
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Reka Thirunavukkarasu
>>> Senior Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>>
>>> Mobile: +94776442007
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Reka Thirunavukkarasu
>>> Senior Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>>
>>> Mobile: +94776442007
>>>
>>>
>>>
>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Shaheed,
Sorry for the confusion..Application update didn't work properly when the
application is in CREATED state. It didn't bring up the correct topology
even the existing application got updated. We will fix this in the next
release. So, the points that you have mentioned are correct. Please keep
these points as the working items for the 4.1.0.
1. The Deployment policy “max” can be updated as needed.
>
> a. This controls the overall limit on the maximum number of
> cartridges on a region+partition basis for each cartridge using this policy.
>
> 2. The Application can only be updated when in deployed state.
>
3. The supported changes are to cartridgeMin/cartridgeMax and/or
> groupMinInstances/groupMaxInstances.
>
> a. For the groupMinInstances/groupMaxInstances to be usable, the
> initial setting must be such that Max > 1, otherwise the group scaling is
> disabled permanently.
>
Thanks,
Reka
On Fri, Jul 24, 2015 at 4:41 PM, Reka Thirunavukkarasu <re...@wso2.com>
wrote:
> Thanks Shaheed for summarizing it..There is a small correction. Sorry..my
> bad..I gave wrong point earlier. I have checked the code and verified the
> functionality. Even application update is implemented when the application
> is in added state.
>
> On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <
> shahhaqu@cisco.com> wrote:
>
>> So, let me see if I can summarise the rules:
>>
>>
>>
> Is this correct? Did I miss something? If this is OK, I’d like to find a
>> home for this information in the docs, but I did not see an obvious page.
>> Can somebody kindly suggest one? (Maybe under the Advanced User Guide
>> section?)
>>
>
> We have only following page currently. We will include the points that you
> have mentioned here also to the page.
>
> [1]
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
>
> [2]
> https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
>
> Thanks,
> Reka
>
>>
>>
>> Thanks, Shaheed
>>
>>
>>
>> *From:* Martin Eppel (meppel)
>> *Sent:* 23 July 2015 17:25
>> *To:* dev@stratos.apache.org
>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Thanks Reka for the clarification, I’ll update my test case accordingly
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>> *Sent:* Wednesday, July 22, 2015 11:50 PM
>> *To:* dev
>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Martin,
>>
>> As we tested the scenario along with your sample, we found out that in
>> the initial application, you were using groupMinInstances=1 and
>> groupMaxInstances=1 which means that stratos took that decision saying
>> groupScaling is disabled for this particular group. After that when you
>> update this particular group with groupMinInstances=2 and
>> groupMaxInstances=2, stratos should take the decision back that
>> groupScaling is enabled for this group which is not possible at the moment.
>> Stratos can't change the groupScaling decision dynamically due to the
>> design.
>>
>> But you can achieve group update, if you use the groupMinInstances=1 and
>> groupMaxInstances=2 for the initial application and then if you update with
>> groupMinInstances=2 and groupMaxInstances=2, it will bring one additional
>> group instance.
>>
>> Please note that GroupScaling is decided by stratos as true only when
>> groupMaxInstances > 1
>>
>>
>>
>> Hope you understand how the group instance update works. Please let me
>> know, if you need more clarification on this.
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>> On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
>> wrote:
>>
>> Sorry, forgot to attach the log file …
>>
>>
>>
>> *From:* Martin Eppel (meppel)
>> *Sent:* Wednesday, July 22, 2015 2:41 PM
>> *To:* dev@stratos.apache.org
>> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Reka, Pubudu
>>
>>
>>
>> I tested a scenario where I update group groupMinInstances/groupMaxInstances
>> (which according the email thread should ?!).
>>
>> However, what I observed is that after updating groupMinInstances/groupMaxInstances
>> (from 1 to 2) no new group is created.
>>
>>
>>
>> Here are the application definitions and log is attached
>> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099]
>> INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
>> Adding application: [application-id] sub-app-update-4)
>>
>>
>>
>> Application deployed (groupMin/Max = 1):
>>
>>
>>
>> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
>> Application:
>>
>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
>> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
>> sub-app-update-4 state Deployed after 0 s
>>
>> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
>> [application] sub-app-update-4
>>
>>
>>
>>
>>
>> Updated application (groupMin/Max = 2):
>>
>>
>>
>> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
>> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
>> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
>> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
>> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
>> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>>
>>
>>
>> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
>> successfully: [application] sub-app-update-4
>>
>> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
>> u'Application updated successfully: [application] sub-app-update-4'}
>>
>>
>>
>> Application after update:
>>
>>
>>
>>
>>
>> This is what I would have expected after the application update:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Please let me know if there is an issue or updating runtime
>> groupMinInstances/groupMaxInstances is currently not supported,
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>>
>>
>>
>>
>> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>>
>> *Sent:* Tuesday, July 21, 2015 11:25 PM
>> *To:* dev
>> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>>
>>
>>
>> Hi Martin,
>>
>> As Pubudu explained, those are the expected steps and the result of the
>> application update. *Application Runtime* can only be updated with
>> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
>> Even if you update other parameters, it will get ignored by the back end.
>>
>> Please note that you can update application only when it is in deployed
>> mode. After application is created, if you need to update, then you will
>> have to delete the application and create it again. Currently application
>> update is not available when the application is in created mode.
>>
>> Thanks,
>>
>> Reka
>>
>>
>>
>> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
>> wrote:
>>
>> Hi Martin,
>>
>>
>>
>> You can update only carridgeMin and cartridgeMax at runtime in
>> application update. Even you can update the deployment policy which uses
>> the application. But you cannot change the deployment policy in application
>> at runtime.
>>
>>
>>
>> In your case, as you have used two different deployment policies, it
>> won't work. It will use the previous deployment policy. I have tested
>> following scenario.
>>
>>
>>
>> 1. Use the deployment policy with partition max as 1.
>>
>> 2. Deploy the application with cartridgeMin 1.
>>
>> 3. Update the same deployment policy with partition max 2.
>>
>> 4. Update application at runtime to cartridgeMin 2.
>>
>> 4. Another instance spawned successfully.
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
>> wrote:
>>
>> Hi,
>>
>>
>>
>> I am currently testing the API to update an application (most notably to
>> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
>> policy).
>>
>>
>>
>> My main question is which are the parameters which are currently
>> supported to be updated as part of application update.
>>
>>
>>
>> I have tested updating (increasing the value) of cartridge cartridgeMin /
>> cartridgeMax of a cartridge policy which works fine, as long as the
>> cartridge deployment policy is correspondingly configured:
>>
>>
>>
>> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
>> “static-2”) with a partitionMax set to 2.
>>
>>
>>
>> However, updating the deployment policy either not supported or fails to
>> work.
>>
>>
>>
>> For example, if I start initially with cartridgeMin / cartridgeMax = 1
>> and a deployment policy “static-1” (with a partitionMax set to 1) and
>> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
>> deployment policy “static-2” ( with a partitionMax set to 2) the
>> cartridge instances are not properly spun up to 2.
>>
>>
>>
>> I am not sure if updating the deployment policy (or any other parameters
>> beyond min / max in the cartridge policy, e.g min / max in group policy etc
>> …) is currently supported or not, which brings me back to my initial
>> question which parameters are supported as part of application “update”,
>> please clarify.
>>
>>
>>
>> Also, is the case supported when decreasing the values, e.g. updating
>> the cartridgeMin / cartridgeMax = 2 to 1 ?
>>
>>
>>
>> Just in case I attached the policy files and log to the email,
>> application, cartridge group json see below inline
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>> Before application update:
>>
>> Application json:
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
>> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>> Cartridge-group.json:
>>
>> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
>> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>>
>>
>>
>> application update json:
>>
>>
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
>> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>>
>>
>> Deployment policies (attached):
>>
>>
>>
>> static-1.json, static-2.json
>>
>>
>>
>> Application (before / after update):
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> *Pubudu Gunatilaka*
>>
>> Software Engineer
>>
>> WSO2, Inc.: http://wso2.com
>>
>> lean.enterprise.middleware
>>
>> mobile: +94 77 4078049
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>>
>>
>>
>> --
>>
>> Reka Thirunavukkarasu
>> Senior Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>>
>> Mobile: +94776442007
>>
>>
>>
>
>
>
> --
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Thanks Shaheed for summarizing it..There is a small correction. Sorry..my
bad..I gave wrong point earlier. I have checked the code and verified the
functionality. Even application update is implemented when the application
is in added state.
On Fri, Jul 24, 2015 at 4:20 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> So, let me see if I can summarise the rules:
>
>
>
> 1. The Deployment policy “max” can be updated as needed.
>
> a. This controls the overall limit on the maximum number of
> cartridges on a region+partition basis for each cartridge using this policy.
>
> 2. The Application can only be updated when in deployed state.
>
Application can be updated at any time whether the application added or in
deployed mode as i explained earlier.
> 3. The supported changes are to cartridgeMin/cartridgeMax and/or
> groupMinInstances/groupMaxInstances.
>
> a. For the groupMinInstances/groupMaxInstances to be usable, the
> initial setting must be such that Max > 1, otherwise the group scaling is
> disabled permanently.
>
>
>
> Is this correct? Did I miss something? If this is OK, I’d like to find a
> home for this information in the docs, but I did not see an obvious page.
> Can somebody kindly suggest one? (Maybe under the Advanced User Guide
> section?)
>
We have only following page currently. We will include the points that you
have mentioned here also to the page.
[1]
https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+an+Application
[2]
https://cwiki.apache.org/confluence/display/STRATOS/4.1.0+Updating+a+Network+Partition
Thanks,
Reka
>
>
> Thanks, Shaheed
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* 23 July 2015 17:25
> *To:* dev@stratos.apache.org
> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>
>
>
> Thanks Reka for the clarification, I’ll update my test case accordingly
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
> *Sent:* Wednesday, July 22, 2015 11:50 PM
> *To:* dev
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Martin,
>
> As we tested the scenario along with your sample, we found out that in the
> initial application, you were using groupMinInstances=1 and
> groupMaxInstances=1 which means that stratos took that decision saying
> groupScaling is disabled for this particular group. After that when you
> update this particular group with groupMinInstances=2 and
> groupMaxInstances=2, stratos should take the decision back that
> groupScaling is enabled for this group which is not possible at the moment.
> Stratos can't change the groupScaling decision dynamically due to the
> design.
>
> But you can achieve group update, if you use the groupMinInstances=1 and
> groupMaxInstances=2 for the initial application and then if you update with
> groupMinInstances=2 and groupMaxInstances=2, it will bring one additional
> group instance.
>
> Please note that GroupScaling is decided by stratos as true only when
> groupMaxInstances > 1
>
>
>
> Hope you understand how the group instance update works. Please let me
> know, if you need more clarification on this.
>
> Thanks,
>
> Reka
>
>
>
> On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Sorry, forgot to attach the log file …
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Wednesday, July 22, 2015 2:41 PM
> *To:* dev@stratos.apache.org
> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Reka, Pubudu
>
>
>
> I tested a scenario where I update group groupMinInstances/groupMaxInstances
> (which according the email thread should ?!).
>
> However, what I observed is that after updating groupMinInstances/groupMaxInstances
> (from 1 to 2) no new group is created.
>
>
>
> Here are the application definitions and log is attached
> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Adding application: [application-id] sub-app-update-4)
>
>
>
> Application deployed (groupMin/Max = 1):
>
>
>
> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
> Application:
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
> sub-app-update-4 state Deployed after 0 s
>
> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
> [application] sub-app-update-4
>
>
>
>
>
> Updated application (groupMin/Max = 2):
>
>
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
> successfully: [application] sub-app-update-4
>
> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
> u'Application updated successfully: [application] sub-app-update-4'}
>
>
>
> Application after update:
>
>
>
>
>
> This is what I would have expected after the application update:
>
>
>
>
>
>
>
>
>
>
>
> Please let me know if there is an issue or updating runtime
> groupMinInstances/groupMaxInstances is currently not supported,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
>
> *Sent:* Tuesday, July 21, 2015 11:25 PM
> *To:* dev
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Martin,
>
> As Pubudu explained, those are the expected steps and the result of the
> application update. *Application Runtime* can only be updated with
> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
> Even if you update other parameters, it will get ignored by the back end.
>
> Please note that you can update application only when it is in deployed
> mode. After application is created, if you need to update, then you will
> have to delete the application and create it again. Currently application
> update is not available when the application is in created mode.
>
> Thanks,
>
> Reka
>
>
>
> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
> wrote:
>
> Hi Martin,
>
>
>
> You can update only carridgeMin and cartridgeMax at runtime in application
> update. Even you can update the deployment policy which uses the
> application. But you cannot change the deployment policy in application at
> runtime.
>
>
>
> In your case, as you have used two different deployment policies, it won't
> work. It will use the previous deployment policy. I have tested following
> scenario.
>
>
>
> 1. Use the deployment policy with partition max as 1.
>
> 2. Deploy the application with cartridgeMin 1.
>
> 3. Update the same deployment policy with partition max 2.
>
> 4. Update application at runtime to cartridgeMin 2.
>
> 4. Another instance spawned successfully.
>
>
>
> Thank you!
>
>
>
>
>
> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Hi,
>
>
>
> I am currently testing the API to update an application (most notably to
> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
> policy).
>
>
>
> My main question is which are the parameters which are currently
> supported to be updated as part of application update.
>
>
>
> I have tested updating (increasing the value) of cartridge cartridgeMin /
> cartridgeMax of a cartridge policy which works fine, as long as the
> cartridge deployment policy is correspondingly configured:
>
>
>
> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
> “static-2”) with a partitionMax set to 2.
>
>
>
> However, updating the deployment policy either not supported or fails to
> work.
>
>
>
> For example, if I start initially with cartridgeMin / cartridgeMax = 1
> and a deployment policy “static-1” (with a partitionMax set to 1) and
> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
> deployment policy “static-2” ( with a partitionMax set to 2) the
> cartridge instances are not properly spun up to 2.
>
>
>
> I am not sure if updating the deployment policy (or any other parameters
> beyond min / max in the cartridge policy, e.g min / max in group policy etc
> …) is currently supported or not, which brings me back to my initial
> question which parameters are supported as part of application “update”,
> please clarify.
>
>
>
> Also, is the case supported when decreasing the values, e.g. updating the
> cartridgeMin / cartridgeMax = 2 to 1 ?
>
>
>
> Just in case I attached the policy files and log to the email,
> application, cartridge group json see below inline
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> Before application update:
>
> Application json:
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
> Cartridge-group.json:
>
> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>
>
>
> application update json:
>
>
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
>
>
> Deployment policies (attached):
>
>
>
> static-1.json, static-2.json
>
>
>
> Application (before / after update):
>
>
>
>
>
>
>
>
>
> --
>
> *Pubudu Gunatilaka*
>
> Software Engineer
>
> WSO2, Inc.: http://wso2.com
>
> lean.enterprise.middleware
>
> mobile: +94 77 4078049
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
So, let me see if I can summarise the rules:
1. The Deployment policy “max” can be updated as needed.
a. This controls the overall limit on the maximum number of cartridges on a region+partition basis for each cartridge using this policy.
2. The Application can only be updated when in deployed state.
3. The supported changes are to cartridgeMin/cartridgeMax and/or groupMinInstances/groupMaxInstances.
a. For the groupMinInstances/groupMaxInstances to be usable, the initial setting must be such that Max > 1, otherwise the group scaling is disabled permanently.
Is this correct? Did I miss something? If this is OK, I’d like to find a home for this information in the docs, but I did not see an obvious page. Can somebody kindly suggest one? (Maybe under the Advanced User Guide section?)
Thanks, Shaheed
From: Martin Eppel (meppel)
Sent: 23 July 2015 17:25
To: dev@stratos.apache.org
Subject: RE: 4.1 Stratos testig: clarifying application update API
Thanks Reka for the clarification, I’ll update my test case accordingly
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Wednesday, July 22, 2015 11:50 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As we tested the scenario along with your sample, we found out that in the initial application, you were using groupMinInstances=1 and
groupMaxInstances=1 which means that stratos took that decision saying groupScaling is disabled for this particular group. After that when you update this particular group with groupMinInstances=2 and groupMaxInstances=2, stratos should take the decision back that groupScaling is enabled for this group which is not possible at the moment. Stratos can't change the groupScaling decision dynamically due to the design.
But you can achieve group update, if you use the groupMinInstances=1 and groupMaxInstances=2 for the initial application and then if you update with groupMinInstances=2 and groupMaxInstances=2, it will bring one additional group instance.
Please note that GroupScaling is decided by stratos as true only when groupMaxInstances > 1
Hope you understand how the group instance update works. Please let me know, if you need more clarification on this.
Thanks,
Reka
On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Sorry, forgot to attach the log file …
From: Martin Eppel (meppel)
Sent: Wednesday, July 22, 2015 2:41 PM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: 4.1 Stratos testig: clarifying application update API
Hi Reka, Pubudu
I tested a scenario where I update group groupMinInstances/groupMaxInstances (which according the email thread should ?!).
However, what I observed is that after updating groupMinInstances/groupMaxInstances (from 1 to 2) no new group is created.
Here are the application definitions and log is attached
(scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} - Adding application: [application-id] sub-app-update-4)
Application deployed (groupMin/Max = 1):
2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format Application:
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added successfully: [application] sub-app-update-4
2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application sub-app-update-4 state Deployed after 0 s
2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:39,826 root INFO: Application deployed successfully: [application] sub-app-update-4
Updated application (groupMin/Max = 2):
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated successfully: [application] sub-app-update-4
2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message': u'Application updated successfully: [application] sub-app-update-4'}
Application after update:
[cid:image001.png@01D0C604.7E25CE00]
This is what I would have expected after the application update:
[cid:image002.png@01D0C604.7E25CE00]
Please let me know if there is an issue or updating runtime groupMinInstances/groupMaxInstances is currently not supported,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Tuesday, July 21, 2015 11:25 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the application update. Application Runtime can only be updated with cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances. Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed mode. After application is created, if you need to update, then you will have to delete the application and create it again. Currently application update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>> wrote:
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image003.png@01D0C604.7E25CE00]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049<tel:%2B94%2077%204078049>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Thanks Reka for the clarification, I’ll update my test case accordingly
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Wednesday, July 22, 2015 11:50 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As we tested the scenario along with your sample, we found out that in the initial application, you were using groupMinInstances=1 and
groupMaxInstances=1 which means that stratos took that decision saying groupScaling is disabled for this particular group. After that when you update this particular group with groupMinInstances=2 and groupMaxInstances=2, stratos should take the decision back that groupScaling is enabled for this group which is not possible at the moment. Stratos can't change the groupScaling decision dynamically due to the design.
But you can achieve group update, if you use the groupMinInstances=1 and groupMaxInstances=2 for the initial application and then if you update with groupMinInstances=2 and groupMaxInstances=2, it will bring one additional group instance.
Please note that GroupScaling is decided by stratos as true only when groupMaxInstances > 1
Hope you understand how the group instance update works. Please let me know, if you need more clarification on this.
Thanks,
Reka
On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Sorry, forgot to attach the log file …
From: Martin Eppel (meppel)
Sent: Wednesday, July 22, 2015 2:41 PM
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: RE: 4.1 Stratos testig: clarifying application update API
Hi Reka, Pubudu
I tested a scenario where I update group groupMinInstances/groupMaxInstances (which according the email thread should ?!).
However, what I observed is that after updating groupMinInstances/groupMaxInstances (from 1 to 2) no new group is created.
Here are the application definitions and log is attached
(scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} - Adding application: [application-id] sub-app-update-4)
Application deployed (groupMin/Max = 1):
2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format Application:
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added successfully: [application] sub-app-update-4
2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application sub-app-update-4 state Deployed after 0 s
2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:39,826 root INFO: Application deployed successfully: [application] sub-app-update-4
Updated application (groupMin/Max = 2):
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated successfully: [application] sub-app-update-4
2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message': u'Application updated successfully: [application] sub-app-update-4'}
Application after update:
[cid:image001.png@01D0C529.6FA4D9B0]
This is what I would have expected after the application update:
[cid:image002.png@01D0C529.6FA4D9B0]
Please let me know if there is an issue or updating runtime groupMinInstances/groupMaxInstances is currently not supported,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Tuesday, July 21, 2015 11:25 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the application update. Application Runtime can only be updated with cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances. Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed mode. After application is created, if you need to update, then you will have to delete the application and create it again. Currently application update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>> wrote:
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image003.png@01D0C529.6FA4D9B0]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049<tel:%2B94%2077%204078049>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007<tel:%2B94776442007>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Martin,
As we tested the scenario along with your sample, we found out that in the
initial application, you were using groupMinInstances=1 and
groupMaxInstances=1 which means that stratos took that decision saying
groupScaling is disabled for this particular group. After that when you
update this particular group with groupMinInstances=2 and groupMaxInstances=2,
stratos should take the decision back that groupScaling is enabled for this
group which is not possible at the moment. Stratos can't change the
groupScaling decision dynamically due to the design.
But you can achieve group update, if you use the groupMinInstances=1
and groupMaxInstances=2
for the initial application and then if you update with groupMinInstances=2
and groupMaxInstances=2, it will bring one additional group instance.
Please note that GroupScaling is decided by stratos as true only when
groupMaxInstances
> 1
Hope you understand how the group instance update works. Please let me
know, if you need more clarification on this.
Thanks,
Reka
On Thu, Jul 23, 2015 at 3:12 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> Sorry, forgot to attach the log file …
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* Wednesday, July 22, 2015 2:41 PM
> *To:* dev@stratos.apache.org
> *Subject:* RE: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Reka, Pubudu
>
>
>
> I tested a scenario where I update group groupMinInstances/groupMaxInstances
> (which according the email thread should ?!).
>
> However, what I observed is that after updating groupMinInstances/groupMaxInstances
> (from 1 to 2) no new group is created.
>
>
>
> Here are the application definitions and log is attached
> (scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO
> {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} -
> Adding application: [application-id] sub-app-update-4)
>
>
>
> Application deployed (groupMin/Max = 1):
>
>
>
> 2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format
> Application:
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1,
> "groupMinInstances": 1, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application
> sub-app-update-4 state Deployed after 0 s
>
> 2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed
> successfully: [application] sub-app-update-4
>
> 2015-07-22 11:53:39,826 root INFO: Application deployed successfully:
> [application] sub-app-update-4
>
>
>
>
>
> Updated application (groupMin/Max = 2):
>
>
>
> {"alias": "sub-app-update-4", "applicationId": "sub-app-update-4",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax":
> 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}],
> "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2,
> "groupMinInstances": 2, "alias": "application-update-4-2-0x0",
> "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2",
> "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2",
> "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
>
>
>
> 2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated
> successfully: [application] sub-app-update-4
>
> 2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message':
> u'Application updated successfully: [application] sub-app-update-4'}
>
>
>
> Application after update:
>
>
>
>
>
> This is what I would have expected after the application update:
>
>
>
>
>
>
>
>
>
>
>
> Please let me know if there is an issue or updating runtime
> groupMinInstances/groupMaxInstances is currently not supported,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
>
>
>
>
> *From:* Reka Thirunavukkarasu [mailto:reka@wso2.com <re...@wso2.com>]
> *Sent:* Tuesday, July 21, 2015 11:25 PM
> *To:* dev
> *Subject:* Re: 4.1 Stratos testig: clarifying application update API
>
>
>
> Hi Martin,
>
> As Pubudu explained, those are the expected steps and the result of the
> application update. *Application Runtime* can only be updated with
> cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
> Even if you update other parameters, it will get ignored by the back end.
>
> Please note that you can update application only when it is in deployed
> mode. After application is created, if you need to update, then you will
> have to delete the application and create it again. Currently application
> update is not available when the application is in created mode.
>
> Thanks,
>
> Reka
>
>
>
> On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
> wrote:
>
> Hi Martin,
>
>
>
> You can update only carridgeMin and cartridgeMax at runtime in application
> update. Even you can update the deployment policy which uses the
> application. But you cannot change the deployment policy in application at
> runtime.
>
>
>
> In your case, as you have used two different deployment policies, it won't
> work. It will use the previous deployment policy. I have tested following
> scenario.
>
>
>
> 1. Use the deployment policy with partition max as 1.
>
> 2. Deploy the application with cartridgeMin 1.
>
> 3. Update the same deployment policy with partition max 2.
>
> 4. Update application at runtime to cartridgeMin 2.
>
> 4. Another instance spawned successfully.
>
>
>
> Thank you!
>
>
>
>
>
> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
> Hi,
>
>
>
> I am currently testing the API to update an application (most notably to
> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
> policy).
>
>
>
> My main question is which are the parameters which are currently
> supported to be updated as part of application update.
>
>
>
> I have tested updating (increasing the value) of cartridge cartridgeMin /
> cartridgeMax of a cartridge policy which works fine, as long as the
> cartridge deployment policy is correspondingly configured:
>
>
>
> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
> “static-2”) with a partitionMax set to 2.
>
>
>
> However, updating the deployment policy either not supported or fails to
> work.
>
>
>
> For example, if I start initially with cartridgeMin / cartridgeMax = 1
> and a deployment policy “static-1” (with a partitionMax set to 1) and
> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
> deployment policy “static-2” ( with a partitionMax set to 2) the
> cartridge instances are not properly spun up to 2.
>
>
>
> I am not sure if updating the deployment policy (or any other parameters
> beyond min / max in the cartridge policy, e.g min / max in group policy etc
> …) is currently supported or not, which brings me back to my initial
> question which parameters are supported as part of application “update”,
> please clarify.
>
>
>
> Also, is the case supported when decreasing the values, e.g. updating the
> cartridgeMin / cartridgeMax = 2 to 1 ?
>
>
>
> Just in case I attached the policy files and log to the email,
> application, cartridge group json see below inline
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> Before application update:
>
> Application json:
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
> Cartridge-group.json:
>
> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>
>
>
> application update json:
>
>
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
>
>
> Deployment policies (attached):
>
>
>
> static-1.json, static-2.json
>
>
>
> Application (before / after update):
>
>
>
>
>
>
>
>
>
> --
>
> *Pubudu Gunatilaka*
>
> Software Engineer
>
> WSO2, Inc.: http://wso2.com
>
> lean.enterprise.middleware
>
> mobile: +94 77 4078049
>
>
>
>
> --
>
> Reka Thirunavukkarasu
> Senior Software Engineer,
> WSO2, Inc.:http://wso2.com,
>
> Mobile: +94776442007
>
>
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Sorry, forgot to attach the log file …
From: Martin Eppel (meppel)
Sent: Wednesday, July 22, 2015 2:41 PM
To: dev@stratos.apache.org
Subject: RE: 4.1 Stratos testig: clarifying application update API
Hi Reka, Pubudu
I tested a scenario where I update group groupMinInstances/groupMaxInstances (which according the email thread should ?!).
However, what I observed is that after updating groupMinInstances/groupMaxInstances (from 1 to 2) no new group is created.
Here are the application definitions and log is attached
(scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} - Adding application: [application-id] sub-app-update-4)
Application deployed (groupMin/Max = 1):
2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format Application:
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added successfully: [application] sub-app-update-4
2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application sub-app-update-4 state Deployed after 0 s
2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:39,826 root INFO: Application deployed successfully: [application] sub-app-update-4
Updated application (groupMin/Max = 2):
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated successfully: [application] sub-app-update-4
2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message': u'Application updated successfully: [application] sub-app-update-4'}
Application after update:
[cid:image001.png@01D0C48C.A4D96300]
This is what I would have expected after the application update:
[cid:image002.png@01D0C48C.A4D96300]
Please let me know if there is an issue or updating runtime groupMinInstances/groupMaxInstances is currently not supported,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Tuesday, July 21, 2015 11:25 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the application update. Application Runtime can only be updated with cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances. Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed mode. After application is created, if you need to update, then you will have to delete the application and create it again. Currently application update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>> wrote:
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image003.png@01D0C48C.A4D96300]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
RE: 4.1 Stratos testig: clarifying application update API
Posted by "Martin Eppel (meppel)" <me...@cisco.com>.
Hi Reka, Pubudu
I tested a scenario where I update group groupMinInstances/groupMaxInstances (which according the email thread should ?!).
However, what I observed is that after updating groupMinInstances/groupMaxInstances (from 1 to 2) no new group is created.
Here are the application definitions and log is attached
(scenario starts with: TID: [0] [STRATOS] [2015-07-22 18:53:37,099] INFO {org.apache.stratos.autoscaler.services.impl.AutoscalerServiceImpl} - Adding application: [application-id] sub-app-update-4)
Application deployed (groupMin/Max = 1):
2015-07-22 11:53:37,217 libmultiiaas.octl DEBUG: Stratos format Application:
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 11:53:37,540 libmultiiaas.octl INFO: Application added successfully: [application] sub-app-update-4
2015-07-22 11:53:37,770 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:37,825 libmultiiaas.octl INFO: Deploying Application sub-app-update-4 state Deployed after 0 s
2015-07-22 11:53:39,826 libmultiiaas.octl DEBUG: Application deployed successfully: [application] sub-app-update-4
2015-07-22 11:53:39,826 root INFO: Application deployed successfully: [application] sub-app-update-4
Updated application (groupMin/Max = 2):
{"alias": "sub-app-update-4", "applicationId": "sub-app-update-4", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-4", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-4-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-3", "autoscalingPolicy": "economyPolicy"}}], "groups": [{"name": "application-update-4-2", "groupMaxInstances": 2, "groupMinInstances": 2, "alias": "application-update-4-2-0x0", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c2", "subscribableInfo": {"alias": "c2-1x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}]}}
2015-07-22 12:03:14,356 libmultiiaas.octl INFO: Application updated successfully: [application] sub-app-update-4
2015-07-22 12:03:14,356 root INFO: {u'status': u'success', u'message': u'Application updated successfully: [application] sub-app-update-4'}
Application after update:
[cid:image002.png@01D0C47E.8BB235E0]
This is what I would have expected after the application update:
[cid:image003.png@01D0C47E.8BB235E0]
Please let me know if there is an issue or updating runtime groupMinInstances/groupMaxInstances is currently not supported,
Thanks
Martin
From: Reka Thirunavukkarasu [mailto:reka@wso2.com]
Sent: Tuesday, July 21, 2015 11:25 PM
To: dev
Subject: Re: 4.1 Stratos testig: clarifying application update API
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the application update. Application Runtime can only be updated with cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances. Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed mode. After application is created, if you need to update, then you will have to delete the application and create it again. Currently application update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>> wrote:
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application update. Even you can update the deployment policy which uses the application. But you cannot change the deployment policy in application at runtime.
In your case, as you have used two different deployment policies, it won't work. It will use the previous deployment policy. I have tested following scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>> wrote:
Hi,
I am currently testing the API to update an application (most notably to update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment policy).
My main question is which are the parameters which are currently supported to be updated as part of application update.
I have tested updating (increasing the value) of cartridge cartridgeMin / cartridgeMax of a cartridge policy which works fine, as long as the cartridge deployment policy is correspondingly configured:
e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy “static-2”) with a partitionMax set to 2.
However, updating the deployment policy either not supported or fails to work.
For example, if I start initially with cartridgeMin / cartridgeMax = 1 and a deployment policy “static-1” (with a partitionMax set to 1) and then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the deployment policy “static-2” ( with a partitionMax set to 2) the cartridge instances are not properly spun up to 2.
I am not sure if updating the deployment policy (or any other parameters beyond min / max in the cartridge policy, e.g min / max in group policy etc …) is currently supported or not, which brings me back to my initial question which parameters are supported as part of application “update”, please clarify.
Also, is the case supported when decreasing the values, e.g. updating the cartridgeMin / cartridgeMax = 2 to 1 ?
Just in case I attached the policy files and log to the email, application, cartridge group json see below inline
Thanks
Martin
Before application update:
Application json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1, "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Cartridge-group.json:
{"name": "sub-app-update-1", "dependencies": {"terminationBehaviour": "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
application update json:
{"alias": "sub-app-update-1", "applicationId": "sub-app-update-1", "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1", "groupMaxInstances": 1, "groupMinInstances": 1, "alias": "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2, "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0", "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}], "groups": []}]}}
Deployment policies (attached):
static-1.json, static-2.json
Application (before / after update):
[cid:image004.png@01D0C47E.8BB235E0]
--
Pubudu Gunatilaka
Software Engineer
WSO2, Inc.: http://wso2.com<http://wso2.com/>
lean.enterprise.middleware
mobile: +94 77 4078049
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi Martin,
As Pubudu explained, those are the expected steps and the result of the
application update. *Application Runtime* can only be updated with
cartridgeMin/cartridgeMax and/or with groupMinInstances/groupMaxInstances.
Even if you update other parameters, it will get ignored by the back end.
Please note that you can update application only when it is in deployed
mode. After application is created, if you need to update, then you will
have to delete the application and create it again. Currently application
update is not available when the application is in created mode.
Thanks,
Reka
On Wed, Jul 22, 2015 at 11:29 AM, Pubudu Gunatilaka <pu...@wso2.com>
wrote:
> Hi Martin,
>
> You can update only carridgeMin and cartridgeMax at runtime in application
> update. Even you can update the deployment policy which uses the
> application. But you cannot change the deployment policy in application at
> runtime.
>
> In your case, as you have used two different deployment policies, it won't
> work. It will use the previous deployment policy. I have tested following
> scenario.
>
> 1. Use the deployment policy with partition max as 1.
> 2. Deploy the application with cartridgeMin 1.
> 3. Update the same deployment policy with partition max 2.
> 4. Update application at runtime to cartridgeMin 2.
> 4. Another instance spawned successfully.
>
> Thank you!
>
>
> On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
> wrote:
>
>> Hi,
>>
>>
>>
>> I am currently testing the API to update an application (most notably to
>> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
>> policy).
>>
>>
>>
>> My main question is which are the parameters which are currently
>> supported to be updated as part of application update.
>>
>>
>>
>> I have tested updating (increasing the value) of cartridge cartridgeMin /
>> cartridgeMax of a cartridge policy which works fine, as long as the
>> cartridge deployment policy is correspondingly configured:
>>
>>
>>
>> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
>> “static-2”) with a partitionMax set to 2.
>>
>>
>>
>> However, updating the deployment policy either not supported or fails to
>> work.
>>
>>
>>
>> For example, if I start initially with cartridgeMin / cartridgeMax = 1
>> and a deployment policy “static-1” (with a partitionMax set to 1) and
>> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
>> deployment policy “static-2” ( with a partitionMax set to 2) the
>> cartridge instances are not properly spun up to 2.
>>
>>
>>
>> I am not sure if updating the deployment policy (or any other parameters
>> beyond min / max in the cartridge policy, e.g min / max in group policy etc
>> …) is currently supported or not, which brings me back to my initial
>> question which parameters are supported as part of application “update”,
>> please clarify.
>>
>>
>>
>> Also, is the case supported when decreasing the values, e.g. updating
>> the cartridgeMin / cartridgeMax = 2 to 1 ?
>>
>>
>>
>> Just in case I attached the policy files and log to the email,
>> application, cartridge group json see below inline
>>
>>
>>
>> Thanks
>>
>>
>>
>> Martin
>>
>>
>>
>> Before application update:
>>
>> Application json:
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
>> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>> Cartridge-group.json:
>>
>> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
>> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>>
>>
>>
>> application update json:
>>
>>
>>
>> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
>> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
>> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
>> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
>> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
>> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
>> "groups": []}]}}
>>
>>
>>
>>
>>
>> Deployment policies (attached):
>>
>>
>>
>> static-1.json, static-2.json
>>
>>
>>
>> Application (before / after update):
>>
>>
>>
>>
>>
>
>
>
> --
>
> *Pubudu Gunatilaka*
> Software Engineer
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> mobile: +94 77 4078049
>
--
Reka Thirunavukkarasu
Senior Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: 4.1 Stratos testig: clarifying application update API
Posted by Pubudu Gunatilaka <pu...@wso2.com>.
Hi Martin,
You can update only carridgeMin and cartridgeMax at runtime in application
update. Even you can update the deployment policy which uses the
application. But you cannot change the deployment policy in application at
runtime.
In your case, as you have used two different deployment policies, it won't
work. It will use the previous deployment policy. I have tested following
scenario.
1. Use the deployment policy with partition max as 1.
2. Deploy the application with cartridgeMin 1.
3. Update the same deployment policy with partition max 2.
4. Update application at runtime to cartridgeMin 2.
4. Another instance spawned successfully.
Thank you!
On Wed, Jul 22, 2015 at 9:25 AM, Martin Eppel (meppel) <me...@cisco.com>
wrote:
> Hi,
>
>
>
> I am currently testing the API to update an application (most notably to
> update the cartridge cartridgeMin / cartridgeMax in a cartridge deployment
> policy).
>
>
>
> My main question is which are the parameters which are currently
> supported to be updated as part of application update.
>
>
>
> I have tested updating (increasing the value) of cartridge cartridgeMin /
> cartridgeMax of a cartridge policy which works fine, as long as the
> cartridge deployment policy is correspondingly configured:
>
>
>
> e.g. updating min/max from 1/1 to 2/2 and (using the deployment policy
> “static-2”) with a partitionMax set to 2.
>
>
>
> However, updating the deployment policy either not supported or fails to
> work.
>
>
>
> For example, if I start initially with cartridgeMin / cartridgeMax = 1
> and a deployment policy “static-1” (with a partitionMax set to 1) and
> then update the cartridge policy cartridgeMin / cartridgeMax = 2 and the
> deployment policy “static-2” ( with a partitionMax set to 2) the
> cartridge instances are not properly spun up to 2.
>
>
>
> I am not sure if updating the deployment policy (or any other parameters
> beyond min / max in the cartridge policy, e.g min / max in group policy etc
> …) is currently supported or not, which brings me back to my initial
> question which parameters are supported as part of application “update”,
> please clarify.
>
>
>
> Also, is the case supported when decreasing the values, e.g. updating the
> cartridgeMin / cartridgeMax = 2 to 1 ?
>
>
>
> Just in case I attached the policy files and log to the email,
> application, cartridge group json see below inline
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> Before application update:
>
> Application json:
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 1,
> "cartridgeMax": 1, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-1", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
> Cartridge-group.json:
>
> {"name": "sub-app-update-1", "dependencies": {"terminationBehaviour":
> "terminate-none", "startupOrders": []}, "cartridges": ["c1"], "groups": []}
>
>
>
> application update json:
>
>
>
> {"alias": "sub-app-update-1", "applicationId": "sub-app-update-1",
> "components": {"cartridges": [], "groups": [{"name": "sub-app-update-1",
> "groupMaxInstances": 1, "groupMinInstances": 1, "alias":
> "sub-app-update-1-x0x", "cartridges": [{"cartridgeMin": 2,
> "cartridgeMax": 2, "type": "c1", "subscribableInfo": {"alias": "c1-0x0",
> "deploymentPolicy": "static-2", "autoscalingPolicy": "economyPolicy"}}],
> "groups": []}]}}
>
>
>
>
>
> Deployment policies (attached):
>
>
>
> static-1.json, static-2.json
>
>
>
> Application (before / after update):
>
>
>
>
>
--
*Pubudu Gunatilaka*
Software Engineer
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile: +94 77 4078049