class globs

[martin f krafft]

Hi Matthew,

thank you for your idea. I cannot really say whether this is good or
bad just yet, because I don't quite understand your use-case.

Let me hypothesize.

I doubt that the files in locations/*/networks/* contain overlapping
data, as you'd be relying on glob() to use some sort of alphanumeric
sorting and suddenly your resulting data would depend on LC_COLLATE.

So therefore, your data files will namespace their data, e.g.
munich_rack4_gateway, or munich:rack4:gateway (i.e. using
a hierarchy).

I am not sure that this is a good use case of reclass. Let me try to
explain why.

Reclass exists to compile and serve infrastructurem knowledge
_about_ a single node _for_ a single node. Arguably, there is a need
for cross-references (i.e. compiling a list of all munin-nodes for
use on the munin server), but the data served is still specific to
a node.

If I understand your plan correctly, then you'd essentially place
your entire network infrastructure knowledge into reclass and expect
the minion to pick the data it wants, ignoring all those data that
aren't applicable to the minion anyway.

Right?

Sure thing, that's a viable use case and I am not per-se opposed to
adding such functionality to reclass.

But I think that this could be solved in better ways. Yes, you call
it a "shortcut for including/merging all those network files", to
which I say that in the long-term, shortcuts end up becoming the
longest distance between two points. ;)

Could you please show us the data? Since I also have machines in
various different networks, and the way I solved it was always an
integral consideration in reclass' design, I'd love to have the
opportunity to provide you with an alternative approach.

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"mein gott, selbst ein huhn kann debian installieren, wenn du genug
 koerner auf die enter-taste legst."
                       -- thomas koehler in de.alt.sysadmin.recovery
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.pantsfullofunix.net/pipermail/reclass/attachments/20131017/30bb2702/attachment.pgp>