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