{"comment":{"created_at":"2011-10-20T17:27:39Z","body":"Tests pass, need to update Web side of app to work still. (Not diving into Web-level testing at this point.)","updated_at":"2011-10-20T17:27:39Z","url":"https://api.github.com/repos/bitprophet/fullerene/issues/comments/2471619","id":2471619,"user":{"avatar_url":"https://secure.gravatar.com/avatar/f1acc6318028fdba9874c77bc622a2fb?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"f1acc6318028fdba9874c77bc622a2fb","url":"https://api.github.com/users/bitprophet","id":6088,"login":"bitprophet"}},"action":"created","issue":{"number":2,"created_at":"2011-10-17T22:25:21Z","pull_request":{"diff_url":null,"patch_url":null,"html_url":null},"body":"Use case is to have \"section headers\" on the larger groupings such as `baseline`, but would also be useful for other things.\r\n\r\nPossible implementation: aliasing, i.e. define `baseline` as `disk` + `cpu` + `...`.\r\n\r\nExpanding this idea, having both metrics and collections of metrics as objects/dicts would make this easier -- we could then optionally allow folks to give them labels/names, and then refer to those elsewhere, i.e. having the same metric path show up in multiple groups/dashboards/whatever. Something like:\r\n\r\n    metrics:\r\n        group1:\r\n            - foo.bar\r\n            - biz.baz:\r\n                name: bizbaz\r\n        group2:\r\n            - bizbaz\r\n\r\nThough that feels slightly backwards in a few ways -- having the metric's key be the actual path is possibly OK, as it's a pattern we're using in exclusions (#7) but defining it inside a group and referring to it in another group is definitely wonky. \r\n\r\nThe other obvious approach is to define metrics in one section and groups/group memberships in another -- but then that implies that perhaps *all* metrics need to be defined in this way, so that for the simple use case of \"this one metric is only used in one spot and has no metadata\" you're now dealing with some boilerplatey crap.\r\n\r\nEDIT: Actually, no -- we can do what is done for the timeperiod/from-kwarg override behavior, and simply prefilter metric paths to see if they match a defined metric name/identifier, then substitute. So metrics with metadata can be optionally defined in one config section containing only those handful of metrics that need customization; the big list o' metrics would then be a mix of one-off real paths and names referencing the metadata'd metrics. E.g.:\r\n\r\n    metrics:\r\n        metric1:\r\n            path: foo.bar.*\r\n            excludes: [biz, baz]\r\n    groups:\r\n        group1:\r\n            - actual.metric.path\r\n            - another.real.metric\r\n            - metric1\r\n            - blah.*\r\n        group2:\r\n            - metric1\r\n\r\nAnother note: one can accomplish referencing itself (i.e. define once, \"insert\" into multiple locations) in YAML natively with YAML references (or whatever they're called, the `&stuff`) but it may be worthwhile to implement this at the Python level instead so that we can make better use of the metadata.","comments":1,"title":"Possibly add subgroups/nested groups of metrics","updated_at":"2011-10-20T17:27:39Z","url":"https://api.github.com/repos/bitprophet/fullerene/issues/2","id":1934245,"assignee":null,"milestone":null,"closed_at":null,"user":{"avatar_url":"https://secure.gravatar.com/avatar/f1acc6318028fdba9874c77bc622a2fb?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"f1acc6318028fdba9874c77bc622a2fb","url":"https://api.github.com/users/bitprophet","id":6088,"login":"bitprophet"},"html_url":"https://github.com/bitprophet/fullerene/issues/2","labels":[],"state":"open"},"legacy":{"issue_id":1934245,"comment_id":2471619}}