Proposal: third-party templates via GitHub

[alexellis]

Expected Behaviour

Anyone should be able to download a community-supported 3rd party template for Perl, PHP, Kotlin etc.

Current Behaviour

PRs to main project.

Possible Solution

I'm open to input on this too.

$ faas-cli add-template https://github.com/alexellis/kotlin-template

Downloading https://github.com/alexellis/kotlin-template/master/blob/master.zip
Expanding kotlin/Dockerfile to template/kotlin/Dockerfile
...

Repo structure:

./template/kotlin/Dockerfile
./template/kotlin/handler.java
./README.md

Initial version of this can be a "dumb" shortcut to download a zip file and unzip into a directory.

Out of scope for v1:

• Listing templates installed locally
• Online directory of templates

Mentions: @johnmccabe and others for the suggestion. @nicholasjackson how does Hashicorp do this?

Other files which need changes:
#82 (comment)

fprocess needs to come out of the Golang code and sit in a template.yml file within i.e. ./template/kotlin/template.yml

language: kotlin
fprocess: kotlin handler.kotlin

[rgee0]

Questions:

Should alternative templates for a language overwrite one another?
If so, should overwriting of "official" templates be allowed?

[ericstoekl]

I'm happy to take on this issue if that's okay. Should have a first-run of it committed by tonight (west coast time).

[ericstoekl]

Derek add label: skill/intermediate

[alexellis]

@rgee0 - maybe we should "cowardly refuse" to overwrite files?

@ems5311 absolutely, please do. I'd see this as re-using some of the work around "fetchTemplates".

[alexellis]

Derek add label: skill/intermediate

[alexellis]

@ems5311 added some more detail in the original comment.

[ericstoekl]

@alexellis, Should this change expect there to be a separate template.yml file in each template folder? And would the schema of that file be just language: and fprocess:?

[alexellis]

In terms of decoupling the Golang code I think yes. What's your take on it?

[austinfrey]

would it make sense to have all templates in their own individual repo? officially supported and custom? officially suportted could still be used on the command line with --lang node etc, but have the github URL's hard coded, all others could use custom URL's. this might also eliminate the need to download the entire master.zip jus to grab the templpates. you'd only need to grab exactly what is needed.

[rgee0]

@aafrey I can see some merit to that idea. I did have to read it twice to understand tho, first time through i thought it was saying a single repo full of templates.

I think if we went down this route we'd have to look at putting the officially supported template details into a config/yaml file - rather than hard coding. This would save rebuilding if we added support for a new language and could be pulled from a remote location with an appropriate CLI option.

[austinfrey]

@rgee0 apologies if that was confusing but i think you got what i meant :) each template would have it's own repo OpenFaaS/node-template or OpenFaaS/python-template. Not sure if that would add to much complexity or management overhead, but it could be useful

putting the officially supported template details into a config/yaml file - rather than hard coding
^^ much smarter :)

[ericstoekl]

@alexellis Sorry, missed your comment. Currently the change that is in the PR #87 puts a separate template.yml file into each language's template dir. If we want to change that to something else, that's no problem

[alexellis]

Having a template file is great - exactly what we said above. I think for reducing latency and for quicker maintenance the cli repo would hold all official templates. Third part repos would also contain one or more language templates.

[0xdevalias]

My /2c is that I sort of like the idea of having them in separate repos, but it would increase the overhead of things potentially. That could be solved with some local caching/etc, but at that point, I wonder if we're over engineering things.

I really like the idea that by having separate repo's we can basically reuse the same code paths for 'official' and '3rd party' templates.

Following the comments above by @aafrey, I would expect something like this:

--lang node would pull from github.com/openfaas/template-node
--lang template-node would pull from github.com/openfaas/template-node
--lang foo/bar would pull from github.com/foo/bar
--lang foo/template-bar would pull from github.com/foo/template-bar
--lang gitlab.com/foo/bar would pull from gitlab.com/foo/bar

The 'whitelist' mappings for the 'shortcut' versions for official OpenFaaS could be maintained in a local template included in the CLI repo:

Eg. when lang is one of node, python, etc, use the 'openfaas shortcut'

When no FQDN is supplied, assume github.

When FQDN supplied, pull from that.

Depends if you were thinking of just downloading the master zip, or cloning with git itself, etc.

Would be worth thinking about if/how updates would be handled as well.

I'm kind of thinking along the lines of homebrew/taps/etc in that regard.

[alexellis]

I wonder if we're over engineering things

This.

Let's try out v0.1 of the change with the current bundle coming from the main repo and anything else added through "add-template" and a well-formed URL.

Can someone try out the PR with their own template? It could be i.e. python3.5 which you use for testing.

[ericstoekl]

The way the current PR is written, you need to have your templates directory in a faas-cli project. This is because the template parsing function uses faas-cli-master/ as the hard-coded root directory of the master.zip file.

https://github.com/alexellis/faas-cli/blob/3a2e81471c69275571d71f84c158bb787fb1ad7b/commands/fetch_templates.go#L31

[itscaro]

I propose to move downloaded archives to .cache directory and add --overwrite flag

.cache
-- template-alexellis-faas-cli.zip
-- template-itscaro-openfaas-template.zip

[alexellis]

The way the current PR is written, you need to have your templates directory in a faas-cli project. This is because the template parsing function uses faas-cli-master/ as the hard-coded root directory of the master.zip file.

@ems5311 - if we are able to work out the prefix by convention we can remove the hard-coding.

[alexellis]

@ems5311 @itscaro would either of you like to write a guide for building and using a third-party template and submit it to the FaaS repo under /guide/ ? (this will be a requirement of merging)

[alexellis]

Merged - congratulations to all involved. 🥇 💯 👍

[alexellis]

Work merged in #220