On Tuesday, January 8, 2013 at 5:10 AM, Erik Dalén wrote: > I've been reading through the experimental PuppetDB reports API and I feel a > lot of stuff is missing in it. I know it is experimental and kind of beta > still, but I thought it might be good to share some feedback on it anyway. > > In the report API > (https://github.com/puppetlabs/puppetdb/blob/master/documentation/experimental/report.md) > I'm missing: > * querying on end-time, start-time & receive-time fields, want to be able to > use = > < => & =< operators on it. > * querying on configuration version > * querying on number of event in the report (total, failed, pending & success) > * querying on puppet-version > > In the events API > (https://github.com/puppetlabs/puppetdb/blob/master/documentation/experimental/event.md) > I would like: > * querying on all the different attributes in the return format (old-value, > property, timestamp, resource-type, resource title, new-value, message & > status) not just on report ID. > * ability to query on certname here as well (easy way to pull all events for > a host without having to pull all reports for it and then another query for > each event in those reports) > Possibly this can be solved by subqueries here: ["in", "report", ["extract", > "id", ["select-reports", ["=", "certname", "foo.example.com > (http://foo.example.com)"]]]] > * Ability to pull the most common types of events in a time period, for > example a list of the most common fail messages the last 2 hours and counts > for them. > >
Thanks Erik, this is really useful information. Improving report querying is going to be a big part of our next batch of work. We know it's almost non-existent, but we wanted to get what we had released sooner rather than later, so at least the storage can be battle-proven for a while. And because we needed more time to gather requirements for query and to design the API. For what it's worth, what you need seems pretty consistent with what we've been planning. So you can count on that coming down the pipe soon. :) > > Also I'm wondering a little bit why it uses a new wire format instead of the > regular http report handler? There are a few reasons for this. The most basic is that we wanted to submit reports as commands, which means they need to conform to our command format. Using our own report processor makes it easier to coexist with others, since you can't use two http handlers at the same time. This also lets us manage exactly the data we're sending, which means we can diverge from what puppet uses if necessary, and also makes reports smaller and faster to process. Since this report format isn't really that user-facing (you can query for it today, but we think it's more common to query for interesting events across a population rather than a whole report for a node) it seemed like the control it gave us was worth the complexity of having another format. Thanks for the feedback; it's great to see interest before it's even released! Nick Lewis > > Looking forward to using it and coding some tools around these new APIs :) > > -- > Erik Dalén > > > -- > 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. > > -- 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.
