Skip to content
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

Open
eproxus opened this issue Aug 28, 2014 · 5 comments
Open

Tag hierarchies #2

eproxus opened this issue Aug 28, 2014 · 5 comments

Comments

@eproxus
Copy link
Contributor

eproxus commented Aug 28, 2014

Some way to support a custom tag hierarchy. For example:

aws-name-server --tag-hierarchy Name,Role,Env ...

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?

@eproxus eproxus changed the title Tag hierarchy Tag hierarchies Aug 28, 2014
@ConradIrwin
Copy link
Owner

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?

@eproxus
Copy link
Contributor Author

eproxus commented Aug 29, 2014

Per env, primarily.

@eproxus
Copy link
Contributor Author

eproxus commented Aug 29, 2014

Actually, I would be perfectly fine if I could throw in Env as the top layer. Like 1.db.dev.aws.example.com.

@ConradIrwin
Copy link
Owner

I guess there are a couple of different ways we could try and do this, I think my favourite is:

./aws-name-server --namespace-tag env --domain aws.bugsnag.com

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:

./aws-name-server --serve +Name.aws.bugsnag.com \
                  --serve +Role.role.aws.bugsnag.com \
                  --serve +Role.+Env.aws.bugsnag.com

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 --domain aws.bugsnag.com as the "quick start" and then have an "advanced usage" section too.

Any thoughts?

@eproxus
Copy link
Contributor Author

eproxus commented Sep 1, 2014

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, --domain $DOMAIN would be shorthand for --serve +Name.$DOMAIN --serve +Role.role.$DOMAIN. Another version could be that just --domain $DOMAIN would by default serve the +Name and +Role.role prefixes if no --serve flags existed, otherwise serve what was specified?

What about collisions? If you do --server +Name.$DOMAIN --server +Name.+Env.$DOMAIN, what happens when you have Name=test and Env=test?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants