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.<div>
<br></div><div><div>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:</div>
<div><br></div><div>/users/<user>/<meter></div><div>/projects/<project>/<meter></div><div>/resource/<resource>/<meter></div><div><br></div><div><div>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.</div>
</div><div><br></div><div>For /resources/<resource> the metadata for the resource is returned (including the list of meters reporting).</div><div><br></div><div>These forms:</div><div><br></div><div>/users/<user></div>
<div>/projects/<project></div><div><br></div><div>return the list of resources owned by the user or project.</div><div><br></div><div>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.</div>
<div><br></div><div>These changes give us a two benefits. Primarily, the API is easier to use, since there are fewer individual calls. It will also be easier to implement, since we won't have so many endpoints that are really just alternative forms of the same query. </div>
<div><br></div><div>If the rest of the team agrees, I would like to make these changes in the next couple of weeks as part of the work that we will be doing to integrate ceilometer with the billing system at DreamHost. </div>
<div><br></div><div>Let me know what you think,</div><div>Doug</div><div><div><br></div><div>1. <a href="https://review.openstack.org/#/c/10913/1/ceilometer/api/v1.py">https://review.openstack.org/#/c/10913/1/ceilometer/api/v1.py</a></div>
</div></div>