On Tue, Oct 10, 2017 at 11:22 AM, Pubudu Gunatilaka <[email protected]> wrote:
> Hi Subhashinie, > > Please find my comments in line. > > >> This is the deployment yaml configuration that I have added. Note that >> "insidePod", "caCertLocation", "serviceAccountToken" are just Hashmap keys >> that can be changed and might change since securing the token has not been >> implemented yet. >> >> >> >> > I would suggest the following structure as it would allow users to add any > extension for the service discovery. > > wso2.carbon.serviceDiscovery: > enabled: true > className : org.wso2.carbon.apimgt.service.discovery.classname > cmsSpecificParameters: > insidePod: true > Why we need insidePod:true ? AFAIR we have discussed this. If config not providing serviceAccountToken thats implies we have to look token inside the pod. Otherwise will take token which provide in the config. > masterUrl: https://localhost:8443 > CACertLocation: anyLocation > token: tokenValue > > Under cmsSpecificParameters, users can provide any property values and > refer them in the code. When you need to plug another service discovery > mechanism, you only need to provide the implementation class name and > provide the required values as properties. > > >> >>>> - Filtering can be done using the deployment yaml (based on >>>> namespace, criteria/labels) or using the UI (based on service name, >>>> namespace, criteria/labels). >>>> >>>> In the future, we may add different service discovery mechanisms. So we >>> need to tackle this and write in a more generic way to handle each and >>> every service discovery mechanisms. >>> >> >> Hope the code is close to what you expect, since it is a common interface >> that gets implemented for different systems. I'll bring it to you today if >> that is alright. >> >>> >>> >>>> >>>> - Service Discovery UI can only be accessed if the user has the >>>> scope "apim:external_services_discover". >>>> - A serparate resource is used for service discovery. >>>> - When an service endpoint gets stored, its namespace will precede >>>> its actual name >>>> - schema of the stored name -> [namespace]-[service >>>> name]-[http/https]-[other necessary attributes] >>>> - example -> dev-fifth-service-http-NodePort >>>> >>>> How this can be done for a different service discovery mechanism? >>> Namespace is only applicable for Kubernetes. These terms are different in >>> other mechanisms. >>> >> >> Service discovery filtering only uses "namespace" and "criteria". >> >> - "namespace" - although kubernetes officially has the term >> namespace, our idea was to use it to identify a scope of the user. >> - "criteria" - at the moment we only use to pass the labels. Yet as >> suggested by Isuru ([email protected]) it is meant to pass any criteria >> the services needs to be filtered by. >> - Other than the service name the application level protocol also >> seemed essential >> >> Do you think we might need a change there? >> > > Could you please explain how we have achieved the following? > > 1. We should be able to show only the services in a namespace. > 2. We should be able to show all the services in all the namespaces. > 3. How to filter using the namespace? > 4. How to use some other filtering mechanism when we use another service > discovery method? > > Thank you! > -- > *Pubudu Gunatilaka* > Committer and PMC Member - Apache Stratos > Senior Software Engineer > WSO2, Inc.: http://wso2.com > mobile : +94774078049 <%2B94772207163> > > -- Lakmal Warusawithana Senior Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
