[PUP-6576] Deprecate the data_binding_terminus setting under the control of --strict Created: 2016/08/03  Updated: 2017/02/02  Resolved: 2016/12/06

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: PUP 4.9.0

Type: Task Priority: Normal
Reporter: Nicholas Fagerlund Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Epic Link: Productize 'lookup'
Team: Puppet Developer Experience
Story Points: 1
Sprint: PDS 2016-11-02, PDS 2016-11-16, PDS 2016-11-30, PDE 2016-12-14
Release Notes: Deprecation
Release Notes Summary: Deprecate data_binding_terminus settings other than 'hiera' and 'none', under the control of --strict
QA Contact: Eric Thompson
QA Risk Assessment: No Action
QA Risk Assessment Reason: deprecation warning, covered by unit tests



This setting ostensibly controls how Puppet does automatic class parameter lookup.

I don't think it quite works that way anymore. AFAIK, everything goes through Puppet lookup, which delegates to Hiera for the first (global) layer of lookups.

Should we remove this setting? Should we replace it with something else?


The data_binding_terminus setting should be deprecated as the goal is to have not singleton/global data configured. It should all be defined per environment and use lookup.
To not drive people crazy the deprecation should use the --strict option to issue a deprecation warning in Puppet 4.9.0 at warning level for both strict=error and strict=warning. We do not want to make it an error quite yet as it requires having switched to lookup in all used environments.

Comment by Nicholas Fagerlund [ 2016/08/03 ]

My take is, axe it.

  • Puppet lookup is how Puppet does lookup.
  • If you need to substitute some other lookup system at the environment level, lookup.conf should have you 100% covered.
    • Likewise if we decide to expand lookup.conf to the global level.
  • That doesn't give you a good way to completely disable lookup in modules, but AFAICT there's no reason to do so, so that's fine.
Comment by Henrik Lindberg [ 2016/08/04 ]

I think (without looking extensively) that lookup goes to the configured provider (i.e. the terminus) for the global level. Thus, the mechanism can be used to turn off the global hiera. Other than that it can be axed. I am not aware of anyone having written an alternative to hiera at the global level.

Comment by R.I.Pienaar [ 2016/08/04 ]

https://github.com/domcleal/foreman_data_binding used by https://github.com/domcleal/foreman_param_lookup


Comment by Henrik Lindberg [ 2016/08/04 ]

Thanks R.I.Pienaar - sounds like a longer discussion is needed as the API may be used for different purposes.

Comment by Craig Dunn [ 2016/08/15 ]

Henrik Lindberg As for R.I.Pienaar's last example, it doesn't seem too hard (right now) to implement the same behaviour using environment data providers.... I have been playing around with this (rather crude and experimental) example to use the new environment data provider API instead of plugging directly into data_binding_terminus:


So far my smoke testing has been successful with that approach, I guess it depends on whatever is going to happen with "global level"

Comment by Henrik Lindberg [ 2016/08/15 ]

Craig Dunn yeah, the environment data provider is what a global data provider would be, only at the global level. It is discussed if a global level is needed at all (is it a good thing to let some users have the ability to override anything in all environments, or a bad thing (global data is bad, and you have to play catch up with what is being done in environments).

Question here is really how many (and which) users would be hit by simply removing the current indirection based extension point for data binding.

Comment by Craig Dunn [ 2016/08/15 ]

Henrik Lindberg I think the number of people/projects using something external for data_binding_terminus is very low, maybe only the three that RI mentioned.

Is the existing implementation of environment data providers (as I implemented above) going to go away? or it this still an unknown?

Comment by Henrik Lindberg [ 2016/08/15 ]

Craig Dunn We are working on "lookup finalizers" atm. The idea is to allow functions to be used in the hierarchy in env, module etc. and that there would be just the one provider that handles that. During the transition I think we need to support the current way of plugging in an environment_data_provider. But long term, there is really no need to have an extra API for different kind of data provider plugins as the support for functions we are designing would be much simpler to use (and just as powerful).

Comment by Henrik Lindberg [ 2016/10/04 ]

We will remove the "data provider terminus" long term in favor of the new format in lookup.conf. We don't need the extra layer of configuration that enables replacement of the entire mechanism. Instead, things like the foreman support should simply be wrapped in a function and included in the lookup.conf, and all lookup's should be made with lookup() - otherwise manifests risk being tied to one particular terminus/technology/mechanism (this we know from experience is bad).

However, we cannot simply drop that terminus, and it will continue to be available until the hiera project as such is removed. We should add deprecation though. I am repurposing this ticket to add a deprecation for using that setting under control of the --strict flag.

Comment by Charlie Sharpsteen [ 2016/11/14 ]

I know we have a few folks that are setting data_binding_terminus to none in order to disable automatic parameter lookup. What changes will they have to make in order to keep lookup disabled at the global and environment levels once this change lands?

Comment by Henrik Lindberg [ 2016/11/14 ]

Thanks Charlie, 'none' is a better option than blank/nil. Will change in the impl I am working on right now.

To not get any env lookup, simply do not have a lookup.yaml in the env, or use one with an empty hierarchy.

Comment by Moses Mendoza [ 2016/11/29 ]

merged to master at https://github.com/puppetlabs/puppet/commit/5d6aa80514cf4c1d46c4b1650f4494fe6bb88c98

Generated at Wed Apr 01 15:12:08 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.