Markus Armbruster <arm...@redhat.com> writes: > Conscious design decision: Backend (BB) and node (BDS) names share a > common name space. > > Enables a convenience feature: when a command needs a node, we accept > either kind of name, and a backend name is resolved to its root node. > > Should not be confused with a command that can work either on a backend > or on a node. There, a backend name resolves to the backend, not its > root node. Can't point to an example offhand. > > Let's concentrate on the "command needs a node" case. > > As we saw in my review of monitor commands, we have two different > conventions there. > > * Single name > > Within BlockdevOptions objects (used by blockdev-add), we use a single > string member, with a name that explains its role. Actually, the > member is an anonymous union of string and BlockdevOptions. > > Example: a BlockdevOptionsGenericFormat object (used for format "raw" > and others) has a member @file that may name a backend or a node. > > Example: a BlockdevOptionsQcow2 object (used for "qcow2"), has a > member @file as above, and a member @backing that may again name a > backend or a node. > > * Pair of names > > Elsewhere, command argument objects have a pair of optional members, > of which exactly one must be present. One of them must name a > backend, the other must name a node. The former is commonly called > @device, the latter @node-name. > > Example: block_passwd parameters @device and @node-name. > > I'd very much like some consistency here. > > As Kevin pointed out, you can't easily change BlockdevOptions to the > "pair of names" convention, because an anonymous union can have only one > object member, and that's taken by BlockdevOptions. If you want us to > adopt the "pair of names" convention, you need to come up with a way to > use it with BlockdevOptions. > > I want us to adopt the "single name" convention instead. Therefore, I > need to come up with a way to use it with the command argument objects > that currently use "pair of names". The problems there are > compatibility and discoverability. [Text on how to solve them snipped...]
John Snow pointed out to me that we still haven't spelled out how this single parameter should be named. On obvious option is calling it node-name, or FOO-node-name when we have several. However, we'd then have two subtly different kinds of parameters called like that: the old ones accept *only* node names, the new ones also accept backend names, which automatically resolve to the backend's root node. Three ways to cope with that: * Find a better name. * Make the old ones accept backend names, too. Only a few, not that much work. However, there are exceptions: - blockdev-add's node-name *defines* the node name. - query-named-block-nodes's node-name *is* the node's name. * Stop worrying and embrace the inconsistency. The affected commands are headed for deprecation anyway. I think I'd go with "node" or "FOO-node" for parameters that reference nodes and accept both node names and backend names, and refrain from touching the existing node-name parameters. Opinions?
