On Tue, Jul 11, 2017 at 7:54 AM, Chamila De Alwis <[email protected]> wrote:
> +1 > > IMO users wouldn't always be willing to start with a Container Cluster > Management system and limiting this feature to a few would limit their > chances to properly make use of the feature. > > From the above explanation, I didn't yet understand how routing would > happen in a CMS when separate Gateways are deployed as separate services. > For example, if we take K8S, how would the API endpoint be mapped to a > Service or Service Loadbalancer endpoint? > > I am not 100% clear on the question. APIM GW will get the APIs endpoint from the Ballerina artifacts. There is no relationship to k8s or any .. When dynamic GWs created, adding proper domain into ingress (and then LB) will be able to access these GWs. > > Regards, > Chamila de Alwis > Committer and PMC Member - Apache Stratos > Senior Software Engineer | WSO2 > Blog: https://medium.com/@chamilad > > > > On Tue, Jul 11, 2017 at 12:34 AM, Nuwan Bandara <[email protected]> wrote: > >> Hi Chamalee, >> >> Shall we not limit this feature to k8s / Openshift. IMO this is quite a >> useful feature for many, if we limit this to users running a full blown >> container management platform then we are limiting the potential of this >> feature. >> >> Can we provide the option where >> >> 1. If someone has configure k8s and Openshift, then we do as you have >> described >> 2. If they haven't, we can provide the artifacts in a bundle (with a >> docker-compose possibly), so the users can download and deploy in anyway >> they want but provide the API Access URL. >> >> By doing this people can deploy this we don't restrict anyone, if we >> provide simple dockerfiles / compose files they can deploy in swarm / ECS >> or simply in a VM. This will make this feature more usable. >> >> WDYT ? >> >> Regards, >> /Nuwan >> >> On Mon, Jul 10, 2017 at 5:34 AM, Chamalee De Silva <[email protected]> >> wrote: >> >>> >>> Hi all, >>> >>> We had a design review for the per API per gateway feature today. >>> Please find the review comments in [1]. >>> >>> As per the the discussion in the revew what we decide was to generate >>> the label for the APIs where the perAPIperGateway feature is enabeld as in >>> below format. >>> >>> prefix-{api-UUID} >>> >>> I have gone through the identifier specifications and according to them, >>> the label can have a limit with *63 characters maximum.* >>> >>> *'' *rfc1035 <http://www.ietf.org/rfc/rfc1035.txt>/rfc1123 >>> <http://www.ietf.org/rfc/rfc1123.txt> >>> label (DNS_LABEL): An alphanumeric (a-z, and 0-9) string, with a >>> maximum length of 63 characters, with the '-' character allowed anywhere >>> except the first or last character, suitable for use as a hostname or >>> segment in a domain name. *"* >>> >>> >>> So the API UUID will get 36 characters and we will have* 27 characters >>> *maximum >>> for the rest. >>> If we allow to include a specific identifier like API name, APIM >>> hostname etc then we may have to bound to the 27 character limit which is >>> not possible as it is decided by the user. >>> So if the name becomes lengthy than the maximum limit, the option is to >>> generate a hashcode with adding all these. >>> On the other hand, since we are exposing this gateway label as the >>> selector for the kubernetes service to select the containers where the >>> particular gateway is available with the API deployed in it, the label >>> should be unique for the cluster as well (kubernetes cluster). >>> >>> So in summary, >>> >>> 1. A label like this is easily possible to use. >>> *PERAPIGW-01234567-0123-0123-0123-012345678901* >>> >>> 2. If we want to add API name, APIM hostname etc in the label, we can >>> use the hash-code of the *prefix-{uuid} *because we cannot >>> guarantee that we get a label with less than 63 character length. >>> >>> >>> What is the best option ? >>> Appreciate your opinion. >>> >>> >>> [1] [APIM][C5] Design Review : Per API Per Gateway Feature @ Mon Jul >>> 10, 2017 10:30am - 11:30am (IST) (WSO2 Engineering Group) >>> >>> >>> Thanks, >>> Chamalee >>> >>> On Mon, Jul 3, 2017 at 11:50 AM, Chamalee De Silva <[email protected]> >>> wrote: >>> >>>> Hi Harsha, >>>> As discussed with Uvindra, after generating the API label for the >>>> composite API, it behaves same as other APIs regarding the gateway >>>> functionality. >>>> >>>> Since the Published APIs as well as the Composite APIs are published to >>>> the JMS topic, I thought of handling this in following way. >>>> >>>> *For the created in the publisher side (not composite APIs) : * >>>> >>>> We are keeping a flag for every API whether this feature is enabled or >>>> not. >>>> >>>> If the feature is enabled we *auto-generate a label *for the API when >>>> it is published. >>>> then after the API is added to the JMS topic, >>>> >>>> 1. We call kubernetes API and do the gateway deployment (deploy the >>>> gateway image) in Kubernetes with the auto generated label. >>>> >>>> 2. Create the Kubernetes Service >>>> >>>> 3. Provide the access URL of the service created and label of the >>>> gateway/API to the admin API and register the Gateway. >>>> >>>> Then the API will be published to that gateway. >>>> >>>> >>>> *For the Composite APIs : * >>>> >>>> Since composite APIs are created in the Store we should also provide >>>> the Ability to enable the feature in store side as well. >>>> >>>> If the feature is enabled, we need to auto-generate a label like above >>>> or use the new label created for the composite API. >>>> >>>> So if we are planning to do kind of an auto-generation of the composite >>>> API label, then we need to consider whether the feature is enabled and >>>> generate the label according to that. >>>> >>>> Because IMO it will be better if we can have a clear separation in the >>>> label of that API to identify that as an API deployed in a separate >>>> Container gateway using this feature. >>>> >>>> After adding the API to the JMS topic with the label, the same steps >>>> will be followed to the composite APIs as well thereafter. >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Chamalee >>>> >>>> >>>> On Thu, Jun 29, 2017 at 3:44 PM, Harsha Kumara <[email protected]> >>>> wrote: >>>> >>>>> Hi Chamalee, >>>>> >>>>> Composite APIs will be created at the store side. Hence we will need >>>>> to think about handling that case as well. >>>>> >>>>> Thanks, >>>>> Harsha >>>>> >>>>> On Mon, Jun 26, 2017 at 4:59 PM, Chamalee De Silva <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Sajith, >>>>>> >>>>>> Yes, this is a feature to be enabled from API Publisher node level. >>>>>> The publisher user can select APIs to be published no matter the API >>>>>> is complex or not considering the functionality of the feature. >>>>>> >>>>>> User can deploy any API (Where this feature is enabled) to a >>>>>> container based gateway (Per API per Gateway) which is auto created with >>>>>> the label. >>>>>> >>>>>> Actually, what I have mentioned about the complex APIs is to explain >>>>>> the need and advantage of having such a feature. >>>>>> >>>>>> IMO having a simple API in a single Gateway is less likely. >>>>>> >>>>>> But yes, there may have situations where a publisher need to have a >>>>>> simple API in a single gateway. >>>>>> >>>>>> They also can achieve that through this feature. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Chamalee >>>>>> >>>>>> On Mon, Jun 26, 2017 at 4:09 PM, Sajith Kariyawasam <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Chamalee, >>>>>>> >>>>>>> On Mon, Jun 26, 2017 at 2:15 PM, Chamalee De Silva < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> With the usage of ballerina in API Manager 3.0.0, we can do most of >>>>>>>> the integration part of the API within API Manager. >>>>>>>> >>>>>>>> With that capability, APIs with high integration complexity can be >>>>>>>> Published and deployed to the Gateway. >>>>>>>> >>>>>>>> Other than that, with the new composite APIs [1] feature to be >>>>>>>> introduced with with APIM 3.0.0, API Manager allows us to create >>>>>>>> customized >>>>>>>> APIs by reshaping a collection of APIs as well. >>>>>>>> With that, an added complexity will be there in such APIs including >>>>>>>> a combination of multiple services . >>>>>>>> >>>>>>>> Since that sort of APIs gives a considerable load to the Gateway >>>>>>>> and make it complex in operation, >>>>>>>> we are planning to give the capability to each of those API to be >>>>>>>> deployed into separate Gateways with *Per API per Gateway Feature* >>>>>>>> . >>>>>>>> >>>>>>>> Following is a sample illustration of the flow with K8. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1. Before publishing the feature the publisher user is facilitated >>>>>>>> to enable the per API per Gateway feature. >>>>>>>> >>>>>>>> 2. If the feature is enabled in API Publisher, the API will be >>>>>>>> published with an auto generated Label. >>>>>>>> >>>>>>>> >>>>>>> Is this feature enabled at the API publisher node level? If so, it >>>>>>> will apply to all the API s irrespective of the complexity of the API, >>>>>>> so >>>>>>> even the simple API will be deployed in their own separate gateway. I >>>>>>> think >>>>>>> it should not be the case, only the selected API s to be deployed in >>>>>>> their >>>>>>> own gateways, whereas the others to be deployed in a common gateway. >>>>>>> >>>>>>> >>>>>>>> 3. Using this label, a new gateway will be start up in a container >>>>>>>> in the Container Management System. >>>>>>>> >>>>>>>> 4. The API will be deployed in that newly created Gateway and >>>>>>>> provide the Access URL and credential related information to the API >>>>>>>> Manager side. >>>>>>>> >>>>>>>> >>>>>>>> We are going to support *K8* and *Openshift* by default in this >>>>>>>> feature. >>>>>>>> And next, we will provide extension point to support other >>>>>>>> Container Management Systems as well. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] mail thread : [C5] API composition support for application >>>>>>>> developers in API Store >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks & Regards, >>>>>>>> >>>>>>>> *Chamalee De Silva* >>>>>>>> Software Engineer >>>>>>>> *WS**O2* Inc. :http://wso2.com/ >>>>>>>> >>>>>>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>>>>>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sajith Kariyawasam >>>>>>> *Associate Tech Lead* >>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >>>>>>> *Committer and PMC member, Apache Stratos * >>>>>>> *AMIE (SL)* >>>>>>> *Mobile: 0772269575 <077%20226%209575>* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks & Regards, >>>>>> >>>>>> *Chamalee De Silva* >>>>>> Software Engineer >>>>>> *WS**O2* Inc. :http://wso2.com/ >>>>>> >>>>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>>>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Harsha Kumara >>>>> Software Engineer, WSO2 Inc. >>>>> Mobile: +94775505618 <+94%2077%20550%205618> >>>>> Blog:harshcreationz.blogspot.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Chamalee De Silva* >>>> Software Engineer >>>> *WS**O2* Inc. :http://wso2.com/ >>>> >>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Chamalee De Silva* >>> Software Engineer >>> *WS**O2* Inc. :http://wso2.com/ >>> >>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>> >>> >> >> >> -- >> >> >> *Thanks & Regards,* >> *Nuwan Bandara | Director - **Solutions Architecture, WSO2 Inc.* >> *+1 646 643 8618 <+1%20646-643-8618> | +1 650 745 2169 Ext 4212 >> <+1%20650-745-2169> | http://nuwanbando.com <http://nuwanbando.com> * >> <http://www.nuwanbando.com/> >> > > -- Lakmal Warusawithana 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
