A first changeset to implement the new API is at <a href="https://review.openstack.org/#/c/10978/">https://review.openstack.org/#/c/10978/</a><div><br></div><div>The docs for the portion of the API that has been implemented can be found at <a href="http://ceilometer.readthedocs.org/en/latest/api.html">http://ceilometer.readthedocs.org/en/latest/api.html</a>. That page shows the old API now, but it will update automatically after some of the other pending reviews are approved and I change the readthedocs configuration to point back to the master branch.</div>
<div><br>See <a href="https://review.openstack.org/#/q/status:open+project:stackforge/ceilometer,n,z">https://review.openstack.org/#/q/status:open+project:stackforge/ceilometer,n,z</a> for the list of pending reviews (hint, hint :-).</div>
<div><br></div><div>Doug<br><br><div class="gmail_quote">On Wed, Aug 8, 2012 at 12:03 PM, Nick Barcet <span dir="ltr"><<a href="mailto:nick.barcet@canonical.com" target="_blank">nick.barcet@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not seeing any further comments on this, and personally agreeing on the<br>
points raised by Doug and with Jay's refinement, I think the next step<br>
would be to produce a new version of the proposed API wiki page and<br>
submit this for formal approval at one of our meetings.<br>
<br>
I'll put the subject to our meeting agenda for tomorrow in any case.<br>
<br>
Nick<br>
<div class="im"><br>
On 08/07/2012 01:38 AM, Doug Hellmann wrote:<br>
> On Mon, Aug 6, 2012 at 6:31 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>> wrote:<br>
><br>
>     On 08/06/2012 06:02 PM, Doug Hellmann wrote:<br>
>     > I've submitted a patch to implement a few of the queries for meter<br>
>     event<br>
>     > data using the "project" filter. As you can see from the diff [1],<br>
>     there<br>
>     > are now 16 separate routes pointing to the same simple function that<br>
>     > calls the database backend. This smells bad, so I would like to<br>
>     propose<br>
>     > changing the API to remove some of the duplication.<br>
>     ><br>
>     > First, when asking for values about a given resource, there isn't any<br>
>     > reason to specify the user or project because they won't change for a<br>
>     > given resource. I don't think it's going to be useful to ask for a<br>
>     > complete dump of all of the metering data for a user at one time,<br>
>     since<br>
>     > the events will refer to different resources and meters. That<br>
>     eliminates<br>
>     > several variations, so instead of 16 URLs listed in the current<br>
>     > implementation, we have 3:<br>
>     ><br>
>     > /users/<user>/<meter><br>
>     > /projects/<project>/<meter><br>
>     > /resource/<resource>/<meter><br>
><br>
>     I assume you mean:<br>
><br>
>     /resources/<resource>/<meter><br>
><br>
><br>
> Yes, thanks for catching that. When in doubt, assume I mean to be<br>
> consistent. :-)<br>
><br>
><br>
><br>
>     > For the supported calculations, we would add "/duration" or<br>
>     "/volume" to<br>
>     > the end of the above URLs. That's 2 sets of 3 more URLs, with each set<br>
>     > pointing to a function to do that calculation for us.<br>
><br>
>     OK.<br>
><br>
>     > For /resources/<resource> the metadata for the resource is returned<br>
>     > (including the list of meters reporting).<br>
>     ><br>
>     > These forms:<br>
>     ><br>
>     > /users/<user><br>
>     > /projects/<project><br>
>     ><br>
>     > return the list of resources owned by the user or project.<br>
><br>
>     I think it would be better to do:<br>
><br>
>     /users/<user>/resources<br>
>     /projects/<project>/resources<br>
><br>
>     Since you would be being explicit about the resource/document returned.<br>
><br>
>     Further, you would limit the return to a single resource document<br>
>     like so:<br>
><br>
>     /users/<user>/resources/<resource><br>
><br>
><br>
>     In the same vein, I think it would be better to have:<br>
><br>
>     /users/<user>/meters/<meter><br>
><br>
>     instead of:<br>
><br>
>     /users/<user>/<meter><br>
><br>
>     For the same reason: you are being explicit that a <meter> is a resource<br>
>     of which a user has many, and you are selecting a specific meter<br>
>     resource from the list of a user's meters.<br>
><br>
><br>
> OK, I can see that. What I wanted to avoid was someone thinking that<br>
> /users/<user> would return anything about the user, since we don't<br>
> really have any interesting metadata about the user object itself.<br>
><br>
><br>
><br>
>     > I'm not sure what to do with "source." It seems like a source should<br>
>     > just tell us about the list of meters is provides, and then we should<br>
>     > ask for the meter data in the usual way. So /sources/<source><br>
>     returns a<br>
>     > list of meter names, and we use /resources/<resource>/<meter> (for<br>
>     > example) to retrieve the actual values.<br>
><br>
>     If /sources/<source> returns a list of meters, then I would think that<br>
>     the appropriate URL construct would instead be this:<br>
><br>
>     /sources/<source>/meters<br>
><br>
>     Best,<br>
>     -jay<br>
><br>
>     _______________________________________________<br>
>     OpenStack-dev mailing list<br>
>     <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
</div></div>>     <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>     <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>