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 <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
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Imesh Gunaratne
Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
