wearetherobots | 1 May 2012 01:45

(puppetlabs/hiera-json) (maint) Use two spaces for indentation

Please review pull request #3: (maint) Use two spaces for indentation opened by (kelseyhightower)

Description:

  • Opened: Mon Apr 30 23:37:58 UTC 2012
  • Based on: puppetlabs:master (4d5d5979b1b58fd1b634caca13e6282f756e508f)
  • Requested merge: kelseyhightower:master (2911386e66deba92a99c42ed759c64cbc9b1cf35)

Diff follows:

diff --git a/README.md b/README.md index b856399..d7641f2 100644 --- a/README.md +++ b/README.md <at> <at> -1,10 +1,10 <at> <at> What? -===== +----- A JSON backend for Hiera Configuration? -============== +-------------- A sample Hiera config file that activates this backend and stores data in _/etc/puppet/hieradata_ can be seen below: <at> <at> -18,7 +18,7 <at> <at> data in _/etc/puppet/hieradata_ can be seen below: :datadir: /etc/puppet/hieradata </pre> -Constact? -========= +Support +------- -R.I.Pienaar / rip <at> devco.net / <at> ripienaar / www.devco.net +Please log tickets and issues at our [Projects site](http://projects.puppetlabs.com) diff --git a/Rakefile b/Rakefile index a9ad774..efd2e37 100644 --- a/Rakefile +++ b/Rakefile <at> <at> -26,8 +26,8 <at> <at> end desc "Run all specs" RSpec::Core::RakeTask.new(:test) do |t| - t.pattern = 'spec/**/*_spec.rb' - t.rspec_opts = File.read("spec/spec.opts").chomp || "" + t.pattern = 'spec/**/*_spec.rb' + t.rspec_opts = File.read("spec/spec.opts").chomp || "" end task :default => [:test, :repackage] diff --git a/lib/hiera/backend/json_backend.rb b/lib/hiera/backend/json_backend.rb index 997a396..eb2f76e 100644 --- a/lib/hiera/backend/json_backend.rb +++ b/lib/hiera/backend/json_backend.rb <at> <at> -1,43 +1,43 <at> <at> class Hiera - module Backend - class Json_backend - def initialize - require 'json' + module Backend + class Json_backend + def initialize + require 'json' - Hiera.debug("Hiera JSON backend starting") - end + Hiera.debug("Hiera JSON backend starting") + end - def lookup(key, scope, order_override, resolution_type) - answer = Backend.empty_answer(resolution_type) + def lookup(key, scope, order_override, resolution_type) + answer = Backend.empty_answer(resolution_type) - Hiera.debug("Looking up #{key} in JSON backend") + Hiera.debug("Looking up #{key} in JSON backend") - Backend.datasources(scope, order_override) do |source| - Hiera.debug("Looking for data source #{source}") + Backend.datasources(scope, order_override) do |source| + Hiera.debug("Looking for data source #{source}") - jsonfile = Backend.datafile(:json, scope, source, "json") || next + jsonfile = Backend.datafile(:json, scope, source, "json") || next - data = JSON.parse(File.read(jsonfile)) + data = JSON.parse(File.read(jsonfile)) - next if data.empty? - next unless data.include?(key) + next if data.empty? + next unless data.include?(key) - # for array resolution we just append to the array whatever - # we find, we then goes onto the next file and keep adding to - # the array - # - # for priority searches we break after the first found data item - case resolution_type - when :array - answer << Backend.parse_answer(data[key], scope) - else - answer = Backend.parse_answer(data[key], scope) - break - end - end - - return answer - end + # for array resolution we just append to the array whatever + # we find, we then goes onto the next file and keep adding to + # the array + # + # for priority searches we break after the first found data item + case resolution_type + when :array + answer << Backend.parse_answer(data[key], scope) + else + answer = Backend.parse_answer(data[key], scope) + break + end end + + return answer + end end + end end diff --git a/spec/json_backend_spec.rb b/spec/json_backend_spec.rb index b9064d5..69241e5 100644 --- a/spec/json_backend_spec.rb +++ b/spec/json_backend_spec.rb <at> <at> -7,92 +7,92 <at> <at> require 'hiera/backend/json_backend' RSpec.configure do |config| - config.mock_with :mocha + config.mock_with :mocha end class Hiera - module Backend - describe Json_backend do - before do - Hiera.stubs(:debug) - Hiera.stubs(:warn) - Hiera::Backend.stubs(:empty_answer).returns(nil) - <at> backend = Json_backend.new - end - - describe "#initialize" do - it "should announce its creation" do # because other specs checks this - Hiera.expects(:debug).with("Hiera JSON backend starting") - Json_backend.new - end - end - - describe "#lookup" do - it "should look for data in all sources" do - Backend.expects(:datasources).multiple_yields(["one"], ["two"]) - Backend.expects(:datafile).with(:json, {}, "one", "json").returns(nil) - Backend.expects(:datafile).with(:json, {}, "two", "json").returns(nil) - - <at> backend.lookup("key", {}, nil, :priority) - end - - it "should retain the data types found in data files" do - Backend.expects(:datasources).yields("one").times(3) - Backend.expects(:datafile).with(:json, {}, "one", "json").returns("/nonexisting/one.json").times(3) - File.expects(:read).with("/nonexisting/one.json").returns('{"stringval":"string", - "boolval":true, - "numericval":1}').times(3) - - Backend.stubs(:parse_answer).with('string', {}).returns('string') - Backend.stubs(:parse_answer).with(true, {}).returns(true) - Backend.stubs(:parse_answer).with(1, {}).returns(1) - - <at> backend.lookup("stringval", {}, nil, :priority).should == "string" - <at> backend.lookup("boolval", {}, nil, :priority).should == true - <at> backend.lookup("numericval", {}, nil, :priority).should == 1 - end - - it "should pick data earliest source that has it for priority searches" do - scope = {"rspec" => "test"} - Backend.stubs(:parse_answer).with('answer', scope).returns("answer") - Backend.stubs(:parse_answer).with('test_%{rspec}', scope).returns("test_test") - Backend.expects(:datasources).multiple_yields(["one"], ["two"]) - Backend.expects(:datafile).with(:json, scope, "one", "json").returns("/nonexisting/one.json") - Backend.expects(:datafile).with(:json, scope, "two", "json").returns(nil).never - File.expects(:read).with("/nonexisting/one.json").returns("one.json") - JSON.expects(:parse).with("one.json").returns({"key" => "test_%{rspec}"}) - - <at> backend.lookup("key", scope, nil, :priority).should == "test_test" - end - - it "should build an array of all data sources for array searches" do - Hiera::Backend.stubs(:empty_answer).returns([]) - Backend.stubs(:parse_answer).with('answer', {}).returns("answer") - Backend.expects(:datafile).with(:json, {}, "one", "json").returns("/nonexisting/one.json") - Backend.expects(:datafile).with(:json, {}, "two", "json").returns("/nonexisting/two.json") - - Backend.expects(:datasources).multiple_yields(["one"], ["two"]) - - File.expects(:read).with("/nonexisting/one.json").returns("one.json") - File.expects(:read).with("/nonexisting/two.json").returns("two.json") - - JSON.expects(:parse).with("one.json").returns({"key" => "answer"}) - JSON.expects(:parse).with("two.json").returns({"key" => "answer"}) - - <at> backend.lookup("key", {}, nil, :array).should == ["answer", "answer"] - end - - it "should parse the answer for scope variables" do - Backend.stubs(:parse_answer).with('test_%{rspec}', {'rspec' => 'test'}).returns("test_test") - Backend.expects(:datasources).yields("one") - Backend.expects(:datafile).with(:json, {"rspec" => "test"}, "one", "json").returns("/nonexisting/one.json") - - File.expects(:read).with("/nonexisting/one.json").returns("one.json") - JSON.expects(:parse).with("one.json").returns({"key" => "test_%{rspec}"}) - - <at> backend.lookup("key", {"rspec" => "test"}, nil, :priority).should == "test_test" - end - end + module Backend + describe Json_backend do + before do + Hiera.stubs(:debug) + Hiera.stubs(:warn) + Hiera::Backend.stubs(:empty_answer).returns(nil) + <at> backend = Json_backend.new + end + + describe "#initialize" do + it "should announce its creation" do # because other specs checks this + Hiera.expects(:debug).with("Hiera JSON backend starting") + Json_backend.new end + end + + describe "#lookup" do + it "should look for data in all sources" do + Backend.expects(:datasources).multiple_yields(["one"], ["two"]) + Backend.expects(:datafile).with(:json, {}, "one", "json").returns(nil) + Backend.expects(:datafile).with(:json, {}, "two", "json").returns(nil) + + <at> backend.lookup("key", {}, nil, :priority) + end + + it "should retain the data types found in data files" do + Backend.expects(:datasources).yields("one").times(3) + Backend.expects(:datafile).with(:json, {}, "one", "json").returns("/nonexisting/one.json").times(3) + File.expects(:read).with("/nonexisting/one.json").returns('{"stringval":"string", + "boolval":true, + "numericval":1}').times(3) + + Backend.stubs(:parse_answer).with('string', {}).returns('string') + Backend.stubs(:parse_answer).with(true, {}).returns(true) + Backend.stubs(:parse_answer).with(1, {}).returns(1) + + <at> backend.lookup("stringval", {}, nil, :priority).should == "string" + <at> backend.lookup("boolval", {}, nil, :priority).should == true + <at> backend.lookup("numericval", {}, nil, :priority).should == 1 + end + + it "should pick data earliest source that has it for priority searches" do + scope = {"rspec" => "test"} + Backend.stubs(:parse_answer).with('answer', scope).returns("answer") + Backend.stubs(:parse_answer).with('test_%{rspec}', scope).returns("test_test") + Backend.expects(:datasources).multiple_yields(["one"], ["two"]) + Backend.expects(:datafile).with(:json, scope, "one", "json").returns("/nonexisting/one.json") + Backend.expects(:datafile).with(:json, scope, "two", "json").returns(nil).never + File.expects(:read).with("/nonexisting/one.json").returns("one.json") + JSON.expects(:parse).with("one.json").returns({"key" => "test_%{rspec}"}) + + <at> backend.lookup("key", scope, nil, :priority).should == "test_test" + end + + it "should build an array of all data sources for array searches" do + Hiera::Backend.stubs(:empty_answer).returns([]) + Backend.stubs(:parse_answer).with('answer', {}).returns("answer") + Backend.expects(:datafile).with(:json, {}, "one", "json").returns("/nonexisting/one.json") + Backend.expects(:datafile).with(:json, {}, "two", "json").returns("/nonexisting/two.json") + + Backend.expects(:datasources).multiple_yields(["one"], ["two"]) + + File.expects(:read).with("/nonexisting/one.json").returns("one.json") + File.expects(:read).with("/nonexisting/two.json").returns("two.json") + + JSON.expects(:parse).with("one.json").returns({"key" => "answer"}) + JSON.expects(:parse).with("two.json").returns({"key" => "answer"}) + + <at> backend.lookup("key", {}, nil, :array).should == ["answer", "answer"] + end + + it "should parse the answer for scope variables" do + Backend.stubs(:parse_answer).with('test_%{rspec}', {'rspec' => 'test'}).returns("test_test") + Backend.expects(:datasources).yields("one") + Backend.expects(:datafile).with(:json, {"rspec" => "test"}, "one", "json").returns("/nonexisting/one.json") + + File.expects(:read).with("/nonexisting/one.json").returns("one.json") + JSON.expects(:parse).with("one.json").returns({"key" => "test_%{rspec}"}) + + <at> backend.lookup("key", {"rspec" => "test"}, nil, :priority).should == "test_test" + end + end end + end end diff --git a/tasks/release.rb b/tasks/release.rb index b472d5a..3b494d4 100644 --- a/tasks/release.rb +++ b/tasks/release.rb <at> <at> -1,16 +1,13 <at> <at> - def described_version - # This ugly bit removes the gSHA1 portion of the describe as that causes failing tests - %x{git describe}.gsub('-', '.').split('.')[0..3].join('.').to_s.gsub('v', '') + # This ugly bit removes the gSHA1 portion of the describe as that causes failing tests + %x{git describe}.gsub('-', '.').split('.')[0..3].join('.').to_s.gsub('v', '') end namespace :pkg do - desc "Build Package" task :release => [ :default ] do Rake::Task[:package].invoke end - end # namespace task :clean => [ :clobber_package ] do

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 02:00

(puppetlabs/puppet) Update use of reparse to reparse_config_files

Please review pull request #730: Update use of reparse to reparse_config_files opened by (pcarlisle)

Description:

The method in settings was renamed, but this use was missed.

  • Opened: Mon Apr 30 23:58:11 UTC 2012
  • Based on: puppetlabs:master (484e170ac379df4428a338722f0c2bbbff13bae2)
  • Requested merge: pcarlisle:repase_config_fix (6d26b5ce3fcd1b6cc575c531bf7d174dceabafd1)

Diff follows:

diff --git a/lib/puppet/daemon.rb b/lib/puppet/daemon.rb index 15358f0..33fb28e 100755 --- a/lib/puppet/daemon.rb +++ b/lib/puppet/daemon.rb <at> <at> -178,7 +178,7 <at> <at> def run_event_loop # `reparse` will just check if the action is required, and would be # better named `reparse_if_changed` instead. if reparse_interval > 0 and now >= next_reparse - Puppet.settings.reparse + Puppet.settings.reparse_config_files # The time to the next reparse might have changed, so recalculate # now. That way we react dynamically to reconfiguration.

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 02:15

(puppetlabs/puppet) Update use of reparse to reparse_config_files

On Tue May 01 00:10:52 UTC 2012 pull request #730 was closed.

Update use of reparse to reparse_config_files requested by (pcarlisle)

The pull request was merged by: jeffweiss

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 02:45

(puppetlabs/puppet) Fix incorrect argument handling for expire in NodeExpirer

On Tue May 01 00:38:03 UTC 2012 pull request #728 was closed.

Fix incorrect argument handling for expire in NodeExpirer requested by (pcarlisle)

The pull request was merged by: daniel-pittman

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 02:45

(puppetlabs/puppet) Properly call indirector when storing file content

On Tue May 01 00:38:54 UTC 2012 pull request #715 was closed.

Properly call indirector when storing file content requested by (ccaum)

The pull request was merged by: daniel-pittman

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 02:45

(puppetlabs/puppet) (#8235) Add plug-in system for tools like Hiera

On Tue May 01 00:43:54 UTC 2012 pull request #718 was closed.

(#8235) Add plug-in system for tools like Hiera requested by (kelseyhightower)

The pull request was merged by: daniel-pittman

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
wearetherobots | 1 May 2012 18:30

(puppetlabs/hiera) (#14256) Adding save API

Please review pull request #46: (#14256) Adding save API opened by (kelseyhightower)

Description:

This patch adds a new API for saving data by delegating to a specific
backend. The backend is responsible for saving data based on a key,
value, and source. The backend must return a status response of true
or false depending on the success or failure of the save operation.

Example:

If we have the following Hiera configuration:

:hierarchy:
- %{environment}
- common

:backends:
- backend_with_save_support

We can save data to the backend_with_save_support like this:

require 'hiera' hiera = Hiera.new status = hiera.save('key, 'value', 'backend_with_save_support', 'common')

This patch includes tests.

  • Opened: Tue May 01 16:23:57 UTC 2012
  • Based on: puppetlabs:master (6bd7122cf4f6d3a97168acc0adf7f0613ab7b8a5)
  • Requested merge: kelseyhightower:feature/master/14256_add_save_api (77b0ca4faff09801e3b6ee046b06a94eb07c1a1d)

Diff follows:

diff --git a/lib/hiera.rb b/lib/hiera.rb index 0cd5d0e..b990ea8 100644 --- a/lib/hiera.rb +++ b/lib/hiera.rb <at> <at> -64,4 +64,25 <at> <at> def initialize(options={}) def lookup(key, default, scope, order_override=nil, resolution_type=:priority) Backend.lookup(key, default, scope, order_override, resolution_type) end + + # Calls the backend to do the actual save. + # + # The backend should match one of the configured backend plugins by name. + # + # The source can be any of the items in the hierarchy. For example, if you + # have the following hierarchy: + # + # :hierarchy: + # - %{environment} + # - common + # + # And the following scope: + # + # { 'environment' => 'production' } + # + # The source should be either 'common', 'production', or any value you + # expect to be matched by %{environment}. + def save(key, value, backend, source) + Backend.save(key, value, backend, source) + end end diff --git a/lib/hiera/backend.rb b/lib/hiera/backend.rb index 0f2f77f..274e707 100644 --- a/lib/hiera/backend.rb +++ b/lib/hiera/backend.rb <at> <at> -176,6 +176,26 <at> <at> def lookup(key, default, scope, order_override, resolution_type) return default if answer == empty_answer(resolution_type) return answer end + + # Calls out to the specified backend to save the data. + def save(key, value, backend, source) + status = false + + if constants.include?("#{backend.capitalize}_backend") || + constants.include?("#{backend.capitalize}_backend".to_sym) + dest = Backend.const_get("#{backend.capitalize}_backend").new + + if dest.respond_to?(:save) + status = dest.save(key, value, source) + else + Hiera.warn("Cannot save data, #{backend} backend does not support saving") + end + else + Hiera.warn("Cannot save data, #{backend} is not a valid backend") + end + + return status + end end end end diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb index f64c64e..f9fd430 100644 --- a/spec/spec_helper.rb +++ b/spec/spec_helper.rb <at> <at> -17,3 +17,12 <at> <at> class Functions end end +class Hiera + module Backend + class Test_backend + def initialize + Hiera.debug("Hiera Test backend starting") + end + end + end +end diff --git a/spec/unit/backend_spec.rb b/spec/unit/backend_spec.rb index 85d1239..ad22378 100644 --- a/spec/unit/backend_spec.rb +++ b/spec/unit/backend_spec.rb <at> <at> -284,5 +284,31 <at> <at> class Hiera Backend.lookup("key", {"test" => "value"}, {}, nil, :hash).should == {"test" => "value"} end end + + describe "#save" do + before do + Hiera.stubs(:debug) + Hiera.stubs(:warn) + end + + it "should warn if the backend is not valid" do + Config.load({}) + Hiera.expects(:warn).with("Cannot save data, nobackend is not a valid backend") + Backend.save("key", "value", "nobackend", "source") + end + + it "should warn if the backend does not support save" do + Config.load({}) + Hiera.expects(:warn).with("Cannot save data, test backend does not support saving") + Backend.save("key", "value", "test", "source").should be_false + end + + it "should return the status from the backend" do + Config.load({}) + Hiera::Backend::Test_backend.any_instance.expects(:save). + with("key", "value", "source").returns(true) + Backend.save("key", "value", "test", "source").should be_true + end + end end end diff --git a/spec/unit/hiera_spec.rb b/spec/unit/hiera_spec.rb index 86c5992..671cc2b 100644 --- a/spec/unit/hiera_spec.rb +++ b/spec/unit/hiera_spec.rb <at> <at> -57,4 +57,13 <at> <at> Hiera.new.lookup(:key, :default, :scope, :order_override, :resolution_type) end end + + describe "#save" do + it "should proxy to the Backend#save method" do + Hiera::Config.stubs(:load) + Hiera::Config.stubs(:load_backends) + Hiera::Backend.expects(:save).with(:key, :value, :backend, :source) + Hiera.new.save(:key, :value, :backend, :source) + end + end end

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Kelsey Hightower | 1 May 2012 18:31
Gravatar

Hiera should have an save API

I'm thinking of adding a new save API to Hiera. The idea is that Hiera should provide an iterface for saving data, which should make it easy for front-end tools to interact with backends that support saving data.


An example of how this might work is shown in the commit message in the following pull request:

I have a ticket here:

Do people think this is a good idea? I see this as a foundational bit for building UI's on top of Hiera. 

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/zHaVVaKsZ-sJ.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
Daniel Pittman | 1 May 2012 19:17
Gravatar

Re: Hiera should have an save API

On Tue, May 1, 2012 at 09:31, Kelsey Hightower <kelsey <at> puppetlabs.com> wrote:

> I'm thinking of adding a new save API to Hiera. The idea is that Hiera
> should provide an iterface for saving data, which should make it easy for
> front-end tools to interact with backends that support saving data.

Why does it make it any easier than having tools with already know
about their back-end semantics directly managing that data?  It has
substantial limitations (eg: no user concept, no credentials, and no
way to determine the appropriate set based on the back-end.)

It doesn't document anything of substance about the API: will save be
fast or slow?  Can save deadlock?  How does it differentiate different
operations on the same key?  How do I determine the hierarchy - or do
I need to implicitly know that to use this?

I have no idea how it works across machines.  Can I use this from the
dashboard when that is installed on a different machine to the master?
 How do changes propagate after `save` is called when I have multiple
masters?

It also makes it impossible to use this in any meaningful UI: there is
absolutely no mechanism to determine what the failure was.  Did we
fail because we got the hierarchy wrong, or the backend wrong, or
something else failed?  Should I just retry, or give up?

> Do people think this is a good idea? I see this as a foundational bit for
> building UI's on top of Hiera.

The principal is reasonable, but this isn't even close to a proposal
for a save API that works in the real world.

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

R.I.Pienaar | 1 May 2012 19:32
Favicon
Gravatar

Re: Hiera should have an save API


----- Original Message -----
> From: "Daniel Pittman" <daniel <at> puppetlabs.com>
> To: puppet-dev <at> googlegroups.com
> Sent: Tuesday, May 1, 2012 6:17:53 PM
> Subject: Re: [Puppet-dev] Hiera should have an save API
> 
> On Tue, May 1, 2012 at 09:31, Kelsey Hightower
> <kelsey <at> puppetlabs.com> wrote:
> 
> > I'm thinking of adding a new save API to Hiera. The idea is that
> > Hiera
> > should provide an iterface for saving data, which should make it
> > easy for
> > front-end tools to interact with backends that support saving data.
> 
> Why does it make it any easier than having tools with already know
> about their back-end semantics directly managing that data?  It has
> substantial limitations (eg: no user concept, no credentials, and no
> way to determine the appropriate set based on the back-end.)

This has been my main concern too and why I never implemented anything like this
in the first place - I think the data being queried is best modelled elsewhere.
The data is best created at the time when you classify a node in that same UI -
hiera should query that data but not know too much about the visual aspects of
it.

This would be usable for small installs who just use the json/yaml backends and
have no node classification system (other than maybe hand editing these files
and using hiera_include or something).  People who are already happy to just
hand hack JSON/YAML anyway.

Having to know the hierarchy on the CLI isn't that great an experience and neither
is typing complex data like hashes, arrays and such.

In mcollective I can type complex data on the CLI because the DDL describes the
data - I know when you typed "1" that it should be a number or a boolean and I
convert that for you.  Hiera has no data description, its free form so even with
a face or whatever it just would be limited use - soon you'll be editing JSON
or YAML again to represent arrays of hashes, thats wrong.

> 
> It doesn't document anything of substance about the API: will save be
> fast or slow?  Can save deadlock?  How does it differentiate
> different operations on the same key?  How do I determine the hierarchy - or do
> I need to implicitly know that to use this?

This is impossible to answer - the save API has no idea about the backends.

We *could* in theory extend backends to provide all these answers through some
kind of flag about the backend but I do not think we should.

Backends are easy to write and understand and so people do actually write them
vs some other plugins we might have like providers or types.  It's a pretty thin
line. Its a case of could but imo should not.

> 
> I have no idea how it works across machines.  Can I use this from the
> dashboard when that is installed on a different machine to the
> master?
>  How do changes propagate after `save` is called when I have multiple
> masters?
> 
> It also makes it impossible to use this in any meaningful UI: there
> is
> absolutely no mechanism to determine what the failure was.  Did we
> fail because we got the hierarchy wrong, or the backend wrong, or
> something else failed?  Should I just retry, or give up?
> 
> > Do people think this is a good idea? I see this as a foundational
> > bit for
> > building UI's on top of Hiera.
> 
> The principal is reasonable, but this isn't even close to a proposal
> for a save API that works in the real world.

I would love to see a solution for this but its deceptively hard to do
and I think ultimately better solved by exposing a REST API into your
dasbhoard/foreman/etc where you have RBAC and the other points you
raised

--

-- 
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.


Gmane