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

[WIP] Add support for Hiera Hash resolution for recursive KV results #19

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fatmcgav
Copy link

@fatmcgav fatmcgav commented Jul 20, 2016

I'm currently prototyping an internal usage for Consul's KV store to handle tiered data, in this case about our micro-services, and have a requirement to retrieve that data via Puppet and Hiera as a hash, which we can then manipulate down-stream.

Rather than reinvent the wheel, I thought I'd take a stab at adding Hash resolution support to hiera-consul.

It's very rough and ready atm, but given the following key structure:

  • services
    • service1
      • context = 'service1s'
      • resource = 'service1'

And a query of service1, the following hash is returned:

{"services/service1/resource"=>"service1",
 "services/service1/"=>nil,
 "services/service1/context"=>"service1s"}

Things to work on/think about...

  • How to handle directories? - Above, it's just 'nil'.
  • Do we want to expose any of the other consul KV fields?
  • Support for Hiera Array resolution?
  • Testing?

Comments welcome...

Cheers
Gavin

@lynxman
Copy link
Owner

lynxman commented Aug 6, 2016

Really love this! Will work a bit more around it.

@fatmcgav
Copy link
Author

fatmcgav commented Aug 6, 2016

Glad you like it...

It needs a bit more polish, but seems to work for my test cases...

I'm thinking it makes more sense to collapse out directories into named hash format, but could always work that into the consul_info function.

Cheers
Gav

@eric-aldinger
Copy link

eric-aldinger commented Jul 31, 2017

I love this as well. I have the same use case and would prefer to have a normal JSON object returned, like I get from an API call to Consul. To make that work you could use a named hash, or add a different parser. I would vote for a different parser.

Our use case is "allowing the returning an object may allow for fewer expensive (timewise) API calls to Consul."

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

Successfully merging this pull request may close these issues.

3 participants