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
