The API looks good to me. Will this be available as a command line tool (standalone one, not contacting a master)? That would be useful for scripts and local development where you might not want to upload the code to a puppetmaster in order to find the classes.
If it is using the indirector it should be pretty trivial to create a puppet face for it. Also, will you create a similar one for defined types? Functions? On Wed, 9 Mar 2016 at 21:45 Chris Price <ch...@puppetlabs.com> wrote: > Hello, > > We're looking into the possibility of deprecating and removing the ` > resource_types` endpoint from Puppet Server. > > The current implementation can return information about a lot of different > things in Puppet, but it's very expensive (in terms of CPU and memory > usage), and has some unexpected side effects that can cause subsequent > requests to other endpoints (including catalog compilation! see > https://tickets.puppetlabs.com/browse/SERVER-1200 ) to misbehave. > > The main use case that we're aware of for the endpoint is to get a list of > all of the classes (and their associated parameters) for an environment. > We've just finished building a new HTTP endpoint called > 'environment_classes' (which will ship in the upcoming releases of OSS and > PE Puppet Server) that will provide that data in a cleaner, less expensive > fashion. You can see a sneak preview of the documentation for this new > endpoint, including its wire formats, here: > > > https://github.com/puppetlabs/puppet-server/blob/dc58bdd94246e5b68bf1adff2d38bf574ca22662/documentation/puppet-api/v3/environment_classes.md > > Once that endpoint is available we'd like to deprecate and eventually > remove the resource_types endpoint. However, we'd first like to make sure > that there aren't other important use cases that users are relying on it > for. (If there are, we'll probably try to address those by adding > additional new HTTP endpoints until we're at feature parity for the things > that people rely on resource_types for.) > > So... this is a solicitation for input. Do you currently rely on the > resource_types endpoint for critical parts of your workflow? What kinds of > things are you using it for? What would you be missing if it were to be > removed? > > We've got a placeholder ticket in our issue tracking system for this > deprecation / removal: > > https://tickets.puppetlabs.com/browse/SERVER-1120 > > It doesn't have a ton of detail yet, but if you're interested in tracking > this, you can watch that ticket as that is where we'll end up tracking > things as this progresses. > > Thanks in advance for your feedback! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLUqXuDSk_Zpqf%3DGvmqjprYmzfwa%3DnUdrbxO3LhOLT1bg%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CAMx1QfLUqXuDSk_Zpqf%3DGvmqjprYmzfwa%3DnUdrbxO3LhOLT1bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfieuo5bv3s3u%3D1Gmk%3DzuwYkUSfQYFruiqgYz%3DtvSvypw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
