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/

Reply via email to