The design review was held and the following conclusions were made. -
In option 1 the size of the package is increased due to the ballerina dependencies and we also have to build the docker image. - In option 2, with the init container present, every time the microgateway fails we have to run the microgateway toolkit, generate the .balx and create a microgateway run time. And also every time we need to scale, it will run the init container. - In option 3 only thing we have to do is create the artifacts and deploy the swagger as a config map from the API manager. - In option 4 there may be some users who do not have git or Jenkins. Due to the above reasons*, option** 3* was selected as the most suitable approach for this project. In option 3 with the swagger definition, we deploy a microgateway for the API. We can ask the K8s admin users to deploy our API Manager K8s operator. From API Manager, we only need to create relevant custom resources and push to the K8s API server. In this way, we can reuse the work we have done so far with APIM K8s CRDs. -- *Sachith Kasthuriarachchi *| Engineering Intern | WSO2 Inc (m) +94 71 694 0826 | (w) www.wso2.com | (e) sachit...@wso2.com <abhis...@wso2.com> <http://goog_1559380502> <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
