On Tue, Apr 26, 2016 at 5:37 PM, Nuwan Dias <[email protected]> wrote:

> Hi Imesh,
>
> Your intention I believe is to make API Manager artifact synchronisation
> possible in containerized environments without modifying the existing
> product and without using deployment synchronizer. Correct?
>

Yes that's correct, the first attempt is that. However if it's not
straightforward, it might be better to rethink and introduce an extension
point in the product to handle it properly.

>
> Looking at the suggested approach from a high level, this is quite similar
> to using dep-sync with a periodic svn checkout on the Gateway worker nodes
> instead of relying on the cluster message to arrive to check of updates. If
> we opt for the dep-sync option without relying on the cluster message, will
> it still be a problem for containers?
>

No, we cannot see any problems of using existing dep-sync. The only concern
is maintaining a version control system just for synchronizing internal
artifacts of a product.

>
> On Tue, Apr 26, 2016 at 3:15 PM, Imesh Gunaratne <[email protected]> wrote:
>
>> ​Hi All,
>>
>> This is to propose a new model for synchronizing Synapse APIs generated
>> by API Publisher in API Gateway worker nodes in containerized environments.
>> Here we are trying to avoid using SVN based deployment synchronizer. This
>> proposal may apply to Kubernetes, Apache Mesos or any other container
>> cluster management systems. Please refer the below diagram:
>>
>> You will have to check for new APIs and modifications to existing APIs as
> well. Which means you will have to write something quite similar to what
> the svn diff tool does. We will have to be a bit careful here because if
> the receiver bundle consumes a lot of resources, it'll affect the API
> traffic too. And the load on the Manager will increase as the number of
> workers grow.
>

Indeed, that's the idea. Regarding the resource concern, we can handle it
using container groups. Still that's only available in K8S.

>
> *Important*
>>
>>    - We might not be able to scale API Gateway Manager node more than
>>    one instance because API Publisher talks to it via a service call. If we
>>    do, all the instances of the API Gateway Manager cluster would not have 
>> all
>>    the Synapse API definitions.
>>
>> If there are more than 1 manager nodes, we can configure the publisher to
> publish APIs to all of them.
>

That's interesting. If so we may not need a gateway manager at all. Can you
please describe how that works? Do we need to specify IP addresses of each
gateway node in publisher?

Thanks

>
>>    - API Gateway Manager pod needs to mount a volume to persist the
>>    Synapse APIs. This is vital for allowing the Gateway Manager pod to auto
>>    heal without loosing the Synapse APIs on the filesystem.
>>
>>
>>    - This design does not depend on any native features of the container
>>    cluster management system.
>>
>>
>> Thanks
>>
>> --
>> *Imesh Gunaratne*
>> Senior Technical Lead
>> WSO2 Inc: http://wso2.com
>> T: +94 11 214 5345 M: +94 77 374 2057
>> W: http://imesh.io TW: @imesh
>> Lean . Enterprise . Middleware
>>
>>
>
>
> --
> Nuwan Dias
>
> Technical Lead - WSO2, Inc. http://wso2.com
> email : [email protected]
> Phone : +94 777 775 729
>



-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.io TW: @imesh
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to