[Lustre-discuss] Metadata storage in test script files

Roman Grigoryev Roman_Grigoryev at xyratex.com
Wed May 2 10:05:40 PDT 2012

Hi Chris,

On 05/02/2012 08:06 PM, Chris wrote:
> On 02/05/2012 16:44, Roman wrote:
>>> I think this is something that needs to live outside the test metadata
>>> being described here.  The definition of "golden configuration" is
>>> hard to define, and depends heavily on factors that change from one
>>> environment to the next.
>> We could separate dynamic and static metadata. But it will be good if
>> both set of data use one engine and storage type with just different
>> sources.
> I think we all understand the static metadata and I believe that the
> data in my original examples is static data. This data relates to a
> version of the test scripts and so can live as part of the test script
> managed using the same git mechanisms.
> Could you explain what you mean by dynamic data so that we can all
> understand exactly what you are suggesting we store.

As true dynamic data I can imagine only tickets now. And I'm not sure
how it important to keep in test sources, it think umbrella for old
bugzilla, WC jira and maybe other bug sources is more important.

But I can imagine situation when we want to update meta data in many
tests. F.e. somebody done by test coverage and want to add it to meta

>> Also, I don't see good way to use 'metadata inheritance' way in shell
>> without adding pretty unclear shell code, so switch to metadata usage
>> should be one-monent or test framework just ignore it and metadata
>> became just static text for external scripts. 
> I'm not sure if there is a place for inheritance in this particular
> situation but if there is then we need to be clear of one thing. There
> can be no implicit   for these scripts. I.e. We can't have a
> single attribute at the top of a file that applies to all tests. The
> reason for this is because one major reason for having metadata is that
> we cause the data to be collected properly, each test needs to have the
> data explicitly captured. If a test does not have the data captured then
> we do not have any data - and no data is a fact (data) in itself, If a
> test inherits data from another test then that must have be explicitly set.
> We cannot allow sweeping inheritance that allows us to imagine we have
> learnt something when actually we've just taken a short cut to give the
> impression of knowledge.

Yes, I mean inheritance from "single attribute at the top of a file"
(with overriding if defined in detailed level). Why we can't have single
attribute at the top which is default values? Going over all tests
manually is very big task.

Back to your original definition, f.e. all tests from lustre-rsync
should be on one component (maybe, as I understand), there is no big
reasons to duplicate componetns.


More information about the lustre-discuss mailing list