-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
Support additional args on the tailscale up command #27
Conversation
Thanks for this PR! I'd like your thoughts on an arbitrary "args" parameter vs. whitelisted arguments, such as: - name: Configure Tailscale
include_role:
name: tailscale
vars:
tailscale_accept_routes: false
tailscale_advertise_routes: "{{ subnet_blocks | join(',' }}" Arbitrary "args" would allow people to match tailscale's supported arguments faster, maybe at the cost of a less easier to configure Role. If we go with the former, we can pass arbitrary arguments safely to the command line with: command: tailscale up --authkey={{ tailscale_auth_key | quote }} {{ tailscale_args | quote }} |
Additionally, to get CI tests running please follow https://github.com/artis3n/ansible-role-tailscale#development-and-contributing. I need to update it because I just realized I am not mentioning the GitHub Actions-compatible instructions. Choose a password for I'd love a simpler way to run CI but since we need an |
Yeah there's a few ways to go about this, I initially was going to add specific values but I feel like maintaining that whitelist approach will just be annoying. Other options: tailscale_args:
advertise-routes: "{{ subnet_blocks | join(',') }}"
accept-routes: false
arbitrary-flag: some value Use the argv option on tailscale_args:
- "-advertise_routes={{ subnet_blocks | join(',') }}"
- "-accept-routes=false"
tailscale_default_args:
- "/usr/bin/tailscale"
- "up"
- "-authkey={{ tailscale_auth_key }}"
command:
argv: "{{ tailscale_default_args + tailscaled_args | default([]) }}" I don't really have a strong opinion either way, this way is the smallest change I could make though :) I will have a look at getting the CI working too |
Those CI instructions won't work because the As for the design, I'm thinking arbitrary arguments works for now as Tailscale continues to rapidly develop, and at some point I'll convert it into a |
Going to start thinking about how to enable collaboration with the CI setup. For now, I'm taking your branch and pushing up my own building off of your commits (so your contributions are preserved). The
|
Incorporated the changes in #29 , closing this one |
|
I'm using ansible to deploy tailscale relays into AWS and want to be able to do something like..