----- Original Message -----
On Fri, Sep 23, 2011 at 06:24:13PM -0400, Ayal Baron wrote:
----- Original Message -----
The current method for gathering a LOCALFS Storage Domain's remotePath property does not work because these domains are connected with a symlink, not a mount. Since this info is already stored in the metadata, just get it from there.
In the code I have noticed some sentiments that path information should be removed from the storage domain metadata. I strongly disagree with
The reason we want to remove the path info from the domain is that in order to reach the domain you have to already know the path info which makes it kind of pointless. This is not to say that we should not be able to report the path or that we should not store it somewhere else.
When you say "in order to reach the domain" are you referring to the vdsm API user or from vdsm internally? As an API user, All I need to reach the domain is a connection to vdsm. I can then do conn.getStorageDomainsList() and then query each uuid returned for details. Since it is already returning all of the other metadata, why not just return the path too?
On the contrary, as I said above, we should be able to report the path, that's fine. It's just silly to persistently store the path inside the domain itself, and that is what the comments you read meant. Getting domain info *should* return the path. But the path for vdsm is either runtime info (kept in memory once user issued a connectStorageServer command) or it's stored locally on the machine somewhere (in a single node scenario it makes perfect sense to persistently keep this info locally, in a cluster, it should be cached.
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel