Allow to change CPU arch constraint via commandline argument

[cryptobias]

I was able to start up faas-nomad on my RPi after some fiddling with the configuration, but I unfortunately was not able to run a function without patching the hard-coded CPU architecture constraint.

This might suffice as an alternative to use OpenFaas with Nomad purely on one architecture (e.g. a RPi cluster) until https://github.com/hashicorp/faas-nomad/issues/18 is implemented.

[hashicorp-cla]

All committers have signed the CLA.

[cryptobias]

@acornies Instead of adding a custom constraint name for the CPU architecture I went with a more generic approach. This unfortunately does not support some of the configurations possible with Nomad's constraints, but it might be enough for most use-cases.

Things that are not working are:

• leaving out the attribute (like you would with distinct_hosts)
• leaving out the value (e.g. with is_set)
• using multiple operators (like is_set !=)
• using consecutive white-spaces in the value (they currently will get replaced by just a space)

I am also not sure if it is still necessary to restrict the architecture by default. If you run a mixed setup you will know and can adjust it via the function constraints.

[cryptobias]

It would even have to be: faas-cli store deploy figlet --constraint "job ${attr.cpu.arch} = arm64" --gateway http://example:8080 (notice the job)

I added this part to distinguish this constraint from the datacenter constraint and maybe allow group and task constraints later on, if applicable.

I chose the above approach exactly because it was more based on how Nomad treats it's constraints. This way you can use it to set constraints on more than just the CPU architecture.

The documentation says:

Constraints are passed directly to the underlying container orchestrator.

The examples in the documentation are based on constraints for Docker Swarm. So I think it could be OK to go with a orchestrator based syntax.

The datacenter constraint is a bit special, since it does not get turned into a constraint, but a special property on the job. Maybe it could even be replaced by a ${node.datacenter} = dc1 constraint.

I see however that someone might have a different expectation from reading the documentation and/or experience with other orchestrators.

What would you think of the following changes?:

• get rid of the job prefix
• ignore strings containing datacenter in the first field when creating the constraints
• allow to leave out the ${ and } in the attribute (and automatically add them, if they is missing)
• allow to use == instead of = for compatibility

That way the constraint could be written as attr.cpu.arch == amd64.

Additionally I would adjust the readme for this repository and give an example for setting constraints other than data center and potentially communicate the limitations mentioned in my previous comment.

[acornies]

I like your suggestions. Yes please!

[cryptobias]

@acornies please have another look. I implemented the suggested changes and did a little refactoring for consistency.

[acornies]

One more thing @cryptobias can you rebase these 5 commits down to 1 using git reset --soft HEAD~5 and sign your commit with --signoff? I'll create a 0.4.3-rc1 release after that.

[cryptobias]

@acornies I combined commits into one and signed it.