On Fri, Jun 23, 2017 at 2:47 PM Nuwan Dias <[email protected]> wrote: > I don't think we need to handle the situation of a Gateway changing its > labels. That is an extremely unlikely use case and writing complex code to > handle that situation is going to be a waste. If someone wants to change a > label of the Gateway we can simply ask them to remove all APIs and start it > as a fresh Gateway. This will make sure that it pulls all the relevant APIs > only on startup. >
+1, no need to handle this. They can start new gateway with new label, and destroy previous one, if need. > On Fri, Jun 23, 2017 at 2:40 PM, Harsha Kumara <[email protected]> wrote: > >> @Tharindu, will gateway change the labels? If a gateway changes the label >> and starts it we are calling to core API to get the available APIs list for >> that particular gateway. In order to handle the label change, we >> can undeploy the APIs which are not under returned list of APIs. >> >> On Fri, Jun 23, 2017 at 2:06 PM, Tharindu Dharmarathna < >> [email protected]> wrote: >> >>> As offline discussion with Lakmal, We are not going to register gateway >>> labels and access URLs on the apim core by Gateway startup. And labels are >>> managed by the admin can assign permissions to those labels to make who can >>> see this labels. Then Gateway will only start with the predefined label. >>> >>> When Gateway gets to start it retrieve APIs according to label assigned. >>> @All, >>> How do we going to handle the already created APIs under the Gateway? >>> >>> In VM scenario if set of API artifacts (ballerina files) created under >>> the gateway. >>> Then Gateway started with the different label. We have a way to get a >>> list of ballerina artifacts under file system and do the check for those >>> its validity for that label. >>> >>> How do we going to handle above requirement from the file system? >>> >>> On Wed, Jun 21, 2017 at 7:24 AM, Isuru Haththotuwa <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> I'm not in favor of using special headers or anything like that. What >>>>> if we just send all API updates to all Gateways? Each Gateway upon >>>>> receiving this event will request for the particular API from the Core. >>>>> The >>>>> Core will only give that API to the Gateway if the Gateway's labels >>>>> matches >>>>> that of the requesting Gateway. If it does not, the core will refuse to >>>>> give the API to the Gateway and in that case if the Gateway already has >>>>> that API deployed it should go and remove it from itself (same code that >>>>> runs in case of an API delete event). >>>>> >>>> This header based filtering is actually a useful feature in the general >>>> case IMO; sometimes we need events to be processed by specific clients >>>> (gateways), in other cases we might need to do a multicast for all clients. >>>> In such situations we can stop the payload being processed unnecessarily. >>>> If we have to process all such events at all gateways, it might leads to >>>> scalability issues specially in container based deployments. >>>> >>>>> >>>>> Thanks, >>>>> NuwanD. >>>>> >>>>> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> As per the APIM C5 architecture, the gateways can be registered in >>>>>>> APIM Core, specifying it's label and accessURLs. When creating/updating >>>>>>> APIs, the API can be moved to a gateway by assigning the label of the >>>>>>> gateway which registered under APIM Core. Once a label is assigned to an >>>>>>> API, that particular API will be deployed and available to the >>>>>>> gateway/gateways represented by the given label/labels. >>>>>>> >>>>>>> Basically, all the API related actions(API >>>>>>> create/update/delete/status change) are published to JMS topic along >>>>>>> with >>>>>>> label information. The gateways are responsible for listening to the >>>>>>> topic, >>>>>>> capture events which are relevant and process them. Ideally, gateways >>>>>>> should filter the events based on API label and only process the events >>>>>>> generated for APIs which are assigned with their gateway labels and >>>>>>> rest of >>>>>>> the events should be ignored. >>>>>>> >>>>>>> But when it comes to label update, the gateways should behave >>>>>>> differently, due to the scenarios explained before. Though API label >>>>>>> update >>>>>>> is populated as an API update event, some of the gateways have to >>>>>>> process >>>>>>> this API updates differently(May be as an API create or may be as an API >>>>>>> delete) >>>>>>> >>>>>>> - Moving API to a new gateway: When a new gateway label is >>>>>>> assigned to an API, the event generated for the gateways with newly >>>>>>> added >>>>>>> label/labels is an API create event and the API should be deployed >>>>>>> to the >>>>>>> gateway/gateway with newly added label/labels. >>>>>>> - Remove API from a gateway: When a label is removed from an >>>>>>> API, the event generated to the gateway with the removed label is an >>>>>>> API >>>>>>> delete event and API should be undeployed from that gateway. >>>>>>> >>>>>>> We came up with few solutions in order to handle label related API >>>>>>> update events. >>>>>>> >>>>>>> - Introducing a new event on API label update: >>>>>>> >>>>>>> During an API update, we need to identify whether there >>>>>>> is a label change and populate a label update event with label change >>>>>>> details (ie: newly added label/previous labels). The gateways can read >>>>>>> the >>>>>>> label change information and decide whether it is relevant to process >>>>>>> the >>>>>>> event and perform API deploy/undeploy actions accordingly. >>>>>>> >>>>>>> - Introducing a header/property to force every API gateway to >>>>>>> process an label update related event: >>>>>>> >>>>>>> If there is a label update, a property is set to JMS >>>>>>> event so that every gateway should process the events generated with >>>>>>> that >>>>>>> particular property. Ideally, the gateways process API events >>>>>>> generated with its own gateway label, but in this case, they have to >>>>>>> process the event if it comes with this property. >>>>>>> >>>>>> +1 for the approach as we can handle through the API update event. >>>>>> What information are we going to send with this property? Is it only >>>>>> specify label change? I think we will need to send the label changes as >>>>>> we >>>>>> will need to process it from the gateway side. Somecases we will need to >>>>>> remove the API from particulae gateway during a label change. >>>>>> >>>>>>> >>>>>>> Any suggestions on this? Your thoughts and suggestions are highly >>>>>>> appreciated >>>>>>> >>>>>>> Thanks >>>>>>> Thilini >>>>>>> >>>>>>> -- >>>>>>> Thilini Shanika >>>>>>> Senior Software Engineer >>>>>>> WSO2, Inc.; http://wso2.com >>>>>>> 20, Palmgrove Avenue, Colombo 3 >>>>>>> >>>>>>> E-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Harsha Kumara >>>>>> Software Engineer, WSO2 Inc. >>>>>> Mobile: +94775505618 <+94%2077%20550%205618> >>>>>> Blog:harshcreationz.blogspot.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Isuru H. >>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* >>>> >>>> >>>> >>> >>> >>> -- >>> >>> *Tharindu Dharmarathna*Senior Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: *+94779109091 <+94%2077%20910%209091>* >>> >> >> >> >> -- >> Harsha Kumara >> Software Engineer, WSO2 Inc. >> Mobile: +94775505618 <+94%2077%20550%205618> >> Blog:harshcreationz.blogspot.com >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > -- Sent from Gmail Mobile
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
