On Wednesday, October 29, 2014 8:48:56 AM UTC-5, JonY wrote: > > Is it (reasonably) feasible to add new resource types? I don't want to > disassemble the whole code base but if there is a known path to this I'd > like to read about it. >
Yes. 1. Defined types <https://docs.puppetlabs.com/puppet/latest/reference/lang_defined_types.html> are resource types. If you have a Puppet manifest set of any significant size then you are probably using these already. 2. You can write your own plugin / native / Ruby resource types, too. There is official documentation <https://docs.puppetlabs.com/guides/complete_resource_example.html> for how to do this, and there are plenty of examples -- many in Puppet's own code, and some in publicly available modules. > Some thoughts:It strikes me that there are at a few situations that I run > into with this SW that would make for decent additions. > > 1. "once": do a given resource type once and set a fact to not repeat it. > I keep kludging solutions to this. > I could imagine a defined type wrapper that would help you do that. > 2. "log": set a log level and location for a resource / node / etc. This > would help to figure out "WTF is going on". > Likewise here, more or less, but I'm inclined to think that it would be easier to just use a collector to override selected resources' loglevels. Nodes don't have loglevels, though, so you can't do it at that scope by any means. > 3. "return value": set a fact with the failure code for a given operation > or agent run. I keep finding cases where the agent is failing and the > server isn't logging it. It isn't until I log in and run the agent that I > see the error(s). > You could write custom facts that extract failure codes for selected prior operations from the system logs. That doesn't require a resource. Resources don't have a sense of a "return code", however, nor any consistent hooks into the operations performed by their providers, so a *generic* mechanism to capture and record such information directly from resources does not sound feasible to me. > 4. "counter": set a fact with the # of times a given operation has been > performed on a system. This would help to track down systems that are > thrashing because of competing operations. > > Puppet already provides per-run reports describing which resources were modified, if you configure it to do so. It does not have much of a generic sense of finer-grained "operations". > > These could either be additional params for existing resources or an outer > layer to same. > > If you are inclined to use a custom-modified version of Puppet then you can do pretty much anything. Some things you suggest doing will require a lot more work than others, however, and you may run into issues with third-party modules (unless you hack those, too). Puppet already provides alternatives for most of the things you described, and if it were me, I would not entertain the possibility of hacking up Puppet itself. John -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d4a2056f-8c46-47e5-bed9-e44260f59de5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
