+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? 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/> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
