On 2/2/10 12:27 PM, "Justin Lloyd" <jll...@digitalglobe.com> wrote: > I've not thought it through completely, but I really like the > /etc/classes directory idea. I had an idea of using an > /etc/digitalglobe.conf shell-style file that could be parsed or sourced > by Cfengine, shell scripts, etc. and could contain comments explaining > each entry (e.g. RUNTIME=gold, FUNCTION=pp). But OTOH, /etc/classes > files could contain descriptions of why they're there. OTTH, I could > have a variable in the conf file that simply contained additional > arbitrary classes, similar to your minimal_host class. And a single file > per host is easier to revision control. This will take some thinking. > Either way, however, such files would generally be outside of Cfengine's > remit, so there's the question of how to manage those files and prevent > them from being inadvertently changed or deleted.
One thing I didn't make clear in my last post... /etc/classes is still considered a bit of a hack. If there is something that must be supported long-term, it would ideally be added to policy (and our documentation and training enforces this). So /etc/classes is not meant to permanently override host configuration. It's just an option for power users (the paged admin at 3AM) when they really need control, or an easy stop gap while integrating new hosts (merged with Company X and got N new roles to think about?). We've found having these sort of flexible options make adoption of cfe easier for all. In terms of monitoring staleness, it should be fairly easy to write a nagios plugin that checks for /etc/classes files > threshold age. Beside this, we also have a system similar to what you describe... Our inventory database can return shell style output to queries received over the web. I highly suggest this approach... Once it was available, everyone started using it. The ability to run a single lightweight query and receive "all hosts of role X" or "all DEV hosts of role Y" in a fairly automated (e.g. The database is updated as part of provisioning new machines, not as manual edits to flat files) saves a lot of time. This sort of database is where more permanent role definitions belong (minimal hosts should eventually transition to a documented role), and we have modules which derive class information from the database (with caching of course, so the database can go down and on one cares...data just gets stale). It's good to see different minds progress in similar directions... I just wanted to encourage you to keep exploring this angle, and focus on making your host configuration data distributed (essential data should be available to each host with caching), centrally managed (through a web UI, SQL query, etc.), and query-able (harder if you don't use a database). We've also found that building web UIs on top of such data helps enforce constraints (e.g. A MAC address shouldn't be formatted like an IP, a FQHN should contain at least 2 dots, etc.). Otherwise, data quality may suffer as teams/number of hosts grow (more typing, more typos). _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
