Michael MacDonald

> @daos-stack/daos-gatekeeper could you tell me if something is missing for landing this PR ? 1) There is still a -1 review by @phender. He needs to remove that if...

@Nasf-Fan: Unfortunately, there is a conflict with the branch that needs to be resolved. I merged master yesterday.

> yes, I'm waiting on feedback from @mjmac with regard to approval of the CLI changes before I continue with the ftest changes related to this PR, I will move...

Stepping back a bit, I agree with the general goal here, which is to improve the command surface. Currently, we have the following: ``` [prepare command options] --pci-allow-list= Whitespace separated...

I'm not disagreeing that the changes here are an improvement; I'm just saying that if we're going to invest the engineering time in making a change (including updating all of...

While we're at it, we could probably also deprecate the unified `storage scan` interface in favor of storage-specific interrogation subcommands, e.g. * daos_server scm scan [--socket N] [--namespaces-only] [--modules-only] *...

> Having said that, it doesn't look like dmg has this separation. e.g., we can't format or scan a specific device type. If we separate in daos_server, but not in...

> Oversimplifying the nvme commands by removing allow and block lists will reduce configuration flexibility and create an impedance between what we offer and what the SPDK subsystem configuration provides....

Perhaps we should rename `scm` to `pmem` in the user-visible command surface? We reference both, but I think it might be clearer to new users if we pick one or...

> Confirmed, we should **not** change "scm" to "pmem". Let's keep the "scm" nomenclature that has been used so far (and which is agnostic to any specific hardware implementation of...