Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Support multiple-revisions of functions #1075
Support multiple-revisions of functions
We should consider how to enable / support multiple-revisions of OpenFaaS functions. This is currently done by changing the name of the function before deployment.
If possible we could use a new feature-flag (for backwards compatibility) and conventions on the Docker image tag to support multiple concurrent versions of functions.
Imagine three different git commits and image tags defined in your stack.yml file:
This would produce 3 endpoints when deployed:
We may want to then add an additional route like
When we have two
Ideas for feature: Alex / Stefan
I think it's important to keep the URL path the same for current/latest function versions.
For routing to a specific version, we could add the version to the route:
The proxy should remove the version from the route when forwarding to the function to avoid forcing the individual functions to know if there is a version attached so that we don't break the path inside the functions.
Behind the scenes, we could use labels to identify the version of the function. That could be created automatically when the function is deployed by taking the label from the container image and creating a label.
There is also the question of how does the deploy work with this in place? Would this mean that the users would need to explicitly remove all the containers themselves? Could we implement some sort of
Very much in favour of managed versioning of functions. Ideally the latest on the same endpoint or at least a softlink endpoint that lands you on the last deployed iteration of a function. Under ideal circumstances you would also have a rollback mechanism that allows you to determine a fixed endpoint of a previous version you know your dependent application worked well with. For interoperability as well as migration in our environment this would be extremely useful.
I like this idea.
With respect to automating smart aliases, i see how the default/latest path could be implemented for semver but not with shas. Wouldn't it be easier to add an
functions: # version allows multiple slash commands in one comment name: derek image: derek:ef5ja functions: # version has rebase command enabled name: derek image: derek:ffa3j functions: # version represents latest stable release, indicated via sem-ver name: derek image: derek:0.6.0
you would get this by default (assuming last in takes the default)
but the user could override this using
functions: # version allows multiple slash commands in one comment name: derek image: derek:ef5ja alias: - derek-latest functions: # version has rebase command enabled name: derek image: derek:ffa3j alias: - derek-feature-branch functions: # version represents latest stable release, indicated via sem-ver name: derek image: derek:0.6.0 alias: - derek-stable
The aliases idea gets us too far into "configure everything" Vs our style or convention over configuration. When building from a feature branch I think you'd tag the image with the branch name.
@stefanprodan could probably add more of how he does this with customers on Kubernetes with flux.
Not adding aliases makes sense
I think I would prefer not automating aliases for shas, because it might be too difficult for someone to consistently understand why and which alias is set. Automting based on "latest tag" and then "semver order" for the default path and then unique names for anything else (shas or branch names) would be pretty clear. You can easily read this directly from the file and predict what will happen.
Using datetime created would mean that the resulting urls would depend on how they were deployed. If you deploy the entire stack file it would be "order of the file". But you could deploy one at a time in a random order.
Note: One downside to semver order is that it does not play well it CI/CD git tag based versions because strict semver does not have a concept of a post-release, i.e. "number of commits after a version". It only has pre-releases, ie "number of versions prior to the next release. See semver/semver#200 and semver/semver#394 This is not an issue, but just something to be aware of. Any strict semver ordering will not be able to properly order nightly or CI/CD builds that use
Why would anyone use sem ver for nightly builds? Usually you would use the short SHA for nightly builds or pre releases and strict sem ver for releases. It's easy to follow this patter and from a CI perspective it's 10 lines of bash: https://github.com/stefanprodan/flagger/blob/master/.travis.yml#L22
I only brought it up because I have been on multiple teams where the consensus was "we use semver" but then there were unexpected differences in how tools behave because people thought that
Hi @alexellis ,
Let me explain how this new version flag can behave in all above CLI
faas-cli build -v
faas-cli push -v
faas-cli deploy -v
Using version labels on pod can help in rolling updates or rollback to previous version (this can be discussed later)
Let me know if above proposal suits the purpose.