Open Stack

On Mon, 20 Oct 2014, Jim Mankovich wrote:
> On 10/20/2014 6:53 AM, Chris Dent wrote:
>> On Fri, 17 Oct 2014, Jim Mankovich wrote:
>>> See answers inline. I don't have any concrete answers as to how to deal
>>> with some of questions you brought up, but I do have some more detail
>>> that may be useful to further the discussion.
>> 
>> That seems like progress to me.

And thanks for keeping it going some more. I'm going to skip your
other (very useful) comments and go (almost) straight (below) to
one thing which goes to the root of the queries I've been making.

Most of the rest of what you said makes sense and we seem to be
mostly in agreement. I suppose the next step would be propose a
spec? https://github.com/openstack/ceilometer-specs

> We have 2 use cases,
> Get all the sensors within a given platform (based on ironic node id)
> Get all the sensors of a given "type/name". independent of platform
> Others?

These are not use cases, these are tasks. That's because these say
nothing about the thing you are actually trying to achieve. "Get all
the sensors with a given platform" is a task without a purpose.
You're not just going to stop there are you? If so why did you get
the information in the first place.

A use case could be:

* I want to get all the sensors of a given platform so I can <do
   something>.

Or even better something like:

* I want to <do something>.

And the way to do that would just so happen to be getting all the
sensors.

I realize this is perhaps pedantic hair-splitting, but I think it
can be useful at least some of the time. I know that from my own
experience I am very rarely able to get the Ceilometer API to give
me the information that I actually want (e.g. "How many vcpus are
currently in action). This feels like the result of data availability
driving the query engine rather than vice versa.

-- 
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent