Hi Praminda,
Seems like this going to be quite complex to support all use-case what we
have. May be simple permission model is ideal.
Please verify following use cases can support with the design.
General use-case
1. By default (in fresh deployment) no labels are defined.
2. When API's create no labels to attach
3. GW and Store will start without any label
1. Store will display API's which does not attach any label
2. GW pull API's which does not attache any label
Multi GW and multi Store use-case
1. Admin will create labels
1. Label : US-WEST, type=gateway, Access URL = us-west.abc.com
2. Label : US-EAST, type=gateway, Access URL = us-east.abc.com
3. Label : ASIA, type=gateway, Access URL = asia.abc.com
4. Label : US , type=store
5. Label : ASIA, type=store
6. Label : WORLD, type=store
2. Admin should be able to set some permission to labels to cover
#10,#11 use-case
3. GW1, will start with US-WEST label and pull all APIs attach US-WEST
label
4. GW2 will start with US-EAST label and pull all APIs attach
US-EAST label
5. GW3 will start with ASIA label and pull all APIs attach ASIA label
6. API1 will attach US-WEST, US-EAST gateway labels and US,WORLD store
labels.
7. API2 will attach US-WEST gateway label and US,WORLD store labels.
8. API3 will attach US-EAST gateway label and US,WORLD store labels.
9. API4 will attach ASIA gateway label and ASIA,WORLD store labels.
10. US publisher team should only be able to attach US-WEST, US-EAST
gateway labels and US,WORLD store labels. (other labels should not visible)
11. ASIA publisher team should only be able to attach ASIA gateway label
and ASIA,WORLD store labels. (other labels should not visible)
thanks
On Thu, Jun 22, 2017 at 2:13 PM, Praminda Jayawardana <[email protected]>
wrote:
> Hi All,
>
> I've updated the design as per the discussion in this thread.
>
>
>
> [image: Inline image 2]
>
>
>
> With this design API Publisher will be asked only to select one label (for
> both gateway and store). Which combination of gateway and store is applied
> for this particular API, depends on the label's scope. If label only has
> GATEWAY scope this API will be deployed on the gateway with selected label
> but it will not be attached with a specific store (will be visible in
> default store). If label has both GATEWAY and STORE scopes API will be
> deployed on a specific gateway and a store specified by that label.
> When selecting label's, API Publisher will only see the labels he/she has
> access depending on the label permissions. Also dynamic label registration
> will not be available anymore as we need intermediate step of permission
> setting in label creation process.
>
> Thanks,
> Praminda
>
>
> On Wed, Jun 21, 2017 at 3:43 PM, Praminda Jayawardana <[email protected]>
> wrote:
>
>> +1 for attaching permission model with labels.
>>
>> As per current discussion we'll need following items added to our todo.
>>
>> 1. Attach permission model with label.
>> 2. admin APIs to manage(CRUD operations) labels. There will be a UI
>> in admin app.
>>
>> Is there any other things we need to consider?
>> Thanks,
>> Praminda
>>
>> On Wed, Jun 21, 2017 at 7:20 AM, Lakmal Warusawithana <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We actually have a REST API to delete a given label. Also, for the
>>>> initial version, we thought of simplifying the label scenario. In later
>>>> releases, we can add an UI support to manage labels.
>>>>
>>>> I don't think we need to bring the permission model unless we provide
>>>> gateways per user/group. In the store side, we have introduced an extension
>>>> point to filter labels depends on the user.
>>>>
>>>> The story behind the label scenario is to simplify the dynamic gateway
>>>> registration. For an example, consider a deployment which has multiple APIs
>>>> deployed in public and private gateways. Now our requirement is to spin a
>>>> new gateway in Singapore region and serve a particular API. What we need to
>>>> do is to spin a gateway in that region with the new label and re-publish
>>>> the API with the new label. We have used labels to manage gateways in this
>>>> scenario.
>>>>
>>>> If we are not allowing dynamic label registration, we can have admin
>>>> API for labels. Yes, we can ship default labels. But when we need to bring
>>>> up a new gateway, we have to make the REST calls to register the gateway.
>>>> This is kind of a user interaction or maybe we can automate this based on
>>>> the use case. But with dynamic label registration, we don't need to do
>>>> anything specifically. If we consider a container scenario, we only need to
>>>> pass an environment variable with the new label name to the container to
>>>> spin up a new gateway container in a new region.
>>>>
>>>>
>>> IMO, but when we come to displaying labels in publisher, governance
>>> aspect going to be critical. If we going to add governance aspect, dynamic
>>> label registration has minimal advantage. In that case anyhow it need to go
>>> through the some kind of permission model.
>>>
>>>
>>>
>>>> Thank you!
>>>> --
>>>> *Pubudu Gunatilaka*
>>>> Committer and PMC Member - Apache Stratos
>>>> Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> mobile : +94774078049 <%2B94772207163>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692 <+94%2071%20428%209692>
>>> Blogs : https://medium.com/@lakwarus/
>>> http://lakmalsview.blogspot.com/
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Praminda Jayawardana*
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> Mobile : +94 (0) 716 590918 <+94%2071%20659%200918>
>>
>
>
>
> --
>
> *Praminda Jayawardana*
> Software Engineer
> WSO2 Inc.; http://wso2.com
> Mobile : +94 (0) 716 590918 <+94%2071%20659%200918>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692 <+94%2071%20428%209692>
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
