openfaas / ofc-bootstrap Goto Github PK

We should publish a binary upon GitHub release. Checkout alexellis/inlets as an example of how this is done.

Expected Behaviour

Move any YAML files for Kubernetes to ofc-bootstrap/templates/k8s

Expected Behaviour

We should offer to install IngressController with HostPort for Kubernetes running on bare metal, or where an LB is not available. This could also reduce the cost for testing clusters by removing the need for an LB.

This would also enable the use-case with "k3s" from @ibuildthecloud

Possible Solution

See the Nginx helm chart on configuring a HostPort / Host networking so that the ingress controller binds to port 80/443 from the container.

Expected Behaviour

We should template of-auth-dep's customers_url value as per init.yaml

Current Behaviour

We don't, so it defaults to everyone signed-up to the community cluster

Possible Solution

Add template file / value

Expected Behaviour

Support for lang: dockerfile should be configurable as per - openfaas/openfaas-cloud#422

Current Behaviour

Off by default

Possible Solution

Expose the configuration option in the init.yaml file and then read it and template the configuration accordingly.

Steps to Reproduce (for bugs)

When fixed you can do:

1. Enable dockerfile type in init.yaml
2. Deploy
3. faas-cli new --lang dockerfile tester
4. git push and see the above deployed as an endpoint

At the moment it's configured in two places:

 - name: "of-client-secret"
    literals:
      - name: of-client-secret
        value: "fdshdg2be27e9h67shg9774nfsf89fnbksb0"
    namespace: "openfaas"

and second time in

oauth:
  client_id: 786sdfhg9bgb0bgsbj9
  client_secret: fdshdg2be27e9h67shg9774nfsf89fnbksb0

One possible solution is to add value_from_config option for the secrets and update CreateK8sSecret()

Expected Behaviour

Images are immutable so never need to be pulled than once, this can just generate additional cold-start latency

Current Behaviour

Set the OpenFaaS controller image pull policy to IfNotPresent rather than Always

This option is available via helm: https://github.com/openfaas/faas-netes/tree/master/chart/openfaas#configuration

Steps to Reproduce (for bugs)

0. Deploy with kind - then check the pull policy of the controller in the openfaas/gateway pod - it will be Always
1. Update the scripts which deploy OpenFaaS via helm
2. Deploy with kind - then check the pull policy of the controller in the openfaas/gateway pod - it should now be IfNotPresent

Context

Improving upon any potential cold-start time from idled functions.

Expected Behaviour

We should only create the secrets we need for the user's configuration.

Current Behaviour

We either comment out secrets we don't want or need, or we create them even when we don't need them.

Example: if auth is turned off we should create of-client-secret in the cluster.

Possible Solution

On call with Bart and Ivana, we thought we could detect features enabled from init.yaml such as:

features:
- scm_github
- scm_gitlab
- tls
- auth
- route53_dns01
- gcp_dns01
- do_dns01
- kubernetes
- swarm

Then go on to filter the secrets based upon the list.

The secrets may need a filter to say which features they are enabled for.

  - name: "github-webhook-secret"
    literals:
      - name: "github-webhook-secret"
        value: ""
    namespace: "openfaas-fn"
    filter:
     - github

While reviewing #89 I thought about how to set a timeout on the rollout commands. Go provides a CommandContext that is designed to allow you to cancel a command via a context cancel. See https://golang.org/pkg/os/exec/#CommandContext

The provided context is used to kill the process (by calling os.Process.Kill) if the context becomes done before the command completes on its own.

We should update func (et ExecTask) Execute() (ExecResult, error) to accept a context so that the caller can set a timeout and explicitly control the max length of a command.

Expected Behaviour

Methods like certManagerReady() should look like

func certManagerReady() {
	ctx, cancel := context.WithTimeout(context.Background, 30*time.Second)
	defer cancel()
	task := execute.ExecTask{
		Command: "./scripts/get-cert-manager.sh",
		Shell:   true,
	}

	res, err := task.Execute(ctx)
	fmt.Println("cert-manager", res.ExitCode, res.Stdout, res.Stderr, err)
}

Possible Solution

1. Update the ExecTask to accept a context

func (et ExecTask) Execute(ctx context.Context) (ExecResult, error)

2. If the ctx is nil, then just use contetxt.Background()
3. use exec.CommandContext instead of exec.Command
4. update all calls to Execute to send at least a nil context

Consider using this library or an alternative to generate passwords/secrets: https://github.com/sethvargo/go-password

Expected Behaviour

Add Travis build status label to README.md

https://travis-ci.org/openfaas-incubator/ofc-bootstrap

Expected Behaviour

Allow users to specify the openfaas (system-namespace?) and openfaas-fn (function-namespace?) namespaces.

I'm not sure what the wider impact this has (e.g. openfaas helm deployment, services that aren't using the common templates, etc...)

At the moment every change in the cloud, that's going to templated yaml config file, means manually editing existing templates, as well as regularly checking for changes in the openfaas-cloud repo.

This issue is for suggestion how to resolve that problem.

First option that comes to mind is fully templating OFC, like here, containing all templates in a separate folder, and changing code to just do checkout.

The way we currently use the tool to deploy OpenFaaS Cloud is by pre-reseting the cluster, as it requires a clean environment.
If this is used in production, people may want to be able to update the cloud to latest version or edit their configuration, without loosing their functions.

Expected Behaviour

Provide a way to update the cluster if configuration is edited and/or there is a new version of OpenFaaS Cloud.

Current Behaviour

Running ofc-bootstrap requires clean cluster.

Expected Behaviour

We should not delete all CRDs in the cluster using reset.sh

Current Behaviour

We delete them all, even ones we didn't create and this causes GKE to break when Calico is enabled.

Possible Solution

• Use kind to create cluster
• Run bootstrap code
• examine CRDs
• PR to reset.sh

Expected Behaviour

• Generate ClusterIssuer for staging and production certificates

You'll need the user's email

• Generate a Certificate for the wildcard domain *.domain.tld

DNS01 challenge - allow user to pick AWS Route53 or GCP DNS

^ you'll need to create a secret for the API

• Generate a Certificate for static domain of auth.system.domain.tld

