On Wed, Mar 11, 2015 at 09:25:04AM -0700, Bostjan Skufca wrote:
> On Wednesday, 11 March 2015 14:57:00 UTC+1, Christopher Wood wrote:
>
> (Replying to two people in one email, hum.)
>
> I rather take your point, but isn't the requirement for different data
> handling just another data item? Is any code unaware of the underlying
> data structure? Even if you have a single type of data (plain
> string-like variables) your code is implicitly aware that it can treat
> them as that type.
>
> Yes, certain dependency always exists, that can not be denied. But it
> should lean towards minimum amount of coupling.
> But if we venture a peek into programming languages, for example towards
> functions that return arrays, which best matches our current discussion.
> function callee ()
> {
> ...
> return $arrayOfData;
> }
> function caller ()
> {
> $newDataArray = callee();
> }
> The caller() gets very messy, if it is its responsibility to figure out if
> returned array from callee() is either:
> - an array of keys and values
> - an array of arrays of keys and values
> This is what I am talking about - if callee just returns array of arrays
> it is not behaving very nicely :)
> And this is exactly what hiera does.
> If I think about this a little further, this is what hiera backends do.
> hiera*() functions on the other hand does a bit poor job at abstracting
> provider internal data, or does a good and simple job alright sacrificing
> some flexibility we had with class inheritance.
> Anyhow, it seems writing custom backend providers is the way out.
>
>
> I'm not really sure there's a way to automagically distinguish
>
> "this is an array, do not retrieve its contents from all levels"
> "this is an array, do retrieve its contents from all levels"
>
> while still preserving our sanity.
>
> Agreed. But if you use hiera with multiple scopes (common, dc, row, rack,
> node), each layer usually knows if data from parent scope should be merged
> with, or replaced.
(I will agree to a point, this is often situational based on the company
culture.)
> Again, maybe it is just that default hiera backends do not allow for such
> flexibility. It should not be hard to switch that to custom provider,
> whose data model actually allows for such flexibility.
>
> (I've had some nasty run-ins with merging lookups and have decided
> they're mostly not for me, maybe the smarter people on this list are
> having better results.)
>
> Care to elaborate a bit, especially how did you overcome them (define all
> data for each node)?
> b.
Abstracting the details a bit, I had a key in common.yaml which was fine at
first but as time went on was not appropriate for all nodes. That was fine
because some subsets of nodes overrode the setting at a higher level. Many
months later I felt it would simplify our hiera configuration (fewer duplicate
hash elements that could be consolidated farther down the tree) if I used a
hiera_hash(). I did not recall the existence of this default setting, nor did I
grep for it (which would have saved me). A stack of nodes got an incorrect
setting and much sadface was had. I had a few more in the lab but this was the
first one that escaped. The fact that I failed to check for existing hiera keys
in other levels is quite obviously my fault, however, it's also important that
the underlying architecture (deep levels, complex merged hiera data) and
culture (a default for everything) enabled the resulting error condition.
Explaining the fix needs an example (fictional): I'm licenced per-datacentre
for Bespoke Proprietary Edition (BPE) plus some testing licences which activate
additional features, and I have a stub class and short hiera tree.
common (true for everything)
type (true for hosts of that type, e.g. frontend, db, core)
datacentre (true for hosts in that location)
node (true for individual hosts)
class bpe ( $licencing ) {
# stuff happens here
}
My desirable behaviour for BPE nodes which do not exist in a licenced
datacentre is to not apply any licence key and thus to not run the daemon.
(Your mileage may vary, my rationale is that my company agreed to these
restrictions and I will stick to them.)
My desirable behaviour for the puppetmaster compiling the catalog for an
unlicenced host is to error out and fail the catalog compilation, highlighting
the missing data at the earliest possible stage of the build. (Your mileage may
vary, my rationale is that a server without all its requirements in place
should not build. The "Finished catalog run" seems to instill a bit of false
confidence that everything worked.)
Putting these together, my bpe::licencing key would go no lower than the
datacentre level. If we roll out a new location somebody would have to add the
key to newdc.yaml before BPE hosts will build there. If somebody wants to try
out the test licensing they can add all licences to a node in one of the
datacentres. The error message signals the admin to go get the required
licences, or at least to ask why it's erroring on licencing when building other
hosts works.
In short, abandon the concept of a default where there isn't a legitimate
default and be stricter about when servers build.
All that said, we do have a remaining hiera_hash() where it has never done any
harm, our yum module. We've had a few build failures in the lab finding out
which repos were mutually incompatible but this one has never been any problem
in production.
> --
> 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 [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/a3b26c59-beb9-4dc1-a669-e253858d602a%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/a3b26c59-beb9-4dc1-a669-e253858d602a%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20150313164017.GA18053%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
