Faas: Research: support new set of official of-watchdog templates

[alexellis]

There is utility in having two sets of templates for OpenFaaS - the existing (forking) mode templates and the new templates using of-watchdog and HTTP which can handle significantly more throughput due to re-use.

Challenges:

• keeping compatibility
• clean naming / UX

Right now people have functions defined as "node" or "go" without an associated version, this is probably something we _should have done_ but didn't.

Here are some options, please add more in the thread..

Option 1

Maintain "node", "go" etc but make new versions of the templates with of-watchdog/http and name them such as: "[email protected]" / "[email protected]"

Option 2

Create a new template repo with "node", "go" etc where these are the of-watchdog/http equivalents

Users would have to type in faas template pull and specify the URL

Alternative - use a branch - this would also have to be specified on faas template pull

Option 3

Cut a 1.0 release of the CLI which points to the existing templates repo and then cut a 2.0 release which points at a new repo populated only with of-watchdog templates.

Option 4

Add of-watchdog templates into the existing "openfaas/templates" repo so that we see:

node10-express
go
go-http
go-http-middleware

This option is where naming is important and it could be confusing as to know which template to pick.

Context

More on the watchdog/of-watchdog and new templates:

http://docs.openfaas.com/architecture/watchdog/

How to create a template:

http://docs.openfaas.com/cli/templates/

[LucasRoesler]

Another option:

1. we should definitely deprecate the old templates and give a reasonable deprecation window (similar to Option 3).
2. we should add versions to the templates (similar to Option 1).
3. create a new template repo (similar to Option 2).
4. we should add a version field to the stack schema (similar to docker-compose).
5. during the deprecation window we can use the stack version field to modify how the template name "go" or "node" is interpreted: If the version is missing or below a certain number, then we can default to the legacy repo.
6. Once the deprecation window is over, we completely replace the legacy repo with the new templates.

[burtonr]

I was thinking about a flag on the faas template pull that would indicate you want the of-watchdog versions. Like a "type" flag

faas template pull --http
faas template pull --fork

Similar to what Lucas was saying, we could initially default to the --fork in order to continue to pull the "legacy" templates. Then, after a certain release of the CLI (v7 perhaps) we could switch the default to the --http option to utilize the new of-watchdog functions.

I think this would allow users who want and use the forking method to continue doing so with little change, but would also make the of-watchdog functions more accessible.

We'd need to add that "type" or "mode" to the template .yml files, but I think a change there is necessary regardless of the option.

[alexellis]

We know what fork and http means, but what about our users? They shouldn't have to care.

cc team @openfaas/cli

[ericstoekl]

I would be in favor of adding the new (HTTP) templates to the existing templates repo, and moving the forking mode templates to a new repository called templates-legacy. I think most users don't care, and the ones who do probably want the benefits of the new HTTP mode rather than forking mode for common programming languages.

[alexellis]

I think most users don't care, and the ones who do probably want the benefits of the new HTTP mode rather than forking mode for common programming languages.

What data is that based on?

The existing templates are used by every OpenFaaS user apart from those who set up their own for some other purpose - it would be a breaking change for almost _every user of OpenFaaS_.

There are some languages where the new node is essential for high-throughput, for everything else they are acceptable. Node and Java are the core runtimes where we absolutely need another option.

[burtonr]

I'm curious what your thoughts are on this @rgee0. You usually come up with some interesting scenarios and solutions :smile:

[rgee0]

We haven't got to 1.0 yet, but that said, we should still try to minimise breaking changes. People have systems and pipelines already built on the current mode of operation, and these should continue to function in the expected mode of operation as we start to introduce this.

So, from that viewpoint, we need to be able to offer the current mode of operation without a change in pattern for the users, while introducing the option to use the new watchdog. Further, we should introduce the new watchdog/templates in such a way that we are able to change again in future should we so wish.

