Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

request: allow custom read-only variables in config file #1226

Open
therealbill opened this Issue Jul 29, 2013 · 6 comments

Comments

Projects
None yet
4 participants
Contributor

therealbill commented Jul 29, 2013

I would like to be able to set custom key/value pairs in the config file to indicate meta-data about the instance of Redis, and have those available. Simplest route seems to me to be to allow config get to get them and not have a set partner. Even enforcing something as simple as "keyvalue" or "key[to the end of the line is one value] would enable such settings as:

instance_id 12345a
instance_name instance1node1
rack_name redis_rack_1

Why do I want this?
Say I am writing a Redis management system were I want to know which host and rack a given instance is on so I can make sure slaves are not run in the same place. Other uses would be in custom Sentinel rules or watchers to avoid promoting slaves to the same rack, etc. as the failed master.

I'd prefer to be able to query this instance metadata, but don't necessarily want to modify it (it is after all instance specific).

Even if we had to prefix it, something like:

meta key value

...would allow the parser to understand these are custom variable and ignore them when doing syntax checking - i.e. don't throw 'bad directive or wrong number of arguments'.

That route would even allow for the possibility of adding those to the info command, such as section 'meta' such that we could do 'info meta' to get the data. That would work as well, and as I consider it, might make more sense than (ab)using config get.

Collaborator

badboy commented Jul 29, 2013

Use CLIENT SETNAME for that.

Contributor

therealbill commented Jul 29, 2013

@badboy that doesn't address anything in the request. I am talking about server side metadata, not information about the client. Specifically, from the command docs: "The CLIENT SETNAME command assigns a name to the current connection."

So CLIENT SETNAME is not related to what I am talking about, nor does it meet the request. I am describing the setting of static Redis server instance metadata, not client connection names.

Cheers

willejs commented Jul 29, 2013

I think this type of metadata should be stored in a configuration management database(I use chef), and your config chosen management (also chef)should draw info from that to configure your redis instances. Redis shouldn't hold metadata about the instance.if you need to know that metadata query your cmdb.

Contributor

therealbill commented Jul 29, 2013

Some of us have infrastructure that is dynamic and chef, puppet, or cfengine do not handle those scenarios. For example, Redis sentinel can fail over a Redis service to a slave quicker than chef (or puppet) can perform a run, let alone be updated. Being able to query in real time where the instance you are talking to is actually running matters when running hundreds or thousands of Redis groups where any one of them at a given moment can be the master.

You wouldn't store how memory your Redis instance is currently using in a CMDB, would you? Perhaps how much it was assigned, but not how much it is currently using. When you've abstracted the Redis service beyond a basic instance, where it is running is dynamic data just as memory or CPU consumption is. Thus, it doesn't belong in the CMDB.

On Jul 29, 2013, at 18:15, willejs notifications@github.com wrote:

I think this type of metadata should be stored in a configuration management database(I use chef), and your config chosen management (also chef)should draw info from that to configure your redis instances. Redis shouldn't hold metadata about the instance.if you need to know that metadata query your cmdb.


Reply to this email directly or view it on GitHub.

Collaborator

badboy commented Jul 30, 2013

@therealbill aaaah, sorry. Totally misread your request. Sorry about that. You're right with your request then.

parhamr commented Aug 9, 2013

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment