Hi Lasanatha, A few points regarding this API.
1. POST /deployments - Instead of returning a 200, IMO this should return a 202 Accepted. In this case, a request to deploy a container cluster has been submitted to the PaaS layer, and we cannot meaningfully return a 200 since it would mean the resource has been created. 202 is better suited since it expresses that the request has been accepted and the necessary chain of action has been initiated. 2. DELETE operations - These should also return a 202 upon successful invocation. Similar to the creation process, the deletion process is also executed in an async manner at the platform layer. 2. GET service methods - The above points should be complemented by a "status" field in the response for the GET requests. This would indicate if the deployment is "completed", "deploying", "deleting", or "failed". WDYT? Furthermore, another technical decision should be to make the underlying implementation extensible, to switch platform providers easily, be it K8S, Mesos etc. I think the environment variable naming blocks this extensibility. IMO it should rather be similar to PLATFORM_ARTIFACTS, which can be any of WSO2 provided deployment artifacts. The deployer will only have to validate this path in order to proceed and hand over deployment to the platform specific implementation. How far does the current implementation support this kind of a scenario? Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Senior Software Engineer | WSO2 Blog: https://medium.com/@chamilad On Thu, Dec 8, 2016 at 10:29 AM, Imesh Gunaratne <[email protected]> wrote: > Hi Pubudu, > > On Tue, Dec 6, 2016 at 2:18 PM, Pubudu Gunatilaka <[email protected]> > wrote: > >> Hi Lasantha, >> >> How do we handle multiple versions in K8s? There could be API changes in >> K8 major versions. I think we need to consider the platform version as well >> when deploying the products. >> > > A very good point! In this scenario the underlying K8S platform that > hosts the SaaS application would be fixed. Therefore we might not need to > send the K8S API version via this API. > We have used Fabric8 SDK in this API for talking to K8S API, therefore > K8S API version compatibility will be handled by that. > > > Thanks > > >> Thank you! >> >> On Tue, Dec 6, 2016 at 12:03 PM, Imesh Gunaratne <[email protected]> wrote: >> >>> Correction: s/identified generated/identifier generated/g >>> >>> Thanks >>> >>> On Tue, Dec 6, 2016 at 12:02 PM, Imesh Gunaratne <[email protected]> wrote: >>> >>>> Hi Lasantha, >>>> >>>> Great work! Please find few comments inline: >>>> >>>> On Mon, Dec 5, 2016 at 5:31 PM, Lasantha Samarakoon <[email protected] >>>> > wrote: >>>>> >>>>> >>>>> Following endpoints are available in this API (Please see the attached >>>>> Swagger definition for detailed description). >>>>> >>>>> *POST /deployments * >>>>> - Payload: Product model >>>>> >>>>> *DELETE /deployments* >>>>> - Payload: Product model >>>>> >>>>> Product model: >>>>> { >>>>> "product":"esb", >>>>> "version":"4.9.0", >>>>> "pattern":1, >>>>> "platform":"kubernetes" >>>>> } >>>>> >>>> >>>> I think we might need to use the same term given for the API resource >>>> for the object model. In this scenario maybe we can call it deployment. >>>> WDYT? >>>> >>>> >>>> We would also need to expose two API resources for queriing >>>> deployments: >>>> >>>> GET /deployments - Returns all deployments >>>> GET /deployments/{id} - Returns the deployment that matches the {id} >>>> >>>> Note the {id} parameter in the second API resource. I think we would >>>> need to add an id property to the deployment definition and use the >>>> identified generated by the container cluster manager. >>>> >>>> *How the API works?* >>>>> >>>>> Kubernetes artifacts which is used to deploy the product in a >>>>> container environment needs to be hosted in the host environment. ' >>>>> KUBERNETES_HOME' environment variable contains the path to this >>>>> Kubernetes artifacts directory. Directory structure of the KUBERNETES_HOME >>>>> is as follows. >>>>> >>>>> [KUBERNETES_HOME]/[PRODUCT_NAME]/[PRODUCT_VERSION]/[PATTERN] >>>>> /[PRODUCT_PROFILE].yaml >>>>> >>>> >>>> Shall we change this to read K8S artifacts from a folder inside >>>> repository/deployment folder (need to check the exact folder path from C5 >>>> product structure)? >>>> >>>> Thanks >>>> >>>> >>>> -- >>>> *Imesh Gunaratne* >>>> Software Architect >>>> WSO2 Inc: http://wso2.com >>>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>>> W: https://medium.com/@imesh TW: @imesh >>>> lean. enterprise. middleware >>>> >>>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Software Architect >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>> W: https://medium.com/@imesh TW: @imesh >>> lean. enterprise. middleware >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Pubudu Gunatilaka* >> Committer and PMC Member - Apache Stratos >> Software Engineer >> WSO2, Inc.: http://wso2.com >> mobile : +94774078049 <%2B94772207163> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