I think we need to keep the number of --lang values small and accommodate options through flags. The user should specify what they want in a clear and easy to understand/remember fashion and the cli should map that through to the required template. As an example I'd prefer a CLI that looks like:

$ faas new --lang=node --arch=arm32v7 --watchdog=1.0 ... (or whatever the flag is)

over

$ faas new --lang=node-armhf-newwatchdog ...

I agree with Lucas that we need to start advertising the fact that the default will change in future.

Also, in an ideal world we'd have a view of who's using what via https://github.com/openfaas/faas-cli/issues/108 to help us gauge the potential impact of such changes. I know Alex has concerns over potential implications of implementing this.

[burtonr]

I like that concept! Concise lang options, and granular flags/options. Curious how far you took that thought @rgee0.

How would the faas template pull behave?

For example, would pulling the node template result in a structure that looked like this?

./templates/
└── node
    ├── arm32v7
    ├── armhf
    └── default

and I imagine we could implement the various watchdog versions with a build-arg to pull the correct one.

How would you handle the various watchdog options that are available now and in the future? There are already a few differences between the current and "of" watchdogs in the different env var options. I can imagine future watchdogs implementing more drastic differences.

Would it work to point to an install script rather than directly downloading the binary? The install script could set the proper parameters or options. However, that wouldn't work well with a multi-stage build...

[rgee0]

How would the faas template pull behave?

Much as it does now. The number of templates would increase and involve implementation via a convention that the CLI is aware of, but the user doesn't need to be. Remember, the idea is that existing CLI commands should still function with the missing new flags being defaulted to what they'd be today.

I imagine we could implement the various watchdog versions with a build-arg to pull the correct one.

For a build-arg to work - if I'm accurately understanding the suggestion - the watchdog and templates would need to be loosely coupled and interchangeable. If this cannot be guaranteed then the template (of which the watchdog is a sub-component) should be considered the atomic unit. If the template is the atomic unit then we can handle using flags on the CLI.

How would you handle the various watchdog options that are available now and in the future?

As above, if we bring the atomic unit up to the template level then the CLI provides the abstraction. For modes, these are runtime config so could be added at faas deploy ..., probably via -e or an additional flag that maps to -e under the covers.

Just my thoughts, I may have over simplified in places.

Concerns: scaling of templates numbers, support lifetimes, maintenance effort.

[burtonr]

@LucasRoesler @viveksyngh @ewilde @johnmccabe
Do any of you guys have thoughts on this? I ask because it came back up in Slack and would like some more input on how to resolve this so we can begin to introduce the of-watchdog more publicly.

[burtonr]

Trying to bring some attention back to this since it sort of stalled a while back.

I'd be willing to implement something, but I get the feeling we still haven't decided on a solution. No matter the solution, this will require changes across several projects. faas, faas-cli, templates, and possibly also store.

I think adding the additional parameters to the template definitions would be required regardless though. This would be to avoid having to come up with various template names for each "style" of watchdog go, go-http, node, node10-express, and so on.

Starting there, we could then update the CLI to have an additional flag that would match with the added watchdog field in the template. I image something like:

faas new fn1 --lang go --watchdog 2.0
would search the templates with language _like_ go with the 2.0 as the watchdog field.

also, faas-new fn2 --lang go-http would still work since the template name is called out explicitly.

Moving forward, we can create templates with easy names (go, node, etc) where the architecture and watchdog versions are managed by the template.yml files. But, this I think, can be thought through more as the work progresses.

How about the first round of changes happen in the templates project adding the additional field(s) to each of the templates indicating the architecture and watchdog versions. I'd say:

• watchdog = 1.0
• of-watchdog = 2.0
  We could even include watchdog-version to specify the specific release of the watchdog in the template yml if that makes sense, otherwise it could always grab the latest version of the appropriate watchdog on template pull

[alexellis]

The template store resolves this issue for the time being. In any case breaking changes are needed to switch completely to a different set of templates.

[alexellis]

Derek add label: design/review

[alexellis]

Derek close: this was done through the template store.