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 this idea. The path is a critical piece of information. End users will care a lot about the path because it is where their images are located. This information is also useful for calling connectStorageServer() and disconnectStorageServer().
Signed-off-by: Adam Litke agl@us.ibm.com
diff --git a/vdsm/storage/fileSD.py b/vdsm/storage/fileSD.py index 35f7ab3..01fabd1 100644 --- a/vdsm/storage/fileSD.py +++ b/vdsm/storage/fileSD.py @@ -24,7 +24,6 @@ import logging import glob
import sd -import fileUtils import storage_exception as se import fileVolume import image @@ -38,7 +37,9 @@ import time REMOTE_PATH = "REMOTE_PATH"
FILE_SD_MD_FIELDS = sd.SD_MD_FIELDS.copy() -# TBD: Do we really need this key? +# Do we really need this key? +# Answer: Yes. The path is an important part of the SD metadata and is useful +# information for end-users. It can also be used to manage storage connections. FILE_SD_MD_FIELDS[REMOTE_PATH] = (str, str)
def getDomUuidFromMetafilePath(metafile): @@ -232,12 +233,7 @@ class FileStorageDomain(sd.StorageDomain): # First call parent getInfo() - it fills in all the common details info = sd.StorageDomain.getInfo(self) # Now add fileSD specific data - info['remotePath'] = '' - mounts = fileUtils.getMounts() - for mount in mounts: - if self.mountpoint == mount[1]: - info['remotePath'] = mount[0] - break + info['remotePath'] = self.getMetaParam(REMOTE_PATH)
return info
----- 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.
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?
----- 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
On Sat, Sep 24, 2011 at 02:25:20PM -0400, Ayal Baron wrote:
----- 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.
In other words: remotePath is broken for localfs, so I'm keen to see a fix. But I'd prefer a fix that does not rely on an ill-fated metadata entry, and genertes the proper path on-the fly.
Dan.
vdsm-devel@lists.fedorahosted.org