You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com> on 2015/02/10 19:15:39 UTC
4.1 deployment policy questions
Hi,
I am just looking at the new group/application mode, for 4.1, and I noticed that the subscribablesInfo no longer contains a deploymentPolicy. For example, from [1]:
"applicationId: "single_group_v1",
...
"subscribableInfo": {
"alias": "tom2group6",
"autoscalingPolicy": "autoscale-policy-1",
"artifactRepository":{
...
}
}
Instead, what seems to have happened is that the deployment policy point back to the application, from [2]:
"applicationId": "single_group_v1",
"applicationPolicy": {
"networkPartition": [
This is surely backwards. Why do deployment policies name the application? Why can't a single deployment policy be referenced by multiple applications (just like before)?
Also, what is confusing is that the samples are themselves inconsistent. For example, the first one I looked at [3] seems to be missing any binding between the application .json and the deployment .json; are these samples actually supposed to work, or are they perhaps a work in progress only?
Any insights would be most welcome.
Thanks, Shaheed
[1] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json
[2] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json
[3] https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts
Re: 4.1 deployment policy questions
Posted by Lakmal Warusawithana <la...@wso2.com>.
Shaheed, shall we go for a call and get this clear.
On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
wrote:
> Hi Shaheed,
>
> Will try to explain further but simple and here some workaround solution.
>
> Previous release we only subscribe to a single cartridge with given
> deployment policy. We have re used defined deployment policy. The main
> reason that we cloud do, single cartridge has single deployment patten for
> a particular deployment.
>
> If we come to composite application with multiple cartridges we have to
> define deployment pattens for each and every cartridge in that composite
> application. Defining deployment patten, have to use cartridge alias for
> distinguish deferent cartridges because we can't use cartridge type, some
> application may have multiple same cartridges and need different deployment
> pattens.
>
> To address particular in your scenario, we can't have two implementation
> whether is singleton or a composite group. Here one possible solution, I
> believe we can implement, and which will cover your simple scenario as well.
>
> solution :
>
> - shall we allow to have global deployment policies (can have many)
> which can pre deploy/add. (I will explain what is these global one)
> - and will allow, in the defining the deployment policy time to
> attached above without defining. (user has both option)
> - then deploy the application
>
> I believed this is what you are looking for
>
> Let me explain these global deployment policy concept. We have section
> call childPolicies which we refer different cartridge alias to define
> deployment pattens.
>
> "childPolicies": [
>
> {
>
> "alias": "mytomcat",
>
> "networkPartition": [
>
> {
>
> "id": "network-partition-1",
>
> "partitionAlgo": "one-after-another",
>
> "partitions": [
>
> {
>
> "id": "partition-1",
>
> "max": 5
>
> }
>
> ]
>
> }
>
> ]
>
> }
>
> I like to propose, introduce section call globalPolicies which can define
> global deployment pattens which going to apply for all cartridges defining
> in that application. If it is single cartridge or not it will use same
> deployment patten.
>
> With this implementation, without changing current design and
> implementation we can achieved simple singleton scenario with attaching
> same deployment policies without re defining per application
> creation/deploy.
>
> Please share your thoughts
>
>
>
> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>
>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>> wrote:
>>
>>>
>>>
>>> OK, I get that argument. But consider that multiple subscriptions all
>>> using a single deployment spec was the previous model, and now we have
>>> inverted that cardinality completely.
>>>
>>
>>>
>> Not exactly, we support multiple subscriptions for Multi-Tenant
>> applications but not for Single-Tenant applications. This is again due to
>> the reason I have explained in the previous response. May be we can improve
>> this in a minor release. BTW the term Subscription has now being changed to
>> Application SignUp.
>>
>>>
>>>
>> To my knowledge, in addition to the generic automation of single
>>> cartridge subscriptions we provided our Stratos users, at least two users
>>> have significant investment in dynamically generating and
>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>> single application cartridges is necessary work needed to get to 4.1, but
>>> all these usages will now require substantive rework to manage the opposite
>>> cardinality w.r.t. deployment policies.
>>>
>>
>>>
>> Here we deploy an application in the context of Tenant not for User. Yes
>> in this release it is not possible to share Single-Tenant applications
>> accross tenants. However each tenant can deploy the same application with a
>> different deployment policy by using a different application id.
>>
>>
>>> I'm all in favour of progress, and change where unavoidable, but this
>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>> users in favour of the currently non-existent grouping users. (And yes, I
>>> am aware of the paradox that we are VERY interested in the grouping).
>>>
>>
>> Yes I agree, may be we can have a separate discussion on this and propose
>> improvements for the next minor release.
>>
>> Thanks
>>
>
>
>
> --
> Lakmal Warusawithana
> Vice President, Apache Stratos
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shaheed,
Yes we didn't discuss this clearly in our discussions. It was introduced
few weeks back to manage network partitions in the global context (while
having the possibility to define them in the deployment policy). Please
find the discussion here [1].
The content of the network partition was taken from the application policy
section of the deployment policy (according to previous model). Now with
the new model, we can only define network partitions in the global context,
they cannot be defined inline.
Regarding the documentation, I do not think we have documented it yet. We
need to do it ASAP.
[1]
http://mail-archives.apache.org/mod_mbox/stratos-dev/201501.mbox/%3CCAGhM-MbwFeQuChhspQX9Ktk5PFRJ_4jv4op7L+CyHiqJQX=9Ww@mail.gmail.com%3E
Thanks
On Sat, Feb 21, 2015 at 11:56 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
>
> Thanks, we'll provide feedback ASAP.
>
> BTW, I see a new object for network partitions...is there some
> documentation which explains the content of this object? I see this under
> 4.0.0:
>
>
> https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Sample+Partition+Definition
>
> but AFAIK, we have not had to use this before...did I miss something?
>
> ------------------------------
> *From:* Imesh Gunaratne [imesh@apache.org]
> *Sent:* 21 February 2015 14:26
> *To:* dev; Shaheedur Haque (shahhaqu)
> *Subject:* Re: 4.1 deployment policy questions
>
> Hi Shaheed,
>
> Yes that's correct, if a deployment policy is defined for a group it
> will be propagated to its child elements.
> I have now prepared a document with new artifacts and API methods:
>
> Apache Stratos 4.1.0-beta Deployment Policy Changes
> <https://docs.google.com/document/d/1XNRNWSO2M-g1hHZnvYMtZSDm2oWMvayaaRardbs5VmI/edit?usp=drive_web>
>
> Please review it and provide your feedback.
>
> Thanks
>
> On Sat, Feb 21, 2015 at 6:31 PM, Shaheedur Haque (shahhaqu) <
> shahhaqu@cisco.com> wrote:
>
>> So in summary, deployment policies propagate top down, is that right?
>>
>>
>>
>> Also, do we have updated samples/specs that I can start to code to yet?
>>
>>
>>
>> *From:* Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com]
>> *Sent:* 19 February 2015 06:11
>> *To:* dev@stratos.apache.org
>> *Subject:* Re: 4.1 deployment policy questions
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>
>>
>>
>>
>> On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>
>> wrote:
>>
>> Hi Lakmal,
>>
>> Please find a question inline.
>>
>>
>>
>> On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>
>>
>> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
>> wrote:
>>
>> Hi Imesh,
>>
>> Please find a question inline.
>>
>>
>>
>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>> Hi Devs,
>>
>>
>>
>> Today we had a call on this topic and please find the summary of the
>> discussion below:
>>
>>
>>
>> - In Stratos 4.0.0 the deployment policy was defined in the global
>> context and it was reusable.
>>
>> - Now deployment policy is in application context and contains deployment
>> pattens of multiple cartridges.
>>
>> - As a result the application deployment process has become complex and
>> backward compatibility with the previous release has been broken.
>>
>>
>>
>> - Therefore we can do a slight modification in the current model and move
>> the deployment policy to the global context:
>>
>> - If so we will have following entities in the global context:
>>
>>
>>
>>
>>
>> - Then we can construct the application by referring Cartridges,
>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>
>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Why a cartridge group need to refer a deployment policy? I assume if a
>> cartridge group is referring a deployment policy, then all the cartridges
>> under that group will use the same deployment policy referred by the group?
>> Or this is for something else. Please give me some insight on this.
>>
>>
>>
>> Yes you are correct. Cartridges under a group will use same department
>> policy referred by the group.
>>
>>
>>
>> Thanks Lakmal for confirming it.
>>
>> I have one more question. If both cartridge group and a cartridge, say
>> cartridge-1, (from that group) define two different deployment policies,
>> all the other cartridges except cartridge-1 will use the deployment policy
>> referred in the cartridge group and cartridge-1 will use the deployment
>> policy referred in it. Is this correct? Or we should not allow both
>> cartridge group and cartridges to refer deployment policies?
>>
>> Parsing the application, to identify which deployment policy each
>> cartridge refers, is going to be damn complex :)
>>
>>
>>
>> If we have define a deployment policy at top, bottom cartridges/groups
>> are not allowed to define any. Top deployment policy applied for all.
>>
>>
>>
>> Thanks Lakmal. That will reduce the complexity.
>>
>> Thanks.
>>
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>> Thanks.al
>>
>>
>> - Now we need to provide an application policy at the application
>> deployment time to specify application availability in network partitions:
>>
>> - This would say whether to start the application in all network
>> partitions or do cloud bursting:
>>
>>
>>
>>
>>
>> - At a later release we can introduce Application Template concept by
>> extracting subscribable information out from the application:
>>
>>
>>
>>
>>
>> Please add your thoughts on this modification.
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>> discuss this before doing any changes.
>>
>>
>>
>> Thanks
>>
>>
>>
>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>> Hi Shaheed,
>>
>>
>>
>> Will try to explain further but simple and here some workaround solution.
>>
>>
>>
>> Previous release we only subscribe to a single cartridge with given
>> deployment policy. We have re used defined deployment policy. The main
>> reason that we cloud do, single cartridge has single deployment patten for
>> a particular deployment.
>>
>>
>>
>> If we come to composite application with multiple cartridges we have to
>> define deployment pattens for each and every cartridge in that composite
>> application. Defining deployment patten, have to use cartridge alias for
>> distinguish deferent cartridges because we can't use cartridge type, some
>> application may have multiple same cartridges and need different deployment
>> pattens.
>>
>>
>>
>> To address particular in your scenario, we can't have two implementation
>> whether is singleton or a composite group. Here one possible solution, I
>> believe we can implement, and which will cover your simple scenario as well.
>>
>>
>>
>> solution :
>>
>> - shall we allow to have global deployment policies (can have many)
>> which can pre deploy/add. (I will explain what is these global one)
>> - and will allow, in the defining the deployment policy time to
>> attached above without defining. (user has both option)
>> - then deploy the application
>>
>> I believed this is what you are looking for
>>
>>
>>
>> Let me explain these global deployment policy concept. We have section
>> call childPolicies which we refer different cartridge alias to define
>> deployment pattens.
>>
>>
>>
>> "childPolicies": [
>>
>> {
>>
>> "alias": "mytomcat",
>>
>> "networkPartition": [
>>
>> {
>>
>> "id": "network-partition-1",
>>
>> "partitionAlgo": "one-after-another",
>>
>> "partitions": [
>>
>> {
>>
>> "id": "partition-1",
>>
>> "max": 5
>>
>> }
>>
>> ]
>>
>> }
>>
>> ]
>>
>> }
>>
>>
>>
>> I like to propose, introduce section call globalPolicies which can define
>> global deployment pattens which going to apply for all cartridges defining
>> in that application. If it is single cartridge or not it will use same
>> deployment patten.
>>
>>
>>
>> With this implementation, without changing current design and
>> implementation we can achieved simple singleton scenario with attaching
>> same deployment policies without re defining per application
>> creation/deploy.
>>
>>
>>
>> Please share your thoughts
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>
>>
>>
>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahhaqu@cisco.com
>> > wrote:
>>
>>
>>
>> OK, I get that argument. But consider that multiple subscriptions all
>> using a single deployment spec was the previous model, and now we have
>> inverted that cardinality completely.
>>
>>
>>
>> Not exactly, we support multiple subscriptions for Multi-Tenant
>> applications but not for Single-Tenant applications. This is again due to
>> the reason I have explained in the previous response. May be we can improve
>> this in a minor release. BTW the term Subscription has now being changed to
>> Application SignUp.
>>
>>
>>
>> To my knowledge, in addition to the generic automation of single
>> cartridge subscriptions we provided our Stratos users, at least two users
>> have significant investment in dynamically generating and
>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>> single application cartridges is necessary work needed to get to 4.1, but
>> all these usages will now require substantive rework to manage the opposite
>> cardinality w.r.t. deployment policies.
>>
>>
>>
>> Here we deploy an application in the context of Tenant not for User.
>> Yes in this release it is not possible to share Single-Tenant applications
>> accross tenants. However each tenant can deploy the same application with a
>> different deployment policy by using a different application id.
>>
>>
>>
>> I'm all in favour of progress, and change where unavoidable, but this
>> seems to gratuitously change the model for the bulk of singleton cartridge
>> users in favour of the currently non-existent grouping users. (And yes, I
>> am aware of the paradox that we are VERY interested in the grouping).
>>
>>
>>
>> Yes I agree, may be we can have a separate discussion on this and propose
>> improvements for the next minor release.
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> --
>>
>> Lakmal Warusawithana
>>
>> Vice President, Apache Stratos
>>
>> Director - Cloud Architecture; WSO2 Inc.
>>
>> Mobile : +94714289692
>>
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>>
>>
>>
>>
>> --
>>
>> Imesh Gunaratne
>>
>>
>>
>> Technical Lead, WSO2
>>
>> Committer & PMC Member, Apache Stratos
>>
>>
>>
>>
>>
>> --
>>
>> Imesh Gunaratne
>>
>>
>>
>> Technical Lead, WSO2
>>
>> Committer & PMC Member, Apache Stratos
>>
>>
>>
>>
>> --
>>
>> Rajkumar Rajaratnam
>>
>> Committer & PMC Member, Apache Stratos
>>
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>>
>> Blog : rajkumarr.com
>>
>>
>>
>> --
>> Sent from Gmail Mobile
>>
>>
>>
>>
>> --
>>
>> Rajkumar Rajaratnam
>>
>> Committer & PMC Member, Apache Stratos
>>
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>>
>> Blog : rajkumarr.com
>>
>>
>>
>>
>>
>> --
>>
>> Lakmal Warusawithana
>>
>> Vice President, Apache Stratos
>>
>> Director - Cloud Architecture; WSO2 Inc.
>>
>> Mobile : +94714289692
>>
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>>
>>
>> --
>>
>> Rajkumar Rajaratnam
>>
>> Committer & PMC Member, Apache Stratos
>>
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>>
>> Blog : rajkumarr.com
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
I have now completed deployment changes and these changes are available in
master branch now. Most of the samples applications are fixed according to
these changes. Refer wordpress sample for more information on latest
application deployment flow.
Thanks
On Wednesday, February 25, 2015, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> Sorry for the delay in providing comments, I hope to get to this very
> soon.
>
>
>
> *From:* Shaheedur Haque (shahhaqu)
> *Sent:* Saturday, February 21, 2015 6:26 PM
> *To:* Imesh Gunaratne; dev
> *Subject:* RE: 4.1 deployment policy questions
>
>
>
>
> Thanks, we'll provide feedback ASAP.
>
> BTW, I see a new object for network partitions...is there some
> documentation which explains the content of this object? I see this under
> 4.0.0:
>
>
> https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Sample+Partition+Definition
>
> but AFAIK, we have not had to use this before...did I miss something?
> ------------------------------
>
> *From:* Imesh Gunaratne [imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>]
> *Sent:* 21 February 2015 14:26
> *To:* dev; Shaheedur Haque (shahhaqu)
> *Subject:* Re: 4.1 deployment policy questions
>
> Hi Shaheed,
>
>
>
> Yes that's correct, if a deployment policy is defined for a group it will
> be propagated to its child elements.
>
> I have now prepared a document with new artifacts and API methods:
>
>
>
> * Apache Stratos 4.1.0-beta Deployment Policy Changes
> <https://docs.google.com/document/d/1XNRNWSO2M-g1hHZnvYMtZSDm2oWMvayaaRardbs5VmI/edit?usp=drive_web>*
>
>
>
> Please review it and provide your feedback.
>
>
>
> Thanks
>
>
>
> On Sat, Feb 21, 2015 at 6:31 PM, Shaheedur Haque (shahhaqu) <
> shahhaqu@cisco.com <javascript:_e(%7B%7D,'cvml','shahhaqu@cisco.com');>>
> wrote:
>
> So in summary, deployment policies propagate top down, is that right?
>
>
>
> Also, do we have updated samples/specs that I can start to code to yet?
>
>
>
> *From:* Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com
> <javascript:_e(%7B%7D,'cvml','rajkumarr@wso2.com');>]
> *Sent:* 19 February 2015 06:11
> *To:* dev@stratos.apache.org
> <javascript:_e(%7B%7D,'cvml','dev@stratos.apache.org');>
> *Subject:* Re: 4.1 deployment policy questions
>
>
>
>
>
>
>
> On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <lakmal@wso2.com
> <javascript:_e(%7B%7D,'cvml','lakmal@wso2.com');>> wrote:
>
>
>
>
>
> On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <rajkumarr@wso2.com
> <javascript:_e(%7B%7D,'cvml','rajkumarr@wso2.com');>> wrote:
>
> Hi Lakmal,
>
> Please find a question inline.
>
>
>
> On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <lakmal@wso2.com
> <javascript:_e(%7B%7D,'cvml','lakmal@wso2.com');>> wrote:
>
>
>
> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <rajkumarr@wso2.com
> <javascript:_e(%7B%7D,'cvml','rajkumarr@wso2.com');>> wrote:
>
> Hi Imesh,
>
> Please find a question inline.
>
>
>
> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>
> Hi Devs,
>
>
>
> Today we had a call on this topic and please find the summary of the
> discussion below:
>
>
>
> - In Stratos 4.0.0 the deployment policy was defined in the global context
> and it was reusable.
>
> - Now deployment policy is in application context and contains deployment
> pattens of multiple cartridges.
>
> - As a result the application deployment process has become complex and
> backward compatibility with the previous release has been broken.
>
>
>
> - Therefore we can do a slight modification in the current model and move
> the deployment policy to the global context:
>
> - If so we will have following entities in the global context:
>
>
>
>
>
> - Then we can construct the application by referring Cartridges, Cartridge
> Groups, Autoscaling Policies and Deployment Policies:
>
> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>
>
>
>
>
>
>
>
>
> Why a cartridge group need to refer a deployment policy? I assume if a
> cartridge group is referring a deployment policy, then all the cartridges
> under that group will use the same deployment policy referred by the group?
> Or this is for something else. Please give me some insight on this.
>
>
>
> Yes you are correct. Cartridges under a group will use same department
> policy referred by the group.
>
>
>
> Thanks Lakmal for confirming it.
>
> I have one more question. If both cartridge group and a cartridge, say
> cartridge-1, (from that group) define two different deployment policies,
> all the other cartridges except cartridge-1 will use the deployment policy
> referred in the cartridge group and cartridge-1 will use the deployment
> policy referred in it. Is this correct? Or we should not allow both
> cartridge group and cartridges to refer deployment policies?
>
> Parsing the application, to identify which deployment policy each
> cartridge refers, is going to be damn complex :)
>
>
>
> If we have define a deployment policy at top, bottom cartridges/groups are
> not allowed to define any. Top deployment policy applied for all.
>
>
>
> Thanks Lakmal. That will reduce the complexity.
>
> Thanks.
>
>
>
> Thanks.
>
>
>
>
>
> Thanks.al
>
>
> - Now we need to provide an application policy at the application
> deployment time to specify application availability in network partitions:
>
> - This would say whether to start the application in all network
> partitions or do cloud bursting:
>
>
>
>
>
> - At a later release we can introduce Application Template concept by
> extracting subscribable information out from the application:
>
>
>
>
>
> Please add your thoughts on this modification.
>
>
>
> Thanks
>
>
>
>
> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>
> +1 for the idea Lakmal! Yes I think it is better to have a call and
> discuss this before doing any changes.
>
>
>
> Thanks
>
>
>
> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lakmal@wso2.com
> <javascript:_e(%7B%7D,'cvml','lakmal@wso2.com');>> wrote:
>
> Hi Shaheed,
>
>
>
> Will try to explain further but simple and here some workaround solution.
>
>
>
> Previous release we only subscribe to a single cartridge with given
> deployment policy. We have re used defined deployment policy. The main
> reason that we cloud do, single cartridge has single deployment patten for
> a particular deployment.
>
>
>
> If we come to composite application with multiple cartridges we have to
> define deployment pattens for each and every cartridge in that composite
> application. Defining deployment patten, have to use cartridge alias for
> distinguish deferent cartridges because we can't use cartridge type, some
> application may have multiple same cartridges and need different deployment
> pattens.
>
>
>
> To address particular in your scenario, we can't have two implementation
> whether is singleton or a composite group. Here one possible solution, I
> believe we can implement, and which will cover your simple scenario as well.
>
>
>
> solution :
>
> - shall we allow to have global deployment policies (can have many)
> which can pre deploy/add. (I will explain what is these global one)
> - and will allow, in the defining the deployment policy time to
> attached above without defining. (user has both option)
> - then deploy the application
>
> I believed this is what you are looking for
>
>
>
> Let me explain these global deployment policy concept. We have section
> call childPolicies which we refer different cartridge alias to define
> deployment pattens.
>
>
>
> "childPolicies": [
>
> {
>
> "alias": "mytomcat",
>
> "networkPartition": [
>
> {
>
> "id": "network-partition-1",
>
> "partitionAlgo": "one-after-another",
>
> "partitions": [
>
> {
>
> "id": "partition-1",
>
> "max": 5
>
> }
>
> ]
>
> }
>
> ]
>
> }
>
>
>
> I like to propose, introduce section call globalPolicies which can define
> global deployment pattens which going to apply for all cartridges defining
> in that application. If it is single cartridge or not it will use same
> deployment patten.
>
>
>
> With this implementation, without changing current design and
> implementation we can achieved simple singleton scenario with attaching
> same deployment policies without re defining per application
> creation/deploy.
>
>
>
> Please share your thoughts
>
>
>
>
>
>
>
> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>
> Yes, I agree with your concerns Shaheed! Please find my comments below:
>
>
>
> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahhaqu@cisco.com
> <javascript:_e(%7B%7D,'cvml','shahhaqu@cisco.com');>> wrote:
>
>
>
> OK, I get that argument. But consider that multiple subscriptions all
> using a single deployment spec was the previous model, and now we have
> inverted that cardinality completely.
>
>
>
> Not exactly, we support multiple subscriptions for Multi-Tenant
> applications but not for Single-Tenant applications. This is again due to
> the reason I have explained in the previous response. May be we can improve
> this in a minor release. BTW the term Subscription has now being changed to
> Application SignUp.
>
>
>
> To my knowledge, in addition to the generic automation of single
> cartridge subscriptions we provided our Stratos users, at least two users
> have significant investment in dynamically generating and
> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
> single application cartridges is necessary work needed to get to 4.1, but
> all these usages will now require substantive rework to manage the opposite
> cardinality w.r.t. deployment policies.
>
>
>
> Here we deploy an application in the context of Tenant not for User. Yes
> in this release it is not possible to share Single-Tenant applications
> accross tenants. However each tenant can deploy the same application with a
> different deployment policy by using a different application id.
>
>
>
> I'm all in favour of progress, and change where unavoidable, but this
> seems to gratuitously change the model for the bulk of singleton cartridge
> users in favour of the currently non-existent grouping users. (And yes, I
> am aware of the paradox that we are VERY interested in the grouping).
>
>
>
> Yes I agree, may be we can have a separate discussion on this and propose
> improvements for the next minor release.
>
>
>
> Thanks
>
>
>
>
>
> --
>
> Lakmal Warusawithana
>
> Vice President, Apache Stratos
>
> Director - Cloud Architecture; WSO2 Inc.
>
> Mobile : +94714289692
>
> Blog : http://lakmalsview.blogspot.com/
>
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
>
>
> --
> Sent from Gmail Mobile
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
>
>
>
>
> --
>
> Lakmal Warusawithana
>
> Vice President, Apache Stratos
>
> Director - Cloud Architecture; WSO2 Inc.
>
> Mobile : +94714289692
>
> Blog : http://lakmalsview.blogspot.com/
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
Sorry for the delay in providing comments, I hope to get to this very soon.
From: Shaheedur Haque (shahhaqu)
Sent: Saturday, February 21, 2015 6:26 PM
To: Imesh Gunaratne; dev
Subject: RE: 4.1 deployment policy questions
Thanks, we'll provide feedback ASAP.
BTW, I see a new object for network partitions...is there some documentation which explains the content of this object? I see this under 4.0.0:
https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Sample+Partition+Definition
but AFAIK, we have not had to use this before...did I miss something?
________________________________
From: Imesh Gunaratne [imesh@apache.org]
Sent: 21 February 2015 14:26
To: dev; Shaheedur Haque (shahhaqu)
Subject: Re: 4.1 deployment policy questions
Hi Shaheed,
Yes that's correct, if a deployment policy is defined for a group it will be propagated to its child elements.
I have now prepared a document with new artifacts and API methods:
[https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png] Apache Stratos 4.1.0-beta Deployment Policy Changes<https://docs.google.com/document/d/1XNRNWSO2M-g1hHZnvYMtZSDm2oWMvayaaRardbs5VmI/edit?usp=drive_web>
Please review it and provide your feedback.
Thanks
On Sat, Feb 21, 2015 at 6:31 PM, Shaheedur Haque (shahhaqu) <sh...@cisco.com>> wrote:
So in summary, deployment policies propagate top down, is that right?
Also, do we have updated samples/specs that I can start to code to yet?
From: Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com<ma...@wso2.com>]
Sent: 19 February 2015 06:11
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: Re: 4.1 deployment policy questions
On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Lakmal,
Please find a question inline.
On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Imesh,
Please find a question inline.
On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>> wrote:
Hi Devs,
Today we had a call on this topic and please find the summary of the discussion below:
- In Stratos 4.0.0 the deployment policy was defined in the global context and it was reusable.
- Now deployment policy is in application context and contains deployment pattens of multiple cartridges.
- As a result the application deployment process has become complex and backward compatibility with the previous release has been broken.
- Therefore we can do a slight modification in the current model and move the deployment policy to the global context:
- If so we will have following entities in the global context:
[cid:image001.png@01D05070.B2727870]
- Then we can construct the application by referring Cartridges, Cartridge Groups, Autoscaling Policies and Deployment Policies:
- Either Cartridges or Cartridge Groups can refer Deployment Policies:
[cid:image002.png@01D05070.B2727870]
[cid:image003.png@01D05070.B2727870]
Why a cartridge group need to refer a deployment policy? I assume if a cartridge group is referring a deployment policy, then all the cartridges under that group will use the same deployment policy referred by the group? Or this is for something else. Please give me some insight on this.
Yes you are correct. Cartridges under a group will use same department policy referred by the group.
Thanks Lakmal for confirming it.
I have one more question. If both cartridge group and a cartridge, say cartridge-1, (from that group) define two different deployment policies, all the other cartridges except cartridge-1 will use the deployment policy referred in the cartridge group and cartridge-1 will use the deployment policy referred in it. Is this correct? Or we should not allow both cartridge group and cartridges to refer deployment policies?
Parsing the application, to identify which deployment policy each cartridge refers, is going to be damn complex :)
If we have define a deployment policy at top, bottom cartridges/groups are not allowed to define any. Top deployment policy applied for all.
Thanks Lakmal. That will reduce the complexity.
Thanks.
Thanks.
Thanks.al
- Now we need to provide an application policy at the application deployment time to specify application availability in network partitions:
- This would say whether to start the application in all network partitions or do cloud bursting:
[cid:image004.png@01D05070.B2727870]
- At a later release we can introduce Application Template concept by extracting subscribable information out from the application:
[cid:image005.png@01D05070.B2727870]
Please add your thoughts on this modification.
Thanks
On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>> wrote:
+1 for the idea Lakmal! Yes I think it is better to have a call and discuss this before doing any changes.
Thanks
On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
Hi Shaheed,
Will try to explain further but simple and here some workaround solution.
Previous release we only subscribe to a single cartridge with given deployment policy. We have re used defined deployment policy. The main reason that we cloud do, single cartridge has single deployment patten for a particular deployment.
If we come to composite application with multiple cartridges we have to define deployment pattens for each and every cartridge in that composite application. Defining deployment patten, have to use cartridge alias for distinguish deferent cartridges because we can't use cartridge type, some application may have multiple same cartridges and need different deployment pattens.
To address particular in your scenario, we can't have two implementation whether is singleton or a composite group. Here one possible solution, I believe we can implement, and which will cover your simple scenario as well.
solution :
* shall we allow to have global deployment policies (can have many) which can pre deploy/add. (I will explain what is these global one)
* and will allow, in the defining the deployment policy time to attached above without defining. (user has both option)
* then deploy the application
I believed this is what you are looking for
Let me explain these global deployment policy concept. We have section call childPolicies which we refer different cartridge alias to define deployment pattens.
"childPolicies": [
{
"alias": "mytomcat",
"networkPartition": [
{
"id": "network-partition-1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "partition-1",
"max": 5
}
]
}
]
}
I like to propose, introduce section call globalPolicies which can define global deployment pattens which going to apply for all cartridges defining in that application. If it is single cartridge or not it will use same deployment patten.
With this implementation, without changing current design and implementation we can achieved simple singleton scenario with attaching same deployment policies without re defining per application creation/deploy.
Please share your thoughts
On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>> wrote:
Yes, I agree with your concerns Shaheed! Please find my comments below:
On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>> wrote:
OK, I get that argument. But consider that multiple subscriptions all using a single deployment spec was the previous model, and now we have inverted that cardinality completely.
Not exactly, we support multiple subscriptions for Multi-Tenant applications but not for Single-Tenant applications. This is again due to the reason I have explained in the previous response. May be we can improve this in a minor release. BTW the term Subscription has now being changed to Application SignUp.
To my knowledge, in addition to the generic automation of single cartridge subscriptions we provided our Stratos users, at least two users have significant investment in dynamically generating and subscribing/unsubscribing cartridges on-the-fly. Converting these to use single application cartridges is necessary work needed to get to 4.1, but all these usages will now require substantive rework to manage the opposite cardinality w.r.t. deployment policies.
Here we deploy an application in the context of Tenant not for User. Yes in this release it is not possible to share Single-Tenant applications accross tenants. However each tenant can deploy the same application with a different deployment policy by using a different application id.
I'm all in favour of progress, and change where unavoidable, but this seems to gratuitously change the model for the bulk of singleton cartridge users in favour of the currently non-existent grouping users. (And yes, I am aware of the paradox that we are VERY interested in the grouping).
Yes I agree, may be we can have a separate discussion on this and propose improvements for the next minor release.
Thanks
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Sent from Gmail Mobile
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
Thanks, we'll provide feedback ASAP.
BTW, I see a new object for network partitions...is there some documentation which explains the content of this object? I see this under 4.0.0:
https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Sample+Partition+Definition
but AFAIK, we have not had to use this before...did I miss something?
________________________________
From: Imesh Gunaratne [imesh@apache.org]
Sent: 21 February 2015 14:26
To: dev; Shaheedur Haque (shahhaqu)
Subject: Re: 4.1 deployment policy questions
Hi Shaheed,
Yes that's correct, if a deployment policy is defined for a group it will be propagated to its child elements.
I have now prepared a document with new artifacts and API methods:
[https://ssl.gstatic.com/docs/doclist/images/icon_11_document_list.png] Apache Stratos 4.1.0-beta Deployment Policy Changes<https://docs.google.com/document/d/1XNRNWSO2M-g1hHZnvYMtZSDm2oWMvayaaRardbs5VmI/edit?usp=drive_web>
Please review it and provide your feedback.
Thanks
On Sat, Feb 21, 2015 at 6:31 PM, Shaheedur Haque (shahhaqu) <sh...@cisco.com>> wrote:
So in summary, deployment policies propagate top down, is that right?
Also, do we have updated samples/specs that I can start to code to yet?
From: Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com<ma...@wso2.com>]
Sent: 19 February 2015 06:11
To: dev@stratos.apache.org<ma...@stratos.apache.org>
Subject: Re: 4.1 deployment policy questions
On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Lakmal,
Please find a question inline.
On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Imesh,
Please find a question inline.
On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>> wrote:
Hi Devs,
Today we had a call on this topic and please find the summary of the discussion below:
- In Stratos 4.0.0 the deployment policy was defined in the global context and it was reusable.
- Now deployment policy is in application context and contains deployment pattens of multiple cartridges.
- As a result the application deployment process has become complex and backward compatibility with the previous release has been broken.
- Therefore we can do a slight modification in the current model and move the deployment policy to the global context:
- If so we will have following entities in the global context:
[cid:image002.png@01D04DD6.4A79C9E0]
- Then we can construct the application by referring Cartridges, Cartridge Groups, Autoscaling Policies and Deployment Policies:
- Either Cartridges or Cartridge Groups can refer Deployment Policies:
[cid:image004.png@01D04DD6.4A79C9E0]
[cid:image006.png@01D04DD6.4A79C9E0]
Why a cartridge group need to refer a deployment policy? I assume if a cartridge group is referring a deployment policy, then all the cartridges under that group will use the same deployment policy referred by the group? Or this is for something else. Please give me some insight on this.
Yes you are correct. Cartridges under a group will use same department policy referred by the group.
Thanks Lakmal for confirming it.
I have one more question. If both cartridge group and a cartridge, say cartridge-1, (from that group) define two different deployment policies, all the other cartridges except cartridge-1 will use the deployment policy referred in the cartridge group and cartridge-1 will use the deployment policy referred in it. Is this correct? Or we should not allow both cartridge group and cartridges to refer deployment policies?
Parsing the application, to identify which deployment policy each cartridge refers, is going to be damn complex :)
If we have define a deployment policy at top, bottom cartridges/groups are not allowed to define any. Top deployment policy applied for all.
Thanks Lakmal. That will reduce the complexity.
Thanks.
Thanks.
Thanks.al
- Now we need to provide an application policy at the application deployment time to specify application availability in network partitions:
- This would say whether to start the application in all network partitions or do cloud bursting:
[cid:image008.png@01D04DD6.4A79C9E0]
- At a later release we can introduce Application Template concept by extracting subscribable information out from the application:
[cid:image010.png@01D04DD6.4A79C9E0]
Please add your thoughts on this modification.
Thanks
On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>> wrote:
+1 for the idea Lakmal! Yes I think it is better to have a call and discuss this before doing any changes.
Thanks
On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
Hi Shaheed,
Will try to explain further but simple and here some workaround solution.
Previous release we only subscribe to a single cartridge with given deployment policy. We have re used defined deployment policy. The main reason that we cloud do, single cartridge has single deployment patten for a particular deployment.
If we come to composite application with multiple cartridges we have to define deployment pattens for each and every cartridge in that composite application. Defining deployment patten, have to use cartridge alias for distinguish deferent cartridges because we can't use cartridge type, some application may have multiple same cartridges and need different deployment pattens.
To address particular in your scenario, we can't have two implementation whether is singleton or a composite group. Here one possible solution, I believe we can implement, and which will cover your simple scenario as well.
solution :
* shall we allow to have global deployment policies (can have many) which can pre deploy/add. (I will explain what is these global one)
* and will allow, in the defining the deployment policy time to attached above without defining. (user has both option)
* then deploy the application
I believed this is what you are looking for
Let me explain these global deployment policy concept. We have section call childPolicies which we refer different cartridge alias to define deployment pattens.
"childPolicies": [
{
"alias": "mytomcat",
"networkPartition": [
{
"id": "network-partition-1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "partition-1",
"max": 5
}
]
}
]
}
I like to propose, introduce section call globalPolicies which can define global deployment pattens which going to apply for all cartridges defining in that application. If it is single cartridge or not it will use same deployment patten.
With this implementation, without changing current design and implementation we can achieved simple singleton scenario with attaching same deployment policies without re defining per application creation/deploy.
Please share your thoughts
On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>> wrote:
Yes, I agree with your concerns Shaheed! Please find my comments below:
On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>> wrote:
OK, I get that argument. But consider that multiple subscriptions all using a single deployment spec was the previous model, and now we have inverted that cardinality completely.
Not exactly, we support multiple subscriptions for Multi-Tenant applications but not for Single-Tenant applications. This is again due to the reason I have explained in the previous response. May be we can improve this in a minor release. BTW the term Subscription has now being changed to Application SignUp.
To my knowledge, in addition to the generic automation of single cartridge subscriptions we provided our Stratos users, at least two users have significant investment in dynamically generating and subscribing/unsubscribing cartridges on-the-fly. Converting these to use single application cartridges is necessary work needed to get to 4.1, but all these usages will now require substantive rework to manage the opposite cardinality w.r.t. deployment policies.
Here we deploy an application in the context of Tenant not for User. Yes in this release it is not possible to share Single-Tenant applications accross tenants. However each tenant can deploy the same application with a different deployment policy by using a different application id.
I'm all in favour of progress, and change where unavoidable, but this seems to gratuitously change the model for the bulk of singleton cartridge users in favour of the currently non-existent grouping users. (And yes, I am aware of the paradox that we are VERY interested in the grouping).
Yes I agree, may be we can have a separate discussion on this and propose improvements for the next minor release.
Thanks
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Sent from Gmail Mobile
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shaheed,
Yes that's correct, if a deployment policy is defined for a group it will
be propagated to its child elements.
I have now prepared a document with new artifacts and API methods:
Apache Stratos 4.1.0-beta Deployment Policy Changes
<https://docs.google.com/document/d/1XNRNWSO2M-g1hHZnvYMtZSDm2oWMvayaaRardbs5VmI/edit?usp=drive_web>
Please review it and provide your feedback.
Thanks
On Sat, Feb 21, 2015 at 6:31 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> So in summary, deployment policies propagate top down, is that right?
>
>
>
> Also, do we have updated samples/specs that I can start to code to yet?
>
>
>
> *From:* Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com]
> *Sent:* 19 February 2015 06:11
> *To:* dev@stratos.apache.org
> *Subject:* Re: 4.1 deployment policy questions
>
>
>
>
>
>
>
> On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
>
>
>
>
> On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
> Hi Lakmal,
>
> Please find a question inline.
>
>
>
> On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
>
>
> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
> Hi Imesh,
>
> Please find a question inline.
>
>
>
> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org> wrote:
>
> Hi Devs,
>
>
>
> Today we had a call on this topic and please find the summary of the
> discussion below:
>
>
>
> - In Stratos 4.0.0 the deployment policy was defined in the global context
> and it was reusable.
>
> - Now deployment policy is in application context and contains deployment
> pattens of multiple cartridges.
>
> - As a result the application deployment process has become complex and
> backward compatibility with the previous release has been broken.
>
>
>
> - Therefore we can do a slight modification in the current model and move
> the deployment policy to the global context:
>
> - If so we will have following entities in the global context:
>
>
>
>
>
> - Then we can construct the application by referring Cartridges, Cartridge
> Groups, Autoscaling Policies and Deployment Policies:
>
> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>
>
>
>
>
>
>
>
>
> Why a cartridge group need to refer a deployment policy? I assume if a
> cartridge group is referring a deployment policy, then all the cartridges
> under that group will use the same deployment policy referred by the group?
> Or this is for something else. Please give me some insight on this.
>
>
>
> Yes you are correct. Cartridges under a group will use same department
> policy referred by the group.
>
>
>
> Thanks Lakmal for confirming it.
>
> I have one more question. If both cartridge group and a cartridge, say
> cartridge-1, (from that group) define two different deployment policies,
> all the other cartridges except cartridge-1 will use the deployment policy
> referred in the cartridge group and cartridge-1 will use the deployment
> policy referred in it. Is this correct? Or we should not allow both
> cartridge group and cartridges to refer deployment policies?
>
> Parsing the application, to identify which deployment policy each
> cartridge refers, is going to be damn complex :)
>
>
>
> If we have define a deployment policy at top, bottom cartridges/groups are
> not allowed to define any. Top deployment policy applied for all.
>
>
>
> Thanks Lakmal. That will reduce the complexity.
>
> Thanks.
>
>
>
> Thanks.
>
>
>
>
>
> Thanks.al
>
>
> - Now we need to provide an application policy at the application
> deployment time to specify application availability in network partitions:
>
> - This would say whether to start the application in all network
> partitions or do cloud bursting:
>
>
>
>
>
> - At a later release we can introduce Application Template concept by
> extracting subscribable information out from the application:
>
>
>
>
>
> Please add your thoughts on this modification.
>
>
>
> Thanks
>
>
>
>
> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
> +1 for the idea Lakmal! Yes I think it is better to have a call and
> discuss this before doing any changes.
>
>
>
> Thanks
>
>
>
> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
> Hi Shaheed,
>
>
>
> Will try to explain further but simple and here some workaround solution.
>
>
>
> Previous release we only subscribe to a single cartridge with given
> deployment policy. We have re used defined deployment policy. The main
> reason that we cloud do, single cartridge has single deployment patten for
> a particular deployment.
>
>
>
> If we come to composite application with multiple cartridges we have to
> define deployment pattens for each and every cartridge in that composite
> application. Defining deployment patten, have to use cartridge alias for
> distinguish deferent cartridges because we can't use cartridge type, some
> application may have multiple same cartridges and need different deployment
> pattens.
>
>
>
> To address particular in your scenario, we can't have two implementation
> whether is singleton or a composite group. Here one possible solution, I
> believe we can implement, and which will cover your simple scenario as well.
>
>
>
> solution :
>
> - shall we allow to have global deployment policies (can have many)
> which can pre deploy/add. (I will explain what is these global one)
> - and will allow, in the defining the deployment policy time to
> attached above without defining. (user has both option)
> - then deploy the application
>
> I believed this is what you are looking for
>
>
>
> Let me explain these global deployment policy concept. We have section
> call childPolicies which we refer different cartridge alias to define
> deployment pattens.
>
>
>
> "childPolicies": [
>
> {
>
> "alias": "mytomcat",
>
> "networkPartition": [
>
> {
>
> "id": "network-partition-1",
>
> "partitionAlgo": "one-after-another",
>
> "partitions": [
>
> {
>
> "id": "partition-1",
>
> "max": 5
>
> }
>
> ]
>
> }
>
> ]
>
> }
>
>
>
> I like to propose, introduce section call globalPolicies which can define
> global deployment pattens which going to apply for all cartridges defining
> in that application. If it is single cartridge or not it will use same
> deployment patten.
>
>
>
> With this implementation, without changing current design and
> implementation we can achieved simple singleton scenario with attaching
> same deployment policies without re defining per application
> creation/deploy.
>
>
>
> Please share your thoughts
>
>
>
>
>
>
>
> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
> Yes, I agree with your concerns Shaheed! Please find my comments below:
>
>
>
> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com> wrote:
>
>
>
> OK, I get that argument. But consider that multiple subscriptions all
> using a single deployment spec was the previous model, and now we have
> inverted that cardinality completely.
>
>
>
> Not exactly, we support multiple subscriptions for Multi-Tenant
> applications but not for Single-Tenant applications. This is again due to
> the reason I have explained in the previous response. May be we can improve
> this in a minor release. BTW the term Subscription has now being changed to
> Application SignUp.
>
>
>
> To my knowledge, in addition to the generic automation of single
> cartridge subscriptions we provided our Stratos users, at least two users
> have significant investment in dynamically generating and
> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
> single application cartridges is necessary work needed to get to 4.1, but
> all these usages will now require substantive rework to manage the opposite
> cardinality w.r.t. deployment policies.
>
>
>
> Here we deploy an application in the context of Tenant not for User. Yes
> in this release it is not possible to share Single-Tenant applications
> accross tenants. However each tenant can deploy the same application with a
> different deployment policy by using a different application id.
>
>
>
> I'm all in favour of progress, and change where unavoidable, but this
> seems to gratuitously change the model for the bulk of singleton cartridge
> users in favour of the currently non-existent grouping users. (And yes, I
> am aware of the paradox that we are VERY interested in the grouping).
>
>
>
> Yes I agree, may be we can have a separate discussion on this and propose
> improvements for the next minor release.
>
>
>
> Thanks
>
>
>
>
>
> --
>
> Lakmal Warusawithana
>
> Vice President, Apache Stratos
>
> Director - Cloud Architecture; WSO2 Inc.
>
> Mobile : +94714289692
>
> Blog : http://lakmalsview.blogspot.com/
>
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
>
>
> --
> Sent from Gmail Mobile
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
>
>
>
>
> --
>
> Lakmal Warusawithana
>
> Vice President, Apache Stratos
>
> Director - Cloud Architecture; WSO2 Inc.
>
> Mobile : +94714289692
>
> Blog : http://lakmalsview.blogspot.com/
>
>
>
>
> --
>
> Rajkumar Rajaratnam
>
> Committer & PMC Member, Apache Stratos
>
> Software Engineer, WSO2
>
> Mobile : +94777568639
>
> Blog : rajkumarr.com
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
So in summary, deployment policies propagate top down, is that right?
Also, do we have updated samples/specs that I can start to code to yet?
From: Rajkumar Rajaratnam [mailto:rajkumarr@wso2.com]
Sent: 19 February 2015 06:11
To: dev@stratos.apache.org
Subject: Re: 4.1 deployment policy questions
On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Lakmal,
Please find a question inline.
On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>> wrote:
On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>> wrote:
Hi Imesh,
Please find a question inline.
On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>> wrote:
Hi Devs,
Today we had a call on this topic and please find the summary of the discussion below:
- In Stratos 4.0.0 the deployment policy was defined in the global context and it was reusable.
- Now deployment policy is in application context and contains deployment pattens of multiple cartridges.
- As a result the application deployment process has become complex and backward compatibility with the previous release has been broken.
- Therefore we can do a slight modification in the current model and move the deployment policy to the global context:
- If so we will have following entities in the global context:
[cid:image002.png@01D04DD6.4A79C9E0]
- Then we can construct the application by referring Cartridges, Cartridge Groups, Autoscaling Policies and Deployment Policies:
- Either Cartridges or Cartridge Groups can refer Deployment Policies:
[cid:image004.png@01D04DD6.4A79C9E0]
[cid:image006.png@01D04DD6.4A79C9E0]
Why a cartridge group need to refer a deployment policy? I assume if a cartridge group is referring a deployment policy, then all the cartridges under that group will use the same deployment policy referred by the group? Or this is for something else. Please give me some insight on this.
Yes you are correct. Cartridges under a group will use same department policy referred by the group.
Thanks Lakmal for confirming it.
I have one more question. If both cartridge group and a cartridge, say cartridge-1, (from that group) define two different deployment policies, all the other cartridges except cartridge-1 will use the deployment policy referred in the cartridge group and cartridge-1 will use the deployment policy referred in it. Is this correct? Or we should not allow both cartridge group and cartridges to refer deployment policies?
Parsing the application, to identify which deployment policy each cartridge refers, is going to be damn complex :)
If we have define a deployment policy at top, bottom cartridges/groups are not allowed to define any. Top deployment policy applied for all.
Thanks Lakmal. That will reduce the complexity.
Thanks.
Thanks.
Thanks.al
- Now we need to provide an application policy at the application deployment time to specify application availability in network partitions:
- This would say whether to start the application in all network partitions or do cloud bursting:
[cid:image008.png@01D04DD6.4A79C9E0]
- At a later release we can introduce Application Template concept by extracting subscribable information out from the application:
[cid:image010.png@01D04DD6.4A79C9E0]
Please add your thoughts on this modification.
Thanks
On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>> wrote:
+1 for the idea Lakmal! Yes I think it is better to have a call and discuss this before doing any changes.
Thanks
On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>> wrote:
Hi Shaheed,
Will try to explain further but simple and here some workaround solution.
Previous release we only subscribe to a single cartridge with given deployment policy. We have re used defined deployment policy. The main reason that we cloud do, single cartridge has single deployment patten for a particular deployment.
If we come to composite application with multiple cartridges we have to define deployment pattens for each and every cartridge in that composite application. Defining deployment patten, have to use cartridge alias for distinguish deferent cartridges because we can't use cartridge type, some application may have multiple same cartridges and need different deployment pattens.
To address particular in your scenario, we can't have two implementation whether is singleton or a composite group. Here one possible solution, I believe we can implement, and which will cover your simple scenario as well.
solution :
* shall we allow to have global deployment policies (can have many) which can pre deploy/add. (I will explain what is these global one)
* and will allow, in the defining the deployment policy time to attached above without defining. (user has both option)
* then deploy the application
I believed this is what you are looking for
Let me explain these global deployment policy concept. We have section call childPolicies which we refer different cartridge alias to define deployment pattens.
"childPolicies": [
{
"alias": "mytomcat",
"networkPartition": [
{
"id": "network-partition-1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "partition-1",
"max": 5
}
]
}
]
}
I like to propose, introduce section call globalPolicies which can define global deployment pattens which going to apply for all cartridges defining in that application. If it is single cartridge or not it will use same deployment patten.
With this implementation, without changing current design and implementation we can achieved simple singleton scenario with attaching same deployment policies without re defining per application creation/deploy.
Please share your thoughts
On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>> wrote:
Yes, I agree with your concerns Shaheed! Please find my comments below:
On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>> wrote:
OK, I get that argument. But consider that multiple subscriptions all using a single deployment spec was the previous model, and now we have inverted that cardinality completely.
Not exactly, we support multiple subscriptions for Multi-Tenant applications but not for Single-Tenant applications. This is again due to the reason I have explained in the previous response. May be we can improve this in a minor release. BTW the term Subscription has now being changed to Application SignUp.
To my knowledge, in addition to the generic automation of single cartridge subscriptions we provided our Stratos users, at least two users have significant investment in dynamically generating and subscribing/unsubscribing cartridges on-the-fly. Converting these to use single application cartridges is necessary work needed to get to 4.1, but all these usages will now require substantive rework to manage the opposite cardinality w.r.t. deployment policies.
Here we deploy an application in the context of Tenant not for User. Yes in this release it is not possible to share Single-Tenant applications accross tenants. However each tenant can deploy the same application with a different deployment policy by using a different application id.
I'm all in favour of progress, and change where unavoidable, but this seems to gratuitously change the model for the bulk of singleton cartridge users in favour of the currently non-existent grouping users. (And yes, I am aware of the paradox that we are VERY interested in the grouping).
Yes I agree, may be we can have a separate discussion on this and propose improvements for the next minor release.
Thanks
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Sent from Gmail Mobile
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639<tel:%2B94777568639>
Blog : rajkumarr.com<http://rajkumarr.com>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692<tel:%2B94714289692>
Blog : http://lakmalsview.blogspot.com/
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com<http://rajkumarr.com>
Re: 4.1 deployment policy questions
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
On Thu, Feb 19, 2015 at 11:31 AM, Lakmal Warusawithana <la...@wso2.com>
wrote:
>
>
> On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
>> Hi Lakmal,
>>
>> Please find a question inline.
>>
>> On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
>>> wrote:
>>>
>>>> Hi Imesh,
>>>>
>>>> Please find a question inline.
>>>>
>>>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> Today we had a call on this topic and please find the summary of the
>>>>> discussion below:
>>>>>
>>>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>>>> context and it was reusable.
>>>>> - Now deployment policy is in application context and contains
>>>>> deployment pattens of multiple cartridges.
>>>>> - As a result the application deployment process has become complex
>>>>> and backward compatibility with the previous release has been broken.
>>>>>
>>>>> - Therefore we can do a slight modification in the current model and
>>>>> move the deployment policy to the global context:
>>>>> - If so we will have following entities in the global context:
>>>>>
>>>>>
>>>>> - Then we can construct the application by referring Cartridges,
>>>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Why a cartridge group need to refer a deployment policy? I assume if a
>>>> cartridge group is referring a deployment policy, then all the cartridges
>>>> under that group will use the same deployment policy referred by the group?
>>>> Or this is for something else. Please give me some insight on this.
>>>>
>>>
>>> Yes you are correct. Cartridges under a group will use same department
>>> policy referred by the group.
>>>
>>
>> Thanks Lakmal for confirming it.
>>
>> I have one more question. If both cartridge group and a cartridge, say
>> cartridge-1, (from that group) define two different deployment policies,
>> all the other cartridges except cartridge-1 will use the deployment policy
>> referred in the cartridge group and cartridge-1 will use the deployment
>> policy referred in it. Is this correct? Or we should not allow both
>> cartridge group and cartridges to refer deployment policies?
>>
>> Parsing the application, to identify which deployment policy each
>> cartridge refers, is going to be damn complex :)
>>
>>
> If we have define a deployment policy at top, bottom cartridges/groups are
> not allowed to define any. Top deployment policy applied for all.
>
Thanks Lakmal. That will reduce the complexity.
Thanks.
>
>
>> Thanks.
>>
>>>
>>>
>>>
>>>> Thanks.al
>>>>
>>>>
>>>>> - Now we need to provide an application policy at the application
>>>>> deployment time to specify application availability in network partitions:
>>>>> - This would say whether to start the application in all network
>>>>> partitions or do cloud bursting:
>>>>>
>>>>>
>>>>> - At a later release we can introduce Application Template concept by
>>>>> extracting subscribable information out from the application:
>>>>>
>>>>>
>>>>>
>>>>> Please add your thoughts on this modification.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>>>> discuss this before doing any changes.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <
>>>>>> lakmal@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Shaheed,
>>>>>>>
>>>>>>> Will try to explain further but simple and here some workaround
>>>>>>> solution.
>>>>>>>
>>>>>>> Previous release we only subscribe to a single cartridge with given
>>>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>>>> a particular deployment.
>>>>>>>
>>>>>>> If we come to composite application with multiple cartridges we have
>>>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>>>> application may have multiple same cartridges and need different deployment
>>>>>>> pattens.
>>>>>>>
>>>>>>> To address particular in your scenario, we can't have two
>>>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>>>> solution, I believe we can implement, and which will cover your simple
>>>>>>> scenario as well.
>>>>>>>
>>>>>>> solution :
>>>>>>>
>>>>>>> - shall we allow to have global deployment policies (can have
>>>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>>>> - and will allow, in the defining the deployment policy time to
>>>>>>> attached above without defining. (user has both option)
>>>>>>> - then deploy the application
>>>>>>>
>>>>>>> I believed this is what you are looking for
>>>>>>>
>>>>>>> Let me explain these global deployment policy concept. We have
>>>>>>> section call childPolicies which we refer different cartridge alias to
>>>>>>> define deployment pattens.
>>>>>>>
>>>>>>> "childPolicies": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "alias": "mytomcat",
>>>>>>>
>>>>>>> "networkPartition": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "id": "network-partition-1",
>>>>>>>
>>>>>>> "partitionAlgo": "one-after-another",
>>>>>>>
>>>>>>> "partitions": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "id": "partition-1",
>>>>>>>
>>>>>>> "max": 5
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ]
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ]
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> I like to propose, introduce section call globalPolicies which can
>>>>>>> define global deployment pattens which going to apply for all cartridges
>>>>>>> defining in that application. If it is single cartridge or not it will use
>>>>>>> same deployment patten.
>>>>>>>
>>>>>>> With this implementation, without changing current design and
>>>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>>>> same deployment policies without re defining per application
>>>>>>> creation/deploy.
>>>>>>>
>>>>>>> Please share your thoughts
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>>>> below:
>>>>>>>>
>>>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>>>> inverted that cardinality completely.
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>>>> Application SignUp.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>>>> have significant investment in dynamically generating and
>>>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Here we deploy an application in the context of Tenant not for
>>>>>>>> User. Yes in this release it is not possible to share Single-Tenant
>>>>>>>> applications accross tenants. However each tenant can deploy the same
>>>>>>>> application with a different deployment policy by using a different
>>>>>>>> application id.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>>>> grouping).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>>>> propose improvements for the next minor release.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lakmal Warusawithana
>>>>>>> Vice President, Apache Stratos
>>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>>> Mobile : +94714289692
>>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Imesh Gunaratne
>>>>>>
>>>>>> Technical Lead, WSO2
>>>>>> Committer & PMC Member, Apache Stratos
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rajkumar Rajaratnam
>>>> Committer & PMC Member, Apache Stratos
>>>> Software Engineer, WSO2
>>>>
>>>> Mobile : +94777568639
>>>> Blog : rajkumarr.com
>>>>
>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>>
>>
>>
>>
>> --
>> Rajkumar Rajaratnam
>> Committer & PMC Member, Apache Stratos
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>> Blog : rajkumarr.com
>>
>
>
>
> --
> Lakmal Warusawithana
> Vice President, Apache Stratos
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com
Re: 4.1 deployment policy questions
Posted by Lakmal Warusawithana <la...@wso2.com>.
On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <ra...@wso2.com>
wrote:
> Hi Lakmal,
>
> Please find a question inline.
>
> On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
>>
>>
>> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> Please find a question inline.
>>>
>>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> Today we had a call on this topic and please find the summary of the
>>>> discussion below:
>>>>
>>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>>> context and it was reusable.
>>>> - Now deployment policy is in application context and contains
>>>> deployment pattens of multiple cartridges.
>>>> - As a result the application deployment process has become complex and
>>>> backward compatibility with the previous release has been broken.
>>>>
>>>> - Therefore we can do a slight modification in the current model and
>>>> move the deployment policy to the global context:
>>>> - If so we will have following entities in the global context:
>>>>
>>>>
>>>> - Then we can construct the application by referring Cartridges,
>>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>>
>>>>
>>>>
>>>>
>>> Why a cartridge group need to refer a deployment policy? I assume if a
>>> cartridge group is referring a deployment policy, then all the cartridges
>>> under that group will use the same deployment policy referred by the group?
>>> Or this is for something else. Please give me some insight on this.
>>>
>>
>> Yes you are correct. Cartridges under a group will use same department
>> policy referred by the group.
>>
>
> Thanks Lakmal for confirming it.
>
> I have one more question. If both cartridge group and a cartridge, say
> cartridge-1, (from that group) define two different deployment policies,
> all the other cartridges except cartridge-1 will use the deployment policy
> referred in the cartridge group and cartridge-1 will use the deployment
> policy referred in it. Is this correct? Or we should not allow both
> cartridge group and cartridges to refer deployment policies?
>
> Parsing the application, to identify which deployment policy each
> cartridge refers, is going to be damn complex :)
>
>
If we have define a deployment policy at top, bottom cartridges/groups are
not allowed to define any. Top deployment policy applied for all.
> Thanks.
>
>>
>>
>>
>>> Thanks.al
>>>
>>>
>>>> - Now we need to provide an application policy at the application
>>>> deployment time to specify application availability in network partitions:
>>>> - This would say whether to start the application in all network
>>>> partitions or do cloud bursting:
>>>>
>>>>
>>>> - At a later release we can introduce Application Template concept by
>>>> extracting subscribable information out from the application:
>>>>
>>>>
>>>>
>>>> Please add your thoughts on this modification.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>>> discuss this before doing any changes.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lakmal@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi Shaheed,
>>>>>>
>>>>>> Will try to explain further but simple and here some workaround
>>>>>> solution.
>>>>>>
>>>>>> Previous release we only subscribe to a single cartridge with given
>>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>>> a particular deployment.
>>>>>>
>>>>>> If we come to composite application with multiple cartridges we have
>>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>>> application may have multiple same cartridges and need different deployment
>>>>>> pattens.
>>>>>>
>>>>>> To address particular in your scenario, we can't have two
>>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>>> solution, I believe we can implement, and which will cover your simple
>>>>>> scenario as well.
>>>>>>
>>>>>> solution :
>>>>>>
>>>>>> - shall we allow to have global deployment policies (can have
>>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>>> - and will allow, in the defining the deployment policy time to
>>>>>> attached above without defining. (user has both option)
>>>>>> - then deploy the application
>>>>>>
>>>>>> I believed this is what you are looking for
>>>>>>
>>>>>> Let me explain these global deployment policy concept. We have
>>>>>> section call childPolicies which we refer different cartridge alias to
>>>>>> define deployment pattens.
>>>>>>
>>>>>> "childPolicies": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "alias": "mytomcat",
>>>>>>
>>>>>> "networkPartition": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "id": "network-partition-1",
>>>>>>
>>>>>> "partitionAlgo": "one-after-another",
>>>>>>
>>>>>> "partitions": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "id": "partition-1",
>>>>>>
>>>>>> "max": 5
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> }
>>>>>>
>>>>>> I like to propose, introduce section call globalPolicies which can
>>>>>> define global deployment pattens which going to apply for all cartridges
>>>>>> defining in that application. If it is single cartridge or not it will use
>>>>>> same deployment patten.
>>>>>>
>>>>>> With this implementation, without changing current design and
>>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>>> same deployment policies without re defining per application
>>>>>> creation/deploy.
>>>>>>
>>>>>> Please share your thoughts
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>>> below:
>>>>>>>
>>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>>> inverted that cardinality completely.
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>>> Application SignUp.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>>> have significant investment in dynamically generating and
>>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>>>> different deployment policy by using a different application id.
>>>>>>>
>>>>>>>
>>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>>> grouping).
>>>>>>>>
>>>>>>>
>>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>>> propose improvements for the next minor release.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Vice President, Apache Stratos
>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>> Mobile : +94714289692
>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Rajkumar Rajaratnam
>>> Committer & PMC Member, Apache Stratos
>>> Software Engineer, WSO2
>>>
>>> Mobile : +94777568639
>>> Blog : rajkumarr.com
>>>
>>
>>
>> --
>> Sent from Gmail Mobile
>>
>
>
>
> --
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: 4.1 deployment policy questions
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
Hi Lakmal,
Please find a question inline.
On Wed, Feb 18, 2015 at 7:33 PM, Lakmal Warusawithana <la...@wso2.com>
wrote:
>
>
> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
>> Hi Imesh,
>>
>> Please find a question inline.
>>
>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> Today we had a call on this topic and please find the summary of the
>>> discussion below:
>>>
>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>> context and it was reusable.
>>> - Now deployment policy is in application context and contains
>>> deployment pattens of multiple cartridges.
>>> - As a result the application deployment process has become complex and
>>> backward compatibility with the previous release has been broken.
>>>
>>> - Therefore we can do a slight modification in the current model and
>>> move the deployment policy to the global context:
>>> - If so we will have following entities in the global context:
>>>
>>>
>>> - Then we can construct the application by referring Cartridges,
>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>
>>>
>>>
>>>
>> Why a cartridge group need to refer a deployment policy? I assume if a
>> cartridge group is referring a deployment policy, then all the cartridges
>> under that group will use the same deployment policy referred by the group?
>> Or this is for something else. Please give me some insight on this.
>>
>
> Yes you are correct. Cartridges under a group will use same department
> policy referred by the group.
>
Thanks Lakmal for confirming it.
I have one more question. If both cartridge group and a cartridge, say
cartridge-1, (from that group) define two different deployment policies,
all the other cartridges except cartridge-1 will use the deployment policy
referred in the cartridge group and cartridge-1 will use the deployment
policy referred in it. Is this correct? Or we should not allow both
cartridge group and cartridges to refer deployment policies?
Parsing the application, to identify which deployment policy each cartridge
refers, is going to be damn complex :)
Thanks.
>
>
>
>> Thanks.al
>>
>>
>>> - Now we need to provide an application policy at the application
>>> deployment time to specify application availability in network partitions:
>>> - This would say whether to start the application in all network
>>> partitions or do cloud bursting:
>>>
>>>
>>> - At a later release we can introduce Application Template concept by
>>> extracting subscribable information out from the application:
>>>
>>>
>>>
>>> Please add your thoughts on this modification.
>>>
>>> Thanks
>>>
>>>
>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>> discuss this before doing any changes.
>>>>
>>>> Thanks
>>>>
>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Shaheed,
>>>>>
>>>>> Will try to explain further but simple and here some workaround
>>>>> solution.
>>>>>
>>>>> Previous release we only subscribe to a single cartridge with given
>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>> a particular deployment.
>>>>>
>>>>> If we come to composite application with multiple cartridges we have
>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>> application may have multiple same cartridges and need different deployment
>>>>> pattens.
>>>>>
>>>>> To address particular in your scenario, we can't have two
>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>> solution, I believe we can implement, and which will cover your simple
>>>>> scenario as well.
>>>>>
>>>>> solution :
>>>>>
>>>>> - shall we allow to have global deployment policies (can have
>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>> - and will allow, in the defining the deployment policy time to
>>>>> attached above without defining. (user has both option)
>>>>> - then deploy the application
>>>>>
>>>>> I believed this is what you are looking for
>>>>>
>>>>> Let me explain these global deployment policy concept. We have section
>>>>> call childPolicies which we refer different cartridge alias to define
>>>>> deployment pattens.
>>>>>
>>>>> "childPolicies": [
>>>>>
>>>>> {
>>>>>
>>>>> "alias": "mytomcat",
>>>>>
>>>>> "networkPartition": [
>>>>>
>>>>> {
>>>>>
>>>>> "id": "network-partition-1",
>>>>>
>>>>> "partitionAlgo": "one-after-another",
>>>>>
>>>>> "partitions": [
>>>>>
>>>>> {
>>>>>
>>>>> "id": "partition-1",
>>>>>
>>>>> "max": 5
>>>>>
>>>>> }
>>>>>
>>>>> ]
>>>>>
>>>>> }
>>>>>
>>>>> ]
>>>>>
>>>>> }
>>>>>
>>>>> I like to propose, introduce section call globalPolicies which can
>>>>> define global deployment pattens which going to apply for all cartridges
>>>>> defining in that application. If it is single cartridge or not it will use
>>>>> same deployment patten.
>>>>>
>>>>> With this implementation, without changing current design and
>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>> same deployment policies without re defining per application
>>>>> creation/deploy.
>>>>>
>>>>> Please share your thoughts
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>> below:
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>> inverted that cardinality completely.
>>>>>>>
>>>>>>
>>>>>>>
>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>> Application SignUp.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>> have significant investment in dynamically generating and
>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>
>>>>>>
>>>>>>>
>>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>>> different deployment policy by using a different application id.
>>>>>>
>>>>>>
>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>> grouping).
>>>>>>>
>>>>>>
>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>> propose improvements for the next minor release.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Vice President, Apache Stratos
>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Rajkumar Rajaratnam
>> Committer & PMC Member, Apache Stratos
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>> Blog : rajkumarr.com
>>
>
>
> --
> Sent from Gmail Mobile
>
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com
Re: 4.1 deployment policy questions
Posted by Lakmal Warusawithana <la...@wso2.com>.
On Wednesday, February 18, 2015, Rajkumar Rajaratnam <ra...@wso2.com>
wrote:
> Hi Imesh,
>
> Please find a question inline.
>
> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>
>> Hi Devs,
>>
>> Today we had a call on this topic and please find the summary of the
>> discussion below:
>>
>> - In Stratos 4.0.0 the deployment policy was defined in the global
>> context and it was reusable.
>> - Now deployment policy is in application context and contains deployment
>> pattens of multiple cartridges.
>> - As a result the application deployment process has become complex and
>> backward compatibility with the previous release has been broken.
>>
>> - Therefore we can do a slight modification in the current model and move
>> the deployment policy to the global context:
>> - If so we will have following entities in the global context:
>>
>>
>> - Then we can construct the application by referring Cartridges,
>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>
>>
>>
>>
> Why a cartridge group need to refer a deployment policy? I assume if a
> cartridge group is referring a deployment policy, then all the cartridges
> under that group will use the same deployment policy referred by the group?
> Or this is for something else. Please give me some insight on this.
>
Yes you are correct. Cartridges under a group will use same department
policy referred by the group.
> Thanks.
>
>
>> - Now we need to provide an application policy at the application
>> deployment time to specify application availability in network partitions:
>> - This would say whether to start the application in all network
>> partitions or do cloud bursting:
>>
>>
>> - At a later release we can introduce Application Template concept by
>> extracting subscribable information out from the application:
>>
>>
>>
>> Please add your thoughts on this modification.
>>
>> Thanks
>>
>>
>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <imesh@apache.org
>> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>>
>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>> discuss this before doing any changes.
>>>
>>> Thanks
>>>
>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lakmal@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','lakmal@wso2.com');>> wrote:
>>>
>>>> Hi Shaheed,
>>>>
>>>> Will try to explain further but simple and here some workaround
>>>> solution.
>>>>
>>>> Previous release we only subscribe to a single cartridge with given
>>>> deployment policy. We have re used defined deployment policy. The main
>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>> a particular deployment.
>>>>
>>>> If we come to composite application with multiple cartridges we have to
>>>> define deployment pattens for each and every cartridge in that composite
>>>> application. Defining deployment patten, have to use cartridge alias for
>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>> application may have multiple same cartridges and need different deployment
>>>> pattens.
>>>>
>>>> To address particular in your scenario, we can't have two
>>>> implementation whether is singleton or a composite group. Here one possible
>>>> solution, I believe we can implement, and which will cover your simple
>>>> scenario as well.
>>>>
>>>> solution :
>>>>
>>>> - shall we allow to have global deployment policies (can have many)
>>>> which can pre deploy/add. (I will explain what is these global one)
>>>> - and will allow, in the defining the deployment policy time to
>>>> attached above without defining. (user has both option)
>>>> - then deploy the application
>>>>
>>>> I believed this is what you are looking for
>>>>
>>>> Let me explain these global deployment policy concept. We have section
>>>> call childPolicies which we refer different cartridge alias to define
>>>> deployment pattens.
>>>>
>>>> "childPolicies": [
>>>>
>>>> {
>>>>
>>>> "alias": "mytomcat",
>>>>
>>>> "networkPartition": [
>>>>
>>>> {
>>>>
>>>> "id": "network-partition-1",
>>>>
>>>> "partitionAlgo": "one-after-another",
>>>>
>>>> "partitions": [
>>>>
>>>> {
>>>>
>>>> "id": "partition-1",
>>>>
>>>> "max": 5
>>>>
>>>> }
>>>>
>>>> ]
>>>>
>>>> }
>>>>
>>>> ]
>>>>
>>>> }
>>>>
>>>> I like to propose, introduce section call globalPolicies which can
>>>> define global deployment pattens which going to apply for all cartridges
>>>> defining in that application. If it is single cartridge or not it will use
>>>> same deployment patten.
>>>>
>>>> With this implementation, without changing current design and
>>>> implementation we can achieved simple singleton scenario with attaching
>>>> same deployment policies without re defining per application
>>>> creation/deploy.
>>>>
>>>> Please share your thoughts
>>>>
>>>>
>>>>
>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <imesh@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>>>>
>>>>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>>>>
>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahhaqu@cisco.com
>>>>> <javascript:_e(%7B%7D,'cvml','shahhaqu@cisco.com');>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> OK, I get that argument. But consider that multiple subscriptions all
>>>>>> using a single deployment spec was the previous model, and now we have
>>>>>> inverted that cardinality completely.
>>>>>>
>>>>>
>>>>>>
>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>> the reason I have explained in the previous response. May be we can improve
>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>> Application SignUp.
>>>>>
>>>>>>
>>>>>>
>>>>> To my knowledge, in addition to the generic automation of single
>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>> have significant investment in dynamically generating and
>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>> cardinality w.r.t. deployment policies.
>>>>>>
>>>>>
>>>>>>
>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>> different deployment policy by using a different application id.
>>>>>
>>>>>
>>>>>> I'm all in favour of progress, and change where unavoidable, but this
>>>>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>>>>> users in favour of the currently non-existent grouping users. (And yes, I
>>>>>> am aware of the paradox that we are VERY interested in the grouping).
>>>>>>
>>>>>
>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>> propose improvements for the next minor release.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Vice President, Apache Stratos
>>>> Director - Cloud Architecture; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
>
--
Sent from Gmail Mobile
Re: 4.1 deployment policy questions
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
Hi Imesh,
Please find a question inline.
On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Devs,
>
> Today we had a call on this topic and please find the summary of the
> discussion below:
>
> - In Stratos 4.0.0 the deployment policy was defined in the global context
> and it was reusable.
> - Now deployment policy is in application context and contains deployment
> pattens of multiple cartridges.
> - As a result the application deployment process has become complex and
> backward compatibility with the previous release has been broken.
>
> - Therefore we can do a slight modification in the current model and move
> the deployment policy to the global context:
> - If so we will have following entities in the global context:
>
>
> - Then we can construct the application by referring Cartridges, Cartridge
> Groups, Autoscaling Policies and Deployment Policies:
> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>
>
>
>
Why a cartridge group need to refer a deployment policy? I assume if a
cartridge group is referring a deployment policy, then all the cartridges
under that group will use the same deployment policy referred by the group?
Or this is for something else. Please give me some insight on this.
Thanks.
> - Now we need to provide an application policy at the application
> deployment time to specify application availability in network partitions:
> - This would say whether to start the application in all network
> partitions or do cloud bursting:
>
>
> - At a later release we can introduce Application Template concept by
> extracting subscribable information out from the application:
>
>
>
> Please add your thoughts on this modification.
>
> Thanks
>
>
> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>> discuss this before doing any changes.
>>
>> Thanks
>>
>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>> Hi Shaheed,
>>>
>>> Will try to explain further but simple and here some workaround solution.
>>>
>>> Previous release we only subscribe to a single cartridge with given
>>> deployment policy. We have re used defined deployment policy. The main
>>> reason that we cloud do, single cartridge has single deployment patten for
>>> a particular deployment.
>>>
>>> If we come to composite application with multiple cartridges we have to
>>> define deployment pattens for each and every cartridge in that composite
>>> application. Defining deployment patten, have to use cartridge alias for
>>> distinguish deferent cartridges because we can't use cartridge type, some
>>> application may have multiple same cartridges and need different deployment
>>> pattens.
>>>
>>> To address particular in your scenario, we can't have two implementation
>>> whether is singleton or a composite group. Here one possible solution, I
>>> believe we can implement, and which will cover your simple scenario as well.
>>>
>>> solution :
>>>
>>> - shall we allow to have global deployment policies (can have many)
>>> which can pre deploy/add. (I will explain what is these global one)
>>> - and will allow, in the defining the deployment policy time to
>>> attached above without defining. (user has both option)
>>> - then deploy the application
>>>
>>> I believed this is what you are looking for
>>>
>>> Let me explain these global deployment policy concept. We have section
>>> call childPolicies which we refer different cartridge alias to define
>>> deployment pattens.
>>>
>>> "childPolicies": [
>>>
>>> {
>>>
>>> "alias": "mytomcat",
>>>
>>> "networkPartition": [
>>>
>>> {
>>>
>>> "id": "network-partition-1",
>>>
>>> "partitionAlgo": "one-after-another",
>>>
>>> "partitions": [
>>>
>>> {
>>>
>>> "id": "partition-1",
>>>
>>> "max": 5
>>>
>>> }
>>>
>>> ]
>>>
>>> }
>>>
>>> ]
>>>
>>> }
>>>
>>> I like to propose, introduce section call globalPolicies which can
>>> define global deployment pattens which going to apply for all cartridges
>>> defining in that application. If it is single cartridge or not it will use
>>> same deployment patten.
>>>
>>> With this implementation, without changing current design and
>>> implementation we can achieved simple singleton scenario with attaching
>>> same deployment policies without re defining per application
>>> creation/deploy.
>>>
>>> Please share your thoughts
>>>
>>>
>>>
>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>>>
>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> OK, I get that argument. But consider that multiple subscriptions all
>>>>> using a single deployment spec was the previous model, and now we have
>>>>> inverted that cardinality completely.
>>>>>
>>>>
>>>>>
>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>> applications but not for Single-Tenant applications. This is again due to
>>>> the reason I have explained in the previous response. May be we can improve
>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>> Application SignUp.
>>>>
>>>>>
>>>>>
>>>> To my knowledge, in addition to the generic automation of single
>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>> have significant investment in dynamically generating and
>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>> all these usages will now require substantive rework to manage the opposite
>>>>> cardinality w.r.t. deployment policies.
>>>>>
>>>>
>>>>>
>>>> Here we deploy an application in the context of Tenant not for User.
>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>> accross tenants. However each tenant can deploy the same application with a
>>>> different deployment policy by using a different application id.
>>>>
>>>>
>>>>> I'm all in favour of progress, and change where unavoidable, but this
>>>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>>>> users in favour of the currently non-existent grouping users. (And yes, I
>>>>> am aware of the paradox that we are VERY interested in the grouping).
>>>>>
>>>>
>>>> Yes I agree, may be we can have a separate discussion on this and
>>>> propose improvements for the next minor release.
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Vice President, Apache Stratos
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Great work Sajith! Thanks for the update!
On Wed, Feb 18, 2015 at 1:33 AM, Sajith Kariyawasam <sa...@wso2.com> wrote:
> Hi Imesh,
>
> I have done following,
> * Update deployApplication operation in Autoscaler service to have
> application policy as an argument, instead of deployment policy. WSDLs ,
> stubs and Rest API is also updated
> * Removed activeByDefault from NetworkPartitionBean and updating utility
> methods used for object conversion accordingly.
>
> Now working on,
> * Persisting application policy and retrieving the same to check for
> active partitions
> * Moving Cloudcontroller client operations to
> CloudControllerServiceClient
>
> Thanks,
> Sajith
>
>
> On Wed, Feb 18, 2015 at 12:18 AM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> Great work Raj! Thanks for the update!
>>
>> FYI: When you are doing changes please try to avoid any code clean ups in
>> this branch beacause it would be difficult for us to merge back to master
>> branch.
>>
>> Thanks
>>
>> On Tue, Feb 17, 2015 at 9:38 PM, Rajkumar Rajaratnam <ra...@wso2.com>
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> I have done the followings as part of the effort in this modification.
>>>
>>> - implemented network partition management logic in CC and updated
>>> relevant rest APIs and Service Clients
>>> - implemented proper deployment policy validation
>>> - fixed authorization action in some rest APIs
>>>
>>> Network partition management and deployment policy management are now
>>> working end-to-end with proper validations. Refer [1] for more detail on
>>> this.
>>>
>>> I am now looking into the changes needs to be done at Autoscaler. Will
>>> update the progress on this thread.
>>>
>>> 1. [Discuss] Deployment policy needs to be validated
>>>
>>> Thanks.
>>>
>>> On Tue, Feb 17, 2015 at 8:32 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Raj/Sajith,
>>>>
>>>> Appreciate if you can provide an update on the progress we have made so
>>>> far with this modification.
>>>>
>>>> Thanks
>>>>
>>>> On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Shaheed,
>>>>>
>>>>> Please find comments inline:
>>>>>
>>>>> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
>>>>> shahhaqu@cisco.com> wrote:
>>>>>
>>>>>> OK, I think we are close. In the following reply, I am only
>>>>>> concerned with the users view, not any Stratos internal concepts or names.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I define an “application instance” to be something which is created
>>>>>> in response to combining an application.json (which contains references to
>>>>>> named deployment policies, one per subscribableInfo) with a set of
>>>>>> deployment policies which match the references. These deployment policies
>>>>>> will have been preloaded into Stratos.
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks for the explanation! Yes I completely agree with your view on
>>>>> this, we will need to expose an application instance id to the user when we
>>>>> introduce application templates.
>>>>>
>>>>>
>>>>>> As you say “we cannot switch deployment policies of an application
>>>>>> once it is deployed. However if needed we can create a new application with
>>>>>> a new set of deployment policies”. So to avoid doubt…
>>>>>>
>>>>>> · An application instance must, by necessity, take a snapshot
>>>>>> of all the policies referred to as the instance is created. Not doing so
>>>>>> would cause confusion if the deployment policies are later updated.
>>>>>>
>>>>> +1 Yes AFAIK this functionality is not there at the moment, we will
>>>>> add it.
>>>>>
>>>>>> o Note: this does not preclude later having the ability to modify
>>>>>> the snapshot (e.g. min/max instance values and so on).
>>>>>>
>>>>> Yes, as I mentioned in the previous response, I also would like to
>>>>> have the ability to update deployment and autoscaling policies with/without
>>>>> affecting deployed applications.
>>>>>
>>>>>> o I assume the same snapshotting is needed for the autoscaling
>>>>>> policies.
>>>>>>
>>>>> Yes indeed, autoscaling policies also need to be snapshotted.
>>>>>
>>>>>> o This does imply that it has to be possible to “show” the
>>>>>> current state of the application and its snapshotted policies for debugging
>>>>>> purposes etc.
>>>>>>
>>>>> +1
>>>>>
>>>>>> · After the instance is deployed, the deployment (and
>>>>>> autoscaling) policies may be changed without affecting the existing
>>>>>> instance.
>>>>>>
>>>>> Yes, I would like to have the capability to either apply changes to
>>>>> deployed applications or not to apply them. If so users could use this
>>>>> feature as they wish.
>>>>>
>>>>> Thanks,
>>>>> Imesh
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Rajkumar Rajaratnam
>>> Committer & PMC Member, Apache Stratos
>>> Software Engineer, WSO2
>>>
>>> Mobile : +94777568639
>>> Blog : rajkumarr.com
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Sajith Kariyawasam <sa...@wso2.com>.
Hi Imesh,
I have done following,
* Update deployApplication operation in Autoscaler service to have
application policy as an argument, instead of deployment policy. WSDLs ,
stubs and Rest API is also updated
* Removed activeByDefault from NetworkPartitionBean and updating utility
methods used for object conversion accordingly.
Now working on,
* Persisting application policy and retrieving the same to check for
active partitions
* Moving Cloudcontroller client operations to CloudControllerServiceClient
Thanks,
Sajith
On Wed, Feb 18, 2015 at 12:18 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Great work Raj! Thanks for the update!
>
> FYI: When you are doing changes please try to avoid any code clean ups in
> this branch beacause it would be difficult for us to merge back to master
> branch.
>
> Thanks
>
> On Tue, Feb 17, 2015 at 9:38 PM, Rajkumar Rajaratnam <ra...@wso2.com>
> wrote:
>
>> Hi Imesh,
>>
>> I have done the followings as part of the effort in this modification.
>>
>> - implemented network partition management logic in CC and updated
>> relevant rest APIs and Service Clients
>> - implemented proper deployment policy validation
>> - fixed authorization action in some rest APIs
>>
>> Network partition management and deployment policy management are now
>> working end-to-end with proper validations. Refer [1] for more detail on
>> this.
>>
>> I am now looking into the changes needs to be done at Autoscaler. Will
>> update the progress on this thread.
>>
>> 1. [Discuss] Deployment policy needs to be validated
>>
>> Thanks.
>>
>> On Tue, Feb 17, 2015 at 8:32 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Raj/Sajith,
>>>
>>> Appreciate if you can provide an update on the progress we have made so
>>> far with this modification.
>>>
>>> Thanks
>>>
>>> On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Shaheed,
>>>>
>>>> Please find comments inline:
>>>>
>>>> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
>>>> shahhaqu@cisco.com> wrote:
>>>>
>>>>> OK, I think we are close. In the following reply, I am only
>>>>> concerned with the users view, not any Stratos internal concepts or names.
>>>>>
>>>>>
>>>>>
>>>>> I define an “application instance” to be something which is created in
>>>>> response to combining an application.json (which contains references to
>>>>> named deployment policies, one per subscribableInfo) with a set of
>>>>> deployment policies which match the references. These deployment policies
>>>>> will have been preloaded into Stratos.
>>>>>
>>>>>
>>>>>
>>>> Thanks for the explanation! Yes I completely agree with your view on
>>>> this, we will need to expose an application instance id to the user when we
>>>> introduce application templates.
>>>>
>>>>
>>>>> As you say “we cannot switch deployment policies of an application
>>>>> once it is deployed. However if needed we can create a new application with
>>>>> a new set of deployment policies”. So to avoid doubt…
>>>>>
>>>>> · An application instance must, by necessity, take a snapshot
>>>>> of all the policies referred to as the instance is created. Not doing so
>>>>> would cause confusion if the deployment policies are later updated.
>>>>>
>>>> +1 Yes AFAIK this functionality is not there at the moment, we will add
>>>> it.
>>>>
>>>>> o Note: this does not preclude later having the ability to modify
>>>>> the snapshot (e.g. min/max instance values and so on).
>>>>>
>>>> Yes, as I mentioned in the previous response, I also would like to have
>>>> the ability to update deployment and autoscaling policies with/without
>>>> affecting deployed applications.
>>>>
>>>>> o I assume the same snapshotting is needed for the autoscaling
>>>>> policies.
>>>>>
>>>> Yes indeed, autoscaling policies also need to be snapshotted.
>>>>
>>>>> o This does imply that it has to be possible to “show” the current
>>>>> state of the application and its snapshotted policies for debugging
>>>>> purposes etc.
>>>>>
>>>> +1
>>>>
>>>>> · After the instance is deployed, the deployment (and
>>>>> autoscaling) policies may be changed without affecting the existing
>>>>> instance.
>>>>>
>>>> Yes, I would like to have the capability to either apply changes to
>>>> deployed applications or not to apply them. If so users could use this
>>>> feature as they wish.
>>>>
>>>> Thanks,
>>>> Imesh
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Rajkumar Rajaratnam
>> Committer & PMC Member, Apache Stratos
>> Software Engineer, WSO2
>>
>> Mobile : +94777568639
>> Blog : rajkumarr.com
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Great work Raj! Thanks for the update!
FYI: When you are doing changes please try to avoid any code clean ups in
this branch beacause it would be difficult for us to merge back to master
branch.
Thanks
On Tue, Feb 17, 2015 at 9:38 PM, Rajkumar Rajaratnam <ra...@wso2.com>
wrote:
> Hi Imesh,
>
> I have done the followings as part of the effort in this modification.
>
> - implemented network partition management logic in CC and updated
> relevant rest APIs and Service Clients
> - implemented proper deployment policy validation
> - fixed authorization action in some rest APIs
>
> Network partition management and deployment policy management are now
> working end-to-end with proper validations. Refer [1] for more detail on
> this.
>
> I am now looking into the changes needs to be done at Autoscaler. Will
> update the progress on this thread.
>
> 1. [Discuss] Deployment policy needs to be validated
>
> Thanks.
>
> On Tue, Feb 17, 2015 at 8:32 PM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Raj/Sajith,
>>
>> Appreciate if you can provide an update on the progress we have made so
>> far with this modification.
>>
>> Thanks
>>
>> On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Shaheed,
>>>
>>> Please find comments inline:
>>>
>>> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
>>> shahhaqu@cisco.com> wrote:
>>>
>>>> OK, I think we are close. In the following reply, I am only concerned
>>>> with the users view, not any Stratos internal concepts or names.
>>>>
>>>>
>>>>
>>>> I define an “application instance” to be something which is created in
>>>> response to combining an application.json (which contains references to
>>>> named deployment policies, one per subscribableInfo) with a set of
>>>> deployment policies which match the references. These deployment policies
>>>> will have been preloaded into Stratos.
>>>>
>>>>
>>>>
>>> Thanks for the explanation! Yes I completely agree with your view on
>>> this, we will need to expose an application instance id to the user when we
>>> introduce application templates.
>>>
>>>
>>>> As you say “we cannot switch deployment policies of an application
>>>> once it is deployed. However if needed we can create a new application with
>>>> a new set of deployment policies”. So to avoid doubt…
>>>>
>>>> · An application instance must, by necessity, take a snapshot
>>>> of all the policies referred to as the instance is created. Not doing so
>>>> would cause confusion if the deployment policies are later updated.
>>>>
>>> +1 Yes AFAIK this functionality is not there at the moment, we will add
>>> it.
>>>
>>>> o Note: this does not preclude later having the ability to modify
>>>> the snapshot (e.g. min/max instance values and so on).
>>>>
>>> Yes, as I mentioned in the previous response, I also would like to have
>>> the ability to update deployment and autoscaling policies with/without
>>> affecting deployed applications.
>>>
>>>> o I assume the same snapshotting is needed for the autoscaling
>>>> policies.
>>>>
>>> Yes indeed, autoscaling policies also need to be snapshotted.
>>>
>>>> o This does imply that it has to be possible to “show” the current
>>>> state of the application and its snapshotted policies for debugging
>>>> purposes etc.
>>>>
>>> +1
>>>
>>>> · After the instance is deployed, the deployment (and
>>>> autoscaling) policies may be changed without affecting the existing
>>>> instance.
>>>>
>>> Yes, I would like to have the capability to either apply changes to
>>> deployed applications or not to apply them. If so users could use this
>>> feature as they wish.
>>>
>>> Thanks,
>>> Imesh
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Rajkumar Rajaratnam <ra...@wso2.com>.
Hi Imesh,
I have done the followings as part of the effort in this modification.
- implemented network partition management logic in CC and updated
relevant rest APIs and Service Clients
- implemented proper deployment policy validation
- fixed authorization action in some rest APIs
Network partition management and deployment policy management are now
working end-to-end with proper validations. Refer [1] for more detail on
this.
I am now looking into the changes needs to be done at Autoscaler. Will
update the progress on this thread.
1. [Discuss] Deployment policy needs to be validated
Thanks.
On Tue, Feb 17, 2015 at 8:32 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Raj/Sajith,
>
> Appreciate if you can provide an update on the progress we have made so
> far with this modification.
>
> Thanks
>
> On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> Hi Shaheed,
>>
>> Please find comments inline:
>>
>> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
>> shahhaqu@cisco.com> wrote:
>>
>>> OK, I think we are close. In the following reply, I am only concerned
>>> with the users view, not any Stratos internal concepts or names.
>>>
>>>
>>>
>>> I define an “application instance” to be something which is created in
>>> response to combining an application.json (which contains references to
>>> named deployment policies, one per subscribableInfo) with a set of
>>> deployment policies which match the references. These deployment policies
>>> will have been preloaded into Stratos.
>>>
>>>
>>>
>> Thanks for the explanation! Yes I completely agree with your view on
>> this, we will need to expose an application instance id to the user when we
>> introduce application templates.
>>
>>
>>> As you say “we cannot switch deployment policies of an application
>>> once it is deployed. However if needed we can create a new application with
>>> a new set of deployment policies”. So to avoid doubt…
>>>
>>> · An application instance must, by necessity, take a snapshot of
>>> all the policies referred to as the instance is created. Not doing so would
>>> cause confusion if the deployment policies are later updated.
>>>
>> +1 Yes AFAIK this functionality is not there at the moment, we will add
>> it.
>>
>>> o Note: this does not preclude later having the ability to modify
>>> the snapshot (e.g. min/max instance values and so on).
>>>
>> Yes, as I mentioned in the previous response, I also would like to have
>> the ability to update deployment and autoscaling policies with/without
>> affecting deployed applications.
>>
>>> o I assume the same snapshotting is needed for the autoscaling
>>> policies.
>>>
>> Yes indeed, autoscaling policies also need to be snapshotted.
>>
>>> o This does imply that it has to be possible to “show” the current
>>> state of the application and its snapshotted policies for debugging
>>> purposes etc.
>>>
>> +1
>>
>>> · After the instance is deployed, the deployment (and
>>> autoscaling) policies may be changed without affecting the existing
>>> instance.
>>>
>> Yes, I would like to have the capability to either apply changes to
>> deployed applications or not to apply them. If so users could use this
>> feature as they wish.
>>
>> Thanks,
>> Imesh
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2
Mobile : +94777568639
Blog : rajkumarr.com
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Raj/Sajith,
Appreciate if you can provide an update on the progress we have made so far
with this modification.
Thanks
On Sun, Feb 15, 2015 at 10:40 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Shaheed,
>
> Please find comments inline:
>
> On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
> shahhaqu@cisco.com> wrote:
>
>> OK, I think we are close. In the following reply, I am only concerned
>> with the users view, not any Stratos internal concepts or names.
>>
>>
>>
>> I define an “application instance” to be something which is created in
>> response to combining an application.json (which contains references to
>> named deployment policies, one per subscribableInfo) with a set of
>> deployment policies which match the references. These deployment policies
>> will have been preloaded into Stratos.
>>
>>
>>
> Thanks for the explanation! Yes I completely agree with your view on this,
> we will need to expose an application instance id to the user when we
> introduce application templates.
>
>
>> As you say “we cannot switch deployment policies of an application once
>> it is deployed. However if needed we can create a new application with a
>> new set of deployment policies”. So to avoid doubt…
>>
>> · An application instance must, by necessity, take a snapshot of
>> all the policies referred to as the instance is created. Not doing so would
>> cause confusion if the deployment policies are later updated.
>>
> +1 Yes AFAIK this functionality is not there at the moment, we will add
> it.
>
>> o Note: this does not preclude later having the ability to modify the
>> snapshot (e.g. min/max instance values and so on).
>>
> Yes, as I mentioned in the previous response, I also would like to have
> the ability to update deployment and autoscaling policies with/without
> affecting deployed applications.
>
>> o I assume the same snapshotting is needed for the autoscaling
>> policies.
>>
> Yes indeed, autoscaling policies also need to be snapshotted.
>
>> o This does imply that it has to be possible to “show” the current
>> state of the application and its snapshotted policies for debugging
>> purposes etc.
>>
> +1
>
>> · After the instance is deployed, the deployment (and
>> autoscaling) policies may be changed without affecting the existing
>> instance.
>>
> Yes, I would like to have the capability to either apply changes to
> deployed applications or not to apply them. If so users could use this
> feature as they wish.
>
> Thanks,
> Imesh
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shaheed,
Please find comments inline:
On Sun, Feb 15, 2015 at 8:03 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> OK, I think we are close. In the following reply, I am only concerned
> with the users view, not any Stratos internal concepts or names.
>
>
>
> I define an “application instance” to be something which is created in
> response to combining an application.json (which contains references to
> named deployment policies, one per subscribableInfo) with a set of
> deployment policies which match the references. These deployment policies
> will have been preloaded into Stratos.
>
>
>
Thanks for the explanation! Yes I completely agree with your view on this,
we will need to expose an application instance id to the user when we
introduce application templates.
> As you say “we cannot switch deployment policies of an application once
> it is deployed. However if needed we can create a new application with a
> new set of deployment policies”. So to avoid doubt…
>
> · An application instance must, by necessity, take a snapshot of
> all the policies referred to as the instance is created. Not doing so would
> cause confusion if the deployment policies are later updated.
>
+1 Yes AFAIK this functionality is not there at the moment, we will add it.
> o Note: this does not preclude later having the ability to modify the
> snapshot (e.g. min/max instance values and so on).
>
Yes, as I mentioned in the previous response, I also would like to have the
ability to update deployment and autoscaling policies with/without
affecting deployed applications.
> o I assume the same snapshotting is needed for the autoscaling
> policies.
>
Yes indeed, autoscaling policies also need to be snapshotted.
> o This does imply that it has to be possible to “show” the current
> state of the application and its snapshotted policies for debugging
> purposes etc.
>
+1
> · After the instance is deployed, the deployment (and
> autoscaling) policies may be changed without affecting the existing
> instance.
>
Yes, I would like to have the capability to either apply changes to
deployed applications or not to apply them. If so users could use this
feature as they wish.
Thanks,
Imesh
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
OK, I think we are close. In the following reply, I am only concerned with the users view, not any Stratos internal concepts or names.
I define an “application instance” to be something which is created in response to combining an application.json (which contains references to named deployment policies, one per subscribableInfo) with a set of deployment policies which match the references. These deployment policies will have been preloaded into Stratos.
As you say “we cannot switch deployment policies of an application once it is deployed. However if needed we can create a new application with a new set of deployment policies”. So to avoid doubt…
· An application instance must, by necessity, take a snapshot of all the policies referred to as the instance is created. Not doing so would cause confusion if the deployment policies are later updated.
o Note: this does not preclude later having the ability to modify the snapshot (e.g. min/max instance values and so on).
o I assume the same snapshotting is needed for the autoscaling policies.
o This does imply that it has to be possible to “show” the current state of the application and its snapshotted policies for debugging purposes etc.
· After the instance is deployed, the deployment (and autoscaling) policies may be changed without affecting the existing instance.
Is that correct?
Thanks, Shaheed
P.S. Do send the .jsons when you have them.
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 15 February 2015 03:52
To: Shaheedur Haque (shahhaqu); dev
Subject: Re: 4.1 deployment policy questions
Hi Shaheed,
On Sun, Feb 15, 2015 at 12:09 AM, Shaheedur Haque (shahhaqu) <sh...@cisco.com>> wrote:
Imesh, Gayan,
I look forward to the updated JSON samples; they will no doubt help reduce confusion.
Yes we will send this ASAP.
Just to comment briefly on the replies you provided. The thing I don’t understand is how you intend the “Application deployment policy (Which is pass with the application deployment)” to work over time:
• Let’s say that on Monday, I define a deployment policy with network partitions A, B and C. I can see that I could use different application deployment policies to turn A or B or C on-and-off and use that to deploy the application (for example) once just to A, and then a second time to B + C. (That seems like a weird use case to me, but if you have a need for it, that is fine).
Since an application is similar to a subscription in 4.0.0, we cannot switch deployment policies of an application once it is deployed. However if needed we can create a new application with a new set of deployment policies.
• Now we get to Friday, and I have just taken a contract with D to use their resources in addition to A, B and C. My service must continue to run uninterrupted on A, B and C even as I take advantage of D. (That seems a more likely use case to me).
Now what is the sequence of steps?
Yes this is possible but it is still not implemented. We could update a deployment policy in runtime and add the new network partition to it. Thereafter we need to decide whether to apply this change to all the running applications or some specific ones. Depending on the decision, a new API method can be exposed to apply a change in a deployment policy to selected set of applications using it.
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shaheed,
On Sun, Feb 15, 2015 at 12:09 AM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> Imesh, Gayan,
>
>
>
> I look forward to the updated JSON samples; they will no doubt help reduce
> confusion.
>
>
>
Yes we will send this ASAP.
> Just to comment briefly on the replies you provided. The thing I don’t
> understand is how you intend the “Application deployment policy (Which is
> pass with the application deployment)” to work over time:
>
>
>
> · Let’s say that on Monday, I define a deployment policy with
> network partitions A, B and C. I can see that I could use different
> application deployment policies to turn A or B or C on-and-off and use that
> to deploy the application (for example) once just to A, and then a second
> time to B + C. (That seems like a weird use case to me, but if you have a
> need for it, that is fine).
>
Since an application is similar to a subscription in 4.0.0, we cannot
switch deployment policies of an application once it is deployed. However
if needed we can create a new application with a new set of deployment
policies.
> · Now we get to Friday, and I have just taken a contract with D
> to use their resources in addition to A, B and C. My service must continue
> to run uninterrupted on A, B and C even as I take advantage of D. (That
> seems a more likely use case to me).
>
>
>
Now what is the sequence of steps?
>
>
>
Yes this is possible but it is still not implemented. We could update a
deployment policy in runtime and add the new network partition to it.
Thereafter we need to decide whether to apply this change to all the
running applications or some specific ones. Depending on the decision, a
new API method can be exposed to apply a change in a deployment policy to
selected set of applications using it.
>
> Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
Imesh, Gayan,
I look forward to the updated JSON samples; they will no doubt help reduce confusion.
Just to comment briefly on the replies you provided. The thing I don’t understand is how you intend the “Application deployment policy(Which is pass with the application deployment)” to work over time:
· Let’s say that on Monday, I define a deployment policy with network partitions A, B and C. I can see that I could use different application deployment policies to turn A or B or C on-and-off and use that to deploy the application (for example) once just to A, and then a second time to B + C. (That seems like a weird use case to me, but if you have a need for it, that is fine).
· Now we get to Friday, and I have just taken a contract with D to use their resources in addition to A, B and C. My service must continue to run uninterrupted on A, B and C even as I take advantage of D. (That seems a more likely use case to me).
Now what is the sequence of steps?
Thanks, Shaheed
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 13 February 2015 11:39
To: dev; Shaheedur Haque (shahhaqu)
Subject: Re: 4.1 deployment policy questions
Hi Shaheed,
Please find comments inline:
On Fri, Feb 13, 2015 at 3:27 PM, Shaheedur Haque (shahhaqu) <sh...@cisco.com>> wrote:
Thanks, I must have missed this thread before. CIL…but remember that I am talking conceptually only as I don’t know the implementation.
From: Imesh Gunaratne [mailto:imesh@apache.org<ma...@apache.org>]
Sent: 13 February 2015 09:28
To: dev; Shaheedur Haque (shahhaqu)
Subject: Re: 4.1 deployment policy questions
[Adding Shaheed]
On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org>> wrote:
I agree with Udara. We could take the following approach to improve the efficiency:
1. Implement deployment policy management logic and service methods in CC without affecting any other modules
2. Implement dpeloyment policy management REST API methods, still this would not affect any other modules
[srh] I take it this means that deployment policies will be loaded ahead of time, just like in 4.0? That would be great, but then I don’t understand how your concept of multiple application instances will work:
Application instance is an internal entity which is used for replicating an application in multiple network partitions. If an application is using cartridges on multiple network partitions, application policy can be configured or netwrk partition usage. This would say whether the application needs to be deployed on all network partitions at once or do cloud bursting.
- Each subscribableInfo points to one deploymentPolicy, so there might be more
than one deploymentPolicy for the application as a whole.
Yes that's correct.
- According to the *current* 4.1 workflow, the curl command specifies the name
for the application and a single –b .json argument, therefore the –b must *contain*
all the named deploymentPolicy’s.
- Different application instances must have different deployment policies, so they
Must use .json files with different content but the same deploymentPolicy names.
No, what we mean by application instance is bit different in the current design since there is no application template concept. Aplication instance is not an instance of an application template. Rather it is an instance of the application in a network partition.
This contradicts having globally defined deployment polciies loaded ahead of time, or did I miss something?
I think not, since an application in 4.1.0 is similar to a subscription in 4.0.0, deployment policies are defined at application creation time.
3. Provide API method details to allow UI and CLI to be updated in parallel
4. Update application bean and definition to refer deployment policy ids, this can be done in parallel
5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy classes in Autoscaler
6. Rename previous Deployment Policy class in Autoscaler to Application Policy and add the new definition
[srh] Please clarify what these “new definitions” are. Please realise that it is simply not possible to review things which are changing without the details of the proposal.
Yes sure I will prepare a document with new artifacts and share more information on that.
Thanks, Shaheed
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shaheed,
Please find comments inline:
On Fri, Feb 13, 2015 at 3:27 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> Thanks, I must have missed this thread before. CIL…but remember that I
> am talking conceptually only as I don’t know the implementation.
>
>
>
> *From:* Imesh Gunaratne [mailto:imesh@apache.org]
> *Sent:* 13 February 2015 09:28
> *To:* dev; Shaheedur Haque (shahhaqu)
> *Subject:* Re: 4.1 deployment policy questions
>
>
>
> [Adding Shaheed]
>
>
>
> On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
> I agree with Udara. We could take the following approach to improve the
> efficiency:
>
>
>
> 1. Implement deployment policy management logic and service methods in CC
> without affecting any other modules
>
> 2. Implement dpeloyment policy management REST API methods, still this
> would not affect any other modules
>
>
>
> [srh] I take it this means that deployment policies will be loaded ahead
> of time, just like in 4.0? That would be great, but then I don’t understand
> how your concept of multiple application instances will work:
>
>
>
Application instance is an internal entity which is used for replicating an
application in multiple network partitions. If an application is using
cartridges on multiple network partitions, application policy can be
configured or netwrk partition usage. This would say whether the
application needs to be deployed on all network partitions at once or do
cloud bursting.
> - Each subscribableInfo points to one deploymentPolicy, so there might
> be more
>
> than one deploymentPolicy for the application as a whole.
>
Yes that's correct.
>
>
> - According to the **current** 4.1 workflow, the curl command specifies
> the name
>
> for the application and a single –b .json argument, therefore the –b must *
> *contain**
>
> all the named deploymentPolicy’s.
>
>
>
> - Different application instances must have different deployment policies,
> so they
>
> Must use .json files with different content but the same deploymentPolicy
> names.
>
No, what we mean by application instance is bit different in the current
design since there is no application template concept. Aplication instance
is not an instance of an application template. Rather it is an instance of
the application in a network partition.
>
>
> This contradicts having globally defined deployment polciies loaded ahead
> of time, or did I miss something?
>
I think not, since an application in 4.1.0 is similar to a subscription in
4.0.0, deployment policies are defined at application creation time.
>
>
> 3. Provide API method details to allow UI and CLI to be updated in parallel
>
> 4. Update application bean and definition to refer deployment policy ids,
> this can be done in parallel
>
> 5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy
> classes in Autoscaler
>
> 6. Rename previous Deployment Policy class in Autoscaler to Application
> Policy and add the new definition
>
>
>
> [srh] Please clarify what these “new definitions” are. Please realise that
> it is simply not possible to review things which are changing without the
> details of the proposal.
>
Yes sure I will prepare a document with new artifacts and share more
information on that.
>
>
> Thanks, Shaheed
>
>
> Thanks
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Gayan Gunarathne <ga...@wso2.com>.
Hi Shaheedur,
Please find my comments on blue.
Thanks,
Gayan
On Fri, Feb 13, 2015 at 3:27 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> Thanks, I must have missed this thread before. CIL…but remember that I
> am talking conceptually only as I don’t know the implementation.
>
>
>
> *From:* Imesh Gunaratne [mailto:imesh@apache.org]
> *Sent:* 13 February 2015 09:28
> *To:* dev; Shaheedur Haque (shahhaqu)
> *Subject:* Re: 4.1 deployment policy questions
>
>
>
> [Adding Shaheed]
>
>
>
> On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
> I agree with Udara. We could take the following approach to improve the
> efficiency:
>
>
>
> 1. Implement deployment policy management logic and service methods in CC
> without affecting any other modules
>
> 2. Implement dpeloyment policy management REST API methods, still this
> would not affect any other modules
>
>
>
> [srh] I take it this means that deployment policies will be loaded ahead
> of time, just like in 4.0? That would be great, but then I don’t understand
> how your concept of multiple application instances will work:
>
>
>
> - Each subscribableInfo points to one deploymentPolicy, so there might be
> more
>
> than one deploymentPolicy for the application as a whole.
>
>
>
> - According to the **current** 4.1 workflow, the curl command specifies
> the name
>
> for the application and a single –b .json argument, therefore the –b must *
> *contain**
>
> all the named deploymentPolicy’s.
>
>
>
> - Different application instances must have different deployment policies,
> so they
>
> Must use .json files with different content but the same deploymentPolicy
> names.
>
>
>
> This contradicts having globally defined deployment polciies loaded ahead
> of time, or did I miss something?
>
[Gayan] Yeah. We are define the deploy policy in globally. In the cartridge
level we are define which deployment policy we are using for the cartridge
under subscribeInfo.
When the application deployment we can specify what is the network
partitions which we are used with the application with the following json.
{
"networkPartition":[
{
"id":"network-partition-1",
"activeByDefault":"true"
},
{
"id":"network-partition-2",
"activeByDefault":"false"
}
]
}
Here I think we need a network partition validation with the deployment
policies which we are using in the application.(Defined in all the
cartridges of the application)
Deployment policy with "activeByDefault=true" is the deployment policy
which we used to deploy application.
As we define the deploy policy in globally we can share the deploy policy
among the different applications.
>
>
>
> 3. Provide API method details to allow UI and CLI to be updated in parallel
>
> 4. Update application bean and definition to refer deployment policy ids,
> this can be done in parallel
>
> 5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy
> classes in Autoscaler
>
> 6. Rename previous Deployment Policy class in Autoscaler to Application
> Policy and add the new definition
>
>
>
> [srh] Please clarify what these “new definitions” are. Please realise that
> it is simply not possible to review things which are changing without the
> details of the proposal.
>
>
>
> Thanks, Shaheed
>
Deployment Policy definition(Globally available)
{
"id": "deployment-policy-2",
"networkPartition": [
{
"id": "network-partition-1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "partition-1",
"max": 5
}
]
}
]
}
Application deployment policy(Which is pass with the application deployment)
{
"networkPartition":[
{
"id":"network-partition-1",
"activeByDefault":"true"
},
{
"id":"network-partition-2",
"activeByDefault":"false"
}
]
}
>
> 7. Fix references to previous Deployment Policy in Autoscaler
>
>
>
> Thanks
>
>
>
> On Thu, Feb 12, 2015 at 11:20 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
> Hi,
>
> I started working on new branch. However it has lot of compilation
> failures. I started fixing few, but there are many. It is true that we are
> changing/adding some functionality which it is OK to functions not to work
> properly. But we can avoid compilation issues IMO. We can change back end
> first and then fix Rest API or some way.
>
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
>
>
>
>
> --
>
> Imesh Gunaratne
>
>
>
> Technical Lead, WSO2
>
> Committer & PMC Member, Apache Stratos
>
--
Gayan Gunarathne
Technical Lead
WSO2 Inc. (http://wso2.com)
email : gayang@wso2.com | mobile : +94 766819985
RE: 4.1 deployment policy questions
Posted by "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>.
Thanks, I must have missed this thread before. CIL…but remember that I am talking conceptually only as I don’t know the implementation.
From: Imesh Gunaratne [mailto:imesh@apache.org]
Sent: 13 February 2015 09:28
To: dev; Shaheedur Haque (shahhaqu)
Subject: Re: 4.1 deployment policy questions
[Adding Shaheed]
On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org>> wrote:
I agree with Udara. We could take the following approach to improve the efficiency:
1. Implement deployment policy management logic and service methods in CC without affecting any other modules
2. Implement dpeloyment policy management REST API methods, still this would not affect any other modules
[srh] I take it this means that deployment policies will be loaded ahead of time, just like in 4.0? That would be great, but then I don’t understand how your concept of multiple application instances will work:
- Each subscribableInfo points to one deploymentPolicy, so there might be more
than one deploymentPolicy for the application as a whole.
- According to the *current* 4.1 workflow, the curl command specifies the name
for the application and a single –b .json argument, therefore the –b must *contain*
all the named deploymentPolicy’s.
- Different application instances must have different deployment policies, so they
Must use .json files with different content but the same deploymentPolicy names.
This contradicts having globally defined deployment polciies loaded ahead of time, or did I miss something?
3. Provide API method details to allow UI and CLI to be updated in parallel
4. Update application bean and definition to refer deployment policy ids, this can be done in parallel
5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy classes in Autoscaler
6. Rename previous Deployment Policy class in Autoscaler to Application Policy and add the new definition
[srh] Please clarify what these “new definitions” are. Please realise that it is simply not possible to review things which are changing without the details of the proposal.
Thanks, Shaheed
7. Fix references to previous Deployment Policy in Autoscaler
Thanks
On Thu, Feb 12, 2015 at 11:20 PM, Udara Liyanage <ud...@wso2.com>> wrote:
Hi,
I started working on new branch. However it has lot of compilation failures. I started fixing few, but there are many. It is true that we are changing/adding some functionality which it is OK to functions not to work properly. But we can avoid compilation issues IMO. We can change back end first and then fix Rest API or some way.
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
[Adding Shaheed]
On Fri, Feb 13, 2015 at 8:31 AM, Imesh Gunaratne <im...@apache.org> wrote:
> I agree with Udara. We could take the following approach to improve the
> efficiency:
>
> 1. Implement deployment policy management logic and service methods in CC
> without affecting any other modules
> 2. Implement dpeloyment policy management REST API methods, still this
> would not affect any other modules
> 3. Provide API method details to allow UI and CLI to be updated in parallel
> 4. Update application bean and definition to refer deployment policy ids,
> this can be done in parallel
> 5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy
> classes in Autoscaler
> 6. Rename previous Deployment Policy class in Autoscaler to Application
> Policy and add the new definition
> 7. Fix references to previous Deployment Policy in Autoscaler
>
> Thanks
>
> On Thu, Feb 12, 2015 at 11:20 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
>> Hi,
>>
>> I started working on new branch. However it has lot of compilation
>> failures. I started fixing few, but there are many. It is true that we are
>> changing/adding some functionality which it is OK to functions not to work
>> properly. But we can avoid compilation issues IMO. We can change back end
>> first and then fix Rest API or some way.
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
I agree with Udara. We could take the following approach to improve the
efficiency:
1. Implement deployment policy management logic and service methods in CC
without affecting any other modules
2. Implement dpeloyment policy management REST API methods, still this
would not affect any other modules
3. Provide API method details to allow UI and CLI to be updated in parallel
4. Update application bean and definition to refer deployment policy ids,
this can be done in parallel
5. Once 1, 2 and 4 are done, remove Application Policy and Chid Policy
classes in Autoscaler
6. Rename previous Deployment Policy class in Autoscaler to Application
Policy and add the new definition
7. Fix references to previous Deployment Policy in Autoscaler
Thanks
On Thu, Feb 12, 2015 at 11:20 PM, Udara Liyanage <ud...@wso2.com> wrote:
> Hi,
>
> I started working on new branch. However it has lot of compilation
> failures. I started fixing few, but there are many. It is true that we are
> changing/adding some functionality which it is OK to functions not to work
> properly. But we can avoid compilation issues IMO. We can change back end
> first and then fix Rest API or some way.
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Udara Liyanage <ud...@wso2.com>.
Hi,
I started working on new branch. However it has lot of compilation
failures. I started fixing few, but there are many. It is true that we are
changing/adding some functionality which it is OK to functions not to work
properly. But we can avoid compilation issues IMO. We can change back end
first and then fix Rest API or some way.
Re: 4.1 deployment policy questions
Posted by Gayan Gunarathne <ga...@wso2.com>.
Added new branch 4.1.0-beta-deployment-policy-fix. Please use this branch
for the modifications of Deploymenet Policy Management.
Thanks,
Gayan
On Thu, Feb 12, 2015 at 10:15 AM, Gayan Gunarathne <ga...@wso2.com> wrote:
> +1 for have a new branch for the modifications.
> I will start to work on introduce new REST API methods for managing
> deployment policies.
>
> Thanks,
> Gayan
>
> On Thu, Feb 12, 2015 at 10:06 AM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> Thanks Lakmal! Since I was working on grouping issues already, I can
>> continue with that. Appreciate if others can start the above tasks.
>>
>> Thanks
>>
>> On Thu, Feb 12, 2015 at 8:13 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Thursday, February 12, 2015, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> I would like to propose to do this modification in a new branch
>>>> (4.1.0-beta-deployment-policy-fix). If so we could fix the grouping
>>>> functional issues and PCA issues in the master branch and we can work in
>>>> parallel. WDYT?
>>>>
>>>
>>> +1 Imesh, we can work parallel since backend implementation not going to
>>> change
>>>
>>>
>>>>
>>>> Correction: s/Deploymenet/Deployment/g
>>>>
>>>> Thanks
>>>>
>>>> On Thu, Feb 12, 2015 at 7:42 AM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> Following is a task breakdown for this mofication:
>>>>>
>>>>> *Deploymenet Policy Management:*
>>>>>
>>>>> - Introduce deployment policy management service methods in Cloud
>>>>> Controller (CC). I believe deployment policies should reside in CC because
>>>>> they contain IaaS related information.
>>>>> - Introduce REST API methods for managing deployment policies
>>>>> - Introduce CLI commands for managing deployment policies
>>>>> - Introduce set of pages in the UI for managing deployment policies
>>>>>
>>>>> *Application Creation:*
>>>>>
>>>>> - Change the deployment policy entity/JSON to the following:
>>>>> {
>>>>> "networkPartition":[
>>>>> {
>>>>> "id":"network-partition-1",
>>>>> "partitionAlgo":"one-after-another",
>>>>> "partitions":[
>>>>> {
>>>>> "id":"partition-1",
>>>>> "max":5
>>>>> }
>>>>> ]
>>>>> }
>>>>> ]
>>>>> }
>>>>>
>>>>> - Update application entity/JSON in the REST API and add
>>>>> "deploymentPolicy" attribute to "subscribableInfo" section.
>>>>> - Add "deploymentPolicy" attribute to group entity in application
>>>>> definition JSON.
>>>>>
>>>>> *Application Deployment:*
>>>>>
>>>>> - Introduce a new entity called ApplicationPolicy to be used at the
>>>>> application deployment time:
>>>>> {
>>>>> "networkPartition":[
>>>>> {
>>>>> "id":"network-partition-1",
>>>>> "activeByDefault":"true"
>>>>> },
>>>>> {
>>>>> "id":"network-partition-2",
>>>>> "activeByDefault":"false"
>>>>> }
>>>>> ]
>>>>> }
>>>>> - Update REST API application deployment method to use new Application
>>>>> Policy entity.
>>>>> - Update CLI application deployment command to use the new Application
>>>>> entity.
>>>>> - Update UI application deployment page to use the new Application
>>>>> entity.
>>>>>
>>>>> Above tasks represent the high level changes we need, however there
>>>>> will be more implementation changes for each task.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> Today we had a call on this topic and please find the summary of the
>>>>>> discussion below:
>>>>>>
>>>>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>>>>> context and it was reusable.
>>>>>> - Now deployment policy is in application context and contains
>>>>>> deployment pattens of multiple cartridges.
>>>>>> - As a result the application deployment process has become complex
>>>>>> and backward compatibility with the previous release has been broken.
>>>>>>
>>>>>> - Therefore we can do a slight modification in the current model and
>>>>>> move the deployment policy to the global context:
>>>>>> - If so we will have following entities in the global context:
>>>>>>
>>>>>>
>>>>>> - Then we can construct the application by referring Cartridges,
>>>>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>>>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Now we need to provide an application policy at the application
>>>>>> deployment time to specify application availability in network partitions:
>>>>>> - This would say whether to start the application in all network
>>>>>> partitions or do cloud bursting:
>>>>>>
>>>>>>
>>>>>> - At a later release we can introduce Application Template concept by
>>>>>> extracting subscribable information out from the application:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please add your thoughts on this modification.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>>>>> discuss this before doing any changes.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <
>>>>>>> lakmal@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Shaheed,
>>>>>>>>
>>>>>>>> Will try to explain further but simple and here some workaround
>>>>>>>> solution.
>>>>>>>>
>>>>>>>> Previous release we only subscribe to a single cartridge with given
>>>>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>>>>> a particular deployment.
>>>>>>>>
>>>>>>>> If we come to composite application with multiple cartridges we
>>>>>>>> have to define deployment pattens for each and every cartridge in that
>>>>>>>> composite application. Defining deployment patten, have to use cartridge
>>>>>>>> alias for distinguish deferent cartridges because we can't use cartridge
>>>>>>>> type, some application may have multiple same cartridges and need different
>>>>>>>> deployment pattens.
>>>>>>>>
>>>>>>>> To address particular in your scenario, we can't have two
>>>>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>>>>> solution, I believe we can implement, and which will cover your simple
>>>>>>>> scenario as well.
>>>>>>>>
>>>>>>>> solution :
>>>>>>>>
>>>>>>>> - shall we allow to have global deployment policies (can have
>>>>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>>>>> - and will allow, in the defining the deployment policy time to
>>>>>>>> attached above without defining. (user has both option)
>>>>>>>> - then deploy the application
>>>>>>>>
>>>>>>>> I believed this is what you are looking for
>>>>>>>>
>>>>>>>> Let me explain these global deployment policy concept. We have
>>>>>>>> section call childPolicies which we refer different cartridge alias to
>>>>>>>> define deployment pattens.
>>>>>>>>
>>>>>>>> "childPolicies": [
>>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>> "alias": "mytomcat",
>>>>>>>>
>>>>>>>> "networkPartition": [
>>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>> "id": "network-partition-1",
>>>>>>>>
>>>>>>>> "partitionAlgo": "one-after-another",
>>>>>>>>
>>>>>>>> "partitions": [
>>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>> "id": "partition-1",
>>>>>>>>
>>>>>>>> "max": 5
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> I like to propose, introduce section call globalPolicies which can
>>>>>>>> define global deployment pattens which going to apply for all cartridges
>>>>>>>> defining in that application. If it is single cartridge or not it will use
>>>>>>>> same deployment patten.
>>>>>>>>
>>>>>>>> With this implementation, without changing current design and
>>>>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>>>>> same deployment policies without re defining per application
>>>>>>>> creation/deploy.
>>>>>>>>
>>>>>>>> Please share your thoughts
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>>>>> below:
>>>>>>>>>
>>>>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahhaqu@cisco.com
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>>>>> inverted that cardinality completely.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>>>>> Application SignUp.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>>>>> have significant investment in dynamically generating and
>>>>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Here we deploy an application in the context of Tenant not for
>>>>>>>>> User. Yes in this release it is not possible to share Single-Tenant
>>>>>>>>> applications accross tenants. However each tenant can deploy the same
>>>>>>>>> application with a different deployment policy by using a different
>>>>>>>>> application id.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>>>>> grouping).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>>>>> propose improvements for the next minor release.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Lakmal Warusawithana
>>>>>>>> Vice President, Apache Stratos
>>>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>>>> Mobile : +94714289692
>>>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Imesh Gunaratne
>>>>>>>
>>>>>>> Technical Lead, WSO2
>>>>>>> Committer & PMC Member, Apache Stratos
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Imesh Gunaratne
>>>>>>
>>>>>> Technical Lead, WSO2
>>>>>> Committer & PMC Member, Apache Stratos
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead
> WSO2 Inc. (http://wso2.com)
> email : gayang@wso2.com | mobile : +94 766819985
>
>
--
Gayan Gunarathne
Technical Lead
WSO2 Inc. (http://wso2.com)
email : gayang@wso2.com | mobile : +94 766819985
Re: 4.1 deployment policy questions
Posted by Gayan Gunarathne <ga...@wso2.com>.
+1 for have a new branch for the modifications.
I will start to work on introduce new REST API methods for managing
deployment policies.
Thanks,
Gayan
On Thu, Feb 12, 2015 at 10:06 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Thanks Lakmal! Since I was working on grouping issues already, I can
> continue with that. Appreciate if others can start the above tasks.
>
> Thanks
>
> On Thu, Feb 12, 2015 at 8:13 AM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
>>
>>
>> On Thursday, February 12, 2015, Imesh Gunaratne <im...@apache.org> wrote:
>>
>>> Hi Devs,
>>>
>>> I would like to propose to do this modification in a new branch
>>> (4.1.0-beta-deployment-policy-fix). If so we could fix the grouping
>>> functional issues and PCA issues in the master branch and we can work in
>>> parallel. WDYT?
>>>
>>
>> +1 Imesh, we can work parallel since backend implementation not going to
>> change
>>
>>
>>>
>>> Correction: s/Deploymenet/Deployment/g
>>>
>>> Thanks
>>>
>>> On Thu, Feb 12, 2015 at 7:42 AM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> Following is a task breakdown for this mofication:
>>>>
>>>> *Deploymenet Policy Management:*
>>>>
>>>> - Introduce deployment policy management service methods in Cloud
>>>> Controller (CC). I believe deployment policies should reside in CC because
>>>> they contain IaaS related information.
>>>> - Introduce REST API methods for managing deployment policies
>>>> - Introduce CLI commands for managing deployment policies
>>>> - Introduce set of pages in the UI for managing deployment policies
>>>>
>>>> *Application Creation:*
>>>>
>>>> - Change the deployment policy entity/JSON to the following:
>>>> {
>>>> "networkPartition":[
>>>> {
>>>> "id":"network-partition-1",
>>>> "partitionAlgo":"one-after-another",
>>>> "partitions":[
>>>> {
>>>> "id":"partition-1",
>>>> "max":5
>>>> }
>>>> ]
>>>> }
>>>> ]
>>>> }
>>>>
>>>> - Update application entity/JSON in the REST API and add
>>>> "deploymentPolicy" attribute to "subscribableInfo" section.
>>>> - Add "deploymentPolicy" attribute to group entity in application
>>>> definition JSON.
>>>>
>>>> *Application Deployment:*
>>>>
>>>> - Introduce a new entity called ApplicationPolicy to be used at the
>>>> application deployment time:
>>>> {
>>>> "networkPartition":[
>>>> {
>>>> "id":"network-partition-1",
>>>> "activeByDefault":"true"
>>>> },
>>>> {
>>>> "id":"network-partition-2",
>>>> "activeByDefault":"false"
>>>> }
>>>> ]
>>>> }
>>>> - Update REST API application deployment method to use new Application
>>>> Policy entity.
>>>> - Update CLI application deployment command to use the new Application
>>>> entity.
>>>> - Update UI application deployment page to use the new Application
>>>> entity.
>>>>
>>>> Above tasks represent the high level changes we need, however there
>>>> will be more implementation changes for each task.
>>>>
>>>> Thanks
>>>>
>>>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Devs,
>>>>>
>>>>> Today we had a call on this topic and please find the summary of the
>>>>> discussion below:
>>>>>
>>>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>>>> context and it was reusable.
>>>>> - Now deployment policy is in application context and contains
>>>>> deployment pattens of multiple cartridges.
>>>>> - As a result the application deployment process has become complex
>>>>> and backward compatibility with the previous release has been broken.
>>>>>
>>>>> - Therefore we can do a slight modification in the current model and
>>>>> move the deployment policy to the global context:
>>>>> - If so we will have following entities in the global context:
>>>>>
>>>>>
>>>>> - Then we can construct the application by referring Cartridges,
>>>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>>>
>>>>>
>>>>>
>>>>> - Now we need to provide an application policy at the application
>>>>> deployment time to specify application availability in network partitions:
>>>>> - This would say whether to start the application in all network
>>>>> partitions or do cloud bursting:
>>>>>
>>>>>
>>>>> - At a later release we can introduce Application Template concept by
>>>>> extracting subscribable information out from the application:
>>>>>
>>>>>
>>>>>
>>>>> Please add your thoughts on this modification.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>>>> discuss this before doing any changes.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <
>>>>>> lakmal@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Shaheed,
>>>>>>>
>>>>>>> Will try to explain further but simple and here some workaround
>>>>>>> solution.
>>>>>>>
>>>>>>> Previous release we only subscribe to a single cartridge with given
>>>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>>>> a particular deployment.
>>>>>>>
>>>>>>> If we come to composite application with multiple cartridges we have
>>>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>>>> application may have multiple same cartridges and need different deployment
>>>>>>> pattens.
>>>>>>>
>>>>>>> To address particular in your scenario, we can't have two
>>>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>>>> solution, I believe we can implement, and which will cover your simple
>>>>>>> scenario as well.
>>>>>>>
>>>>>>> solution :
>>>>>>>
>>>>>>> - shall we allow to have global deployment policies (can have
>>>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>>>> - and will allow, in the defining the deployment policy time to
>>>>>>> attached above without defining. (user has both option)
>>>>>>> - then deploy the application
>>>>>>>
>>>>>>> I believed this is what you are looking for
>>>>>>>
>>>>>>> Let me explain these global deployment policy concept. We have
>>>>>>> section call childPolicies which we refer different cartridge alias to
>>>>>>> define deployment pattens.
>>>>>>>
>>>>>>> "childPolicies": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "alias": "mytomcat",
>>>>>>>
>>>>>>> "networkPartition": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "id": "network-partition-1",
>>>>>>>
>>>>>>> "partitionAlgo": "one-after-another",
>>>>>>>
>>>>>>> "partitions": [
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>> "id": "partition-1",
>>>>>>>
>>>>>>> "max": 5
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ]
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> ]
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> I like to propose, introduce section call globalPolicies which can
>>>>>>> define global deployment pattens which going to apply for all cartridges
>>>>>>> defining in that application. If it is single cartridge or not it will use
>>>>>>> same deployment patten.
>>>>>>>
>>>>>>> With this implementation, without changing current design and
>>>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>>>> same deployment policies without re defining per application
>>>>>>> creation/deploy.
>>>>>>>
>>>>>>> Please share your thoughts
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>>>> below:
>>>>>>>>
>>>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>>>> inverted that cardinality completely.
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>>>> Application SignUp.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>>>> have significant investment in dynamically generating and
>>>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Here we deploy an application in the context of Tenant not for
>>>>>>>> User. Yes in this release it is not possible to share Single-Tenant
>>>>>>>> applications accross tenants. However each tenant can deploy the same
>>>>>>>> application with a different deployment policy by using a different
>>>>>>>> application id.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>>>> grouping).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>>>> propose improvements for the next minor release.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lakmal Warusawithana
>>>>>>> Vice President, Apache Stratos
>>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>>> Mobile : +94714289692
>>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Imesh Gunaratne
>>>>>>
>>>>>> Technical Lead, WSO2
>>>>>> Committer & PMC Member, Apache Stratos
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>> --
>> Sent from Gmail Mobile
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Gayan Gunarathne
Technical Lead
WSO2 Inc. (http://wso2.com)
email : gayang@wso2.com | mobile : +94 766819985
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Thanks Lakmal! Since I was working on grouping issues already, I can
continue with that. Appreciate if others can start the above tasks.
Thanks
On Thu, Feb 12, 2015 at 8:13 AM, Lakmal Warusawithana <la...@wso2.com>
wrote:
>
>
> On Thursday, February 12, 2015, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Devs,
>>
>> I would like to propose to do this modification in a new branch
>> (4.1.0-beta-deployment-policy-fix). If so we could fix the grouping
>> functional issues and PCA issues in the master branch and we can work in
>> parallel. WDYT?
>>
>
> +1 Imesh, we can work parallel since backend implementation not going to
> change
>
>
>>
>> Correction: s/Deploymenet/Deployment/g
>>
>> Thanks
>>
>> On Thu, Feb 12, 2015 at 7:42 AM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> Following is a task breakdown for this mofication:
>>>
>>> *Deploymenet Policy Management:*
>>>
>>> - Introduce deployment policy management service methods in Cloud
>>> Controller (CC). I believe deployment policies should reside in CC because
>>> they contain IaaS related information.
>>> - Introduce REST API methods for managing deployment policies
>>> - Introduce CLI commands for managing deployment policies
>>> - Introduce set of pages in the UI for managing deployment policies
>>>
>>> *Application Creation:*
>>>
>>> - Change the deployment policy entity/JSON to the following:
>>> {
>>> "networkPartition":[
>>> {
>>> "id":"network-partition-1",
>>> "partitionAlgo":"one-after-another",
>>> "partitions":[
>>> {
>>> "id":"partition-1",
>>> "max":5
>>> }
>>> ]
>>> }
>>> ]
>>> }
>>>
>>> - Update application entity/JSON in the REST API and add
>>> "deploymentPolicy" attribute to "subscribableInfo" section.
>>> - Add "deploymentPolicy" attribute to group entity in application
>>> definition JSON.
>>>
>>> *Application Deployment:*
>>>
>>> - Introduce a new entity called ApplicationPolicy to be used at the
>>> application deployment time:
>>> {
>>> "networkPartition":[
>>> {
>>> "id":"network-partition-1",
>>> "activeByDefault":"true"
>>> },
>>> {
>>> "id":"network-partition-2",
>>> "activeByDefault":"false"
>>> }
>>> ]
>>> }
>>> - Update REST API application deployment method to use new Application
>>> Policy entity.
>>> - Update CLI application deployment command to use the new Application
>>> entity.
>>> - Update UI application deployment page to use the new Application
>>> entity.
>>>
>>> Above tasks represent the high level changes we need, however there will
>>> be more implementation changes for each task.
>>>
>>> Thanks
>>>
>>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Hi Devs,
>>>>
>>>> Today we had a call on this topic and please find the summary of the
>>>> discussion below:
>>>>
>>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>>> context and it was reusable.
>>>> - Now deployment policy is in application context and contains
>>>> deployment pattens of multiple cartridges.
>>>> - As a result the application deployment process has become complex and
>>>> backward compatibility with the previous release has been broken.
>>>>
>>>> - Therefore we can do a slight modification in the current model and
>>>> move the deployment policy to the global context:
>>>> - If so we will have following entities in the global context:
>>>>
>>>>
>>>> - Then we can construct the application by referring Cartridges,
>>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>>
>>>>
>>>>
>>>> - Now we need to provide an application policy at the application
>>>> deployment time to specify application availability in network partitions:
>>>> - This would say whether to start the application in all network
>>>> partitions or do cloud bursting:
>>>>
>>>>
>>>> - At a later release we can introduce Application Template concept by
>>>> extracting subscribable information out from the application:
>>>>
>>>>
>>>>
>>>> Please add your thoughts on this modification.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>>> discuss this before doing any changes.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lakmal@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi Shaheed,
>>>>>>
>>>>>> Will try to explain further but simple and here some workaround
>>>>>> solution.
>>>>>>
>>>>>> Previous release we only subscribe to a single cartridge with given
>>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>>> a particular deployment.
>>>>>>
>>>>>> If we come to composite application with multiple cartridges we have
>>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>>> application may have multiple same cartridges and need different deployment
>>>>>> pattens.
>>>>>>
>>>>>> To address particular in your scenario, we can't have two
>>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>>> solution, I believe we can implement, and which will cover your simple
>>>>>> scenario as well.
>>>>>>
>>>>>> solution :
>>>>>>
>>>>>> - shall we allow to have global deployment policies (can have
>>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>>> - and will allow, in the defining the deployment policy time to
>>>>>> attached above without defining. (user has both option)
>>>>>> - then deploy the application
>>>>>>
>>>>>> I believed this is what you are looking for
>>>>>>
>>>>>> Let me explain these global deployment policy concept. We have
>>>>>> section call childPolicies which we refer different cartridge alias to
>>>>>> define deployment pattens.
>>>>>>
>>>>>> "childPolicies": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "alias": "mytomcat",
>>>>>>
>>>>>> "networkPartition": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "id": "network-partition-1",
>>>>>>
>>>>>> "partitionAlgo": "one-after-another",
>>>>>>
>>>>>> "partitions": [
>>>>>>
>>>>>> {
>>>>>>
>>>>>> "id": "partition-1",
>>>>>>
>>>>>> "max": 5
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> }
>>>>>>
>>>>>> ]
>>>>>>
>>>>>> }
>>>>>>
>>>>>> I like to propose, introduce section call globalPolicies which can
>>>>>> define global deployment pattens which going to apply for all cartridges
>>>>>> defining in that application. If it is single cartridge or not it will use
>>>>>> same deployment patten.
>>>>>>
>>>>>> With this implementation, without changing current design and
>>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>>> same deployment policies without re defining per application
>>>>>> creation/deploy.
>>>>>>
>>>>>> Please share your thoughts
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>>> below:
>>>>>>>
>>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>>> inverted that cardinality completely.
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>>> Application SignUp.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>>> have significant investment in dynamically generating and
>>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>>>> different deployment policy by using a different application id.
>>>>>>>
>>>>>>>
>>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>>> grouping).
>>>>>>>>
>>>>>>>
>>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>>> propose improvements for the next minor release.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lakmal Warusawithana
>>>>>> Vice President, Apache Stratos
>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>> Mobile : +94714289692
>>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
> --
> Sent from Gmail Mobile
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Lakmal Warusawithana <la...@wso2.com>.
On Thursday, February 12, 2015, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Devs,
>
> I would like to propose to do this modification in a new branch
> (4.1.0-beta-deployment-policy-fix). If so we could fix the grouping
> functional issues and PCA issues in the master branch and we can work in
> parallel. WDYT?
>
+1 Imesh, we can work parallel since backend implementation not going to
change
>
> Correction: s/Deploymenet/Deployment/g
>
> Thanks
>
> On Thu, Feb 12, 2015 at 7:42 AM, Imesh Gunaratne <imesh@apache.org
> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>
>> Hi Devs,
>>
>> Following is a task breakdown for this mofication:
>>
>> *Deploymenet Policy Management:*
>>
>> - Introduce deployment policy management service methods in Cloud
>> Controller (CC). I believe deployment policies should reside in CC because
>> they contain IaaS related information.
>> - Introduce REST API methods for managing deployment policies
>> - Introduce CLI commands for managing deployment policies
>> - Introduce set of pages in the UI for managing deployment policies
>>
>> *Application Creation:*
>>
>> - Change the deployment policy entity/JSON to the following:
>> {
>> "networkPartition":[
>> {
>> "id":"network-partition-1",
>> "partitionAlgo":"one-after-another",
>> "partitions":[
>> {
>> "id":"partition-1",
>> "max":5
>> }
>> ]
>> }
>> ]
>> }
>>
>> - Update application entity/JSON in the REST API and add
>> "deploymentPolicy" attribute to "subscribableInfo" section.
>> - Add "deploymentPolicy" attribute to group entity in application
>> definition JSON.
>>
>> *Application Deployment:*
>>
>> - Introduce a new entity called ApplicationPolicy to be used at the
>> application deployment time:
>> {
>> "networkPartition":[
>> {
>> "id":"network-partition-1",
>> "activeByDefault":"true"
>> },
>> {
>> "id":"network-partition-2",
>> "activeByDefault":"false"
>> }
>> ]
>> }
>> - Update REST API application deployment method to use new Application
>> Policy entity.
>> - Update CLI application deployment command to use the new Application
>> entity.
>> - Update UI application deployment page to use the new Application entity.
>>
>> Above tasks represent the high level changes we need, however there will
>> be more implementation changes for each task.
>>
>> Thanks
>>
>> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <imesh@apache.org
>> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>>
>>> Hi Devs,
>>>
>>> Today we had a call on this topic and please find the summary of the
>>> discussion below:
>>>
>>> - In Stratos 4.0.0 the deployment policy was defined in the global
>>> context and it was reusable.
>>> - Now deployment policy is in application context and contains
>>> deployment pattens of multiple cartridges.
>>> - As a result the application deployment process has become complex and
>>> backward compatibility with the previous release has been broken.
>>>
>>> - Therefore we can do a slight modification in the current model and
>>> move the deployment policy to the global context:
>>> - If so we will have following entities in the global context:
>>>
>>>
>>> - Then we can construct the application by referring Cartridges,
>>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>>
>>>
>>>
>>> - Now we need to provide an application policy at the application
>>> deployment time to specify application availability in network partitions:
>>> - This would say whether to start the application in all network
>>> partitions or do cloud bursting:
>>>
>>>
>>> - At a later release we can introduce Application Template concept by
>>> extracting subscribable information out from the application:
>>>
>>>
>>>
>>> Please add your thoughts on this modification.
>>>
>>> Thanks
>>>
>>>
>>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <imesh@apache.org
>>> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>>>
>>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>>> discuss this before doing any changes.
>>>>
>>>> Thanks
>>>>
>>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <lakmal@wso2.com
>>>> <javascript:_e(%7B%7D,'cvml','lakmal@wso2.com');>> wrote:
>>>>
>>>>> Hi Shaheed,
>>>>>
>>>>> Will try to explain further but simple and here some workaround
>>>>> solution.
>>>>>
>>>>> Previous release we only subscribe to a single cartridge with given
>>>>> deployment policy. We have re used defined deployment policy. The main
>>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>>> a particular deployment.
>>>>>
>>>>> If we come to composite application with multiple cartridges we have
>>>>> to define deployment pattens for each and every cartridge in that composite
>>>>> application. Defining deployment patten, have to use cartridge alias for
>>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>>> application may have multiple same cartridges and need different deployment
>>>>> pattens.
>>>>>
>>>>> To address particular in your scenario, we can't have two
>>>>> implementation whether is singleton or a composite group. Here one possible
>>>>> solution, I believe we can implement, and which will cover your simple
>>>>> scenario as well.
>>>>>
>>>>> solution :
>>>>>
>>>>> - shall we allow to have global deployment policies (can have
>>>>> many) which can pre deploy/add. (I will explain what is these global one)
>>>>> - and will allow, in the defining the deployment policy time to
>>>>> attached above without defining. (user has both option)
>>>>> - then deploy the application
>>>>>
>>>>> I believed this is what you are looking for
>>>>>
>>>>> Let me explain these global deployment policy concept. We have section
>>>>> call childPolicies which we refer different cartridge alias to define
>>>>> deployment pattens.
>>>>>
>>>>> "childPolicies": [
>>>>>
>>>>> {
>>>>>
>>>>> "alias": "mytomcat",
>>>>>
>>>>> "networkPartition": [
>>>>>
>>>>> {
>>>>>
>>>>> "id": "network-partition-1",
>>>>>
>>>>> "partitionAlgo": "one-after-another",
>>>>>
>>>>> "partitions": [
>>>>>
>>>>> {
>>>>>
>>>>> "id": "partition-1",
>>>>>
>>>>> "max": 5
>>>>>
>>>>> }
>>>>>
>>>>> ]
>>>>>
>>>>> }
>>>>>
>>>>> ]
>>>>>
>>>>> }
>>>>>
>>>>> I like to propose, introduce section call globalPolicies which can
>>>>> define global deployment pattens which going to apply for all cartridges
>>>>> defining in that application. If it is single cartridge or not it will use
>>>>> same deployment patten.
>>>>>
>>>>> With this implementation, without changing current design and
>>>>> implementation we can achieved simple singleton scenario with attaching
>>>>> same deployment policies without re defining per application
>>>>> creation/deploy.
>>>>>
>>>>> Please share your thoughts
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <imesh@apache.org
>>>>> <javascript:_e(%7B%7D,'cvml','imesh@apache.org');>> wrote:
>>>>>
>>>>>> Yes, I agree with your concerns Shaheed! Please find my comments
>>>>>> below:
>>>>>>
>>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <shahhaqu@cisco.com
>>>>>> <javascript:_e(%7B%7D,'cvml','shahhaqu@cisco.com');>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OK, I get that argument. But consider that multiple subscriptions
>>>>>>> all using a single deployment spec was the previous model, and now we have
>>>>>>> inverted that cardinality completely.
>>>>>>>
>>>>>>
>>>>>>>
>>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>>> the reason I have explained in the previous response. May be we can improve
>>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>>> Application SignUp.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> To my knowledge, in addition to the generic automation of single
>>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>>> have significant investment in dynamically generating and
>>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>>> cardinality w.r.t. deployment policies.
>>>>>>>
>>>>>>
>>>>>>>
>>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>>> different deployment policy by using a different application id.
>>>>>>
>>>>>>
>>>>>>> I'm all in favour of progress, and change where unavoidable, but
>>>>>>> this seems to gratuitously change the model for the bulk of singleton
>>>>>>> cartridge users in favour of the currently non-existent grouping users.
>>>>>>> (And yes, I am aware of the paradox that we are VERY interested in the
>>>>>>> grouping).
>>>>>>>
>>>>>>
>>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>>> propose improvements for the next minor release.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Vice President, Apache Stratos
>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Sent from Gmail Mobile
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Devs,
I would like to propose to do this modification in a new branch
(4.1.0-beta-deployment-policy-fix). If so we could fix the grouping
functional issues and PCA issues in the master branch and we can work in
parallel. WDYT?
Correction: s/Deploymenet/Deployment/g
Thanks
On Thu, Feb 12, 2015 at 7:42 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Devs,
>
> Following is a task breakdown for this mofication:
>
> *Deploymenet Policy Management:*
>
> - Introduce deployment policy management service methods in Cloud
> Controller (CC). I believe deployment policies should reside in CC because
> they contain IaaS related information.
> - Introduce REST API methods for managing deployment policies
> - Introduce CLI commands for managing deployment policies
> - Introduce set of pages in the UI for managing deployment policies
>
> *Application Creation:*
>
> - Change the deployment policy entity/JSON to the following:
> {
> "networkPartition":[
> {
> "id":"network-partition-1",
> "partitionAlgo":"one-after-another",
> "partitions":[
> {
> "id":"partition-1",
> "max":5
> }
> ]
> }
> ]
> }
>
> - Update application entity/JSON in the REST API and add
> "deploymentPolicy" attribute to "subscribableInfo" section.
> - Add "deploymentPolicy" attribute to group entity in application
> definition JSON.
>
> *Application Deployment:*
>
> - Introduce a new entity called ApplicationPolicy to be used at the
> application deployment time:
> {
> "networkPartition":[
> {
> "id":"network-partition-1",
> "activeByDefault":"true"
> },
> {
> "id":"network-partition-2",
> "activeByDefault":"false"
> }
> ]
> }
> - Update REST API application deployment method to use new Application
> Policy entity.
> - Update CLI application deployment command to use the new Application
> entity.
> - Update UI application deployment page to use the new Application entity.
>
> Above tasks represent the high level changes we need, however there will
> be more implementation changes for each task.
>
> Thanks
>
> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Devs,
>>
>> Today we had a call on this topic and please find the summary of the
>> discussion below:
>>
>> - In Stratos 4.0.0 the deployment policy was defined in the global
>> context and it was reusable.
>> - Now deployment policy is in application context and contains deployment
>> pattens of multiple cartridges.
>> - As a result the application deployment process has become complex and
>> backward compatibility with the previous release has been broken.
>>
>> - Therefore we can do a slight modification in the current model and move
>> the deployment policy to the global context:
>> - If so we will have following entities in the global context:
>>
>>
>> - Then we can construct the application by referring Cartridges,
>> Cartridge Groups, Autoscaling Policies and Deployment Policies:
>> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>>
>>
>>
>> - Now we need to provide an application policy at the application
>> deployment time to specify application availability in network partitions:
>> - This would say whether to start the application in all network
>> partitions or do cloud bursting:
>>
>>
>> - At a later release we can introduce Application Template concept by
>> extracting subscribable information out from the application:
>>
>>
>>
>> Please add your thoughts on this modification.
>>
>> Thanks
>>
>>
>> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>>> discuss this before doing any changes.
>>>
>>> Thanks
>>>
>>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
>>> wrote:
>>>
>>>> Hi Shaheed,
>>>>
>>>> Will try to explain further but simple and here some workaround
>>>> solution.
>>>>
>>>> Previous release we only subscribe to a single cartridge with given
>>>> deployment policy. We have re used defined deployment policy. The main
>>>> reason that we cloud do, single cartridge has single deployment patten for
>>>> a particular deployment.
>>>>
>>>> If we come to composite application with multiple cartridges we have to
>>>> define deployment pattens for each and every cartridge in that composite
>>>> application. Defining deployment patten, have to use cartridge alias for
>>>> distinguish deferent cartridges because we can't use cartridge type, some
>>>> application may have multiple same cartridges and need different deployment
>>>> pattens.
>>>>
>>>> To address particular in your scenario, we can't have two
>>>> implementation whether is singleton or a composite group. Here one possible
>>>> solution, I believe we can implement, and which will cover your simple
>>>> scenario as well.
>>>>
>>>> solution :
>>>>
>>>> - shall we allow to have global deployment policies (can have many)
>>>> which can pre deploy/add. (I will explain what is these global one)
>>>> - and will allow, in the defining the deployment policy time to
>>>> attached above without defining. (user has both option)
>>>> - then deploy the application
>>>>
>>>> I believed this is what you are looking for
>>>>
>>>> Let me explain these global deployment policy concept. We have section
>>>> call childPolicies which we refer different cartridge alias to define
>>>> deployment pattens.
>>>>
>>>> "childPolicies": [
>>>>
>>>> {
>>>>
>>>> "alias": "mytomcat",
>>>>
>>>> "networkPartition": [
>>>>
>>>> {
>>>>
>>>> "id": "network-partition-1",
>>>>
>>>> "partitionAlgo": "one-after-another",
>>>>
>>>> "partitions": [
>>>>
>>>> {
>>>>
>>>> "id": "partition-1",
>>>>
>>>> "max": 5
>>>>
>>>> }
>>>>
>>>> ]
>>>>
>>>> }
>>>>
>>>> ]
>>>>
>>>> }
>>>>
>>>> I like to propose, introduce section call globalPolicies which can
>>>> define global deployment pattens which going to apply for all cartridges
>>>> defining in that application. If it is single cartridge or not it will use
>>>> same deployment patten.
>>>>
>>>> With this implementation, without changing current design and
>>>> implementation we can achieved simple singleton scenario with attaching
>>>> same deployment policies without re defining per application
>>>> creation/deploy.
>>>>
>>>> Please share your thoughts
>>>>
>>>>
>>>>
>>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>>>>
>>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> OK, I get that argument. But consider that multiple subscriptions all
>>>>>> using a single deployment spec was the previous model, and now we have
>>>>>> inverted that cardinality completely.
>>>>>>
>>>>>
>>>>>>
>>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>>> applications but not for Single-Tenant applications. This is again due to
>>>>> the reason I have explained in the previous response. May be we can improve
>>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>>> Application SignUp.
>>>>>
>>>>>>
>>>>>>
>>>>> To my knowledge, in addition to the generic automation of single
>>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>>> have significant investment in dynamically generating and
>>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>>> all these usages will now require substantive rework to manage the opposite
>>>>>> cardinality w.r.t. deployment policies.
>>>>>>
>>>>>
>>>>>>
>>>>> Here we deploy an application in the context of Tenant not for User.
>>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>>> accross tenants. However each tenant can deploy the same application with a
>>>>> different deployment policy by using a different application id.
>>>>>
>>>>>
>>>>>> I'm all in favour of progress, and change where unavoidable, but this
>>>>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>>>>> users in favour of the currently non-existent grouping users. (And yes, I
>>>>>> am aware of the paradox that we are VERY interested in the grouping).
>>>>>>
>>>>>
>>>>> Yes I agree, may be we can have a separate discussion on this and
>>>>> propose improvements for the next minor release.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Vice President, Apache Stratos
>>>> Director - Cloud Architecture; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Devs,
Following is a task breakdown for this mofication:
*Deploymenet Policy Management:*
- Introduce deployment policy management service methods in Cloud
Controller (CC). I believe deployment policies should reside in CC because
they contain IaaS related information.
- Introduce REST API methods for managing deployment policies
- Introduce CLI commands for managing deployment policies
- Introduce set of pages in the UI for managing deployment policies
*Application Creation:*
- Change the deployment policy entity/JSON to the following:
{
"networkPartition":[
{
"id":"network-partition-1",
"partitionAlgo":"one-after-another",
"partitions":[
{
"id":"partition-1",
"max":5
}
]
}
]
}
- Update application entity/JSON in the REST API and add "deploymentPolicy"
attribute to "subscribableInfo" section.
- Add "deploymentPolicy" attribute to group entity in application
definition JSON.
*Application Deployment:*
- Introduce a new entity called ApplicationPolicy to be used at the
application deployment time:
{
"networkPartition":[
{
"id":"network-partition-1",
"activeByDefault":"true"
},
{
"id":"network-partition-2",
"activeByDefault":"false"
}
]
}
- Update REST API application deployment method to use new Application
Policy entity.
- Update CLI application deployment command to use the new Application
entity.
- Update UI application deployment page to use the new Application entity.
Above tasks represent the high level changes we need, however there will be
more implementation changes for each task.
Thanks
On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Devs,
>
> Today we had a call on this topic and please find the summary of the
> discussion below:
>
> - In Stratos 4.0.0 the deployment policy was defined in the global context
> and it was reusable.
> - Now deployment policy is in application context and contains deployment
> pattens of multiple cartridges.
> - As a result the application deployment process has become complex and
> backward compatibility with the previous release has been broken.
>
> - Therefore we can do a slight modification in the current model and move
> the deployment policy to the global context:
> - If so we will have following entities in the global context:
>
>
> - Then we can construct the application by referring Cartridges, Cartridge
> Groups, Autoscaling Policies and Deployment Policies:
> - Either Cartridges or Cartridge Groups can refer Deployment Policies:
>
>
>
> - Now we need to provide an application policy at the application
> deployment time to specify application availability in network partitions:
> - This would say whether to start the application in all network
> partitions or do cloud bursting:
>
>
> - At a later release we can introduce Application Template concept by
> extracting subscribable information out from the application:
>
>
>
> Please add your thoughts on this modification.
>
> Thanks
>
>
> On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> +1 for the idea Lakmal! Yes I think it is better to have a call and
>> discuss this before doing any changes.
>>
>> Thanks
>>
>> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>> Hi Shaheed,
>>>
>>> Will try to explain further but simple and here some workaround solution.
>>>
>>> Previous release we only subscribe to a single cartridge with given
>>> deployment policy. We have re used defined deployment policy. The main
>>> reason that we cloud do, single cartridge has single deployment patten for
>>> a particular deployment.
>>>
>>> If we come to composite application with multiple cartridges we have to
>>> define deployment pattens for each and every cartridge in that composite
>>> application. Defining deployment patten, have to use cartridge alias for
>>> distinguish deferent cartridges because we can't use cartridge type, some
>>> application may have multiple same cartridges and need different deployment
>>> pattens.
>>>
>>> To address particular in your scenario, we can't have two implementation
>>> whether is singleton or a composite group. Here one possible solution, I
>>> believe we can implement, and which will cover your simple scenario as well.
>>>
>>> solution :
>>>
>>> - shall we allow to have global deployment policies (can have many)
>>> which can pre deploy/add. (I will explain what is these global one)
>>> - and will allow, in the defining the deployment policy time to
>>> attached above without defining. (user has both option)
>>> - then deploy the application
>>>
>>> I believed this is what you are looking for
>>>
>>> Let me explain these global deployment policy concept. We have section
>>> call childPolicies which we refer different cartridge alias to define
>>> deployment pattens.
>>>
>>> "childPolicies": [
>>>
>>> {
>>>
>>> "alias": "mytomcat",
>>>
>>> "networkPartition": [
>>>
>>> {
>>>
>>> "id": "network-partition-1",
>>>
>>> "partitionAlgo": "one-after-another",
>>>
>>> "partitions": [
>>>
>>> {
>>>
>>> "id": "partition-1",
>>>
>>> "max": 5
>>>
>>> }
>>>
>>> ]
>>>
>>> }
>>>
>>> ]
>>>
>>> }
>>>
>>> I like to propose, introduce section call globalPolicies which can
>>> define global deployment pattens which going to apply for all cartridges
>>> defining in that application. If it is single cartridge or not it will use
>>> same deployment patten.
>>>
>>> With this implementation, without changing current design and
>>> implementation we can achieved simple singleton scenario with attaching
>>> same deployment policies without re defining per application
>>> creation/deploy.
>>>
>>> Please share your thoughts
>>>
>>>
>>>
>>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>>>
>>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> OK, I get that argument. But consider that multiple subscriptions all
>>>>> using a single deployment spec was the previous model, and now we have
>>>>> inverted that cardinality completely.
>>>>>
>>>>
>>>>>
>>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>>> applications but not for Single-Tenant applications. This is again due to
>>>> the reason I have explained in the previous response. May be we can improve
>>>> this in a minor release. BTW the term Subscription has now being changed to
>>>> Application SignUp.
>>>>
>>>>>
>>>>>
>>>> To my knowledge, in addition to the generic automation of single
>>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>>> have significant investment in dynamically generating and
>>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>>> all these usages will now require substantive rework to manage the opposite
>>>>> cardinality w.r.t. deployment policies.
>>>>>
>>>>
>>>>>
>>>> Here we deploy an application in the context of Tenant not for User.
>>>> Yes in this release it is not possible to share Single-Tenant applications
>>>> accross tenants. However each tenant can deploy the same application with a
>>>> different deployment policy by using a different application id.
>>>>
>>>>
>>>>> I'm all in favour of progress, and change where unavoidable, but this
>>>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>>>> users in favour of the currently non-existent grouping users. (And yes, I
>>>>> am aware of the paradox that we are VERY interested in the grouping).
>>>>>
>>>>
>>>> Yes I agree, may be we can have a separate discussion on this and
>>>> propose improvements for the next minor release.
>>>>
>>>> Thanks
>>>>
>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Vice President, Apache Stratos
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Devs,
Today we had a call on this topic and please find the summary of the
discussion below:
- In Stratos 4.0.0 the deployment policy was defined in the global context
and it was reusable.
- Now deployment policy is in application context and contains deployment
pattens of multiple cartridges.
- As a result the application deployment process has become complex and
backward compatibility with the previous release has been broken.
- Therefore we can do a slight modification in the current model and move
the deployment policy to the global context:
- If so we will have following entities in the global context:
- Then we can construct the application by referring Cartridges, Cartridge
Groups, Autoscaling Policies and Deployment Policies:
- Either Cartridges or Cartridge Groups can refer Deployment Policies:
- Now we need to provide an application policy at the application
deployment time to specify application availability in network partitions:
- This would say whether to start the application in all network partitions
or do cloud bursting:
- At a later release we can introduce Application Template concept by
extracting subscribable information out from the application:
Please add your thoughts on this modification.
Thanks
On Wed, Feb 11, 2015 at 12:29 PM, Imesh Gunaratne <im...@apache.org> wrote:
> +1 for the idea Lakmal! Yes I think it is better to have a call and
> discuss this before doing any changes.
>
> Thanks
>
> On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
> wrote:
>
>> Hi Shaheed,
>>
>> Will try to explain further but simple and here some workaround solution.
>>
>> Previous release we only subscribe to a single cartridge with given
>> deployment policy. We have re used defined deployment policy. The main
>> reason that we cloud do, single cartridge has single deployment patten for
>> a particular deployment.
>>
>> If we come to composite application with multiple cartridges we have to
>> define deployment pattens for each and every cartridge in that composite
>> application. Defining deployment patten, have to use cartridge alias for
>> distinguish deferent cartridges because we can't use cartridge type, some
>> application may have multiple same cartridges and need different deployment
>> pattens.
>>
>> To address particular in your scenario, we can't have two implementation
>> whether is singleton or a composite group. Here one possible solution, I
>> believe we can implement, and which will cover your simple scenario as well.
>>
>> solution :
>>
>> - shall we allow to have global deployment policies (can have many)
>> which can pre deploy/add. (I will explain what is these global one)
>> - and will allow, in the defining the deployment policy time to
>> attached above without defining. (user has both option)
>> - then deploy the application
>>
>> I believed this is what you are looking for
>>
>> Let me explain these global deployment policy concept. We have section
>> call childPolicies which we refer different cartridge alias to define
>> deployment pattens.
>>
>> "childPolicies": [
>>
>> {
>>
>> "alias": "mytomcat",
>>
>> "networkPartition": [
>>
>> {
>>
>> "id": "network-partition-1",
>>
>> "partitionAlgo": "one-after-another",
>>
>> "partitions": [
>>
>> {
>>
>> "id": "partition-1",
>>
>> "max": 5
>>
>> }
>>
>> ]
>>
>> }
>>
>> ]
>>
>> }
>>
>> I like to propose, introduce section call globalPolicies which can define
>> global deployment pattens which going to apply for all cartridges defining
>> in that application. If it is single cartridge or not it will use same
>> deployment patten.
>>
>> With this implementation, without changing current design and
>> implementation we can achieved simple singleton scenario with attaching
>> same deployment policies without re defining per application
>> creation/deploy.
>>
>> Please share your thoughts
>>
>>
>>
>> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>>
>>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> OK, I get that argument. But consider that multiple subscriptions all
>>>> using a single deployment spec was the previous model, and now we have
>>>> inverted that cardinality completely.
>>>>
>>>
>>>>
>>> Not exactly, we support multiple subscriptions for Multi-Tenant
>>> applications but not for Single-Tenant applications. This is again due to
>>> the reason I have explained in the previous response. May be we can improve
>>> this in a minor release. BTW the term Subscription has now being changed to
>>> Application SignUp.
>>>
>>>>
>>>>
>>> To my knowledge, in addition to the generic automation of single
>>>> cartridge subscriptions we provided our Stratos users, at least two users
>>>> have significant investment in dynamically generating and
>>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>>> single application cartridges is necessary work needed to get to 4.1, but
>>>> all these usages will now require substantive rework to manage the opposite
>>>> cardinality w.r.t. deployment policies.
>>>>
>>>
>>>>
>>> Here we deploy an application in the context of Tenant not for User. Yes
>>> in this release it is not possible to share Single-Tenant applications
>>> accross tenants. However each tenant can deploy the same application with a
>>> different deployment policy by using a different application id.
>>>
>>>
>>>> I'm all in favour of progress, and change where unavoidable, but this
>>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>>> users in favour of the currently non-existent grouping users. (And yes, I
>>>> am aware of the paradox that we are VERY interested in the grouping).
>>>>
>>>
>>> Yes I agree, may be we can have a separate discussion on this and
>>> propose improvements for the next minor release.
>>>
>>> Thanks
>>>
>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Vice President, Apache Stratos
>> Director - Cloud Architecture; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
+1 for the idea Lakmal! Yes I think it is better to have a call and discuss
this before doing any changes.
Thanks
On Wed, Feb 11, 2015 at 8:05 AM, Lakmal Warusawithana <la...@wso2.com>
wrote:
> Hi Shaheed,
>
> Will try to explain further but simple and here some workaround solution.
>
> Previous release we only subscribe to a single cartridge with given
> deployment policy. We have re used defined deployment policy. The main
> reason that we cloud do, single cartridge has single deployment patten for
> a particular deployment.
>
> If we come to composite application with multiple cartridges we have to
> define deployment pattens for each and every cartridge in that composite
> application. Defining deployment patten, have to use cartridge alias for
> distinguish deferent cartridges because we can't use cartridge type, some
> application may have multiple same cartridges and need different deployment
> pattens.
>
> To address particular in your scenario, we can't have two implementation
> whether is singleton or a composite group. Here one possible solution, I
> believe we can implement, and which will cover your simple scenario as well.
>
> solution :
>
> - shall we allow to have global deployment policies (can have many)
> which can pre deploy/add. (I will explain what is these global one)
> - and will allow, in the defining the deployment policy time to
> attached above without defining. (user has both option)
> - then deploy the application
>
> I believed this is what you are looking for
>
> Let me explain these global deployment policy concept. We have section
> call childPolicies which we refer different cartridge alias to define
> deployment pattens.
>
> "childPolicies": [
>
> {
>
> "alias": "mytomcat",
>
> "networkPartition": [
>
> {
>
> "id": "network-partition-1",
>
> "partitionAlgo": "one-after-another",
>
> "partitions": [
>
> {
>
> "id": "partition-1",
>
> "max": 5
>
> }
>
> ]
>
> }
>
> ]
>
> }
>
> I like to propose, introduce section call globalPolicies which can define
> global deployment pattens which going to apply for all cartridges defining
> in that application. If it is single cartridge or not it will use same
> deployment patten.
>
> With this implementation, without changing current design and
> implementation we can achieved simple singleton scenario with attaching
> same deployment policies without re defining per application
> creation/deploy.
>
> Please share your thoughts
>
>
>
> On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Yes, I agree with your concerns Shaheed! Please find my comments below:
>>
>> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com>
>> wrote:
>>
>>>
>>>
>>> OK, I get that argument. But consider that multiple subscriptions all
>>> using a single deployment spec was the previous model, and now we have
>>> inverted that cardinality completely.
>>>
>>
>>>
>> Not exactly, we support multiple subscriptions for Multi-Tenant
>> applications but not for Single-Tenant applications. This is again due to
>> the reason I have explained in the previous response. May be we can improve
>> this in a minor release. BTW the term Subscription has now being changed to
>> Application SignUp.
>>
>>>
>>>
>> To my knowledge, in addition to the generic automation of single
>>> cartridge subscriptions we provided our Stratos users, at least two users
>>> have significant investment in dynamically generating and
>>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>>> single application cartridges is necessary work needed to get to 4.1, but
>>> all these usages will now require substantive rework to manage the opposite
>>> cardinality w.r.t. deployment policies.
>>>
>>
>>>
>> Here we deploy an application in the context of Tenant not for User. Yes
>> in this release it is not possible to share Single-Tenant applications
>> accross tenants. However each tenant can deploy the same application with a
>> different deployment policy by using a different application id.
>>
>>
>>> I'm all in favour of progress, and change where unavoidable, but this
>>> seems to gratuitously change the model for the bulk of singleton cartridge
>>> users in favour of the currently non-existent grouping users. (And yes, I
>>> am aware of the paradox that we are VERY interested in the grouping).
>>>
>>
>> Yes I agree, may be we can have a separate discussion on this and propose
>> improvements for the next minor release.
>>
>> Thanks
>>
>
>
>
> --
> Lakmal Warusawithana
> Vice President, Apache Stratos
> Director - Cloud Architecture; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: 4.1 deployment policy questions
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Shaheed,
Will try to explain further but simple and here some workaround solution.
Previous release we only subscribe to a single cartridge with given
deployment policy. We have re used defined deployment policy. The main
reason that we cloud do, single cartridge has single deployment patten for
a particular deployment.
If we come to composite application with multiple cartridges we have to
define deployment pattens for each and every cartridge in that composite
application. Defining deployment patten, have to use cartridge alias for
distinguish deferent cartridges because we can't use cartridge type, some
application may have multiple same cartridges and need different deployment
pattens.
To address particular in your scenario, we can't have two implementation
whether is singleton or a composite group. Here one possible solution, I
believe we can implement, and which will cover your simple scenario as well.
solution :
- shall we allow to have global deployment policies (can have many)
which can pre deploy/add. (I will explain what is these global one)
- and will allow, in the defining the deployment policy time to attached
above without defining. (user has both option)
- then deploy the application
I believed this is what you are looking for
Let me explain these global deployment policy concept. We have section call
childPolicies which we refer different cartridge alias to define deployment
pattens.
"childPolicies": [
{
"alias": "mytomcat",
"networkPartition": [
{
"id": "network-partition-1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "partition-1",
"max": 5
}
]
}
]
}
I like to propose, introduce section call globalPolicies which can define
global deployment pattens which going to apply for all cartridges defining
in that application. If it is single cartridge or not it will use same
deployment patten.
With this implementation, without changing current design and
implementation we can achieved simple singleton scenario with attaching
same deployment policies without re defining per application
creation/deploy.
Please share your thoughts
On Wed, Feb 11, 2015 at 7:21 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Yes, I agree with your concerns Shaheed! Please find my comments below:
>
> On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com> wrote:
>
>>
>>
>> OK, I get that argument. But consider that multiple subscriptions all
>> using a single deployment spec was the previous model, and now we have
>> inverted that cardinality completely.
>>
>
>>
> Not exactly, we support multiple subscriptions for Multi-Tenant
> applications but not for Single-Tenant applications. This is again due to
> the reason I have explained in the previous response. May be we can improve
> this in a minor release. BTW the term Subscription has now being changed to
> Application SignUp.
>
>>
>>
> To my knowledge, in addition to the generic automation of single cartridge
>> subscriptions we provided our Stratos users, at least two users have
>> significant investment in dynamically generating and
>> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
>> single application cartridges is necessary work needed to get to 4.1, but
>> all these usages will now require substantive rework to manage the opposite
>> cardinality w.r.t. deployment policies.
>>
>
>>
> Here we deploy an application in the context of Tenant not for User. Yes
> in this release it is not possible to share Single-Tenant applications
> accross tenants. However each tenant can deploy the same application with a
> different deployment policy by using a different application id.
>
>
>> I'm all in favour of progress, and change where unavoidable, but this
>> seems to gratuitously change the model for the bulk of singleton cartridge
>> users in favour of the currently non-existent grouping users. (And yes, I
>> am aware of the paradox that we are VERY interested in the grouping).
>>
>
> Yes I agree, may be we can have a separate discussion on this and propose
> improvements for the next minor release.
>
> Thanks
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Yes, I agree with your concerns Shaheed! Please find my comments below:
On Wed, Feb 11, 2015 at 4:13 AM, Shaheed Haque <sh...@cisco.com> wrote:
>
>
> OK, I get that argument. But consider that multiple subscriptions all
> using a single deployment spec was the previous model, and now we have
> inverted that cardinality completely.
>
>
Not exactly, we support multiple subscriptions for Multi-Tenant
applications but not for Single-Tenant applications. This is again due to
the reason I have explained in the previous response. May be we can improve
this in a minor release. BTW the term Subscription has now being changed to
Application SignUp.
>
>
To my knowledge, in addition to the generic automation of single cartridge
> subscriptions we provided our Stratos users, at least two users have
> significant investment in dynamically generating and
> subscribing/unsubscribing cartridges on-the-fly. Converting these to use
> single application cartridges is necessary work needed to get to 4.1, but
> all these usages will now require substantive rework to manage the opposite
> cardinality w.r.t. deployment policies.
>
>
Here we deploy an application in the context of Tenant not for User. Yes in
this release it is not possible to share Single-Tenant applications accross
tenants. However each tenant can deploy the same application with a
different deployment policy by using a different application id.
> I'm all in favour of progress, and change where unavoidable, but this
> seems to gratuitously change the model for the bulk of singleton cartridge
> users in favour of the currently non-existent grouping users. (And yes, I
> am aware of the paradox that we are VERY interested in the grouping).
>
Yes I agree, may be we can have a separate discussion on this and propose
improvements for the next minor release.
Thanks
Re: 4.1 deployment policy questions
Posted by Shaheed Haque <sh...@cisco.com>.
OK, I get that argument. But consider that multiple subscriptions all using a single
deployment spec was the previous model, and now we have inverted that cardinality
completely.
To my knowledge, in addition to the generic automation of single cartridge
subscriptions we provided our Stratos users, at least two users have significant
investment in dynamically generating and subscribing/unsubscribing cartridges on-
the-fly. Converting these to use single application cartridges is necessary work needed
to get to 4.1, but all these usages will now require substantive rework to manage the
opposite cardinality w.r.t. deployment policies.
I'm all in favour of progress, and change where unavoidable, but this seems to
gratuitously change the model for the bulk of singleton cartridge users in favour of the
currently non-existent grouping users. (And yes, I am aware of the paradox that we
are VERY interested in the grouping).
On Wednesday 11 February 2015 00:32:31 Udara Liyanage wrote:
An application definition defines cartridges and dependencies among the cartridges,
and few other stuff such as autoscaling etc. Deployment policy defines how to deploy
an application. Ideally application is defined once, but it should be able to deploy
differently by using different deployment policy.Let's consider a use case. A user can
define an php-mysql application. Then it should be able to deploy in single region, or
across regions etc by using different deployment policies.
On 10 Feb 2015 23:46, "Shaheedur Haque (shahhaqu)" <shahhaqu@cisco.com[1]>
wrote:
Hi,
I am just looking at the new group/application mode, for 4.1, and I noticed that the
subscribablesInfo no longer contains a deploymentPolicy. For example, from [1]:
“applicationId: “*single_group_v1*”,
…
"subscribableInfo": {
"alias": "tom2group6",
"autoscalingPolicy": "autoscale-policy-1",
"artifactRepository":{
…
}
}
Instead, what seems to have happened is that the deployment policy point back to
the application, from [2]:
"applicationId": "*single_group_v1*",
"applicationPolicy": {
"networkPartition": [
This is surely backwards. Why do deployment policies name the application? Why can’t
a single deployment policy be referenced by multiple applications (just like before)?
Also, what is confusing is that the samples are themselves inconsistent. For example,
the first one I looked at [3] seems to be missing *any* binding between the
application .json and the deployment .json; are these samples actually supposed to
work, or are they perhaps a work in progress only?
Any insights would be most welcome.
Thanks, Shaheed
[1] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json[2]
[2] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json[3]
[3] https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts[4]
--------
[1] mailto:shahhaqu@cisco.com
[2] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json
[3] https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json
[4] https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts
Re: 4.1 deployment policy questions
Posted by Udara Liyanage <ud...@wso2.com>.
An application definition defines cartridges and dependencies among the
cartridges, and few other stuff such as autoscaling etc. Deployment policy
defines how to deploy an application. Ideally application is defined once,
but it should be able to deploy differently by using different deployment
policy.
Let's consider a use case. A user can define an php-mysql application. Then
it should be able to deploy in single region, or across regions etc by
using different deployment policies.
On 10 Feb 2015 23:46, "Shaheedur Haque (shahhaqu)" <sh...@cisco.com>
wrote:
> Hi,
>
>
>
> I am just looking at the new group/application mode, for 4.1, and I
> noticed that the subscribablesInfo no longer contains a deploymentPolicy.
> For example, from [1]:
>
>
>
> “applicationId: “*single_group_v1*”,
>
> …
>
> "subscribableInfo": {
>
> "alias": "tom2group6",
>
> "autoscalingPolicy": "autoscale-policy-1",
>
> "artifactRepository":{
>
> …
>
> }
>
> }
>
> Instead, what seems to have happened is that the deployment policy point
> back to the application, from [2]:
>
>
>
> "applicationId": "*single_group_v1*",
>
> "applicationPolicy": {
>
> "networkPartition": [
>
> This is surely backwards. Why do deployment policies name the
> application? Why can’t a single deployment policy be referenced by multiple
> applications (just like before)?
>
>
>
> Also, what is confusing is that the samples are themselves inconsistent.
> For example, the first one I looked at [3] seems to be missing *any*
> binding between the application .json and the deployment .json; are these
> samples actually supposed to work, or are they perhaps a work in progress
> only?
>
>
>
> Any insights would be most welcome.
>
>
>
> Thanks, Shaheed
>
>
>
> [1]
> https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/application.json
>
> [2]
> https://github.com/apache/stratos/blob/master/samples/applications/single-group-v1/artifacts/openstack/deployment-policy.json
>
> [3]
> https://github.com/apache/stratos/tree/master/samples/applications/single-cartridge/artifacts
>
>
>
>
>
Re: 4.1 deployment policy questions
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Shadeed,
A good question!
On Tue, Feb 10, 2015 at 11:45 PM, Shaheedur Haque (shahhaqu) <
shahhaqu@cisco.com> wrote:
> Hi,
>
> This is surely backwards. Why do deployment policies name the
> application? Why can’t a single deployment policy be referenced by multiple
> applications (just like before)?
>
> In the current release it is not possible to re-use an application
definion with multiple deploymet policies. To be more specific there is no
application template support. This is something we discussed during past
months in the Dev mailing list and decided to include it in a later release
due to the complexity of the application composite model and its deployment
process.
At the moment an application can only be deployed with a given deployment
policy. If we need to deploy the same application with a different
deployment policy we will need to use a different application id.
> Also, what is confusing is that the samples are themselves inconsistent.
> For example, the first one I looked at [3] seems to be missing *any*
> binding between the application .json and the deployment .json; are these
> samples actually supposed to work, or are they perhaps a work in progress
> only?
>
We have removed application id from the deployment policy because it is
there in the API URL which is used for deploying the application:
curl -X POST -H "Content-Type: application/json" -d
"@${iaas_artifacts_path}/deployment-policy.json"
-k -v -u admin:admin https://${host_ip}:${host_port}/api/applications/
single-cartridge-app/deploy
It seems like it has been not reflected in the deployment policy in [2].
Thanks
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos