Il giorno mercoledì 16 ottobre 2013 12:14:12 UTC+2, R.I. Pienaar ha scritto:
>
>
>
> ----- Original Message -----
> > From: "Alessandro Franceschi" <a...@lab42.it <javascript:>>
> > To: puppet...@googlegroups.com <javascript:>
> > Sent: Wednesday, October 16, 2013 10:54:14 AM
> > Subject: Re: [Puppet Users] Re: Status of Data in modules
> >
> >
> >
> > On Tuesday, October 15, 2013 3:35:00 PM UTC+2, R.I. Pienaar wrote:
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "jcbollinger" <john.bollin...@stjude.org>
> > > > To: puppet...@googlegroups.com <javascript:>
> > > > Sent: Tuesday, October 15, 2013 2:08:10 PM
> > > > Subject: Re: [Puppet Users] Re: Status of Data in modules
> > > >
> > > >
> > > >
> > > > On Tuesday, October 15, 2013 12:52:39 AM UTC-5, David Schmitt wrote:
> > > > >
> > > > > On 14.10.2013 16:16, jcbollinger wrote:
> > > > > > So the proposed solution at this point is:
> > > > > > - enable an implicit data-binding lookup against the
> > > hiera-puppet
> > > > > > backend for a value of 'classname::variable' in the file
> > > > > > 'modules/classname/manifests/params.pp', which simplifies
> class
> > > > > > definition and provides consistency with other hiera
> backends.
> > > As a
> > > > > > module author, you'd still leave your logic for variables in
> > > > > > params.pp, but they'd be implicitly looked up via data
> bindings
> > > as
> > > > > > the class is declared, after consulting site-wide hiera.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Do I understand correctly that you set out to get rid of the
> > > ::params
> > > > > > class pattern, but now you favor an approach that depends on
> that
> > > > > > pattern? Why is that better than being more general: enable an
> > > implicit
> > > > > > lowest-priority hierarchy level for values of form
> > > > > > 'modulename::variable', drawing on data from per-module data
> files
> > > such
> > > > > > as modules/modulename/data.yaml?
> > > > >
> > > > > AIUI, prototyping revealed that many params classes contain logic
> that
> > > > > cannot be expressed in .yaml to calculate default values. Making
> the
> > > > > fallback lookup check the params class, the logic can be preserved
> > > while
> > > > > avoiding verbose boilerplate code like the params_lookup calls in
> > > > > Alessandro's modules.
> > > > >
> > > > >
> > > >
> > > > I'm not saying that categorically getting rid of ::params classes is
> a
> > > > viable target. In fact, I don't really understand why it was ever
> an
> > > > objective in the first place. On the other hand, I don't see why it
> > > makes
> > > > sense for Puppet to give special significance to that pattern,
> either.
> > > A
> > > > more general data-in-modules feature such as I describe would give
> users
> > > > the option to avoid ::params classes in some cases, and I'm inclined
> to
> > > > think that it would be easier to implement, to understand, and to
> use.
> > > >
> > >
> > > there are many reasons to avoid params.pp. It's *code* not *data* and
> > > it's
> > > one file that tends to include data for many different
> roles/sources/uses.
> > >
> > > You have to consider the main reasons for separating data from code in
> > > order
> > > to understand the motivation.
> > >
> > > When you have a params.pp you end up with stuff like this:
> > >
> > >
> > >
> https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/params.pp#L28-140
>
> > >
> > > No-one would call that maintainable or readable vs say having
> AIX.json,
> > > Debian.json and so forth.
> > >
> > > For a community member who wants to add support for a new OS this
> > > simplifies things a LOT. They can see what operating systems are
> supported
> > > already and they can easily add a new one by dropping a single file.
> > >
> > > This improves the contributor life cycle significantly:
> > >
> > > * Adding FooOS support will not break existing supported OS support.
> > > FooOS.json is only going to be read on FooOS machines.
> > > * They do not have to worry about complex merge conflicts on busy
> modules
> > > such as the ones you'd find internal to large companies vs many
> team
> > > members editing a single param.pp
> > > * There's no syntax and stuff to bother about, its pretty easy
> evaluate
> > > the data and to pre/post commit check this stuff. Contributor dont
> > > have
> > > to test extensively to ensure he didnt accidentally mess up
> params.pp
> > > complex nested statements in some subtle manner
> > > * In large environments if you have strict change control etc, the
> > > previous
> > > points help things a lot, you can easily reason about the
> implications
> > > and you
> > > can be sure they wont affect existing systems. It's just data that
> > > will affect
> > > a small subset users.
> > >
> > > This improves the maintainers life because:
> > >
> > > * They can find it easier to merge new OS support because the change
> is
> > > contained
> > > in seperate files and easy to evaluate
> > > * Fewer complex merge commits and easier, cleaner, commit history
> > > * The code is simpler and generally easier to maintain in the long
> term
> > >
> > > This improves the module user life because:
> > >
> > > * He can just look at existing data files and know without having to
> > > parse complex
> > > nested case statements what the available overridable data is and
> what
> > > the keys
> > > would be etc.
> > >
> > > There are more but these are the basics
> > >
> > > From a Puppet system perspective its important that this feature
> behave
> > > consistently
> > > and predictably with the current more or less universally accepted
> > > standard of data
> > > seperation - hiera. And hiera is all about data, the hiera puppet
> backend
> > > has been
> > > broken for ages and not been missed because it does not provide a
> solution
> > > that solves
> > > the above points. And so the data separation around params.pp will
> not
> > > solve the real
> > > problems either.
> > >
> > > Data simply should not be mixed with logic - because then it becomes
> code
> > > again with
> > > all the related problems.
> > >
> >
> > It's difficult to disagree with such statements, and actually I do agree
> > with all of them.
> >
> > Just would like to point out pair of notes, not necessarily in
> > contradiction with what you wrote:
> > - The params pattern was probably the best choice up to now, data in
> > modules probably provides an alternative and conceptually better way to
> do
> > the same things, which will also the have practical benefits you well
> > pointed out, but, to my understanding, it has some issues that have to
> be
> > addressed:
>
> indeed, params.pp is fine in the absence of something better. The goal
> has to
> be to separate data from code though. To ask why data in params.pp is a
> problem
> or to ask why it's the right approach is simply to ask why hiera exists at
> all.
>
> > -- Is more difficult to write modules, especially in some specific
> cases,
> > as Eric said, we can cope with that but that's worth considering,
> because
> > complexity is never a welcomed word when talking about code.
>
> indeed - in cases where you have to associate some deriving logic with
> some
> data item the temptation is there to put that logic in the data. This is
> a
> mistake.
>
> There's nothing wrong with a hybrid model where you have data - pure data
> -
> in a data file and then a class similar in spirit to params.pp to take
> that data
> and massage it and create derived data.
>
> The missing thing here and probably the elephant in the room is validation
> of that data. The proposed type implementation in the current thing thats
> in 3.3.x is a mistake.
>
> It's a trojan horse to get some half baked type system into Puppet via the
> back door, it's at odds with everything else in Puppet and simply not the
> right
> way to go about it, additional complexity that doesn't seem to have any
> place
> in Puppet. As a means of providing data validation it's very naive -
> saying
> data should be of type Integer is not enough of a validation.
>
> We should rather approach this in a way that there be some descriptive
> language
> that describes the data - ie. the foo::bar key has to be a Integer between
> 10
> and 20 - this should be something a module author provides and that any
> data
> be it from paramaterised classes, data bindings or otherwise are subject
> to
> this validation.
>
> > -- It's not clear , at least to me, if some real use cases are covered,
> > such as the ones where some class parameters or internal vars change
> > according to the value provided to other parameters.
> > The install case I think is quite clear to express this, and I still
> > haven't understood if it's possible to have in the module's hiera.yaml
> > something like this:
> >
> > ---
> > version: 3
> > hierarchy:
> > - category: 'osfamily'
> > - category: 'operatingsystem'
> >
> > - category: '^{install}' # Is this possible? Is this the correct
> syntax?
>
> hiera does support interpolation of data yes - I think that's what you
> mean?
> not sure where install comes from, I am guessing its a in-scope variable?
>
Yes, is a parameter of the class it allow's users to decide how to
install the class/module's application: via package, downloading and
extracting a tarball from the official site or whatever.
When used, some module's parameters change (for example the paths of files)
and therefore the values of these paths are no more the operatingsystem
specific ones but depend on other variables ( something like
$install_destination_dir, for example).
So the issue here is: if $install == 'upstream' (retrieve the software as a
zip/tarball from the upstream site and not use the OS package) and
$install_destination_dir == '/opt' , for example, then the paths of the
configuration files is different.
To my understanding in order to reproduce this logic in hiera data, we have
to add a hierarchy level according to the value of $install and in the
relevant yaml file (or whatever datastore) interpolate
$install_destination_dir in order to provide the correct $config_file_path .
Actually my sample hiera.yml could be just :
---
version: 3
hierarchy:
- category: 'osfamily'
- category: 'operatingsystem'
- category: 'install' # Class' scope variable , what the correct way to
reference it?
...
so maybe it's not that hard to do.
> >
> > - category: 'environment'
> > - category: 'common'
> > paths:
> > - 'is_virtual/${is_virtual}'
> > - 'common'
> >
> >
> > -- If a case like the above can't be expressed as "pure" hiera data,
> we'll
> > have to turn back in having some data in code (incidentally I don't
> > consider it a mortal sin, as we have been doing this in modules all the
> > time up to now), either reverting to hiera_puppet or with the usual code
> > gymnics with selectors, cases and ifs.
>
>
> It's a critical feature thats always been there - If I understand what you
> mean.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
