Open Stack

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120808/d0ad090e/attachment.pgp>