Underscore is allowed in NQN and gw name which might cause issues with OMAP keys

[gbregman]

The NQN string contains a user part after the ":". While the part up to the ":" has rigid rules and we make sure the NQN conforms, there are no restrictions on the user part, as long as the length of the NQN is under the limit. This means we can create a subsystem which has "_" in its NQN. When we create OMAP keys we use "_" as the delimiter between the different parts. For example, a host key looks like:

host_<subsys-nqn>_<host-nqn>

if the subsystem NQN contains a "_" when we'll try to parse the host key we would get a partial subsystem NQN as we'll stop at the first "_".

We have a few options:

• Not allowing a "_" in NQNs
• Replace the "_" delimiter with a character not allowed anywhere in the NQN. Namely a non UTF-8 character.
• Change the way we construct the OMAP key. We have several options to do that like escaping "_", introducing a length prefix for each component of the key and more

The first option is the simplest. In principle it might create issues with existing OMAP files which already contain an NQN with a "_" but I doubt this is real issue. The second options will break compatibility with existing OMAP file and we need to make sure the non UTF-8 character is handled properly on all levels. The third option will certainly break compatibility with existing OMAP files.

A similar issue we have with gateway names.

[gbregman]

@oritwas Do you have any suggestions?

[oritwas]

We can always encode the NQN (using string encode in python) before we write to the OMAP and decode it when reading

[oritwas]

Another option is to disallow underscore in the NQN