Open Stack

A first changeset to implement the new API is at
https://review.openstack.org/#/c/10978/

The docs for the portion of the API that has been implemented can be found
at http://ceilometer.readthedocs.org/en/latest/api.html. 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.

See
https://review.openstack.org/#/q/status:open+project:stackforge/ceilometer,n,zfor
the list of pending reviews (hint, hint :-).

Doug

On Wed, Aug 8, 2012 at 12:03 PM, Nick Barcet <nick.barcet at canonical.com>wrote:

> Not seeing any further comments on this, and personally agreeing on the
> points raised by Doug and with Jay's refinement, I think the next step
> would be to produce a new version of the proposed API wiki page and
> submit this for formal approval at one of our meetings.
>
> I'll put the subject to our meeting agenda for tomorrow in any case.
>
> Nick
>
> On 08/07/2012 01:38 AM, Doug Hellmann wrote:
> > On Mon, Aug 6, 2012 at 6:31 PM, Jay Pipes <jaypipes at gmail.com
> > <mailto:jaypipes at gmail.com>> wrote:
> >
> >     On 08/06/2012 06:02 PM, Doug Hellmann wrote:
> >     > I've submitted a patch to implement a few of the queries for meter
> >     event
> >     > data using the "project" filter. As you can see from the diff [1],
> >     there
> >     > are now 16 separate routes pointing to the same simple function
> that
> >     > calls the database backend. This smells bad, so I would like to
> >     propose
> >     > changing the API to remove some of the duplication.
> >     >
> >     > First, when asking for values about a given resource, there isn't
> any
> >     > reason to specify the user or project because they won't change
> for a
> >     > given resource. I don't think it's going to be useful to ask for a
> >     > complete dump of all of the metering data for a user at one time,
> >     since
> >     > the events will refer to different resources and meters. That
> >     eliminates
> >     > several variations, so instead of 16 URLs listed in the current
> >     > implementation, we have 3:
> >     >
> >     > /users/<user>/<meter>
> >     > /projects/<project>/<meter>
> >     > /resource/<resource>/<meter>
> >
> >     I assume you mean:
> >
> >     /resources/<resource>/<meter>
> >
> >
> > Yes, thanks for catching that. When in doubt, assume I mean to be
> > consistent. :-)
> >
> >
> >
> >     > For the supported calculations, we would add "/duration" or
> >     "/volume" to
> >     > the end of the above URLs. That's 2 sets of 3 more URLs, with each
> set
> >     > pointing to a function to do that calculation for us.
> >
> >     OK.
> >
> >     > For /resources/<resource> the metadata for the resource is returned
> >     > (including the list of meters reporting).
> >     >
> >     > These forms:
> >     >
> >     > /users/<user>
> >     > /projects/<project>
> >     >
> >     > return the list of resources owned by the user or project.
> >
> >     I think it would be better to do:
> >
> >     /users/<user>/resources
> >     /projects/<project>/resources
> >
> >     Since you would be being explicit about the resource/document
> returned.
> >
> >     Further, you would limit the return to a single resource document
> >     like so:
> >
> >     /users/<user>/resources/<resource>
> >
> >
> >     In the same vein, I think it would be better to have:
> >
> >     /users/<user>/meters/<meter>
> >
> >     instead of:
> >
> >     /users/<user>/<meter>
> >
> >     For the same reason: you are being explicit that a <meter> is a
> resource
> >     of which a user has many, and you are selecting a specific meter
> >     resource from the list of a user's meters.
> >
> >
> > OK, I can see that. What I wanted to avoid was someone thinking that
> > /users/<user> would return anything about the user, since we don't
> > really have any interesting metadata about the user object itself.
> >
> >
> >
> >     > I'm not sure what to do with "source." It seems like a source
> should
> >     > just tell us about the list of meters is provides, and then we
> should
> >     > ask for the meter data in the usual way. So /sources/<source>
> >     returns a
> >     > list of meter names, and we use /resources/<resource>/<meter> (for
> >     > example) to retrieve the actual values.
> >
> >     If /sources/<source> returns a list of meters, then I would think
> that
> >     the appropriate URL construct would instead be this:
> >
> >     /sources/<source>/meters
> >
> >     Best,
> >     -jay
> >
> >     _______________________________________________
> >     OpenStack-dev mailing list
> >     OpenStack-dev at lists.openstack.org
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120808/3b883a2d/attachment-0001.html>