[LU-18502] YAML import and export for nodemaps

• Type: New Feature
• Resolution: Unresolved
• Priority: Minor
• Labels: nodemap
• Assignee: WC Triage
• Reporter: Marc Vef

Description

A general import and export for nodemaps and their properties would be beneficial, e.g., for backup, parsing, restore, etc. For exporting nodemap YAML definitions, the existing lctl nodemap_info can be extended. For importing nodemap YAML definitions, a new command, e.g., lctl nodemap_import, can be added. In addition, the API should allow enough flexibility to restrict the export/import to specific nodemaps and their properties so that users are not required to manually modify the YAML definition, e.g., to remove unwanted nodemaps or properties before importing.

The following API definition is possible:

1. (extended) lctl nodemap_info [--name <nodemap_name>] [--list] [–-yaml] [–-property <value>]
    - Adds the new --yaml argument which extends the existing lctl nodemap_info command to support YAML-formatted output.
    - All arguments are optional so that lctl nodemap_info. For example, only using --yaml would output all nodemaps in YAML format.
    - Using additional arguments to specify a nodemap and/or property restricts the output.
    - --property may be used multiple times to allow several properties to be exported.
 

2. (new) lctl nodemap_import [--name <nodemap_name>] [-–property <value>] ./nodemap.yaml
    - Imports a YAML file generated by lctl nodemap_info. 
    - The command can be used to import multiple nodemaps and properties at once, depending on the input file.
    - lctl nodemap_import further allows restricting the import to specific nodemaps and/or properties. This is useful when the imported YAML file includes more information than needed. --property may be used multiple times to allow several properties to be imported.

Sample YAML definition:

nodemap.c0.admin_nodemap: 0
nodemap.c0.audit_mode: 1
nodemap.c0.deny_unknown: 0
nodemap.c0.exports: [
 { nid: 192.155.155.50@tcp, uuid: bb3e4906-d094-4afb-a8bb-8ff66a6bb518 }
]
nodemap.c0.fileset: /remote
nodemap.c0.forbid_encryption: 0
nodemap.c0.id: 2
nodemap.c0.idmap: [
 { idtype: uid, client_id: 1003, fs_id: 11000 },
 { idtype: gid, client_id: 1003, fs_id: 11000 }
]
nodemap.c0.map_mode: all
nodemap.c0.offset: {
 start_uid: 0,
 limit_uid: 0,
 start_gid: 0,
 limit_gid: 0,
 start_projid: 0,
 limit_projid: 0
}
nodemap.c0.ranges: [
 { id: 2, start_nid: 192.155.155.50@tcp, end_nid: 192.155.155.50@tcp }
]
nodemap.c0.rbac: file_perms,dne_ops,quota_ops,byfid_ops,chlg_ops,fscrypt_admin,server_upcall,ignore_root_prjquota,hsm_ops
nodemap.c0.readonly_mount: 0
nodemap.c0.sepol: 
nodemap.c0.squash_gid: 65534
nodemap.c0.squash_projid: 65534
nodemap.c0.squash_uid: 65534
nodemap.c0.trusted_nodemap: 0

 

Issue Links

• is related to: LU-18715 Improve lctl nodemap_info
• is related to: LU-18357 Support multiple filesets per nodemap

Comments

[Gerrit Updater]

"Marc Vef <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/58113
Subject: LU-18502 utils: Support YAML for get_param parameter names
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 56b84b0dd9380fa956602f669fe239a1c85361b7

[Marc Vef]

ok, great, then I'll make a patch for the -y option.

Well, for nodemaps to function, a mounted debugfs should not be necessary. Modifying nodemaps from the CLI is purely done through ioctl (so, no set_param). And this needs to be done by the root user anyways.

But, we need "lctl get_param nodemap" because it is currently the only way to read the current nodemap configuration. If I understood Andreas correctly, the nodemap config should be included in the sosreport as well. So if debugfs is not available, this could be an issue, especially for dynamic nodemaps, which are in-memory only and do not persist across restarts.

sebastien Is this correct, or have I missed anything?

[James A Simmons]

The lctl -y changes  would be a nice cleanup. So I bring this up since in the near future the nodemap handling  will be moved to debugfs. With this change the nodemap handling will no longer be available to non root users. That doesn't seem to be a problem for nodemap. The second thing is items in debugfs are considered optional. Meaning Lustre can still function if for some reason debugfs is not mounted. Is nodemap a critical item?

[Marc Vef]

simmonsja, looking more into this, it seems we do not need a "completely new" YAML definition for nodemaps, as I proposed in the description. I was not aware that lctl get_param -n should already be YAML-compliant. With a few fixes that are currently in-flight, like 57915 and 58085, we should be set on the value side for nodemaps.

What is still an issue is that the header (or key) from get_param is not YAML-compliant. I saw that you added the -y option for lctl get_param, and it could make sense to extend it such that the key and value are both valid YAML.

Currently, we have this, which is not valid YAML for two reasons: '=' should be ': ' and '[' needs to be on the first line:

$  lctl get_param -y nodemap.nm1.idmap
nodemap.nm1.idmap=
[
 { idtype: uid, client_id: 1003, fs_id: 11000 },
 { idtype: gid, client_id: 1003, fs_id: 11000 }
]

Therefore, I propose the following change such that:

$  lctl get_param -y nodemap.nm1.idmap
nodemap.nm1.idmap: [
 { idtype: uid, client_id: 1003, fs_id: 11000 },
 { idtype: gid, client_id: 1003, fs_id: 11000 }
]

This is probably doable with little effort on the utils side only. And, calling lctl get_param nodemap.. would give us a full YAML-compliant dump of the nodemap config. What do you think? Should/Can we extend "-y" like this, or should we include this only into lctl nodemap_info?

I'm not familiar with the Netlink API. It is a nice idea, but would it still be relevant after the change to "-y"?

[James A Simmons]

We should consider moving to the Netlink API then. Its very flexible with constant API changes. Plus you can do version to get earlier formats.