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.
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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
