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) < shahh...@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:r...@wso2.com <r...@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) <mep...@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:r...@wso2.com <r...@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 <pubu...@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) <mep...@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
