Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow to change CPU arch constraint via commandline argument #82
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 #18 is implemented.
@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:
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.
acornies left a comment
Thanks for the updated PR! I have one more suggestion that would make it less nuanced to nomad var interpolation: With your change, the function deploy would look something like:
I'm worried that using
which maps to
It would even have to be:
I added this part to distinguish this constraint from the
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:
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.
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?:
That way the constraint could be written as
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.