Re: [libvirt] [PATCH 7/7] storage: Check for duplicate host for incoming pool def

On 04/30/2015 05:59 AM, Ján Tomko wrote: So you feel it's OK or better to document and restrict something that could essentially work given some code? IOW: For this one pool type it is better to restrict based solely on the IQN - that's a preferable solution? Because it's not worth doing that much work just to work around misconfigured systems or a perception of misconfiguration? Because we have already supported it and technically it can work if you've done your configuration correctly and (more or less) know what you're doing. IMO, using address name resolution while not a "perfect solution" is better than deciding to disallow something that someone may have a reason to configure in such a manner. If the name resolution causes an issue due to unreliable DNS or some other DNS factor beyond the scope of libvirt, then the host configuration has far greater issues. I could just as easily claim I doubt someone would have such an unreliable DNS configuration, but I'm sure I'd be wrong too! Still having an unreliable DNS is allowed. getaddrinfo for output. And the session matching code uses a two level loop (usr/iscsi_util.c - iscsi_addr_match()) which compares a stored address against the incoming/proposed session address (uses ai_addrlen and ai_addr comparisons) after the getaddrinfo. So essentially not much different than what I proposed. The open-iscsi code though is claiming the two are the same, so it won't create a new session which is why we get into the situation we get into. There is a saying "Imitation is the sincerest form of flattery"... I wonder how many people just cut-n-paste what's in the docs to get things to work? In this case, it may be considered babysitting those that aren't as proficient, but it may also help in the case where someone doesn't realize their mistake. While we may find the practice of copying a configuration that works less than desirable, it can happen. While we don't think someone would configure one pool using the IP Address and another pool using a name, it can happen. I think restricting on the same IQN takes a big hammer approach, but if that's what is desired because it's felt that it's either too much code to add or because DNS is misconfigured, misbehaving, or not reliable enough, then while I technically disagree, I suppose since we can make up the rules to play by. BTW: Beyond this bz (1171984), there is an iSCSI ipv4 vs. ipv6 host name configuration issue described in bz1188463 and bz1207929 which describes a usage with gluster volume lookups where a failure is declared seemingly because the pool is defined with the IP address while the vol-name lookup was done using a name. The changes in v2 could easily be "reused" in order to ascertain that the name and number match. Beyond that it'd be up the gluster code to do it's own resolution in order to find the target. John