Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Functions are manipulated in non-annotated namespace #679

Open
martindekov opened this issue Aug 16, 2020 · 2 comments
Open

Functions are manipulated in non-annotated namespace #679

martindekov opened this issue Aug 16, 2020 · 2 comments

Comments

@martindekov
Copy link
Contributor

martindekov commented Aug 16, 2020

Functions should only be created/deleted etc. In namespaces which have annotation openfaas=1/true in faas-netes and operator. Currently the logic rejects secrets created in those namespaces, but creates functions.

Expected Behaviour

Try creating function in namespace which does not have annotation results in failure.

Current Behaviour

Creating function in namespace with no openfaas=1 annotation succeeds.

Possible Solution

Check query namespaces before creating function similar to logic in handlers.ListNamespaces

Steps to Reproduce (for bugs)

  1. Deploy faas-netes/operator with ClusterRole to true to enable multiple namespaces support
  2. Create namespace staging-fn without annotation
  3. Create function check it succeeds
  4. Create secret and check 4xx status

Context

Similar problem exists while developing multiple namespaces support for the operator.

Your Environment

  • FaaS-CLI version ( Full output from: faas-cli version ):
    N/A
  • Docker version docker version (e.g. Docker 17.0.05 ):
    N/A
  • What version and distriubtion of Kubernetes are you using? kubectl version
    N/A
  • Operating System and version (e.g. Linux, Windows, MacOS):
    N/A
  • Link to your project or a code example to reproduce issue:
    N/A
  • What network driver are you using and what CIDR? i.e. Weave net / Flannel
    N/A
@alexellis
Copy link
Member

Is this fixed by #673 @martindekov ?

@martindekov
Copy link
Contributor Author

No Alex, I will open separate PR with this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants