Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Yaniv Kaul yk...@redhat.com Sent: Sunday, May 13, 2012 2:04:59 PM On 05/13/2012 11:54 AM, Einav Cohen wrote: [top posting] GUI Mockup has been updated according to this thread: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Further comments are welcome. - POSIX, not Posix. - 'POSIX compliant FS', not 'PosixFS' - Mockups updated. - rest-api change is probably needed [Ori/Geert/Yair - FYI] - I'd be happy if we could validate whatever we pass to the mount command against command injection[1] . Ayal/Saggi: Do we have such validation on vdsm? I think we can start with that, we can always add validation to the engine core/UI later. Y. [1] https://www.owasp.org/index.php/Command_Injection Thanks, Einav - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Einav Cohen eco...@redhat.com Cc: Ayal Baron aba...@redhat.com , engine-devel@ovirt.org , Simon Grinberg sgrin...@redhat.com , Saggi Mizrahi smizr...@redhat.com , Geert Jansen gjan...@redhat.com , Ori Liel ol...@redhat.com , Miki Kenneth mkenn...@redhat.com , Andrew Cathrow acath...@redhat.com Sent: Sunday, May 13, 2012 10:05:23 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated On 05/11/2012 11:28 PM, Einav Cohen wrote: - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:03:04 PM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:39:42 AM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org , Simon Grinberg sgrin...@redhat.com , Saggi Mizrahi smizr...@redhat.com , Geert Jansen gjan...@redhat.com , Ori Liel ol...@redhat.com , Yair Zaslavsky yzasl...@redhat.com , Ayal Baron aba...@redhat.com , Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. +1 on path and this was my original implementation by the way. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the Path text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs' so maybe a Please use should be incorporated in this case as well, maybe also an example, etc. What do you think? I replied after viewing the other message and disliking it (personal opinion). I prefer a static explanation (what the field is) rather than an action request. So in the NFS example I would've phrased it as Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. But in any event it is better to have consistency (so both messages should probably be phrased similarly). There is no problem changing the phrasing for NFS. So for NFS, the caption will be: Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. And for PosixFS, the caption will be: Path to device to mount / remote export. (no 'takes the form' or example provided) Agreed? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
On 05/13/2012 02:04 PM, Yaniv Kaul wrote: On 05/13/2012 11:54 AM, Einav Cohen wrote: [top posting] GUI Mockup has been updated according to this thread: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Further comments are welcome. - POSIX, not Posix. - 'POSIX compliant FS', not 'PosixFS' - I'd be happy if we could validate whatever we pass to the mount command against command injection[1] . Y. [1] https://www.owasp.org/index.php/Command_Injection Thanks, Einav - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Einav Cohen eco...@redhat.com Cc: Ayal Baron aba...@redhat.com, engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Miki Kenneth mkenn...@redhat.com, Andrew Cathrow acath...@redhat.com Sent: Sunday, May 13, 2012 10:05:23 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated On 05/11/2012 11:28 PM, Einav Cohen wrote: - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:03:04 PM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:39:42 AM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. +1 on path and this was my original implementation by the way. Now that I think of it - maybe we can have Address as optional argument AND Path as mandatory at REST-API? Examples - address: 10.35.16.36 path: /export/share1 Will be translated to mountSpec of 10.35.16.36:/export/share1 path: /home/someuser/domain1 Will be translated to mounSpec of /home/some/user/domain1. Thoughts on this? - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the Path text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs' so maybe a Please use should be incorporated in this case as well, maybe also an example, etc. What do you think? I replied after viewing the other message and disliking it (personal opinion). I prefer a static explanation (what the field is) rather than an action request. So in the NFS example I would've phrased it as Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. But in any event it is better to have consistency (so both messages should probably be phrased similarly). There is no problem changing the phrasing for NFS. So for NFS, the caption will be: Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. And for PosixFS, the caption will be: Path to device to mount / remote export. (no 'takes the form' or example provided) Agreed? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... attachment: NewNfsStorageDomainDialog-PathExplanation.png___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:39:42 AM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the Path text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs' so maybe a Please use should be incorporated in this case as well, maybe also an example, etc. What do you think? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Friday, May 11, 2012 5:15:51 PM - Original Message - From: Geert Jansen gjan...@redhat.com To: Ayal Baron aba...@redhat.com Cc: Andrew Cathrow acath...@redhat.com, engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Miki Kenneth mkenn...@redhat.com, Einav Cohen eco...@redhat.com Sent: Friday, May 11, 2012 10:10:37 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated On 05/10/2012 09:46 PM, Ayal Baron wrote: device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Why? This makes some very interesting use cases a lot more difficult to set up. We should allow multiple hosts in a PosixFS data center, and it should be the user's responsibility that if he adds multiple hosts, that each of those see the same data. I *think* we're saying the same thing. If you have multiple hosts in a datacenter with PosixFS then it's your responsibility to make sure that they can all see the same storage +1. I believe that Ayal didn't mean that we should limit the number of Hosts in a PosixFS DC to 1; all he said is that in case the user has defined more than 1 Host in a PosixFS DC and the PosixFS storage domain in it happens to be a local one (i.e. local on one of the Hosts in the DC), all other Hosts will become Non Operational (simply because they won't be able to reach that storage domain). Correct. It was a disclaimer that we do not prevent user from doing stupid things. Regards, Geert ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:39:42 AM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the Path text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs' so maybe a Please use should be incorporated in this case as well, maybe also an example, etc. What do you think? I replied after viewing the other message and disliking it (personal opinion). I prefer a static explanation (what the field is) rather than an action request. So in the NFS example I would've phrased it as Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. But in any event it is better to have consistency (so both messages should probably be phrased similarly). - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:03:04 PM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Friday, May 11, 2012 11:39:42 AM - Original Message - - Original Message - From: Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:46:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' - Path it is. - Instead of a tool-tip, I suggest to use an explanation caption below the text-box (similar to what we have for NFS storage domain - see attached). Agreed? i.e. Path to device to mount / remote export or something? Yes, that's a good answer to the question afterwards :) But what do you think about the general idea of using an explanation caption below the Path text-box (instead of a tool-tip that was suggested here earlier)? Also, do you think that the above should be the exact phrasing? The NFS one is: Please use 'FQDN:/path' or 'IP:/path' Example 'server.example.com:/export/VMs' so maybe a Please use should be incorporated in this case as well, maybe also an example, etc. What do you think? I replied after viewing the other message and disliking it (personal opinion). I prefer a static explanation (what the field is) rather than an action request. So in the NFS example I would've phrased it as Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. But in any event it is better to have consistency (so both messages should probably be phrased similarly). There is no problem changing the phrasing for NFS. So for NFS, the caption will be: Remote path to NFS export, takes either the form: FQDN:/path or IP:/path, e.g. server.example.com:/export/VMs. And for PosixFS, the caption will be: Path to device to mount / remote export. (no 'takes the form' or example provided) Agreed? - What should be the exact phrasing of the explanation text? mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : In addition - if we only support V1, why add the combo box? Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 9:28:31 AM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. Miki - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 4:28:31 PM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 9:28:31 AM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
On 05/10/2012 04:46 PM, Miki Kenneth wrote: we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. Miki - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 4:28:31 PM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? This is important - it may yield a change to REST-API. Ayal? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
On 05/10/2012 05:16 PM, Andrew Cathrow wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Miki Kenneth mkenn...@redhat.com Cc: Einav Cohen eco...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:14:32 AM Subject: Re: PosixFS: GUI mock-ups have been updated On 05/10/2012 04:46 PM, Miki Kenneth wrote: we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. Miki - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 4:28:31 PM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? This is important - it may yield a change to REST-API. Ayal? The validation should be not empty, after than anything goes. Ori - this means we should model REST-API differently, and not as I thought (current REST-API implementation will not be able to pass mountSpec without : to backend). I will summon a meeting on Sunday to close that ASAP In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 5:16:24 PM - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Miki Kenneth mkenn...@redhat.com Cc: Einav Cohen eco...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 10:14:32 AM Subject: Re: PosixFS: GUI mock-ups have been updated On 05/10/2012 04:46 PM, Miki Kenneth wrote: we should had a mouseover tooltip for explaining what is PosixFS and mentioned that it is supported only in 3.1 cluster. Miki - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 4:28:31 PM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? This is important - it may yield a change to REST-API. Ayal? The validation should be not empty, after than anything goes. +1. Let's have only non-empty validation. We will re-visit later if necessary (not sure it will be). Haim: FYI. In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? - Note that the current PosixFS implementation in the rest-api utilizes the already-existing path property within the storage tag within the storage_domain rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good is the error reporting back going to be - if the mount options are wrong, or if something fails with the mount will we see error 12345 in the UI and require the user to go digging in vdsm logs or are we going to pull back and display toe complete message. Depends on backend/vdsm; Yair/Ayal? - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 9:28:31 AM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path - Note that the current PosixFS implementation in the rest-api utilizes the already-existing path property within the storage tag within the storage_domain rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good is the error reporting back going to be - if the mount options are wrong, or if something fails with the mount will we see error 12345 in the UI and require the user to go digging in vdsm logs or are we going to pull back and display toe complete message. Depends on backend/vdsm; Yair/Ayal? - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 9:28:31 AM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. From talking to Haim I understood that path should include : From talking to Ayal, the path can be similar in its format to a path provided when creating an NFS storage domain (e.g. server:/dir1/dir2), *or* to a path provided when creating a Local storage domain (e.g. /tmp/dir3), meaning, without :. @Ayal - any chance for a clarification here? In addition - if we only support V1, why add the combo box? We are always showing the combo-box, even if we have only one option in it (so the user will know what is the value that is being sent). However, we disable it. I updated the mock-up to clarify this. Thanks! Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:01:20 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 6:06:23 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path But it *can* be local or remote, so why Remote Path? Path actually sounds like a good term. Can it be local - do we want a user mounting a local filesystem? - Note that the current PosixFS implementation in the rest-api utilizes the already-existing path property within the storage tag within the storage_domain rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good is the error reporting back going to be - if the mount options are wrong, or if something fails with the mount will we see error 12345 in the UI and require the user to go digging in vdsm logs or are we going to pull back and display toe complete message. Depends on backend/vdsm; Yair/Ayal? - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i...@eldanet.com, Alexey Chub ac...@redhat.com, engine-devel@ovirt.org, Haim Ateya hat...@redhat.com Sent: Thursday, May 10, 2012 9:28:31 AM Subject: Re: PosixFS: GUI mock-ups have been updated - Original Message - From: Yair Zaslavsky yzasl...@redhat.com Sent: Thursday, May 10, 2012 4:21:42 PM On 05/10/2012 04:16 PM, Einav Cohen wrote: Please review the mock-ups on the feature page: http://www.ovirt.org/wiki
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:03:16 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:01:20 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 6:06:23 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path But it *can* be local or remote, so why Remote Path? Path actually sounds like a good term. Can it be local - do we want a user mounting a local filesystem? If it is possible - I don't see why limiting it. It should be similar to defining a Local on Host storage domain IIUC. Even if it is potentially harmful for some reason, we don't want to nanny the user, right? He should know what he is doing. - Note that the current PosixFS implementation in the rest-api utilizes the already-existing path property within the storage tag within the storage_domain rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good is the error reporting back going to be - if the mount options are wrong, or if something fails with the mount will we see error 12345 in the UI and require the user to go digging in vdsm logs or are we going to pull back and display toe complete message. Depends on backend/vdsm; Yair/Ayal? - Original Message - From: Einav Cohen eco...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, Andrew Cathrow acath...@redhat.com, Miki Kenneth mkenn...@redhat.com, Simon Grinberg sgrin...@redhat.com, Eldan Hildesheim ehild...@redhat.com, Eldan Hildesheim i
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:12:06 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:03:16 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:01:20 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 6:06:23 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path But it *can* be local or remote, so why Remote Path? Path actually sounds like a good term. Can it be local - do we want a user mounting a local filesystem? If it is possible - I don't see why limiting it. It should be similar to defining a Local on Host storage domain IIUC. Even if it is potentially harmful for some reason, we don't want to nanny the user, right? He should know what he is doing. I'm not saying we should stop them, we should make it clear how this is going to be used. When we're setting up a storage domain it's shared storage. - Note that the current PosixFS implementation in the rest-api utilizes the already-existing path property within the storage tag within the storage_domain rest-api business entity, therefore I put in the mockup the same term. Do you think that the rest-api should have a different term as well? I presume we are doing just not-null validation for path. Obviously we can't validate the mount options but how good
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:18:58 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:12:06 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:03:16 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:01:20 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 6:06:23 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path But it *can* be local or remote, so why Remote Path? Path actually sounds like a good term. Can it be local - do we want a user mounting a local filesystem? If it is possible - I don't see why limiting it. It should be similar to defining a Local on Host storage domain IIUC. Even if it is potentially harmful for some reason, we don't want to nanny the user, right? He should know what he is doing. I'm not saying we should stop them, we should make it clear how this is going to be used. When we're setting up a storage domain it's shared storage. I am probably missing something here, but I assume that Path isn't a good term (I apologize for not understanding why). In any case, we need to finalize this term, since it has implications on the rest-api as well. Andrew/Geert/Simon/Ayal/Miki
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 1:42:15 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:18:58 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:12:06 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 8:03:16 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Sent: Thursday, May 10, 2012 1:01:20 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 6:06:23 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 10:56:09 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Andrew Cathrow acath...@redhat.com Sent: Thursday, May 10, 2012 4:57:44 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Saggi Mizrahi smizr...@redhat.com, Yair Zaslavsky yzasl...@redhat.com Cc: Haim Ateya hat...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Simon Grinberg sgrin...@redhat.com Sent: Thursday, May 10, 2012 9:51:32 AM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated - Original Message - From: Saggi Mizrahi smizr...@redhat.com Sent: Thursday, May 10, 2012 4:39:49 PM I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. Yes, this should be handled on the backend side (Yair - please note, maybe it is already implemented like this - don't know): When getting a null-or-empty mount options value from the client, the backend needs to make sure to *not* set the relevant parameter in the vdsm verb at all. So leaving the mount options text-box empty in the GUI is legal, only needs to be handled in a certain way in the backend. In theory for a PosixFS file system a user could create multiple storage domains of different PosixFS types. Perhaps that's not a problem, but worth noting. Is Path the correct term to use for the remote mount? I can imagine customers thinking that is local and messing with fstab. Not sure if there's a better term - filesystem URI ? - In the initial mock-up, it was called Mount Spec. Is it better? I don't like any of the options - but have a preference for Filesystem URI, but I'd like others to weigh in here. My concern with path is that it could mean local or remote, so another option is Remote Path But it *can* be local or remote, so why Remote Path? Path actually sounds like a good term. Can it be local - do
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] PosixFS: GUI mock-ups have been updated
- Original Message - - Original Message - From: Einav Cohen eco...@redhat.com To: Andrew Cathrow acath...@redhat.com Cc: engine-devel@ovirt.org, Simon Grinberg sgrin...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Geert Jansen gjan...@redhat.com, Ori Liel ol...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Ayal Baron aba...@redhat.com, Miki Kenneth mkenn...@redhat.com Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated ... The important thing is that it's clear what it is - eg. the remote/target not the local mount point. That could be accomplished in the tool tip, etc. So if there will be a tool-tip (or similar) in the GUI explaining what this field is supposed to be, are you OK with keeping the term Path (in both GUI and rest-api)? I am , does everyone else agree. either 'path' or 'device' mount [-fnrsvw] [-t vfstype] [-o options] device dir device is what is being mounted and in the case of NFS is server:path There is a reason why we termed it PosixFS and not SharedFS and that users can specify local devices/FS's (and there is no reason to limit it). Note that if user defines a local FS and adds 2 hosts to the Posix FS DC then 1 host will be non-op Miki - this is not cluster level seeing as PosixFS is a DC type (afaik) so no need for tooltips about that. In the future when we get rid of the single storage type in DC limitation then we'll be able to define a local posixFS domain and a shared one. Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please feel free to suggest a new term, or vote for one of the previously-discussed terms (Remote Path / Path / Mount Spec / File System URI). If no decision will be made here, the term will remain as-is, i.e. Path. ... ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
