-
Notifications
You must be signed in to change notification settings - Fork 34
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
Tag hierarchies #2
Comments
Hi @eproxus, This sounds like a very complicated way of doing things so I'd like to understand your setup a bit more. Do you re-use name tags per-role per-env, or just per-env? |
Per env, primarily. |
Actually, I would be perfectly fine if I could throw in |
I guess there are a couple of different ways we could try and do this, I think my favourite is:
That said, I think this feature ties in strongly with the idea of serving custom tags (not just name/role), so it might be nice if we can find a solution that ties in with that too. Maybe something like this, but with nicer syntax:
That also introduces the edge case of "what to do with a machine with no Env tag"? I'm always worried that too much configuration will just make it hard to use. I guess we can just keep Any thoughts? |
I like the last version, it is a better generalization from my first proposal. I guess one route would only server the machines that match (i.e. that have values for all tags in that route)? Agree, What about collisions? If you do |
Some way to support a custom tag hierarchy. For example:
This would allow names like:
<name>.<role>.<env>.aws.example.com
->skywalker.app.staging.aws.example.com
There are probably many edge cases in supporting such a structure. E.g. what to do with missing tags?, how to access the
<n>
component of higher levels?The text was updated successfully, but these errors were encountered: