Issue #11608 has been updated by Pieter van de Bruggen.
* Is our default hierarchy right?
+1
* Is ‘global’ the right name for the previously-known-as ‘common’ hierarchical
layer?
+1
* What do we name the function(s) for data lookup? Is lookup() right?
+1
* With regard to the replacement of hiera_include(), do we need to enforce a
convention here around the key lookup?
Can you elaborate on this a bit? What sort of convention are you thinking of?
* What do we do about the existing hiera config file? That can’t be expressed
in puppet.conf can it?
We could do away with the Hiera config file and inline this in the
[master.data] section of puppet.conf *iff* we implemented support for
multi-value keys. This would probably look like:
[master.data]
dir=%{certname}
dir=%{environment}
dir=global
The downside is that we cannot guarantee that people aren't already relying on
the existing duplicate handling behavior, and this would create unrelated
errors elsewhere in the application. If we could find a reasonable way to
represent this in a backwards compatible way, we should absolutely roll it in.
----------------------------------------
Feature #11608: Lowrider: Data/Model separation by including Hiera-like
functionality in Puppet
https://projects.puppetlabs.com/issues/11608#change-61497
Author: Nigel Kersten
Status: Needs More Information
Priority: Normal
Assignee: Nigel Kersten
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
https://github.com/kelseyhightower/puppet/tree/ticket/master/11608_data_separation_with_hiera
# Codename: Lowrider
## Problem
In order for modules to be truly reusuable, you need to be able to supply
site-specific data outside the module itself.
Authors however need to be able to supply data themselves with modules, but
well separated outside the manifests so that users can override data.
# Overview
We're going to build Hiera-like functionality into Puppet itself as a first
class citizen, using the Hiera code base as a starting point, and freezing the
existing Hiera project with minimal maintenance by Puppet Labs.
"hiera" will generally be retired as a user facing element with the noun "data"
and the verb "lookup".
Backwards compatibility will be provided by existing Hiera installs, so it's
critical that users can continue to run Hiera alongside Territory while they do
any necessary migration. Existing Hiera users are important to us.
At this stage we are looking to support a single on-disk data format, JSON.
### Goals
1. Automatically look up unspecified class parameters in the data store.
1. Allow manual look up of data in the data store by explicit keys.
1. Provide a Face to interact with the data store.
### Out of scope, to implement later
1. A remote read/write API/service wrapped around Hiera.
### Out of scope, no plan to implement later.
1. Allow module authors to ship data in their modules.
We have a general principle we're looking to promote where class parameters are
considered your interface for the user
of your module. Just like you wouldn't make GUI elements that control aspects
of a program your users shouldn't need to
modify, you shouldn't make class parameters for everything. This should be kept
in mind with the design.
We are *not* interacting with an external Hiera install here, we are creating
Hiera-like functionality in Puppet core, using the Hiera code base.
## Automatically look up unspecified class parameters in the data store
class ntp($servers=['time.puppetlabs.com']) {
...
}
### Lookup Order
1. Directly specified value
* `class { ntp: servers => ["ntp.puppetlabs.lan", "ntp2.puppetlabs.lan"] }`
1. Value via Hiera when not directly specified
* `class { ntp: }` will lookup the key `ntp::servers`
1. Default value in class definition when not directly specified or found in
Hiera
* `class { ntp:}` and `class ntp ($servers=["default.server"]) { ... }`
Note the change from existing Hiera where we are now going to be looking up the
fully qualified variable name as the key,
avoiding the existing problem of a global namespace being polluted with
'ntp_ntpservers'.
### Default Hierarchy
Proposed:
:hierarchy:
- %{certname}
- %{environment}
- global
Note the rename of 'common' in Hiera terminology to 'global', and associated
design question.
## Allow manual look up of data in the data store by explicit keys
Puppet manifests should have access to the data store using a data lookup
function like this:
class site {
class { 'ntp':
ntpservers => lookup('dmz_ntpservers'),
}
$maintenance_message = lookup('dmz_maintenance_state_text')
file { '/etc/motd':
content => $maintenance_message,
}
}
This is where users can lookup arbitrary keys and use the returned data in
class or resource declarations, or really for any DSL purpose.
## Puppet Data Face:
The current Hiera CLI functionality will be ported to a Face with the following
feature set:
* Ability to read data from the data store
* Ability to query values based on a user supplied scope
Example:
# Query the data backend for var_name:
$ puppet data search var_name
# Query the data backend for var_name with a specific scope:
$ puppet data search var_name --scope "key=value"
## Puppet Deprecations
* extlookup function
## Hiera functionality that will not survive the transition
* "puppet" backend for Hiera
* YAML support
* We won't port `hiera_include()` as we're going to fix #7801
## Rough User Stories/Desires
* As a user, I want to be able to migrate a node from prod -> test -> prod
without needing to copy all the data back and forth.
* This is the driver behind having the environment in the default
hierarchy, rather than environment-specific data stores.
## Outstanding Questions
### General
* ???
* ???
### Design
* Is our default hierarchy right?
* Is 'global' the right name for the previously-known-as 'common'
hierarchical layer?
* What do we name the function(s) for data lookup? Is `lookup()` right?
* With regard to the replacement of `hiera_include()`, do we need to enforce
a convention here around the key lookup?
* What do we do about the existing hiera config file? That can't be expressed
in puppet.conf can it?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
