[LU-7004] fix "lctl set_param -P" to allow deprecation of "lctl conf_param"

• Type: Improvement
• Resolution: Fixed
• Priority: Critical
• Fix Version/s: Lustre 2.13.0
• Affects Version/s: Lustre 2.9.0
• Labels: llnl patch
• Assignee: James A Simmons
• Reporter: Andreas Dilger

Description

The lctl set_param -P functionality was landed via LU-3155 for 2.5.0 and deprecates lctl conf_param usage. There is a deprecation message printed in jt_lcfg_mgsparam() since 2.7.53 that conf_param is obsolete and set_param should be used instead.

The test scripts need to be changed over to use "lctl set_param -P" exclusively, both to quiet the deprecation warning, as well as verify that the "lctl set_param -P" functionality is working correctly.

For now, I'm going to bump the deprecation warning to 2.8.53 to give us time to make this change in the 2.9 release cycle since there isn't enough time to do it for 2.8.0 anymore.

Issue Links

• is related to: LU-10937 Use sysfs to fix up sptlrpc handling.
• is related to: LU-8482 auster run of sanity trying to use deprecated lctl conf_param in 2.8
• is related to: LU-9431 class_process_proc_param can't handle sysfs
• is related to: LU-7031 lctl set_param -P behaves differently than lctl conf_param
• is related to: LU-9399 lctl conf_param and lctl set_param -P are broken for llite parameters
• is related to: LU-10626 utils/tests: lctl set_param -P does not appear to do anything
• is related to: LU-10756 Send Uevents for interesting Lustre changes
• is related to: LU-8414 DNE: Setting of remote_dir_gid parameter not persistent
• is related to: LU-3155 Permanent parameters with lctl set_param -P

Comments

[Peter Jones]

James

Do I recall correctly - this is the only fix needed but it should be queued up for 2.12.1 in addition to being in 2.13?

Peter

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/32784/
Subject: LU-7004 mgs: remove using obdname2fsname() from mgs layer.
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 5da91cd4e44f8113b00035324738a9bb67f8a597

[James A Simmons]

Can patch https://review.whamcloud.com/#/c/32784 be reviewed so it can land for 2.12. It was discovered that obdname2fsname() doesn't cover all the cases so this patch removes the use of obdname2fsname() on the MSG server when dealing with config logs. Currently it can break in some corner cases. After this patch then obdname2fsname() will only be used with sptlrpc like before. That can be addressed in the follow on LU-10937 patch for 2.13.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/30087/
Subject: LU-7004 tests: move from lctl conf_param to lctl set_param -P
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: b9c359a70db9d5a6b69cc222c5f3b306a23df8b1

[James A Simmons]

So I see one regression with lctl set_param -P.  Some test use the form get the parameter valu:

lctl set_param osc.lustre-OST0001-osc-[^M]*.active=1

The shell seems to expand this properly or the get_param routine parses this correctly.

Now if I run on the MGS lctl set_param "P" osc.lustre-OST0001-osc[^M]*.active=1 then the [^M] is actually cached in the config logs. The function obdname2fsname() chokes on this wildcard. So the question is how to handle this. I see the following:

1) Make the shell expand the [^M] to some value before passing the string to lctl itself. I don't know how to       do that

2) Use regex or something in the C code of lctl to expand this out before packing the data for the ioctl on           the MGS.

3) Change the test scripts to drop the [^M] for lctl set_param -P.

Which is the best option?

[Gerrit Updater]

James Simmons ([e-mail]) uploaded a new patch: https://review.whamcloud.com/32784
Subject: LU-7004 obd: handle fsname-MDT0000-**MDT0000 for obdname2fsname
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 29b45b5dd7c87dbf4b6168ca07d8bbd0acbafe84

[James A Simmons]

looks like this work is coming to completion

[James A Simmons]

So the good news is that I found lctl conf_param lustre-OST*.failover.node=10.0.0.1@tcp can be done with set_param P with already existing code. The command to do it is lctl set_param -P osc.lustre-OST*.import=connection=10.0.0.1@tcp. So its just a matter of updating the test in this case. Only sptlrpc is not functional.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/31081/
Subject: LU-7004 quota: make lctl set_param -P functional for quota
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 6d9df3b2c0d54b16d00b6e419c7bb958e6b54844

[Gerrit Updater]

John L. Hammond ([e-mail]) merged in patch https://review.whamcloud.com/31207/
Subject: LU-7004 obd: make LCFG_SET_PARAM functional
Project: fs/lustre-release
Branch: b2_10
Current Patch Set:
Commit: d7f9f2130c5d8c74004f36aa68938df57778a6b1

[Gerrit Updater]

Minh Diep ([e-mail]) uploaded a new patch: https://review.whamcloud.com/31207
Subject: LU-7004 obd: make LCFG_SET_PARAM functional
Project: fs/lustre-release
Branch: b2_10
Current Patch Set: 1
Commit: 14d209c516d710585d4c492bfdfa6d2eb1add25d