On Wednesday, February 18, 2015, Rajkumar Rajaratnam <rajkum...@wso2.com>
wrote:
> Hi Imesh,
>
> Please find a question inline.
>
> On Wed, Feb 11, 2015 at 7:27 PM, Imesh Gunaratne <im...@apache.org
> <javascript:_e(%7B%7D,'cvml','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.
>
>
>> - 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
>> <javascript:_e(%7B%7D,'cvml','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 <lak...@wso2.com
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>
>>
>>
>>
>> --
>> 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
