Functions with same name in different stacks collide about faas-swarm HOT 10 OPEN

@alexellis what do you think? We could update the the swarm provider so that the service name in docker has a prefix/namespace per gateway. This prefix would be completely internal and would not be exposed to the user in urls or api responses.

from faas-swarm.

I think you are right about needing to add a prefix to the service name, but I think i would rather see tis as something that is configured in the gateway and applied to all functions that are deployed through it instead of extending the yaml. This seems like something that the function author should not really need to care about and that the gateway can solve. It would be even better if the gateway could infer this from the Docker stack in someway so that it can automatically be created without any additional configuration flags

from faas-swarm.

Hi @dschulten thanks for your interest in faas-swarm.

Can I ask if you are using exactly the same Docker network and network label for both stacks?

Can you give step by step bash commands so that one of us can reproduce what you're seeing?

Thanks

Alex

from faas-swarm.

You may also be interested in OpenFaaS Cloud which scopes or namespaces functions to a user-account or organization/project. This may be more suitable for your needs than deploying OpenFaaS to the same set of nodes or same Swarm cluster multiple times.

from faas-swarm.

I am not just interested in openfaas, I am wholly committed ;-)

I needed to customize the vanilla openfaas docker-compose.yml to put the stack behind traefik, and I have added more services into the same file; also I let them use my own common network (not functions). The network name in the docker-compose.yml is the same, but docker swarm creates two separate networks when it creates the stacks. Both are attachable and both are labeled the same, as in the following contrived example:

networks:
  myapps:
    driver: overlay
    attachable: true
    labels:
      - "openfaas=true"

$ docker network ls

NETWORK ID          NAME                          DRIVER              SCOPE
l5zw89zgl2de        development_myapps            overlay             swarm
jfqnphbw3iku        acceptance_myapps             overlay             swarm

If it helps, I can try to create a cleanroom example which shows the setup.

from faas-swarm.

@LucasRoesler that was my first thought, too, but I wasn't sure if a service should know in which swarm stack it is running from an architectural point of view. OTOH if an openfaas stack had a name - which could be passed with faas-cli deploy or a top-level name key in stack.yml or some calculated value, then there would be no dependency on swarm apis.

from faas-swarm.

@dschulten i was thinking that the gateway would simply mutate the name internally, adding the required prefix. The gateway should have a way to determine what it's "name" is, either by asking the swarm api or by a configuration flag at deployment. I would like to avoid changing the stack schema and the cli if we can.

We already have a dependency in the swarm provider on the swarm apis, by definition, so that doesn't concern me. This is a very swarm specific issue that would only be changed in the swarm-provider anyway.

from faas-swarm.

@LucasRoesler If we depend on the swarm api anyway, it's fine. Roughly where in the code would that happen?

from faas-swarm.

The handling of the service name would need to be updated in each of the handlers, which are conveniently located in handlers/. We would need to update to add/remove the name prefix as appropriate

from faas-swarm.

@LucasRoesler I just hit this issue and checked out faas-swarm handlers. The solution you proposed seems reasonable to me.
It would avoid polluting function names with prefixes at the caller side.

from faas-swarm.