W dniu 30.03.2012 02:00, Michael Hudson-Doyle pisze: > On Thu, 29 Mar 2012 10:49:21 +0200, Zygmunt Krynicki > <[email protected]> wrote: >> W dniu 29.03.2012 06:36, Michael Hudson-Doyle pisze: >>> On Tue, 27 Mar 2012 23:10:37 +0200, Zygmunt Krynicki >>> <[email protected]> wrote: >>>> Hi. >>>> >>>> Another specification for the backlog and your feedback. Please read >>>> this as I'd like to move towards planning dependency blueprints (even if >>>> they also end up in a backlog). >>>> >>>> https://blueprints.launchpad.net/linaro-python-dashboard-bundle/+spec/pluggable-bundle-format >>> >>> Hi, >>> >>> Can you motivate this one a bit? It seems sort of vaguely reasonable >>> (although I feel the creeping horrors of SGML and DTDs and things on the >>> horizon), but I would like to know the problem you are solving here. >> >> I actually wanted to avoid SGML that feels to be slowly creeping in. The >> motivation is to allow the core format to remain small and lean and to >> allow users to experiment with custom data sets. For example, if I want >> to include accurate kernel data it could go into a linux-specific >> section. If I want to include apt/dpkg data it could go into a >> dpkg-specific section. Likewise if I want to include some trace / >> profiler data specific to my application I could create my own >> representation and store the data there. >> >> This goes hand in hand with plugs support in lava-test. I'd like to be >> able to say, run that test and capture this side band data with plugs A, >> B and C. Some ideas are: sampling CPU, memory, network and IO load, >> capturing GPU performance data, power measurement data. Capturing >> package data for non-apt systems. > > I like the idea in general, although I can't convince myself it's a > priority.
It's not, it's pretty low now. I just need an excuse to release a new format with this big empty "plugs" dictionary that does not have additionalProperties: false. > I'm also not sure how some details will work in practice, like how would > the data associated with a plug be stored in postgres? Also > experimentation sort of implies versioning, would you have a version for > a plug, or would the diplay of older data sometimes break when you > install a new version of a plug? So you are right and the only solution is, we don't. We'll keep the raw data as it was provided. Specialized extensions can track any deserialized / denormalized / normalized models of that data. As for versions, we keep our current policy, every third party extension can do whatever the author desires, including shooting themselves in the foot if they want. We'll give people a sandbox to play in, I hope. ZK PS: CC-ing the list again -- Zygmunt Krynicki Linaro Validation Team _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
