Hi All,
Now we have implemented two APIs for managing tenant operations [1];
1. Tenants API for tenant management
2. Deployments API for deployment automation
Next, we would need to design how tenant user management, API
authentication, and authorization should be handled. Please refer
Above changes have now been moved to move-to-c5 branch and refined:
https://github.com/wso2/carbon-multitenancy/tree/move-to-c5
Thanks
On Tue, Nov 22, 2016 at 2:14 PM, Imesh Gunaratne wrote:
> Hi Lasantha,
>
> Shall we move what you have implemented so far to wso2 multitenancy
Hi Lasantha,
Shall we move what you have implemented so far to wso2 multitenancy
repository [1]? Maybe we can use a new branch called 5.0.0.
[1] https://github.com/wso2/carbon-multitenancy
Thanks
On Mon, Nov 21, 2016 at 12:53 PM, Lasantha Samarakoon
wrote:
> Hi all,
>
>
Few more suggestions to consider..
- Get all tenants : Don't we need to add limit/offset to support
pagination?
- Get a tenant by name : Response code 400 can be introduced if the name
is invalid
- Create new tenant: Response code 400 needed to notify the errors in
payload.
-
Hi Lashantha
Few corrections according to WSO2 REST API guidelines [1].
1. The POST should return 201 Created response.
2. And as a practice we do not use 500 error codes in API interface.
3. If the tenant is already exist you can send a 400 Bad Rest with error
json explaining what went wrong.
On Tue, Nov 15, 2016 at 5:00 PM, Lasantha Samarakoon
wrote:
> Hi all,
>
> We are currently working on implementing multitenancy for Carbon-5 based
> products. In order to implement this we are creating Kubenetes namespaces
> for each tenant (namespaces provides isolation
Hi all,
We are currently working on implementing multitenancy for Carbon-5 based
products. In order to implement this we are creating Kubenetes namespaces
for each tenant (namespaces provides isolation between tenants and the same
approach has been used by WSO2 cloud as well).
In most of the