It looks like this was changed to use the pro version which requires purchasing a license (or getting a temporary free one). Is there no longer any way to use the non pro version?

Expected Behaviour

To be able to use the OSS version as described in the README.md. It makes it sound like you have to provide a license to "upgrade" to the pro version, but now that seems like a requirement.

Current Behaviour

When installing via helm chart, after the DO vm gets created, the pod fails because it's trying to execute inlets-pro

Possible Solution

Provide options to select non pro version

Is this feature coming? It would be super-useful to be able to support drafts - I want to be able to create a draft release whenever I merge develop to master, and automatically upload the artefacts, so I can type in some release notes, and then publish. Would love if this could support the draft name coming from the create_release step.

Also, as an aside, it would be nice to enhance the error message so that instead of just 'not found', it said 'release not found' - because until I found this issue I spent ages trying to debug the action not finding the assets in the path to upload.... :)

Hi @alexellis, how should we change the ADOPTORS file if we're a personal user and no company or production presence yet?

Your user has to be configured to be able to execute sudo commands without password:

sudo visudo
stephen ALL=(ALL) NOPASSWD:ALL

I would request this information is added to the README

There's a problem with this approach

root@ubuntu-faasd:~# cat  /var/lib/faasd/hosts

127.0.0.1	localhost
10.62.0.1	faasd-provider
10.62.0.103	mongodb

10.62.0.104	basic-auth-plugin

10.62.0.105	nats

10.62.0.106	prometheus

10.62.0.107	gateway

10.62.0.108	queue-worker

10.62.0.109	postgresql

10.62.0.110	redis
root@ubuntu-faasd:~# cat  /var/lib/faasd-provider/hosts

127.0.0.1	localhost
10.62.0.1	faasd-provider
10.62.0.90	basic-auth-plugin

10.62.0.91	nats

10.62.0.92	prometheus

10.62.0.93	gateway

10.62.0.94	queue-worker

10.62.0.95	postgresql

10.62.0.96	redis

10.62.0.97	mongodb
root@ubuntu-faasd:~#root@ubuntu-faasd:~# cat  /var/lib/faasd/hosts

127.0.0.1	localhost
10.62.0.1	faasd-provider
10.62.0.103	mongodb

10.62.0.104	basic-auth-plugin

10.62.0.105	nats

10.62.0.106	prometheus

10.62.0.107	gateway

10.62.0.108	queue-worker

10.62.0.109	postgresql

10.62.0.110	redis
root@ubuntu-faasd:~# cat  /var/lib/faasd-provider/hosts

127.0.0.1	localhost
10.62.0.1	faasd-provider
10.62.0.90	basic-auth-plugin

10.62.0.91	nats

10.62.0.92	prometheus

10.62.0.93	gateway

10.62.0.94	queue-worker

10.62.0.95	postgresql

10.62.0.96	redis

10.62.0.97	mongodb

If there's already a hosts file present in the faasd dir and you end up restarting in order -> faasd-provider -> faasd then faasd-provider reads a stale hosts file which gets updated by faasd when running systemctl restart faasd-provider -> systemctl restart faasd If there isn't a hosts file in the faasd directory, then faasd-provider fails and systemd keeps trying to restart it, and it only successfully restart when faasd starts up and writes a hosts file. So the. trouble starts when you restart the services when there's already a. hosts file present in faasd dir. I think this makes even a stronger argument for not reading the hosts file from faasd-provider.

I would love your opinions on this @alexellis

More details on issue #134

Signed-off-by: Utsav Anand utsavanand2@gmail.com

<!--- Provide a general summary of your changes in the Title above --> Potential fix for #134

Description

<!--- Describe your changes in detail --> Read from from /var/lib/faasd/hosts and write to /var/lib/faasd-provider/hosts to resolve services for the deployed functions.

Motivation and Context

<!--- Why is this change required? What problem does it solve? --> <!--- If it fixes an open issue, please link to the issue here. -->

• [ ] I have raised an issue to propose this change this is required
• [x] Issue #134

How Has This Been Tested?

<!--- Please describe in detail how you tested your changes. --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. -->

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

Commits:

• [x] I've read the CONTRIBUTION guide
• [x] My commit message has a body and describe how this was tested and why it is required.
• [x] I have signed-off my commits with git commit -s for the Developer Certificate of Origin (DCO)

Code:

• [x] My code follows the code style of this project.
• [ ] I have added tests to cover my changes.

Docs:

• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.

K3s has an air-gapped installation method, maybe we can add this to k3sup.

https://rancher.com/docs/k3s/latest/en/installation/airgap/

Expected Behaviour

<!--- If you're describing a bug, tell us what should happen --> <!--- If you're suggesting a change/improvement, tell us how it should work -->

Current Behaviour

<!--- If describing a bug, tell us what happens instead of the expected behavior --> <!--- If suggesting a change/improvement, explain the difference from current behavior -->

Possible Solution

<!--- Not obligatory, but suggest a fix/reason for the bug, --> <!--- or ideas how to implement the addition or change -->

Steps to Reproduce (for bugs)

<!--- Provide a link to a live example, or an unambiguous set of steps to --> <!--- reproduce this bug. Include code to reproduce, if relevant --> 1. 2. 3. 4.

Context

<!--- How has this issue affected you? What are you trying to accomplish? --> <!--- Providing context helps us come up with a solution that is most useful in the real world -->

Your Environment

• What Kubernetes distribution are you using?

kubectl version

• What OS or type or VM are you using for your cluster? Where is it hosted? (for k3sup install/join):

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

uname -a

cat /etc/os-release

"Be part of the solution"

Subject to approval, are you willing to work on a Pull Request for this issue or feature request?

Yes/No

@alexellis I know, the build of my own function works perfectly fine :) It just did not click to me that the store is based on architecture :) I'm running OpenFaas on my 9 node rpi4 kubernetes cluster, and basically learning OpenFaas on it. By the way thanks for all the articles about Kubernetes and OpenFaas on medium.com they were great read.

Thanks @alexellis makes sense, yes I'm on arm64

@Waterdrips ctr uses ctr image import.

To use on an airgapped system:

1. Set pull-policy in /usr/lib/systemd/system/faasd-provider.service:

ExecStart=/usr/local/bin/faasd provider --pull-policy IfNotPresent

2. Build with docker, import with ctr (and don't forget to use the openfaas-fn namespace):

docker build -t my-service-faas:latest frontend -f faasd/my-service/Dockerfile
docker save my-service-faas:latest | ctr -n openfaas-fn image import -

3. "Up" your setup:

faas-cli up --skip-push

Troubleshooting:

• Check your images with: ctr -n openfaas-fn i ls
• Check your stack.yaml to include the correct image name listed above, e.g.: image: my-service-faas:latest

I just deployed latest OpenFass on my kubernetes and when looking on Portal I can see only two store functions "NodeInfo" and "Sha512sum", do I need to update the list somehow as I can see more in the github json...

I will work on this.

Derek assign: me