On Wed, Feb 22, 2012 at 05:44:37PM -0200, Luiz Capitulino wrote:
> On Wed, 22 Feb 2012 10:54:45 -0600
> Michael Roth <mdr...@linux.vnet.ibm.com> wrote:
>
> > But I'm not suggesting we make query-balloon asynchronous.
> >
> > I'm suggesting be re-enable it as a synchronous interface by having it
> > immediately return the latest-available results from a timer-driven
> > query mechanism that tucks away the query results, such as the one Anthony
> > suggested.
>
> I'm not sure I like the semantics, as query-balloon would have some fields
> that actually depends on a timer based polling being enabled somewhere else,
> while others fields ('actual') would always be there.
I think that's more a side-effect of sticking stats unrelated to
ballooning in query-balloon in the first place... but yah, maybe it
makes the interfaces not worth reviving.
>
> > > But that's a dead discussion I guess, as I already agreed on implementing
> > > this as a device property.
> >
> > Along with timer-based refresh of the properties? If so I don't understand
> > why we
> > can't just have query-balloon simply return those properties when it's
> > called? I
> > thought that's what Anthony was driving at with the timer-based
> > approach.
>
> What I had understood is to make each stats a dynamic device property, then
> mngt apps would use qom-set/get on them.
Ahhhh, yah... you're probably right. And we get that for free by tieing
the data to properties, which I guess is where the significance of QOM
was wrt to the polling approach (since we could actually stick the data
anywhere if we did something like query-balloon).
I don't really have any objection there, my main concern was that we
were gonna be adding something *beyond* qom-get or query-balloon, but if
that's not the case, carry on :)
>
> Anthony, can you detail your suggestion please?
>
