+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 <lak...@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 <shahh...@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
