<font size=2 face="sans-serif">What I always recommend is to make a directory
of test cases and run</font><br><br><font size=2 face="sans-serif">mmapplypolicy /gpfs-path/test-cases
-I test (or -I yes if you want to try operating on the test files) -L 2
(or -L 6 or something in between) -P policy-rules [other-options]</font><br><br><font size=2 face="sans-serif">Because as I think you're saying</font><br><br><font size=2 face="sans-serif">mmapplypolicy gpfs-fsname -I test ...
</font><br><br><font size=2 face="sans-serif">Can consume a lot of compute and IO
resource, just scanning the metadata.</font><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Jez Tucker <jtucker@pixitmedia.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/27/2016 12:22 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Dry-Run functionality ?</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=3>Hi Marc,<br><br> Quite. We have had coverage of (1) and (2) in
the API for some time.<br><br>My overriding thought is that (QoS aside) if one executes an mmapplypolicy,
for whatever reason, then a certain amount of resource is consumed.<br>This may not be preferred.<br><br>So let me rephrase to the users: in your real-world working
environment, would you prefer:<br><br>a) Return what would be called. E.G. mmapplypolicy -P mypol.pol --flag1
--flag2 --etc which is a sanity check, but not a policy run, hence
no load<br>b) mmapplypolicy /gpfs-path -P policy-rules-file -I test -L
2 [other options]` will do a dry run and show what actions
would be performed on each file.<br><br>To be clear; you can currently achieve either launch with the API as it
stands.<br>However we'd like to know what the general concensus would prefer to be
the norm in such an implementation.<br><br>Regarding dry run functionality this can be achieved globally as follows:<br><br>setDryRun(True)<br><API commands to delete filesets><br><API commands to delete snapshots><br><API commands to migrate data><br><br>or as a more granular decorator:<br><br>@dryrun<br>... def delete_filesets(): <br> <API commands to delete filesets><br><br>Jez<br><br></font><br><font size=3>On 20/06/16 16:03, Marc A Kaplan wrote:</font><br><font size=2 face="sans-serif"><b>Jez,</b></font><font size=3><br></font><font size=2 face="sans-serif"><br> Regarding your recent post. Do the mmchpolicy and mmapplypolicy
commands have sufficient functionality for your purposes? <br>Are you suggesting some improvements? If so, what? Please provide
examples and/or specific suggestions.</font><font size=3><br></font><font size=2 face="sans-serif"><br>WRT your numbered items:</font><font size=3><br></font><font size=2 face="sans-serif"><br>(1) `mmchpolicy fsname -I policy-rules-file test`
does a complete syntax check on policy-rules-file and some other sanity
checking.</font><font size=3><br></font><font size=2 face="sans-serif"><br>(2) `mmapplypolicy /gpfs-path/empty-directory -P policy-rules-file -I test
-L 0` is another way to validate policy-rules-file. Rules like MIGRATE
and LIST that are interpreted by mmapplypolicy will be scrutinized.
For example check that each named pool is defined either within the file
system or by an EXTERNAL POOL rules.</font><font size=3><br></font><font size=2 face="sans-serif"><br>(3) `mmapplypolicy /gpfs-path -P policy-rules-file -I test -L 2
[other options]` will do a dry run and show what actions would
be performed on each file.</font><font size=3><br><br></font><font size=2 face="sans-serif"><br>--marc</font><font size=3><br></font><font size=2 face="sans-serif"><br>-----------</font><font size=3><br></font><font size=3 face="Times New Roman"><br>API calls for Policies have the ability to run in 'test' or 'run' mode.
(ref: man mmapplypolicy)<br><br>How would you expect to use dry-run functionality on a policy?<br>We have our own opinion, but we'd like to hear yours.<br><br>1) Validate the policy and print the policy content to stdout/other. No
mmapplypolicy is performed.<br>2) Validate the policy and enforce mmapplypolicy with -I test<br>3) Return what would be called. E.G. mmapplypolicy -P mypol.pol --flag1
--flag2 --etc<br>4) Other<br><br>Best regards,<br><br>Jez<br>-- </font><font size=3 face="Arial"><br>Jez Tucker<br>Head of Research & Development</font><font size=3><br><br><br></font><br><tt><font size=3>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=3><br></font></tt><br><font size=3><br></font><br><font size=3>-- </font><br><font size=3 face="Arial">Jez Tucker<br>Head of Research & Development</font><font size=3 color=red face="Arial"><br>Pixit Media</font><font size=3 color=blue face="Arial"><u><br></u></font><a href=http://www.pixitmedia.com/><font size=3 color=blue face="Arial"><u>www.pixitmedia.com</u></font></a><br><br><br><font size=3>This email is confidential in that it is intended for
the exclusive attention of the addressee(s) indicated. If you are not the
intended recipient, this email should not be read or disclosed to any other
person. Please notify the sender immediately and delete this email from
your computer system. Any opinions expressed are not necessarily those
of the company from which this email was sent and, whilst to the best of
our knowledge no viruses or defects exist, no responsibility can be accepted
for any loss or damage arising from its receipt or subsequent use of this
email.</font><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><BR>