stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: 4.1 deployment policy questions
Date Sat, 21 Feb 2015 14:26:20 GMT
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 <lakmal@wso2.com>
> wrote:
>
>
>
>
>
> On Thu, Feb 19, 2015 at 11:25 AM, Rajkumar Rajaratnam <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>
> wrote:
>
>
>
> On Wednesday, February 18, 2015, Rajkumar Rajaratnam <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> 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>
> 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 <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> 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

Mime
View raw message