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
