Open Stack

On Mon, Aug 6, 2012 at 6:31 PM, Jay Pipes <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
> 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/20120806/a2df29c3/attachment.html>