stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Eppel (meppel)" <mep...@cisco.com>
Subject RE: 4.1 Stratos testig: clarifying application update API
Date Thu, 23 Jul 2015 16:24:59 GMT
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) <meppel@cisco.com<mailto:meppel@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<mailto: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@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 <pubudug@wso2.com<mailto:pubudug@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) <meppel@cisco.com<mailto:meppel@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

Mime
View raw message