[GitHub] larandersson commented on issue #414: Syntax for referring to item versions

[GitBox <gi...@apache.org>]

larandersson commented on issue #414: Syntax for referring to item versions
URL: https://github.com/apache/incubator-openwhisk/issues/414#issuecomment-462784493
 
 
   One of the many use-cases for OpenWhisk is for implementing API:s. However, for this to be a serious alternative compared to building microservices we need to have proper versioning. Otherwise it will be very hard to convince customers that they can only have 1 active version of their function in production at any given time, and they can't specify which version to invoke. Furthermore, when upgrading a function, there is no way to perform blue-green or canary deployments so upgrading becomes a very risky business.
   
   I'm not convinced that semantic versioning is the ideal solution. First, I think it's more than is needed, and secondly, what about invoking an action and asking for version>0.0.1 and there's several versions that satisfy the condition. Which version should be chosen? 
   
   Working with API:s, many vendors provide the ability to assign any arbitrary tag as a version number, and that's all that is needed. The same could be applied here, which also would give one the option of using GitHub commit tags as version numbers, just as we do with image tags.
   
   Another question that comes to mind is how to refer to versions in the API and CLI. Starting with the API, there is no de-facto standard for resource versioning. Some suggest using path parameters, others suggest request parameters or http headers such as *Accept* or *If-Match* with ETags, or even custom headers. A clear advantage of using a header would be that this will not break v1 of the API. For the CLI we would just add a *--version* flag for the appropriate commands. But how should we handle when the version is omitted? If we use the notion of a *default* version, which the user could indicate using a *--default* flag (default true) when creating or updating an entity, we could fall back to this default version. The difference between a *default* version and the latest version is that they are not necessarily the same.
   
   Once we implement versioning, we can move on to routing. Being able to specify a version to invoke, we can implement green-blue and canary deployments. To be able to support canary deployments, we need a way to specify load-balancing between versions. If all actions where fired trough triggers, we could use rules for this, but I don't think they are. Invoking an action through the API doesn't involve any trigger or rule, so either we would have to implement some kind of default trigger/rule for this under the hood, or we need a new entity for load-balancing that the controller can use.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services