To be consistent with the above change, I have also removed application id
from the deployment policy as it is already there in the REST API method
URL:
POST -d {deployment-policy.json} /applications/{applicationId}/deploy
{
"applicationPolicy": {
"networkPartition": [
{
"id": "network-p1",
"activeByDefault": "true",
"partitions": [
{
"id": "p1",
"provider": "mock",
"property": [
{
"name": "region",
"value": "default"
}
]
}
]
}
]
},
"childPolicies": [
{
"alias": "tomcat",
"networkPartition": [
{
"id": "network-p1",
"partitionAlgo": "one-after-another",
"partitions": [
{
"id": "p1",
"max": 5
}
]
}
]
}
]
}
Thanks
On Sun, Jan 11, 2015 at 9:45 AM, Imesh Gunaratne <[email protected]> wrote:
> Application id is now removed from the domain mappings JSON:
>
> POST -d {domain-mappings.json} /applications/{applicationId}/domainMappings
>
> {
> "domainMappings": [
> {
> "cartridgeAlias":"tomcat",
> "domainName":"abc.com",
> "contextPath":"/abc/app"
> }
> ]
> }
>
> Similarly application id was removed from the application signup JSON:
>
> POST -d {application-signup.json} /applications/{applicationId}/signups
>
> {
> "artifactRepositories":[
> {
> "alias":"php",
> "privateRepo":false,
> "repoUrl":"https://github.com/imesh/stratos-php-applications.git
> ",
> "repoUsername":"",
> "repoPassword":""
> },
> {
> "alias":"tomcat",
> "privateRepo":false,
> "repoUrl":"https://github.com/imesh/stratos-php-applications.git
> ",
> "repoUsername":"",
> "repoPassword":""
> }
> ]
> }
>
> Thanks
>
> On Sun, Jan 11, 2015 at 8:59 AM, Imesh Gunaratne <[email protected]> wrote:
>
>> Yes it is there in the URI, we can remove it from the payload.
>>
>> On Sun, Jan 11, 2015 at 8:45 AM, Nirmal Fernando <[email protected]>
>> wrote:
>>
>>> Why do we need applicationId in the payload? Isn't it available in the
>>> URI ?
>>>
>>> On Sun, Jan 11, 2015 at 2:15 AM, Imesh Gunaratne <[email protected]>
>>> wrote:
>>>
>>>> I have now completed implementing REST API methods for domain mappings
>>>> functionality:
>>>>
>>>> POST -d {domain-mappings.json}
>>>> /applications/{applicationId}/domainMappings
>>>> GET /applications/{applicationId}/domainMappings
>>>> DELETE -d {domain-mappings.json}
>>>> /applications/{applicationId}/domainMappings
>>>>
>>>> {
>>>> "applicationId":"single-cartridge-app",
>>>> "domainMappings": [
>>>> {
>>>> "cartridgeAlias":"tomcat",
>>>> "domainName":"abc.com",
>>>> "contextPath":"/abc/app"
>>>> }
>>>> ]
>>>> }
>>>>
>>>> Thanks
>>>>
>>>> On Sat, Jan 10, 2015 at 11:15 AM, Imesh Gunaratne <[email protected]>
>>>> wrote:
>>>>
>>>>> I have now implemented core domain mapping functionality together with
>>>>> application signup events to fix load balancer tenant information model.
>>>>> Changes were pushed to master branch.
>>>>>
>>>>> Next we need to implement new REST API methods to manage domain
>>>>> mappings.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Thu, Jan 8, 2015 at 4:04 PM, Imesh Gunaratne <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Thanks for the quick feedback Lakmal!
>>>>>>
>>>>>> +1 for the suggestions on core domain mapping functionality. I will
>>>>>> incorporate those with this fix. We already have REST API methods for
>>>>>> managing domain mappings, I will update those accordingly with this
>>>>>> modification.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On Thu, Jan 8, 2015 at 3:18 PM, Lakmal Warusawithana <[email protected]
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Imesh,
>>>>>>>
>>>>>>> Here is few steps in my mind.
>>>>>>>
>>>>>>> - Need to expose REST API for domain mapping. It should generic
>>>>>>> to single and MT applications
>>>>>>> - Need to have some REST API for getting application structure
>>>>>>> with relevant aliases for create json payload for both signup and
>>>>>>> domain
>>>>>>> mapping.
>>>>>>> - Tenants can submit domain mapping against service aliases in
>>>>>>> the application. It should be contained mapping domain, application
>>>>>>> context.
>>>>>>>
>>>>>>> Eg: application host = myphp.php.stratos.org/website and
>>>>>>> we need access it by giving abc.com. then
>>>>>>> mapping domain : abc.com
>>>>>>> context : website
>>>>>>>
>>>>>>> - SM can store domain mapping with the tenant info.
>>>>>>> - Need to have separate topic "domainmapping" which LB need to
>>>>>>> subscribed. SM should publish domains, cluster, appliactionid,
>>>>>>> context
>>>>>>> - SM should implement add domain, remove domain and populate
>>>>>>> above topic.
>>>>>>> - LB should filter by application id (only get relevant to the
>>>>>>> application ids which need to act)
>>>>>>> - update in-memory LB routing table with domain,cluster,context.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 8, 2015 at 1:52 PM, Imesh Gunaratne <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Devs,
>>>>>>>>
>>>>>>>> Domain mappings functionality was introduced in 4.0.0 release to
>>>>>>>> allow users to map domain names for their service subscriptions. The
>>>>>>>> result
>>>>>>>> was that users were able to use domain names for accessing service
>>>>>>>> clusters
>>>>>>>> without having to use the generated cluster host names.
>>>>>>>>
>>>>>>>> In 4.0.0 release these domain names were managed against the
>>>>>>>> service subscriptions made by the tenants. Now in 4.1.0 release we do
>>>>>>>> not
>>>>>>>> have a concept of subscriptions, rather application signups are used
>>>>>>>> for
>>>>>>>> managing artifact repository information.
>>>>>>>>
>>>>>>>> IMO to fix domain mappings functionality in 4.1.0 release we may
>>>>>>>> need to store domain names against application signups.
>>>>>>>>
>>>>>>>> *Single-Tenant Applications:*
>>>>>>>> - An application signup is auto generated for each single-tenant
>>>>>>>> application by extracting the artifact repository information provided.
>>>>>>>> - Since there could only be one application signup for a
>>>>>>>> single-tenant application, users could add domain names for each
>>>>>>>> service
>>>>>>>> cluster by specifying the application id and the cartridge alias.
>>>>>>>>
>>>>>>>> *Multi-Tenant Applications:*
>>>>>>>> - Each tenant could signup for a a multi-tenant application after
>>>>>>>> super tenant deploys the application.
>>>>>>>> - Since there could be many application signups for a multi-tenant
>>>>>>>> application, users need to specify the application id, sign up id and
>>>>>>>> the
>>>>>>>> cartridge alias for adding domain names for service clusters.
>>>>>>>> - The signup id can be fetched using the tenant id of the user
>>>>>>>> since there could only be one application signup for a tenant for a
>>>>>>>> given
>>>>>>>> multi-tenant application.
>>>>>>>>
>>>>>>>> Please add your thoughts on this.
>>>>>>>>
>>>>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Nirmal
>>>
>>> Nirmal Fernando.
>>> PPMC Member & Committer of Apache Stratos,
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>> Blog: http://nirmalfdo.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
