On 21/03/17 19:30, LEIBOVICI Thomas wrote:
Hi Gerals,
Finally I find a little time to reply you.
On 02/17/17 08:14, Gerald Hofer wrote:
Hi,
I am testing a configuration that should sort files into different
archive ids based on location and I want to use a different
parameters for the copytool based on file size. But I think I ran
into a bug in that configuration.
My understanding is that the parameters should be done based on the
following order:
1) As default parameters for a policy
2) In policy triggers
3) In policy rules
4) In fileclass definitions
Indeed, this is the expected behavior.
So these are the different levels in my example:
1) The parameters sections has a default and defines the command:
2) No action params in the trigger
3) The rules section has currently no parameters either ( I had the
archive ids on that level earlier)
4) The file class definitions have now the different parameters:
Your configuration about "action_params" looks good.
The observation is that FileClass definitions small_files, std_files
and big_files does not seem to set the {data} parameter.
This particular configurations does test that the {data} parameter in
principal gets set in a FileClass. If I write a file into
/gdatat1/siteB the file gets migrated to archive_id 2 and data "t1".
So both parameters are overwritten from the default archive_id 1 and
"t2".
OK
But if I am writing a small file into /gdatat1/siteAB the {data}
parameter does not get overwritten from the default by the
small_files FileClass.
Got it.
Actions params are inherited from the "target_fileclass" matched by
the policy rule.
As your policy is:
rule archive_siteAB {
target_fileclass = siteAB;
...
}
The matched fileclass in your case is siteAB :
FileClass siteAB {
definition { tree == "/gdatat1/siteAB" }
lhsm_archive_action_params { archive_id = 3; }
}
You did not define {data} for that fileclass. So it is normal it is
not overwritten.
The point is that I want to get it overwritten by the fileclass that
depends on the size of the file. It does not make any difference if I
overwrite it in the the rules where I match it or in the fileclass
further up in the fileclass - as far as I can see if it is only based
on the matching fileclass to overwrite it, it does not make any real
difference if you can overwrite it in the fileclass - I can always
write it into the rule. I want to overwrite it in the (not matched in
the rules, but still applicable matching based on size):
So I have tow variables:
archive_id
data
and I want to match it based on file size and directory:
Directory
file size
archive_id
data
/gdatat1/siteA
small
1
t1
/gdatat1/siteB
small
2
t1
/gdatat1/siteAB
small
3
t1
/gdatat1/siteA
large
1
t2
/gdatat1/siteB
large
2
t2
/gdatat1/siteAB
large
3
t2
The problem I found is that any file classes that are not matched by the
rules are not overwriting the data variable. I don't want to overwrite
the data variable in the fileclass that is based on directory - as you
can see the data variable should not be the same.
I could built one fileclass per each of these lines, but the idea is to
define more directories and sort different projects into different
archive ids. I don't necessarily want to define two file classes for
each directory I am adding. And the reporting seems to indicate that the
file classes can be independent.
Thanks,
Gerald
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
robinhood-support mailing list
robinhood-support@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/robinhood-support
