On May 27, 1:09 am, Michael Stahnke <[email protected]> wrote: > I have a concern with this type, but it's more generic and not your > implementation. > > The basic premise is that if you gather a resource externally from puppet's > catalog, that resource can change, but the catalog might not. > > Let me explain a bit more. > > Given you have a a REST API or even a simply GET to get a configuration file > for service foo. > When configuration file for service foo changes, the catalog might not > change, and maybe it should. > > If you have a newer version of a configuration file available, and thus it > requires configuration changes, but for some reason the catalog won't > compile (or you're on cached catalogs, or whatever), you now have a non > congruent version of the RESTFUL resource paired with the catalog. >
Yes this situation would be possible but I think this objection stems from an underlying assumption that this web resource would be primarily used to retrieve files. I wasn't thinking about this in that regard, after all puppet already has file synchronization mechanisms. Rather this new type would provide the ability to invoke calls on external web based resources and verify the results. As a matter of fact the plugin as it stands does not save the http result's body, but we could always add this as an optional feature if we wanted. > I ran into some sticky situations at my former job when I tried to do things > like this. > > You also run into issues of how puppet handles an external resource when it > gives a 500 or a 404. The catalog will still compile, because it doesn't > verify the external resource via http at catalog compilation time. The plugin currently also supports http status code verification, so that the puppet recipe author can specify the http return status code they are expecting in the result (or an array of possible values) > > I could be the only person that has ever run into issues like this, or your > implementation may be handling this better than my previous experiences were > able to. I really appreciate your feedback, I would like to make this module as robust and comprehensive as possible. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
