where people are at?
- startrek from scratch: https://github.com/pro-puppet/puppet-module-startrek
- ashp reworked ntp module: https://github.com/apenney/puppetlabs-ntp/tree/data-in-modules/data
design questions
- Q: are categories per-module or global?
A: they're global, so we need standards for what the category stack ought to be
some debate about how to contribute different selectors than the default osfamily / environment / common
- you could use puppet expressions inside the data
- you could put a custom back-end
seems like either we need to have non-changable standard hierarchy -or- have the hierarchy be module-specific
- if the module expresses a hierarchy that uses categories not in the site config, that's an error
are all the directories hardcoded? i.e. is the data for $osfamily always in an osfamily/ directory
- bodepd has multiple categories that map to the same file
confusion around hiera.yaml and bindings_config.yaml
- bindings_config.yaml tells the system which modules' data to use and the overall priority
- then you have a heira.yaml per module which maps global category names to data locations inside the module
module variable bindings are in a flat namespace
- so a module with a variable just named 'port' would provide results for $port in puppet's scope
- module variables that are specific to themselves should be namespaced anyway for implicit bindings
- this has some dangers but permits things like a module which only provides configuration, i.e. has a modulefile which expresses dependencies on 'real' modules so they get pulled in and then provides specific sets of configuration
the binder constructs a mapping of keys to a producer, and the producer is responsible for giving a value when handed a request for the key. for static keys, the producer (i.e. yaml lookup) just returns a value. but you could make a ruby producer that performs any kind of code operation when handed a request. if you don't want to do it per key, you could produce another binder (i.e. hiera2 back-end) that is handed the facts and is responsible for handing back a binding of all keys to values.
spencer sets a $cname variable and uses that to look up values in hiera. (i don't quite understand this) i think the answer's in the ruby binding API https://github.com/puppetlabs/armatures/blob/master/arm-9.data_in_modules/index.md#who-has-a-funny-hat-in-ruby
daenny question about better docs -- yes, definitely on the way.
bodepd question about how to guarantee that it's available. eric0 says once these things get into PE there's going to be API guarantees because we're going to have to support it for 3 years and train/doc to it, but until that point things are flexible and experimental.
spencer suggests putting binder_config.yaml in the packages so it's explicit and visible instead of hidden
bodepd suggests config file format is too terse. the category definition specifically is pretty obtuse, maybe that should be a hash of values instead.