> > As I said, that's a very odd way of doing things. It's odd on at least > two levels: > > 1. it's a bit odd that you want to configure the application by > dynamically submitting data to the service, instead of by directly managing > its configuration data store. This approach has negative consequences, > including, but not limited to, the type of problem you have asked about. >
If what you're saying is bypassing the API to manipulate the api's datastore directly it is not an option and generally doesn't sound like a good idea ... > 2. it's very odd that you construct the JSON data by using an external > application to cull it from PuppetDB, especially when you're already using > exported resources. There may be a good reason for this approach -- > The restful api is used to configure monitoring. If someone wants monitoring configured they speak to the api. People use Puppet to manage their hosts. The manifests describing the state of a host includes the exported resources which on their turn describe the state of the monitoring for that host (or its services/applications). Since the data required to configure monitoring is is stored in PuppetDB, we need to have a way to interface that to the restful api .... > it's hard to tell since you're so parsimonious with the details -- but I > wouldn't generally recommend it. > I understand your inquiry to the context of this, but I didn't want this post to focus on why things are as they are. > Overall, it does not mesh well with Puppet's approach to configuration > management: state, not actions, are the central focus of Puppet's view of > configuration management. Its basic mode of operation involves cycles of > (a) determining what the desired machine state is, (b) comparing the actual > state to the desired one, and (c) updating the machine state where > necessary. > Agreed. The process you describe seems grossly inconsistent with that model. > Well, the state of monitoring of a host is managed by an external system and should become aligned to the state described by Puppet which is regarded as authoritative. A better idea would be to cut out the middleware altogether. Put the the > host on which your service runs under Puppet management, if it isn't > already. Manage the service's configuration files via Puppet, and signal > it to re-read them when Puppet changes them. This is a pretty standard > pattern. > Not an option. The api should be used exclusively to manipulate monitoring configuration. > A variation on this pattern that might interest you involves building the > configuration file from multiple fragments, via the Concat module. The > fragments can be exported by multiple hosts and collected into the catalog > for the machine(s) on which the overall file needs to be managed. Even if > there is no alternative to managing your service via its REST API -- maybe > it has no static configuration file, for example -- you should still be > able to use this or a similar approach to avoid scraping the needed > configuration data from PuppetDB. > Yes, that's an idea. It would avoid the need of continuously scraping the DB. Food for thought. If you *must* do it this way, then you can configure agents to send reports > to the master at the end of each run, and you can configure a report > processor on the master that does whatever it needs to do with the > resulting data. > That's the kind of stuff I was looking for. > If you can get by with less data, and if your catalog runs normally go > complete without any changes, then you could perhaps also run the agent via > a scheduler (instead of as a daemon), with the --detailed-exit-codes option > turned on, and trigger your middleware based on the agent reporting via its > exit code that changes were applied. > That's valuable information. I need to look into this Absurd. You should use Execs where they make sense. Execs can be > over-used, but the alternative is to use a different resource type, not to > avoid modeling your configuration via resources. If there isn't already a > suitable resource type available, then that involves making one. And don't > tell whoever enforces that policy, but you'll see Execs in a lot of popular > and well-respected modules, including many of those published by > PuppetLabs. If you rely on many third-party modules then you probably have > some Execs in your manifest set from those sources. > Agreed. > If the prohibition against Execs is absolute and incontrovertible, > however, then it wouldn't be too hard to write a custom type that just > wraps the specific command you need to run, and that executes it (only) > when it refreshes. Deploying an instance of such a type in the right place > would be a great deal better than relying on some kind of external > middleware to trigger updates based on log traffic. > Agreed. Thanks John for the suggestions and insights. Much appreciated. This information gives me something to works with. -- 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/c2ea213a-482f-4bf7-b1eb-6911ad021c94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
