Dynamic Tables (dashboard widget)

@Ali Holmes Thank you!

One more desirable thing would be the ability to reference properties (device and ILPs), not just datapoints.  This would enable presentation of asset information, for example, assuming propertysources are producing results.

I agree with this 100%. Running in to this issue now.

In my example, I would like a table showing a full list of VMware datastores and their used/free capacity. With how tables are set up now, I'd have to manually enter a row for each datastore, and manually update that as we add/remove/modify them.

I found this because I just tried for the first time to add a table and was floored that I must define every row by hand.  In this case, I have to work around the lack of "bottom N" in graphs so I can watch for devices that have rebooted recently in one place.  I want to put in this table all devices in a group, which seems like a no-brainer from a functionality standpoint.  Having to manually define those and maintain forever is a non-starter.  Can we please get the rows to be enterable as device groups and/or globs, as in other places?

Thanks,
Mark

This is something we're spec'ing out currently. It's likely we'll have to limit the dynamic table to a single datasource to ensure columns have the same number of instances, but it sounds like that will be sufficient for the examples provided?

Hi Ali -- thanks for responding!  That sounds like it would make sense, but I can imagine some counterexamples.  For example, datasources that are similar but not identical (different types of snmp_If* DSes spring to mind).  I recommend allowing multiple DSes, but require the same datapoints.  If the DP does not exist, then show a NaN.  The next step would be to have a DP-mapping capability, but that seems overly complex.

If we had it as described, I would definitely be happier than without it, of course!

Thanks,
Mark

@Ali Holmes that is a good start, although I was told the same thing last November by my account manager. It's been almost a year and no progress has been made and this is still being spec'd out?

I also kinda agree with @mnagel - there shouldn't be a problem just NaN'ing the "bad" cell in the table. Doing one is a good start, but let's not be content with just that.

For what it's worth, you can kind of "ghetto" this up already with a line chart. The data and logic is already baked in, just displayed as a point on a graph over time, instead of the most recent datapoint.

Hi @ErnieC, our Product team went through a reorg in May that resulted in a significant shift in priorities. I can assure you that this is in development and slated for v99 (phase 1) if all goes smoothly. 

Fantastic, thank you for the update!

Glad to see this was released in v99. We will be playing with it over the next few weeks. Thanks!

So close....  Why are we still pinned to 'TopN' for selectors?  Can we please also have 'BottomN'? I know this can't be difficult from a programming perspective and it is really needed.

Thanks,
Mark