Can I suggest that we rename the label types we have come up with at the moment?
We right now have *Gateway* and *Store* label types. These names are tightly coupled to the high level product components that they are designed to work with and do not communicate their proper intent and purpose. The lower layers of the product(example: DAO layer) should not be aware of the higher level components. We can rename as follows, Gateway label ----> Deployment label(Since its communicates where the associated API will be deployed) Store label ----> View label(Since it communicates that this is related to the ability to view the associated API. This functionality happens to be used to implement publishing to multiple stores) This communicates intent better and will remove direct coupling to higher level. WDYT? On 22 June 2017 at 14:13, 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 > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
