On Oct 19, 6:04 pm, Bruce Richardson <itsbr...@workshy.org> wrote: > [...] I agree with you about the > importance of state, but in that scenario, to me, not being an LDAP > client is the basic state.
After much consideration, I think a great deal of this debate hinges on that definition. It is perfectly reasonable, but not exclusively so. For instance, my basic state is for systems to be NIS clients. It seems most reasonable to me for the basic state to provide those configuration details from which few of my systems deviate. The OP's, at present, is for systems to be LDAP clients. > The basic, clean state of a system should be > something Puppet protects from the start; including classes should > modify or extend that and, in most cases, I expect my configuration to > be protective enough of the core and well known functionality so that > it should make no difference whether a class was previously included and > then dropped or never included in the first place. I don't quite understand that. How does your configuration protect the basic state of a system without including classes? You could use global resources, but then those could not be overridden. I suspect that instead you have one or more core classes that you include on every node to establish and maintain the basic state; that seems consistent with your further comments. Particular nodes then include *other* classes to modify or extend. [...] > I certainly know enough about the core components of a > system (nsswitch, pam, fstab and so on), to know what will interfere > with that and what is irrelevant. The seed of any configuration, for > me, would be locking those down in their simple and functional state. > This means that including an ldap::client will extend that, but in the > absence of ldap::client, the core function will be restored. I think you're saying that you would implement ldap::client itself using subclassing if (and only if) it needs to alter anything in the core. There's merit to that, and doing it that way could indeed have exactly the results you describe. No further subclass would be required. But how does this apply to the OP? His current basic state is for systems to be LDAP clients. That's not what you would choose, but if he retains that choice, then does not your approach call for subclassing where a node must not be an LDAP client? Such nodes would then include ldap::client::disabled to override the base, and dropping that class would restore base functionality, just as you recommend. In all likelihood, such a subclass could be very slim: it probably needs to override only a small number of resources to disable the client (maybe just /etc/nsswitch.conf); it shouldn't need to completely counter everything in ldap::client. > I do > not share your nervousness about purging - purge and well managed > resources - and judicious use of virtual ones - is generally cleaner > than a whole set of twinned active/inactive classes. It doesn't mean I > never, ever write a disable/cleanup class but it isn't my habit. I'm curious: what types of resources do you purge, in what contexts? Your configuration philosophy seems similar to mine in that you don't try to manage every system detail, but that rather limits the available scope for purging, doesn't it? [...] > This is more than semantic quibbling about how to label different > states; inheriting and overriding a more complex state to impose a > simpler state is not the same as defaulting to the simpler state. Much then depends on the chosen measure of complexity. I think you mean to judge by some measure of distance between the target state and a base reference state, which I take to be your "basic" / "clean" state. Your recommendations then make good sense when you stipulate the existance of a default state to fall back on, especially when coupled with purging to clean up potentially troublesome unwanted resources (thanks for those clarifications). How that applies to the OP's case is a different question, however. If he continues to rely on a base state in which the LDAP client is enabled, then overriding that state to disable the client leads to a more complex state (by the above standard). As I said at the beginning, much seems to hinge on the choice of base state. Our positions now seem much closer than they originally did. I won't argue over how a system's base state should be constituted -- that's too subjective -- and otherwise we seem largely to agree. Overall, my main objection to your original response was about your claim that a subclass-based solution would require use of defines and conditionals. You seem to have backed off on that, so I think we're good. Cheers, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
