Closed psoares closed 6 years ago
Derek add label: proposal
This can make sense for deploying locally, but how would you deploy to a remote cluster like GKE? How would it know that it's kubernetes and not docker swarm? This might be useful if it only deploys on docker swarm locally.
Hi @psoares, thanks for giving us your feedback on the user experience.
While I can see where you are wanting to get with this, I don't think it's right for the project.
The responsibility of the faas-cli mirrors that of the Docker CLI (it wraps docker
for some operations).
I already addressed the point of having sample functions built-in on Slack saying that you should delete them. We have an issue going back to Jan 2018 which outlines that we plan to remove the samples from the compose stack - in Kubernetes we have no samples in the default deployment.
https://github.com/openfaas/faas/issues/478
I shouldn't need to checkout the project's source code in order to deploy it.
You don't need to do this, but it is the default way to install projects which use Docker Compose / Docker Swarm. On Kubernetes you can use our Helm chart. I also recommended to you on Slack to use Kubernetes in production rather than Docker Swarm.
Please feel free to share your other suggestions via Slack or if you run into issues via GitHub too.
Alex
Derek close: non-goal
If anyone would like to contribute towards creating a separate stack which retains the functions that would be great. The work has been outstanding since January and our Kubernetes flavor already addresses this point.
@ericstoekl Deployment to other platforms could maybe be addressed through an integration of faas-netes with faas-cli ? Meaning faas-cli would be usable for local deployment by default, and with some options for kubernetes?... Anyway, it seems like this is a non goal for the project.
The current mode of deployment of OpenFaas is cumbersome. A "simple" user of the framework needs to checkout the code and run a script. By doing so, he also imports demo functions that he's probably not interested in, and the only way of getting rid of them is to remove them from the
docker-compose.yml
file located at the root of the project.This also makes upgrades difficult. The only thing that I would like to have to upgrade would be the faas-cli itself...
Expected Behaviour
As a user of OpenFaas (as opposed to a project contributor), I should be able to run all the required containers by using only the faas-cli. I shouldn't need to checkout the project's source code in order to deploy it.
The usage instructions would then become, for example for MacOS users:
Upgrading to the latest version of openfaas should involve updating the faas-cli.
e.g.:
Note: this is what is available in the Fn framework.
Current Behaviour
Currently, as a user, I need to checkout the openfaas/faas project and run the
deploy_stack.sh
script located at the root of the project.Upgrading to a newer version involves updating the project source code. If you made changes to
docker-compose.yml
locally (for example to remove unwanted functions), this will result in conflicts.