When DO's DNS01 challenge goes into a stable release of cert-manager (not master) we'll add it as a third option giving:

1. AWS Route 53
2. Google Cloud DNS
3. DO

Docs:

https://cert-manager.readthedocs.io/en/latest/reference/issuers/acme/dns01.html#supported-dns01-providers

Expected Behaviour

Deploy all functions from the OpenFaaS Cloud stack file

Current Behaviour

Not deployed

Current Behaviour

2019/01/25 14:56:44 Validating tools available in PATH
exec: kubectl version --client
res: Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-13T23:16:58Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"darwin/amd64"}

exec: openssl version
res: LibreSSL 2.2.7

exec: helm version -c
res: Client: &version.Version{SemVer:"v2.12.2", GitCommit:"7d2b0c73d734f6586ed222a567c5d103fed435be", GitTreeState:"clean"}

exec: faas-cli version
res: ___ _____ ____
/ _ \ _ __ ___ _ __ | | _ __ / |
| | | | ' \ / _ \ ' | | / |/ _ _
| || | |) | / | | | | (| | (| |) |
_/| ./ ___|| ||| _,|_,|__/
||

CLI:
commit: a141dedf94ffeed84412365fd591bdc8999c5a1b
version: 0.8.3

Plan loaded from: init.yaml
{kubernetes [{s3-secret-key [{s3-secret-key }] openfaas-fn []} {s3-access-key [{s3-access-key }] openfaas-fn []} {basic-auth [{basic-auth-user admin} {basic-auth-password }] openfaas []} {payload-secret [{payload-secret }] openfaas []} {jwt-private-key [] openfaas [{key ./tmp/key openssl ecparam -genkey -name prime256v1 -noout -out ./tmp/key}]} {jwt-public-key [] openfaas [{key.pub ./tmp/key.pub openssl ec -in ./tmp/key -pubout -out ./tmp/key.pub}]} {github-webhook-secret [{github-webhook-secret secret}] openfaas-fn []} {private-key [] openfaas-fn [{private-key ~/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem }]} {of-client-secret [{of-client-secret fb58e886977efbece9cd77452be27e9}] openfaas []} {route53-credentials-secret [] kube-system [{secret-access-key ~/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem }]} {registry-secret [] openfaas [{config.json ~/.docker/config.json }]}] stag.o6s.io docker.io/ofctest/ https://raw.githubusercontent.com/openfaas/openfaas-cloud/master/CUSTOMERS {24253 } false {914f3fb036ce9cd774} {cloud-minio.openfaas.svc.cluster.local:9000 us-east-1 false pipeline} false {email@domain route53 prod us-east-1 ASYAKIUJE8AYRQQ7DU3M}}
Orchestration: Kubernetes
2019/01/25 14:56:45 Creating namespaces
exec: scripts/create-namespaces.sh
res: namespace/openfaas unchanged
namespace/openfaas-fn unchanged

2019/01/25 14:56:46 namespace/openfaas unchanged
namespace/openfaas-fn unchanged

2019/01/25 14:56:46
Building Ingress
2019/01/25 14:56:46 Creating Tiller
exec: scripts/create-tiller-sa.sh
res: serviceaccount/tiller created
clusterrolebinding.rbac.authorization.k8s.io/tiller created

2019/01/25 14:56:46 serviceaccount/tiller created
clusterrolebinding.rbac.authorization.k8s.io/tiller created

2019/01/25 14:56:46
exec: scripts/create-tiller.sh
res: Creating /Users/ymeng/.helm
Creating /Users/ymeng/.helm/repository
Creating /Users/ymeng/.helm/repository/cache
Creating /Users/ymeng/.helm/repository/local
Creating /Users/ymeng/.helm/plugins
Creating /Users/ymeng/.helm/starters
Creating /Users/ymeng/.helm/cache/archive
Creating /Users/ymeng/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /Users/ymeng/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run helm init with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

2019/01/25 14:56:46 Creating /Users/ymeng/.helm
Creating /Users/ymeng/.helm/repository
Creating /Users/ymeng/.helm/repository/cache
Creating /Users/ymeng/.helm/repository/local
Creating /Users/ymeng/.helm/plugins
Creating /Users/ymeng/.helm/starters
Creating /Users/ymeng/.helm/cache/archive
Creating /Users/ymeng/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /Users/ymeng/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run helm init with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

2019/01/25 14:56:46
2019/01/25 14:56:46 Is tiller ready? 1/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:48 Is tiller ready? 2/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:51 Is tiller ready? 3/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:53 Is tiller ready? 4/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:55 Is tiller ready? 5/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:57 Is tiller ready? 6/260
exec: ./scripts/get-tiller.sh
res:
tiller 0
2019/01/25 14:56:59 Is tiller ready? 7/260
exec: ./scripts/get-tiller.sh
res: 1
tiller 0 1
2019/01/25 14:57:00 Creating Ingress Controller
exec: scripts/install-nginx.sh
res:
2019/01/25 14:57:00
2019/01/25 14:57:00 Error: failed to download "stable/nginx-ingress" (hint: running helm repo update may help)

[{s3-secret-key [{s3-secret-key }] openfaas-fn []} {s3-access-key [{s3-access-key }] openfaas-fn []} {basic-auth [{basic-auth-user admin} {basic-auth-password }] openfaas []} {payload-secret [{payload-secret }] openfaas []} {jwt-private-key [] openfaas [{key ./tmp/key openssl ecparam -genkey -name prime256v1 -noout -out ./tmp/key}]} {jwt-public-key [] openfaas [{key.pub ./tmp/key.pub openssl ec -in ./tmp/key -pubout -out ./tmp/key.pub}]} {github-webhook-secret [{github-webhook-secret secret}] openfaas-fn []} {private-key [] openfaas-fn [{private-key ~/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem }]} {of-client-secret [{of-client-secret fb58e886977efbece9cd77452be27e9}] openfaas []} {route53-credentials-secret [] kube-system [{secret-access-key ~/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem }]} {registry-secret [] openfaas [{config.json ~/.docker/config.json }]}]
exec: scripts/generate-sha.sh
res: 88c5b508aa948ad0a98bbe41beda975617dbb20a
exec: kubectl create secret generic -n openfaas-fn s3-secret-key --from-literal=s3-secret-key=b0bbfac932eaefe8140065ba2fbbc50c7b2053803b6873b2975c1a88133e0ec2
res: secret/s3-secret-key created

{secret/s3-secret-key created
0}
exec: scripts/generate-sha.sh
res: 8a3f2a2b80bcacbb9cfb2009d4969c50e356daff
exec: kubectl create secret generic -n openfaas-fn s3-access-key --from-literal=s3-access-key=624e104bc5d133bd8e5d13c53718cd6695ec8fdcdfad5078e390413e9fc16a60
res: secret/s3-access-key created

{secret/s3-access-key created
0}
exec: scripts/generate-sha.sh
res: b0a444eade65da6e87927c799e983b6abcf78907
exec: kubectl create secret generic -n openfaas basic-auth --from-literal=basic-auth-user=admin --from-literal=basic-auth-password=6f3db25f694a3fd11a843cbed04ea2d69569812febec65b76b5c1aabd660b9b9
res: secret/basic-auth created

{secret/basic-auth created
0}
exec: scripts/generate-sha.sh
res: 8019f5585faeba00301c8c02482ce0935d054e22
exec: kubectl create secret generic -n openfaas payload-secret --from-literal=payload-secret=8328c3334a07d524f2395ece87fe211cebb250b80e78085fd6972822f725290f
res: secret/payload-secret created

{secret/payload-secret created
0}
exec: openssl ecparam -genkey -name prime256v1 -noout -out ./tmp/key
res:
exec: kubectl create secret generic -n openfaas jwt-private-key --from-file=key=./tmp/key
res: secret/jwt-private-key created

{secret/jwt-private-key created
0}
exec: openssl ec -in ./tmp/key -pubout -out ./tmp/key.pub
res:
exec: kubectl create secret generic -n openfaas jwt-public-key --from-file=key.pub=./tmp/key.pub
res: secret/jwt-public-key created

{secret/jwt-public-key created
0}
exec: kubectl create secret generic -n openfaas-fn github-webhook-secret --from-literal=github-webhook-secret=secret
res: secret/github-webhook-secret created

{secret/github-webhook-secret created
0}
exec: kubectl create secret generic -n openfaas-fn private-key --from-file=private-key=/Users/ymeng/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem
res: secret/private-key created

{secret/private-key created
0}
exec: kubectl create secret generic -n openfaas of-client-secret --from-literal=of-client-secret=fb58e886977efbece9cd77452be27e9
res: secret/of-client-secret created

{secret/of-client-secret created
0}
exec: kubectl create secret generic -n kube-system route53-credentials-secret --from-file=secret-access-key=/Users/ymeng/Downloads/openfaascloudtest-example.2019-01-25.private-key.pem
res: secret/route53-credentials-secret created

{secret/route53-credentials-secret created
0}
exec: kubectl create secret generic -n openfaas registry-secret --from-file=config.json=/Users/ymeng/.docker/config.json
res: secret/registry-secret created

{secret/registry-secret created
0}
2019/01/25 14:57:02 Creating Minio
exec: scripts/install-minio.sh
res:
2019/01/25 14:57:03
2019/01/25 14:57:03 Error: failed to download "stable/minio" (hint: running helm repo update may help)

2019/01/25 14:57:03 Creating Cert-Manager
exec: scripts/install-cert-manager.sh
res:
2019/01/25 14:57:03
2019/01/25 14:57:03 Error: failed to download "stable/cert-manager" (hint: running helm repo update may help)

2019/01/25 14:57:03 Creating secrets for functions to consume
exec: scripts/create-functions-auth.sh
res: secret/basic-auth-user created
secret/basic-auth-password created

2019/01/25 14:57:04 secret/basic-auth-user created
secret/basic-auth-password created

2019/01/25 14:57:04
2019/01/25 14:57:04 Creating OpenFaaS
exec: scripts/install-openfaas.sh
res: "openfaas" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "openfaas" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
Release "openfaas" does not exist. Installing it now.

2019/01/25 14:57:07 "openfaas" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "openfaas" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
Release "openfaas" does not exist. Installing it now.

2019/01/25 14:57:07 Error: release openfaas failed: configmaps "alertmanager-config" already exists

exec: kubectl apply -f tmp/generated-ingress-ingress-wildcard.yaml
res: ingress.extensions/openfaas-ingress created

2019/01/25 14:57:08 ingress.extensions/openfaas-ingress created

exec: kubectl apply -f tmp/generated-ingress-ingress.yaml
res: ingress.extensions/openfaas-auth-ingress created

2019/01/25 14:57:08 ingress.extensions/openfaas-auth-ingress created

Creating stack.yml
2019/01/25 14:57:08 Creating SealedSecrets
exec: scripts/install-sealedsecrets.sh
res: SealedSecrets release: v0.7.0
customresourcedefinition.apiextensions.k8s.io/sealedsecrets.bitnami.com created
serviceaccount/sealed-secrets-controller created
deployment.apps/sealed-secrets-controller created
service/sealed-secrets-controller created
rolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
role.rbac.authorization.k8s.io/sealed-secrets-key-admin created
clusterrolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
clusterrole.rbac.authorization.k8s.io/secrets-unsealer created

2019/01/25 14:57:14 SealedSecrets release: v0.7.0
customresourcedefinition.apiextensions.k8s.io/sealedsecrets.bitnami.com created
serviceaccount/sealed-secrets-controller created
deployment.apps/sealed-secrets-controller created
service/sealed-secrets-controller created
rolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
role.rbac.authorization.k8s.io/sealed-secrets-key-admin created
clusterrolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
clusterrole.rbac.authorization.k8s.io/secrets-unsealer created

2019/01/25 14:57:14
2019/01/25 14:57:14 Are SealedSecrets ready? 1/260
exec: ./scripts/get-sealedsecretscontroller.sh
res:
sealedsecretscontroller 0
2019/01/25 14:57:16 Are SealedSecrets ready? 2/260
exec: ./scripts/get-sealedsecretscontroller.sh
res:
sealedsecretscontroller 0
2019/01/25 14:57:18 Are SealedSecrets ready? 3/260
exec: ./scripts/get-sealedsecretscontroller.sh
res:
sealedsecretscontroller 0
2019/01/25 14:57:20 Are SealedSecrets ready? 4/260
exec: ./scripts/get-sealedsecretscontroller.sh
res:
sealedsecretscontroller 0
2019/01/25 14:57:22 Are SealedSecrets ready? 5/260
exec: ./scripts/get-sealedsecretscontroller.sh
res:
sealedsecretscontroller 0
2019/01/25 14:57:24 Are SealedSecrets ready? 6/260
exec: ./scripts/get-sealedsecretscontroller.sh
res: 1
sealedsecretscontroller 0 1
exec: ./scripts/export-sealed-secret-pubcert.sh
res: SealedSecrets release: v0.7.0
-----BEGIN CERTIFICATE-----
MIIErjCCApagAwIBAgIRANq1bsX6zBfrQSGA1Y7JBKMwDQYJKoZIhvcNAQELBQAw
ADAeFw0xOTAxMjUxOTU3MjRaFw0yOTAxMjIxOTU3MjRaMAAwggIiMA0GCSqGSIb3
DQEBAQUAA4ICDwAwggIKAoICAQC2oUtWy101dj7Wxh91e+IZ0WMDGP6NgX7xVWKr
wqcRPpEbvIhxGodCybNLJEqOi9eSu1MIX4QhzSOfnRH5c3u+Jefjpge7dOurxWW8
pptussvFS4751eIIKm9kUMi5WuwzxPHG/+qxByuNSLaRV6sRFogyZ8kuIlDhi1Ow
iU6wRhci6aZYhNQkNPrWfsO5TtQfmplY0wS+Plj/BYspuwEDMh7Dx/A5ESiDY7w9
zB7dKcLKFe4kT27VDZbhrTnGN0UjxhMx0sSkaiETFDc/IGdgFdwcSZlu9hAKe7AH
u285hxMQUvt3J7U5rpmKLsTtWOCPpjdHqkGJSm3PVI4BLqntCIiK0aln/f5/4poQ
EvVh+QK7TQfpoahMWXQYKk+MXI0XWnWLC4QcwjbmUiw1K1ickSGYQ4wxFPCuadEs
BvTuJ+JehQmretwc+kBFYA2g3nAeKa3Bp0lOkZE7LoYsOvfmpLuWfekjqrN+MCAl
roxcsEMnxYjdw8j/ulDQRAuW1uOLL9OanNB4RGlr7rBz1+/9VBZb8DsOlOaYjT14
SVrruxNC+yB6ZTBQed/jaVZ/KFrP+R+QkKDee9Ct6Q9Y/rv9iPhHFljH5C9Ve0LW
SJ9LKhpDzeFmfhV8O9wIikBe4ACnKqfb3wiuLaStplLnsqDNJF4cR2tesTGDkTRG
AnW00QIDAQABoyMwITAOBgNVHQ8BAf8EBAMCAAEwDwYDVR0TAQH/BAUwAwEB/zAN
BgkqhkiG9w0BAQsFAAOCAgEAXKjQY7PmZUUlhey9bPiHlbi9T6RQ5+a6v5ap9VWX
tBY027DJXgrjZRgKzm/oo74vh8bL6jzNfUpzHxP4wDG3V70MLkfXrOYEPva1kzZ6
4dwEz9Qu6OW4sZJmfNNKhf5BVAf6tfobRqtM6nJQAqZqNxryPebIFUOkOVW6A0hC
kkDQ+3oUsEweSGBhKJT6juLOqV8nrU+MzNOJ/XO0LzfMrOhUDTuJeTv1UjvChVeY
uvK3rt++Q+SajbOaPpW1S4HPvAcv3qM/YOvGdwWEWzAimz0bmLwglskZtj5trGY5
x9qE/ZqccLcPOe4TVCWkZD90FcFMtD/BwUC2AJUDuDpZCdcIjVpc8O4Nv0+3R38L
+BwezTym5+mGDhr3ixRj4PvTul2y3iMLa/+tSV3+n5FigMcc9ARFn7QMxmfi0twT
+rL5K49bTOryXl9yVaNnmLoopsCfLqUFlyVtjOS7WeCspwVOPQrkRudw6bq2HOy4
laDdquUkMwOhAhl2JzCSDyq9j28I3CFcjSyQpcWTWGI3CWObAqRQXtC1f0mi/rPW
Fjl0d77NK8oYzgPI7g2aOv4zE2yKaJ5Psz8nvZoof9Go8cEzf9yXILwMXC8C4GEt
Z5F6THp7WgsahZuZ1e+4adhZjUzb0Fbq5RvoxJ3s6frMHra0vHGmOFh7RO/ULnlZ
nZI=
-----END CERTIFICATE-----

secrets cert 0 SealedSecrets release: v0.7.0
-----BEGIN CERTIFICATE-----
MIIErjCCApagAwIBAgIRANq1bsX6zBfrQSGA1Y7JBKMwDQYJKoZIhvcNAQELBQAw
ADAeFw0xOTAxMjUxOTU3MjRaFw0yOTAxMjIxOTU3MjRaMAAwggIiMA0GCSqGSIb3
DQEBAQUAA4ICDwAwggIKAoICAQC2oUtWy101dj7Wxh91e+IZ0WMDGP6NgX7xVWKr
wqcRPpEbvIhxGodCybNLJEqOi9eSu1MIX4QhzSOfnRH5c3u+Jefjpge7dOurxWW8
pptussvFS4751eIIKm9kUMi5WuwzxPHG/+qxByuNSLaRV6sRFogyZ8kuIlDhi1Ow
iU6wRhci6aZYhNQkNPrWfsO5TtQfmplY0wS+Plj/BYspuwEDMh7Dx/A5ESiDY7w9
zB7dKcLKFe4kT27VDZbhrTnGN0UjxhMx0sSkaiETFDc/IGdgFdwcSZlu9hAKe7AH
u285hxMQUvt3J7U5rpmKLsTtWOCPpjdHqkGJSm3PVI4BLqntCIiK0aln/f5/4poQ
EvVh+QK7TQfpoahMWXQYKk+MXI0XWnWLC4QcwjbmUiw1K1ickSGYQ4wxFPCuadEs
BvTuJ+JehQmretwc+kBFYA2g3nAeKa3Bp0lOkZE7LoYsOvfmpLuWfekjqrN+MCAl
roxcsEMnxYjdw8j/ulDQRAuW1uOLL9OanNB4RGlr7rBz1+/9VBZb8DsOlOaYjT14
SVrruxNC+yB6ZTBQed/jaVZ/KFrP+R+QkKDee9Ct6Q9Y/rv9iPhHFljH5C9Ve0LW
SJ9LKhpDzeFmfhV8O9wIikBe4ACnKqfb3wiuLaStplLnsqDNJF4cR2tesTGDkTRG
AnW00QIDAQABoyMwITAOBgNVHQ8BAf8EBAMCAAEwDwYDVR0TAQH/BAUwAwEB/zAN
BgkqhkiG9w0BAQsFAAOCAgEAXKjQY7PmZUUlhey9bPiHlbi9T6RQ5+a6v5ap9VWX
tBY027DJXgrjZRgKzm/oo74vh8bL6jzNfUpzHxP4wDG3V70MLkfXrOYEPva1kzZ6
4dwEz9Qu6OW4sZJmfNNKhf5BVAf6tfobRqtM6nJQAqZqNxryPebIFUOkOVW6A0hC
kkDQ+3oUsEweSGBhKJT6juLOqV8nrU+MzNOJ/XO0LzfMrOhUDTuJeTv1UjvChVeY
uvK3rt++Q+SajbOaPpW1S4HPvAcv3qM/YOvGdwWEWzAimz0bmLwglskZtj5trGY5
x9qE/ZqccLcPOe4TVCWkZD90FcFMtD/BwUC2AJUDuDpZCdcIjVpc8O4Nv0+3R38L
+BwezTym5+mGDhr3ixRj4PvTul2y3iMLa/+tSV3+n5FigMcc9ARFn7QMxmfi0twT
+rL5K49bTOryXl9yVaNnmLoopsCfLqUFlyVtjOS7WeCspwVOPQrkRudw6bq2HOy4
laDdquUkMwOhAhl2JzCSDyq9j28I3CFcjSyQpcWTWGI3CWObAqRQXtC1f0mi/rPW
Fjl0d77NK8oYzgPI7g2aOv4zE2yKaJ5Psz8nvZoof9Go8cEzf9yXILwMXC8C4GEt
Z5F6THp7WgsahZuZ1e+4adhZjUzb0Fbq5RvoxJ3s6frMHra0vHGmOFh7RO/ULnlZ
nZI=
-----END CERTIFICATE-----

exec: ./scripts/clone-cloud-components.sh
res:
{ Cloning into './tmp/openfaas-cloud'...
0}
exec: ./scripts/deploy-cloud-components.sh
res: deployment.apps/of-builder created
service/of-builder created
clusterrole.rbac.authorization.k8s.io/sealed-secrets-manager created
rolebinding.rbac.authorization.k8s.io/manage-sealed-secrets created
deployment.apps/of-router created
service/of-router created
service/auth created
Creating payload-secret in openfaas-fn
secret/payload-secret created
Fetch templates from repository: https://github.com/openfaas/templates.git at master
Forwarding from 127.0.0.1:31111 -> 8080
Forwarding from [::1]:31111 -> 8080
Checking if OpenFaaS GW is up.
Handling connection for 31111
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: /ui/
Date: Fri, 25 Jan 2019 19:57:43 GMT
Content-Length: 39

Moved Permanently.

Calling the OpenFaaS server to validate the credentials...
Handling connection for 31111
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
credentials saved for admin http://127.0.0.1:31111
Deploying: import-secrets.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/import-secrets

Deploying: system-github-event.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-github-event

Deploying: github-push.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/github-push

Deploying: git-tar.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/git-tar

Deploying: buildshiprun.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/buildshiprun

Deploying: garbage-collect.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/garbage-collect

Deploying: github-status.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/github-status

Deploying: pipeline-log.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/pipeline-log

Deploying: list-functions.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/list-functions

Deploying: audit-event.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/audit-event

Deploying: echo.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/echo

Deploying: system-metrics.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-metrics

Fetch templates from repository: https://github.com/openfaas-incubator/node8-express-template at master
Deploying: system-dashboard.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-dashboard

Deploying: system-list-functions.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-list-functions

{deployment.apps/of-builder created
service/of-builder created
clusterrole.rbac.authorization.k8s.io/sealed-secrets-manager created
rolebinding.rbac.authorization.k8s.io/manage-sealed-secrets created
deployment.apps/of-router created
service/of-router created
service/auth created
Creating payload-secret in openfaas-fn
secret/payload-secret created
Fetch templates from repository: https://github.com/openfaas/templates.git at master
Forwarding from 127.0.0.1:31111 -> 8080
Forwarding from [::1]:31111 -> 8080
Checking if OpenFaaS GW is up.
Handling connection for 31111
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: /ui/
Date: Fri, 25 Jan 2019 19:57:43 GMT
Content-Length: 39

Moved Permanently.

Calling the OpenFaaS server to validate the credentials...
Handling connection for 31111
WARNING! Communication is not secure, please consider using HTTPS. Letsencrypt.org offers free SSL/TLS certificates.
credentials saved for admin http://127.0.0.1:31111
Deploying: import-secrets.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/import-secrets

Deploying: system-github-event.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-github-event

Deploying: github-push.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/github-push

Deploying: git-tar.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/git-tar

Deploying: buildshiprun.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/buildshiprun

Deploying: garbage-collect.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/garbage-collect

Deploying: github-status.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/github-status

Deploying: pipeline-log.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/pipeline-log

Deploying: list-functions.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/list-functions

Deploying: audit-event.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/audit-event

Deploying: echo.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/echo

Deploying: system-metrics.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-metrics

Fetch templates from repository: https://github.com/openfaas-incubator/node8-express-template at master
Deploying: system-dashboard.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-dashboard

Deploying: system-list-functions.
Handling connection for 31111
Handling connection for 31111

Deployed. 202 Accepted.
URL: http://127.0.0.1:31111/function/system-list-functions

cp: ./tmp/generated-of-auth-dep.yml: No such file or directory
2019/01/25 14:57:41 Attempting to expand templates from https://github.com/openfaas/templates.git
2019/01/25 14:57:41 Fetched 15 template(s) : [csharp csharp-armhf dockerfile go go-armhf java8 node node-arm64 node-armhf php7 python python-armhf python3 python3-armhf ruby] from https://github.com/openfaas/templates.git
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 39 100 39 0 0 1278 0 --:--:-- --:--:-- --:--:-- 1300
2019/01/25 14:57:51 Attempting to expand templates from https://github.com/openfaas-incubator/node8-express-template
2019/01/25 14:57:51 Fetched 2 template(s) : [node8-express node8-express-armhf] from https://github.com/openfaas-incubator/node8-express-template
0}
Plan completed in 68.837006 seconds

Steps to Reproduce (for bugs)

Just follow the steps in this instructions.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  0.8.3

• Docker version docker version (e.g. Docker 17.0.05 ):
  Docker 18.09.1

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Kubernetes (FaaS-netes)

• Operating System and version (e.g. Linux, Windows, MacOS):
  MacOS

• Link to your project or a code example to reproduce issue:

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

We can use the blocking command

Expected Behaviour

We can use kubectl rollout status instead of looping to see if various services / deployments have come up / are ready. Found this out via @zeerorg

Current Behaviour

We are looping in code.

Possible Solution

Try out kubectl rollout status instead for things like checking cert-manager / SealedSecrets / Tiller etc are up and ready for the next stage.

Expected Behaviour

All core services apart from SealedSecrets use helm charts, but there is a helm chart available now, so let's move to it:

https://github.com/helm/charts/tree/master/stable/sealed-secrets

If someone has specified a private key / secret name then we should use that too and allow an override.

This would let us migrate OFC from one cluster to another retaining the same private key for encrypting SealedSecrets.

Expected Behaviour

We should regularly sync the templated stack.yml in this repo for OpenFaaS Cloud and the upstream untemplated file in the openfaas/openfaas-cloud repo.

This task is to sync all image versions and labels in:

• stack.yml
• gitlab.yml

(source)
Non-templated files: https://github.com/openfaas/openfaas-cloud

(target)
Templated files: https://github.com/openfaas-incubator/ofc-bootstrap/tree/master/templates

Expected Behaviour

This should work on GKE

Current Behaviour

It doesn't and gives an error when creating the sealed secrets controller

Possible Solution

This command should be included, but if and only if the user is deploying to GKE. We could also have this as a pre-requisite in the README.

kubectl create clusterrolebinding "cluster-admin-$(whoami)" \
    --clusterrole=cluster-admin \
    --user="$(gcloud config get-value core/account)"

Steps to Reproduce (for bugs)

Context

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

• Docker version docker version (e.g. Docker 17.0.05 ):

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?

• Operating System and version (e.g. Linux, Windows, MacOS):

• Link to your project or a code example to reproduce issue:

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

All functions currently run as non-root given that they must use certain templates which are non-root. The Dockerfile template is currently turned off but represents a way that a user can turn root back on.

This change would use the PR from faas-netes and update the helm chart installation flags.

openfaas/faas-netes#419 (merged)

Expected Behaviour

Cloning the project, copying example.init.yaml to init.yaml (modify config options for TLS, Oauth, github app, etc), and running ./ofc-bootstrap should deploy to cluster the full installation without errors.

Current Behaviour

During the installation w/ the current master, the ./scripts/deploy-cloud-components.sh will fail on missing basic-auth secret. Kubectl port forward will fail, the logic for "Checking if OpenFaas GW is up" will fail, etc.

Possible Solution

Add basic_auth=true back into example.init.yaml, modify filters for secrets to set basic_auth to default, add BasicAuth bool back into pkg/types/types.go Plan struct.

Steps to Reproduce (for bugs)

1. create a clean local env
2. create a new kubernetes cluster
3. clone the project
4. attempt to run ./ofc-bootstrap with your modified init.yaml file

Context

Cannot access the openfaas-cloud install, missing github functions, clusterissuer deployments also fail and need to be manually applied.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ): 0.8.3

• Docker version docker version (e.g. Docker 17.0.05 ): 18.09.2

• Are you using Docker Swarm or Kubernetes (FaaS-netes)? Kubernetes

• Operating System and version (e.g. Linux, Windows, MacOS): MacOS Mojave

• Link to your project or a code example to reproduce issue:

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

At the moment templates are generated with three different approaches in stack.go, tls.go and ingress.go.

These can be refactored to use common methods.

Needs adding unit tests as well.

Expected Behaviour

The local charts should be up to date

Current Behaviour

Depending on timing it may error.

Error: failed to download "stable/nginx-ingress" (hint: running helm repo update may help)

./ofc-bootstrap -yaml=init.yaml with TLS to false still errors because do-access-token is missing

Expected Behaviour

I believe with TLS off, it should not need do-access-token

Current Behaviour

CLI:
commit: a141dedf94ffeed84412365fd591bdc8999c5a1b
version: 0.8.3

panic: stat /home/burf2000/Downloads/do-access-token: no such file or directory

goroutine 1 [running]:
main.main()
/home/burf2000/work/src/github.com/openfaas-incubator/ofc-bootstrap/main.go:114 +0x8e3

Possible Solution

I guess use DO?

Steps to Reproduce (for bugs)

./ofc-bootstrap -yaml=init.yaml

Context

Your Environment

Ubuntu 16.04

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

Expected Behaviour

• Step: deploy OpenFaaS Cloud dashboard

Current Behaviour

Dashboard is not deployed

Current Behaviour

2019/04/09 22:12:44 template: templates/gateway_config.yml:38:28: executing "templates/gateway_config.yml" at <.EnableDockerfileLan...>: can't evaluate field EnableDockerfileLang in type stack.gatewayConfig

This happened on Linux with enable_dockerfile_lang: true in init.yaml

I also had the following errors after that:

 cp: cannot stat './tmp/generated-gateway_config.yml': No such file or directory
cp: cannot stat './tmp/generated-github.yml': No such file or directory
cp: cannot stat './tmp/generated-slack.yml': No such file or directory
cp: cannot stat './tmp/generated-dashboard_config.yml': No such file or directory
cp: cannot stat './tmp/generated-of-auth-dep.yml': No such file or directory
2019/04/09 22:13:13 Attempting to expand templates from https://github.com/openfaas/templates.git
2019/04/09 22:13:15 Fetched 15 template(s) : [csharp csharp-armhf dockerfile go go-armhf java8 node node-arm64 node-armhf php7 python python-armhf python3 python3-armhf ruby] from https://github.com/openfaas/templates.git
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    39  100    39    0     0    105      0 --:--:-- --:--:-- --:--:--   105
cp: cannot stat '../generated-stack.yml': No such file or directory

I assume these are related due to the issue stopping the template flow.

Expected Behaviour

Add a Dockerfile similar to the openfaas/faas-cli to build a binary for Darwin (MacOS) and Linux. ARM is not required.

Add a make dist option also.

Current Behaviour

User or maintainer builds binaries manually.

Expected Behaviour

I should be able to select GitHub or GitLab as my SCM (source control management) provider through init.yaml including any other secrets which may be required for it.

Current Behaviour

Not available via automation.

Expected Behaviour

* [ ] Refactor: default to init.yaml if present

Current Behaviour

Need to pass -yaml

Expected Behaviour

We should try updating cert-manager to the latest stable, if not latest alpha which contains the DO DNS01 challenge.

Current Behaviour

We're on an older, easier to automate version. When updating try re-running the scenario over several times including the reset script. This is where the newer versions were failing earlier when creating the CRDs.

Some suggestions to make the readme easier to read and follow along

Expected Behaviour

No doubt when "pulling the trigger" and executing the ofc-bootstrap. Knowing that you've completed all the steps, and set all the values properly

Current Behaviour

Having to read through the readme several times to make sure all the steps were completed and nothing was missed.

Had to go back and forth between the openfaas-cloud/docs page and here to be certain.

Possible Solution

• Move the "Roadmap" section to a separate file
  • Possibly also the "Status" section, but I can see where that could be useful to remain
• Add section just for the Github App setup
  • Similar to the Create Your Github App section in openfaas-cloud
  • List out the sections (in order of presence) and what value should be put there
• Update DNS section with a little more detail
  • Call out the command to get public IP of the LoadBalancer (hidden in text)
  • Describe all the DNS fields required (A record, etc)
• Have an explicit list of fields from the init.yml that are required to change
  • Currently, you have to read through the entire document and the init.yml file to know what needs changed
  • Without an explicit list, you have to read through everything multiple times to know you didn't miss anything
  • Check box each of the fields so users can check them off when they're complete to avoid confusion (was this the default value, or did I already update it?)
• Different formatting for optional steps
  • The optional sections blend in and are difficult to know where they end and required steps start again
  • Maybe a quote section > to indicate the beginning and end of the optional sections?
  • Also, good to know why it's optional. "Password auto-generated", "If Running locally", etc

Other things I may have missed/overlooked?

Steps to Reproduce (for bugs)

Be a user who doesn't have extensive OpenFaaS, Kubernetes, Github App, and DNS expertise

Not really a bug

Context

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  0.8.3

• Docker version docker version (e.g. Docker 17.0.05 ):
  18.06.2-ce

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Kubernetes

• Operating System and version (e.g. Linux, Windows, MacOS):
  Ubuntu 18.10

• Link to your project or a code example to reproduce issue:
  N/A

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

It's not available in helm/charts, as blocked by #10830 and #90

Once it's in the repo, update install-cert-manager.sh to use v0.6.0 and test in all existing DNS Services (GC DNS and Route53) with enabled TLS.

The version is currently available in jetstack chart repo

helm repo add jetstack https://charts.jetstack.io/
helm repo update
helm install \
    --name cert-manager \
    --namespace kube-system \
    --version v0.6.0 \
    jetstack/cert-manager

Follow up of #28

Needs extra annotation if installed into an existing namespace (as in our case it's in kube-system):

kubectl label namespace kube-system certmanager.k8s.io/disable-validation=true

https://cert-manager.readthedocs.io/en/latest/admin/resource-validation-webhook.html#tls-configuration

Proposed idea: Optionally replace the NGINX Ingress with NGINX-based Kong controller.

Expected Behaviour

Use Kong as the K8 ingress controller to realize the benefits of an API gateway protecting the OpenFaas endpoints. Not many people want their functions exposed to the public Internet and additionally not all want to have a seperate https URL for each endoint. Would be great to have Kong direct and protect traffic to a function from a single https://api.server.com/function or even several https://function.api.server.com/ endpoints.

Possible Solution

https://github.com/luispabon/kong-certbot-agent provided an LE manager for Kong.

Context

Secure API Gateway protected functions.

Your Environment

Kubernetes, minikube, Mac OS, Postgres, OpenFaas, Kong local dev setup for goal of a vendor-neutral portable cloud platform

Expected Behaviour

https://github.com/openfaas/openfaas-cloud/tree/master/docs#create-an-internal-trust-secret

Current Behaviour

Not implemented.

Possible Solution

Add to init.yaml's secrets section.

I entered a sentence for the value in my github-webhook-secret in the init.yml file, but when the functions were deploying, they gave an error because they couldn't find they secret. In the output, there is an error when the secret is being created saying "error: exactly one NAME is required, got 7".

I'm not as familiar with go (as I am with JavaScript), but I quoted the value in pkg/types/secrets and it still gave the error. The command looked like it would be correct.

Expected Behaviour

Secrets should be allowed to contain spaces.

Current Behaviour

Error when creating secrets: "error: exactly one NAME is required, got 7".

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

CLI:
 commit:  70ebebb71f015f4edb0c3e1f03ef3d262b1d84f6
 version: 0.7.7

• Docker version docker version (e.g. Docker 17.0.05 ):

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Started a Kubernetes cluster through Kind backed by Docker.

• Operating System and version (e.g. Linux, Windows, MacOS):
  MacOS

• Link to your project or a code example to reproduce issue:

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

Expected Behaviour

Skip installing, adding and waiting for cert-manager if "tls: false"

Current Behaviour

We install it anyway and wait for it to get ready.

Possible Solution

Remove it

Steps to Reproduce (for bugs)

1. Skip cert-manager if "tls: false" and see cert-manager (which creates TLS certificates) getting installed

Expected Behaviour

Longer builds 5-15min should work with the default configuration without the user needing to apply tweaks.

Current Behaviour

I installed on DO K8s and scheduled a build which took longer than expected and then I saw that the GitHub check for the stack deploy got an "x". Extending the timeout appeared to fix this.

Possible Solution

Update defaults in:

https://github.com/openfaas-incubator/ofc-bootstrap/blob/master/scripts/install-openfaas.sh

We can use Go Duration notations, so should use "5m" instead of "300s"

• Evaluate all timeouts including async timeouts and update.

Expected Behaviour

No errors

Current Behaviour

sealedsecretscontroller 0   <nil>
2019/02/10 20:23:19 Are SealedSecrets ready? 8/260
exec:  ./scripts/get-sealedsecretscontroller.sh
res: 1
sealedsecretscontroller 0 1  <nil>
exec:  ./scripts/export-sealed-secret-pubcert.sh
res: 
secrets cert 0  ./scripts/export-sealed-secret-pubcert.sh: line 17: ./kubeseal: Permission denied
 <nil>
exec:  ./scripts/clone-cloud-components.sh

Possible Solution

Verify if anything is needed in the scripts which are running here.

Expected Behaviour

[ ] Step: deploy container builder (buildkit)

Current Behaviour

Not available

I'd like to be able to set my own configuration for the S3 properties.

Expected Behaviour

Allow setting S3 properties in init.yaml, which will be populated in gateway_config.yaml. The properties should default to the minio settings currently being used.

Current Behaviour

S3 properties are hardcoded to minio settings.

Possible Solution

Add S3 struct to read properties from init.yaml and templates to templates/gateway_config.yaml.

I'm working on a PR for this.

Expected Behaviour

Template the URL for the "slack_url" so that people can get an audit trail in their Slack workspaces from the OFC deployment.

When deploying OFC on EKS, cert-manager-webhook pod ends in a CrashLoopBackOff

Expected Behaviour

cert-manager-webhook Pod should be in Running state

Current Behaviour

cert-manager-webhook Pod ends in CrashLoopBackOff state

Possible Solution

There is an issue with API aggregation certificates on EKS (see cert-manager/cert-manager#1220 and aws/containers-roadmap#152).
A possible solution is to use helm chart v0.6.6 (which use v0.6.2 of cert-manager)

Steps to Reproduce (for bugs)

1. Launch an EKS cluster
2. Configure OFC init.yml and run ./ofc-bootstrap

Context

The process of ofc-bootstrap didn't complete successfully.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):
  CLI:
  commit: a141dedf94ffeed84412365fd591bdc8999c5a1b
  version: 0.8.3
• Docker version docker version (e.g. Docker 17.0.05 ):
  Client:
  Version: 17.06.2-ce
  API version: 1.30
  Go version: go1.8.3
  Git commit: 3dfb8343b139d6342acfd9975d7f1068b5b1c3d3
  Built: Tue Nov 14 22:03:51 2017
  OS/Arch: linux/amd64

Server:
Version: 17.06.2-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 402dd4a/17.06.2-ce
Built: Tue Nov 14 22:04:39 2017
OS/Arch: linux/amd64
Experimental: false

• Are you using Docker Swarm or Kubernetes (FaaS-netes)?
  Kubernetes:
  Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-12-06T01:33:57Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
  Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
• Operating System and version (e.g. Linux, Windows, MacOS):
  Amazon Linux 2
• Link to your project or a code example to reproduce issue:
  Just run ofc-bootstrap to provision OFC over EKS

Expected Behaviour

If using a private remote registry we should create a pull secret in the cluster when using Kubernetes.

Current Behaviour

When using the Docker Hub we generally auth for pushing, but don't auth for pulling because we use public images. With a private registry users need to add a "pull secret" afterwards. https://docs.openfaas.com/deployment/kubernetes/#use-a-private-registry-with-kubernetes

Possible Solution

Can we parse the docker/config.json file, find the server entry needed and then create the secret programatically from the one which has already been provided?

https://docs.openfaas.com/deployment/kubernetes/#use-a-private-registry-with-kubernetes

Expected Behaviour

The user should set a new flag in init.yaml called scale_to_zero or similar.

https://github.com/openfaas/faas-netes/tree/master/chart/openfaas#configuration

Current Behaviour

Users can update this manually.

Possible Solution

This should be passed through to https://github.com/openfaas-incubator/ofc-bootstrap/blob/master/scripts/install-openfaas.sh#L6 where it can be passed into the faasIdler.dryRun flag of the helm chart.

If scale_to_zero is enabled, then dryRun takes the inverse i.e. false.

Add scale_to_zero as false in init.yaml.

Steps to Reproduce (for bugs)

When complete here's the acceptance criteria:

1. User can set scale_from_zero: true in init.yaml
2. kubectl describe faas-idler -n openfaas shows dryRun is set to false.
3. User then sets scale_from_zero: false in init.yaml OR comments out the line
4. kubectl describe faas-idler -n openfaas shows dryRun is set to true.

Context

This could add efficiency savings to OpenFaaS Cloud operators

Getting an error when running ofc-bootstrap on windows in git bash.

Expected Behaviour

The script shouldn't give an error and continue.

Steps to Reproduce (for bugs)

Run ofc-bootstrap in windows under git bash.

Context

Trying to setup openfaas cloud from windows dev machine.

Your Environment

• FaaS-CLI version 0.8.1:

• Docker version 18.09.1:

• Kubernetes?

• Windows:

• Link to your project or a code example to reproduce issue:

• Please also follow the troubleshooting guide and paste in any other diagnostic information you have:

Error log:

The kubernetes cluster was hosted on DigitalOcean

Expected Behaviour

We can reduce CPU overhead by using httpProbes in the helm chart when installing OpenFaaS via helm.

Current Behaviour

exec healthchecks are being used

Expected Behaviour

We should backport the templated Kubernetes changes to openfaas-cloud and look to create a small helm chart for it. This means we can concentrate on the files which are common between Swarm / K8s.

Current Behaviour

They'll have to be maintained separately