[Engine-devel] PosixFS: GUI mock-ups have been updated
Please review the mock-ups on the feature page: http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI Comments are welcome. ---- Thanks, Einav
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
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@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
I do express that empty mount options SHOULD NOT send an empty string, rather, omit the whole argument. ----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message ----- From: "Saggi Mizrahi" <smizrahi@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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 ? 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.
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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.
- 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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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" <ecohen@redhat.com> > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" > <abaron@redhat.com> > Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew > Cathrow" > <acathrow@redhat.com>, "Miki Kenneth" > <mkenneth@redhat.com>, "Simon Grinberg" > <sgrinber@redhat.com>, > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > Hildesheim" <info@eldanet.com>, "Alexey Chub" > <achub@redhat.com>, > engine-devel@ovirt.org, "Haim Ateya" > <hateya@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" <yzaslavs@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
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:03:16 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, engine-devel@ovirt.org, "Eldan Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" <sgrinber@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" <smizrahi@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" <ecohen@redhat.com> > > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal > > Baron" > > <abaron@redhat.com> > > Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew > > Cathrow" > > <acathrow@redhat.com>, "Miki Kenneth" > > <mkenneth@redhat.com>, "Simon Grinberg" > > <sgrinber@redhat.com>, > > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > > Hildesheim" <info@eldanet.com>, "Alexey Chub" > > <achub@redhat.com>, > > engine-devel@ovirt.org, "Haim Ateya" > > <hateya@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" <yzaslavs@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
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:03:16 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 4:57:44 PM
----- Original Message ----- > From: "Einav Cohen" <ecohen@redhat.com> > To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair > Zaslavsky" > <yzaslavs@redhat.com> > Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan Hildesheim" > <info@eldanet.com>, engine-devel@ovirt.org, "Eldan > Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" > <sgrinber@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" <smizrahi@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 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" <ecohen@redhat.com> > > > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal > > > Baron" > > > <abaron@redhat.com> > > > Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew > > > Cathrow" > > > <acathrow@redhat.com>, "Miki Kenneth" > > > <mkenneth@redhat.com>, "Simon Grinberg" > > > <sgrinber@redhat.com>, > > > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > > > Hildesheim" <info@eldanet.com>, "Alexey Chub" > > > <achub@redhat.com>, > > > engine-devel@ovirt.org, "Haim Ateya" > > > <hateya@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" <yzaslavs@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
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:18:58 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:03:16 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> > Sent: Thursday, May 10, 2012 4:57:44 PM > > ----- Original Message ----- > > From: "Einav Cohen" <ecohen@redhat.com> > > To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair > > Zaslavsky" > > <yzaslavs@redhat.com> > > Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan > > Hildesheim" > > <info@eldanet.com>, engine-devel@ovirt.org, "Eldan > > Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" > > <sgrinber@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" <smizrahi@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/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".
- 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" <ecohen@redhat.com> > > > > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal > > > > Baron" > > > > <abaron@redhat.com> > > > > Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew > > > > Cathrow" > > > > <acathrow@redhat.com>, "Miki Kenneth" > > > > <mkenneth@redhat.com>, "Simon Grinberg" > > > > <sgrinber@redhat.com>, > > > > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > > > > Hildesheim" <info@eldanet.com>, "Alexey Chub" > > > > <achub@redhat.com>, > > > > engine-devel@ovirt.org, "Haim Ateya" > > > > <hateya@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" <yzaslavs@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 > > >
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:18:58 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 8:03:16 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@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" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message ----- > From: "Einav Cohen" <ecohen@redhat.com> > To: "Andrew Cathrow" <acathrow@redhat.com>, "Geert > Jansen" > <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, > "Yair > Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" > <abaron@redhat.com> > Cc: engine-devel@ovirt.org, "Simon Grinberg" > <sgrinber@redhat.com>, > "Saggi Mizrahi" <smizrahi@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" <acathrow@redhat.com> > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > ----- Original Message ----- > > > From: "Einav Cohen" <ecohen@redhat.com> > > > To: "Saggi Mizrahi" <smizrahi@redhat.com>, "Yair > > > Zaslavsky" > > > <yzaslavs@redhat.com> > > > Cc: "Haim Ateya" <hateya@redhat.com>, "Eldan > > > Hildesheim" > > > <info@eldanet.com>, engine-devel@ovirt.org, "Eldan > > > Hildesheim" <ehildesh@redhat.com>, "Simon Grinberg" > > > <sgrinber@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" <smizrahi@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.
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.
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".
> > - 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" <ecohen@redhat.com> > > > > > To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal > > > > > Baron" > > > > > <abaron@redhat.com> > > > > > Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, > > > > > "Andrew > > > > > Cathrow" > > > > > <acathrow@redhat.com>, "Miki Kenneth" > > > > > <mkenneth@redhat.com>, "Simon Grinberg" > > > > > <sgrinber@redhat.com>, > > > > > "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan > > > > > Hildesheim" <info@eldanet.com>, "Alexey Chub" > > > > > <achub@redhat.com>, > > > > > engine-devel@ovirt.org, "Haim Ateya" > > > > > <hateya@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" <yzaslavs@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 > > > > > > >
...
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".
...
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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".
...
----- Original Message -----
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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".
...
--=_d3dc9ed8-f78b-4619-8697-13e954cbc408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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".
...
--=_d3dc9ed8-f78b-4619-8697-13e954cbc408 Content-Type: image/png; name=NewNfsStorageDomainDialog-PathExplanation.png Content-Disposition: attachment; filename=NewNfsStorageDomainDialog-PathExplanation.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAsUAAAEoCAYAAACw+YzZAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz AAAOxAAADsQBlSsOGwAAIABJREFUeJzs3XlcVPX+x/HXDJuAiKKiuSDu5gpKpqYtrrnk1VTQUrvK zUozK7O6mQtlqanlkrfIJUvT3NdSK5cWydyIXHFFDUVFRdmUbX5/8GNiZN9Emffz8eABc5bv+cyZ A/PmO99zjqF8+fImMmFnZ0ejRo2oUKFCZrNFRERERO5LkZGRHD58mMTERPM0g5ubW4ZQXLp0aZo1 a4aTk5N5mq2tLf379+ehhx7Czc0NW1vbu1O1iIiIiEg+JCUlce3aNfbu3cu3335LUlKSeV5cXBwh ISHExMQAYChbtqxFKC5dujQtW7bEzs7OPG3YsGE8+uijCsIiIiIicl9KSkril19+4YsvvjBPS0xM ZM+ePcTExGBwdXU1h2IHBwdatWqFo6MjAK6urnz00Ue4urpaNBoTE8OxY8f466+/CAoKMidsERER EZHi4uhUmlvxsTg6OVPRvRJ169SlRQsvvL28zMvcuHGDN998kxs3bgAQHx/P7t27Mbi4uJhDsY+P D+7u7gCULVuWOXPmmHuMTSYTZ86cYdy4cSQnJ9/N5yciIiIiki8Gg4FGTbzo0b0rXs2aAqk9xCNH jiQqKgqAy5cv/xOK3dzcaNWqlbmBL774gjJlygBw69YtFi1axM6dO+/y0xARERERKThnl7J0ebIr vn3+BcDNmzcZNmyYeb6NnZ3dRJPJhLe3t3nYxLBhw2jQoAGQGognTZrEgQMH7n71IiIiIiKFIDHh FmdOnyIh2UCjhg1wcHDAzc2N/fv3A2A0mUw4OjpSrlw5IPUqE48++iiQOmRi0aJFnDx5stiegIiI iIhIYbh1K55Nmzay/8CfABYXkjACPPDAA+aFu3TpYp555swZDZkQERERkRIjIT6GlWvXAamdwV26 dAH+PxSnnVwH0L59ewBSUlIYN27c3a5TRERERKRIhZ04xp69+4B/sq9t75EPkHTBERJSF3JzcwNS L2icm6tMlC1blsqVK1O+fHnziXk3b97k6tWrREREmM/qExERERG5V+zes4+WD/mYs6/trZNe2NjY YDCkLuDg4ADAsWPHcmysevXqeHp64uzsDKSOQQZwcXHBxcWFihUrEhYWxvnz54vgqVi3b7/9FoD+ /fsXcyUiIiIi95/Q0OPAP9nXtlSpUpb3ff7/dBwUFJRtQ1WrVqVWrVrY2tparJ+evb09tWrVIiUl hfDw8FwXmRb4PvvsM37++ecM0+9WEEzbHsDt27e5ePEie/fuZcOGDVk+ZxERERG590Vdvwr8k31t HR0dLe4DnSYkJCTLRlxcXKhcuTIpKSkkJCTkuNHKlStz8+ZNoqOj81Ts008/zW+//XZP3CzEwcEB T09PPD09admyJWPHjs10v90t6iEWERERyb/kRMsMa+vg4JBpWI2Njc2yEVdXV2xtbc2B2GQTT6Lz CZIcz6Y2Gl8Du9i6GJJTr3tsa2uLq6trnkJxbGwsBoOBtm3bWvQW36ldu3Y89dRTVKpUib///pt1 69axd+9eypQpwxdffEFwcDBTp04F4L///S/NmjWzmPb222/TrFkz/P39iYuLy3Qb/fv3x8HBgQYN GjBs2DBq1KhBjx49WLdunXmZRx55hKeeeorKlStz6dIlfvjhB7Zt2wakBuqvvvqKq1ev8tlnnzF0 6FASExOZN28eVatWZeDAgcTFxTFnzhzz5e+qVKnCc889R506dTAajRw/fpyFCxdy6dIlwLLXPH37 H374If7+/tSsWZMzZ87w2WefceXKlVzvdxERERHrYLJ4ZEwbR5EXTk5OJCYmmr9uOR4jocxfpNjd IMXuBgll/uKW4zGLZZycnPK8jXXr1vH0009jY2OT6TItW7ZkxIgReHh44ODgQO3atXn11VepW7cu N2/e5MKFC9SsWRMAGxsb8w1J6tevj9FoBKBWrVqcPXs2y0Cc5vbt24SEhLBw4UIAvL29zfMeeugh Ro4ciaenJ6VKlaJGjRo8//zztGvXDsD8z0Pp0qUZPnw4VapUMS/j7++Pi4sLlSpVYuDAgeY2X3zx RRo3boyzszOOjo40a9aMF198MdPa0rc/ZswYGjZsiKOjIw0bNmTIkCHZ72gRERERwWhnZ5fnlWxs bEhISDB/JTudy7BMstM5i2WyCrZZMRgM/Pzzz9jY2NC2bdtMl+nWrRsA06ZN47nnniMwMBAbGxs6 d+4MwNGjRylbtixly5aldu3aODg4cPLkSZycnPD09KRChQqUKVOGI0eO5LqutBMQq1atap7WvXt3 ALZs2cLw4cPZtGkTgPm6d2knIDo4OLBhwwamTZsGQI0aNVi6dKn5saenp7nN8ePH8+yzz9K/f39e e+01AOrWrZtpTenbP3z4MP7+/nz99dcA5n8ERERERCRrtvkJxYmJiaSkpJgf25jAcMcyJhMkpTsZ LT/jgpOTk1m/fr15bPGdqlWrBsCYMWMsptevXx9IDbAdOnSgZs2a5sC5atUq3n77bRo2bGgeVnD0 6NFc15QW7tM/n+rVqwOwadMmrl27xpYtW+jRo4fFTVHS/PLLLxYn6f3666/mnt5SpUqZp3t4ePD8 889Ts2ZN881U0r5nZ/ny5cTGxrJt2zYGDx6c5x56EREREWtktLW1NZ91l1txcXEWQyOSr7tnWCb5 urvFMjkNT8jKzp07sbOzo23bthZBPDuurq7AP2G3Zs2aNGrUiMuXL/Pnn39y48YNGjVqRO3atTGZ TLm6/Fyahg0bAmR6NY20cdjx8fFZrp+279Kvk9mVLIYNG0bdunWxtbU19wTnxs2bN4HU4R4iIiIi kju2eR3WABATE2MxHCIpojL2ySnYuV0GIPGaOwlXKmNKF/ZiYmLyVWBiYiIbNmzg6aef5tatWxY9 nxcuXKBevXpMmTKFgwcPZuiNjoyM5OrVq9SrV4969eqxa9cuILUHuUmTJjg4OBAeHp6rEwBtbW2p X78+zz33HAB79uwxzwsPD6devXp07tyZLVu2mIdNFOT6zB4eHgCMHTsWOzs7Jk6cCICjo2O2oVtE RERE8s427YSzvIiPj8fe3v6fj/MTjSTEVoOwancsmRqKk5KSChTktm3bRq9evTIMBfjuu++oV68e b7/99j9bTEzkwIEDfPLJJ0Bqb/EjjzyCwWAwjx0+fPgwDz/8MA8++CA//vhjjttPf71igNOnT1us t3HjRkaPHs2AAQMYMGCAxfT8ioyMpEqVKnzwwQckJycTGRlJhQoVmDt3LkOHDs13uyIiIiKSkTEy KiZPH89DavBM+9g/KSkp26/0y+ZXYmKi+eS19P744w/mzp3LuXOpJ/Vdv36d3377jfnz55uXOXbs mHl4yOHDh4F/hlUYDIZcjydOSUnh77//ZsOGDUyYMMGiV3rv3r3mOm7dusWZM2f45JNP2L9/f76f 8+LFi7l+/TqXL1/miy++4Msvv+TixYtERkbmu00RERERyZzhq6++Mm3ZssU8XnfZsmUYDIZc3RzC wcEBe3v7LK8skZycTEJCgsa3ioiIiMg959tvv8VkMjFgwAByvpxBNm7fvk1SUhK2trYYjUaLKzOk pKSQlJR0T9yNTkREREQkOwUKxZAagBV8RUREROR+lvez7EREREREShiFYhERERGxesa83rhDRERE RKSkUU+xiIiIiFg9hWIRERERsXpZXn3izru4iYiIiIiUVOopFhERERGrl+11ioNDw+5SGSIiIiIi d493fU+LxznevOPOFURERERE7meZdfxq+ISIiIiIWL0C3+ZZil9AQEBxlyAiWZgwYUJxlyAiIrmg UFxC6I1X5N6jf1hFRO4fGj5RglStWrW4SxARERG5LykUi4iIiIjVUygWEREREaunUCwiIiIiVk+h WERERESsnkKxiIiIiFg9hWIRERERsXrGQ8dOkpKSkucVfXx8GDlyJCaTKdN5IiIiIiL3C6O7WxkM BkO+Vi5TpgwrV64s5JJERERERO6uAg2fePvtt1m+fDlhYWFZLnPw4EHefPNN2rdvz2OPPcaYMWOI iooyz/fx8WHz5s34+fnx6KOPMnToUE6ePMnPP//MoEGDaNeuHUOGDOHcuXPmdVJSUliwYAE9e/ak ffv2vPfee8THxxfkqYiIiIiIFStQKHZxceGdd95h/PjxJCUlZbrM7Nmz6dWrF+vXr2fp0qXY29vz 6aefWiyzdu1a3njjDVavXk3Dhg0ZNmwYy5cv59VXX2Xt2rU0atSIJUuWmJdftmwZv/32GwEBASxa tIioqCg+//zzgjwVEREREbFiBT7RrkWLFvj4+BAYGJjp/Hnz5tGmTRtcXFyoWrUqI0aMICgoyGKZ V199lYceeoiKFSsydOhQbt68yciRI2nRogUVKlRg6NCh7Nixw7z82rVrGTlyJN7e3nh4eDB8+HC2 b99e0KciIiIiIlbKtjAaeemllxg6dCiPPPIIXl5eFvOOHDnCnDlzCA0N5ebNmwAYjZZZvGHDhuaf 3dzcAHjwwQctpl2/ft38+OLFiwwbNsyijTvbFBERERHJrUIJxXZ2dgQEBPDWW2/x1VdfWcx75513 6Nu3L1OnTqV06dKcP3+ePn36FGh7lStXZty4cRkCuIiIiIhIfhRa92qtWrXo06cPH330kcX00qVL U6ZM6hUuQkJCmDp1aoG31bdvX2bNmsXu3buJjY3lyJEjvP766wVuV0RERESsk21m1xnOLz8/P155 5RWLaaNHj2b+/PlMnz6dSpUq8dxzz7Fnz54Cb8doNDJ9+nQiIiKoVasW/v7+BWpTRERERKyXbXJy cr5W3LdvX4ZpBoOBOXPmWEzz9vZm7ty5FtN69OiRbTs5TTMajfj5+eHn55fnukVERERE7mTMbygW ERERESkpjE2aNMn3He1EREREREoCY0xMTHHXICIiIiJSrHRxXxERERGxekYNnSg5wsPDi7sEERER kftSoV6STYpPQEBAcZcgIiIict8qlDvaSfGaMGFCcZcgIiIicl/TmGIRERERsXoKxSIiIiJi9RSK RURERMTqKRSLiIiIiNXTJdlERERExOqpp1hERERErJ5R1ykWEREREWunnmIRERERsXq6eUcJoLvZ idx7dFMdEZH7i0JxCaE3YJHClZycnK/1goJ2sX37jkKuRkREiprGFIuIFJKgoF0EBQUVdxkiIpIP tgrFIiJZS0i4netlFYhFRO5fxvx+RCgiIiIiUlLke/iEj48PPj4+tGzZkm7dujFkyBAWLVpEXFxc ntspDJcvX+bdd9+lZ8+ePPbYY/j7+7Nr165CaRsKr86SKDg4mObNmxMXF4e9vT1//vlnhmXS3yTG YDBk+pUmPDycgQMHUqVKFezt7alYsSJdu3YlODiY2NhYvLy8CAkJuSvPTURERKxDgXqK9+3bxx9/ /MGSJUsYPXo0586dw9fXl5s3bxZiiTm7cuUKgwcPpkGDBnzxxRd8//33jBgxgm+//fau1mGNkpOT GTRoEAsXLsTJyQmj0ci4ceNISEjIdj2TyZThK82AAQOoX78++/btIy4ujtDQUAYMGMCCBQtwdnZm wYIFDBo0iJSUlKJ+eiIiImIljElJSRRkXLHBYMDNzY3GjRszfvx4nnjiCWbPnm2ef/DgQd58803a t2/PY489xpgxY4iKigL+6X1N63XOzTqZ+fzzz/H19WXgwIFUrlwZZ2dnmjdvzpw5c8zLpKSksGDB Anr27En79u157733iI+PN8/38fHh+++/x9fXl7Zt2zJkyBDCwsKyrTM3ba5bt44+ffrQsmXL/Oze Atm+fTtNmjTBxcWFbt26WYx3zO+8O61cuZJ69erh5eUFQFJSEq+++mqBLhMXHBzMqFGjqFKlCra2 tri5uTF48GA+/fRTAFq0aIGnpydr167N9zZE8mrx4iU4OTln+Fq8eElxlyYiIoWg0McU9+7d2+Kj 7dmzZ9OrVy/Wr1/P0qVLsbe3N4ebffv2mb+n/ZzTOpkJDg6mS5cu2da1bNkyfvvtNwICAli0aBFR UVF8/vnnFsts2rSJt99+m7Vr1/Lggw/yzTffZFtnbtrcunUrEydOZM+ePdnWVxReeeUVpk6dSmRk JP369WP8+PEFnnen1atX4+vra36cnJxMhw4diI6OZvfu3fmqu3///mzatIn169dz5MiRTP9p69ev HytXrsxX+yL5MWjQQAIDAy2mBQYGMmjQwGKqSERECtXcuXNN/fv3N/n5+Zn8/PxMKSkppjQHjp0x ZaVFixaZTo+Pjzc98sgjWa4XHh5u6tq1a47tZLfOndq0aWO6fft2tm306dPHtH//fvPjEydOmHr0 6GFRx9GjR82PIyMjTR07dsy2zty0eeDAgWzrKgwTJ07McZnbt2+bjEZjoc4zmUwmDw8PU1hYmPkx YDKZTKaYmBhT165dTXFxcRbT036+8yu95ORk0zfffGPq3bu3yd3d3VShQgXTSy+9ZIqMjDQvc/Lk SZOHh0cOz1ok/5KSkkxJSUmmuLhYi6/AwEATYAoMDMwwb8qUyaYpUybn6ndSRESKT/qMm5KSYvLz 8zPZFnZP8YULF6hSpYr58ZEjR5gzZw6hoaHmscZGY/Z3l87rOpUqVeLKlStUrVo1y2UuXrzIsGHD LKbd2WaDBg3MP5cvX57r169nW2du2mzWrFm2bRSlnTt3MmbMGI4dO0ZcXJzFGNz8zrvT5cuXcXd3 zzDd2dmZ//73v4wdO5aPP/44w3xTNkN2jEYjzzzzDM888wwAp06dYt68efj6+rJt2zYAKleuzJUr V3LeCSKFLK1nWD3EIiIli/G3334r1BOW1qxZYx5fCvDOO+/wyCOPsG7dOvbs2cPq1asttmcwGDJs P6d17uTt7c0PP/yQbV2VK1dm/vz55iEQ+/bty9OQhszqzE2bOf0DUJSGDh3Kq6++yoULF7hx40ah zMuLdu3aYWNjw86dO7G1zf/NE2vXrs1bb71VLENQRDKjQCwiUvIUSmK7fv06hw8f5r333mPnzp28 /PLL5nmlS5emTJkyGAwGQkJCmDp1qsW6ZcuW5dChQxbTclrnTi+++CIrVqxg6dKlXL58mdjYWIKD g3nllVfMy/Tt25dZs2axe/duYmNjOXLkCK+//nqun2NmdRa0zaLm7u6Op6cnCQkJTJs2jYoVK3Ly 5MkCzctsG5cvX86yhvfff5+pU6diZ2eX67oHDx7Mhx9+yKVLl0hKSiIiIoJJkybRrl078zIRERFU rFgx122KiIiIZMd20KBBLF26NF+9xT4+PhiNRipUqEClSpV49NFHGT16NM7OzuZlRo8ezfz585k+ fTqVKlXiueees+jx+/e//82oUaOIjo42n8SW0zp3qlixIl999RWzZs1i2bJl3Lhxg3r16jF06FDz Mn5+fhiNRqZPn05ERAS1atXC398/1881szoL2mZRmzVrFl27dsXV1ZV58+YBqcM5YmNj8z3vTi1b tmT37t3UqFEj0xpKlSpFQEAAbdq0yVPdL730Ek2bNiUqKopKlSrRuXNnFi1aZF7m999/p3Xr1rlu U0RERCQ7ho0bN5rSh+Jly5aZb6QQHBqGd33PYixPciMgIIAJEyYUy7a//fZbVq1axapVq+7qdnv1 6sXAgQPp27fvXd2uWI+08y3ycpvntMtR3rp1u9h+J0VEJGfpM67JZGLAgAGFM3xCrFe/fv04evQo f/31113bZnBwMKdOneLpp5++a9sUERGRki3/Zz+JADY2NixevJghQ4bw66+/4uTkVKTbi4uLw9/f n8WLFxfrSYxiHYKCdmV78xoRESk5FIqlwJo3b87+/fvvyracnJw4cODAXdmWWDcFYhER66JQXEIU 5LbKIiIiItZOobgE0Ak9IiIiIgWjQZkiIiIiYvUUikVERETE6ikUi4iIiIjVUygWEREREaunUCwi IiIiVk+hWERERESsnnHmzJkkJiYWdx0iIiIiIsXG2KxZM+zs7Iq7DhERERGRYmNs06ZNcdcgIiIi IlKsbE0mU7YLvL+yxV0qRURERESk6PVoujrDNOPu3buLoRQRERERkXuH8cCBAzrRTkRERESsmvH1 11/XiXYiIiIiYtV0nWIRERERsXoKxSIiIiJi9RSKRURERMTqKRSLiIiIiNVTKBYRERERq6dQLCIi IiJWT6FYRERERKyeQrGIiIiIWD2FYhERERGxerbFXYCISFFKOdKzuEsQsRrGhhuKu4QSSX/HCia3 x6VCsYiUeBMnTsRkMmEwGPRd3/U9m+9JSUn5+h0LCtrF9u07Cvk3V9J7880xxV1CsbG3d8jXenk9 LjV8QkSshslk0nd91/ccvudVUNAugoKC8rWuSFHJz3FpGxmdUETliIjcG/L7Zi9iTdL3FCck3M71 egrEcrcU9XFpdLS1z/NKIiL3E4PBUNwliNzz9M+jWLt8jSke12+/+efo+MuEXzvM9oNzuBp9ttAK y20N769sked10svL+gWRn3pz4un+EIMe+5xPv+/J9dhwAEqXKk/7JiOpVakVzg7luJ0US/jVg/z0 1yyu3DxdaNsuKpm9RnD3XicpmTJ7s08LykajEQ8PD1q3bs0HH3xAzZo1c9Vmp06d+PHHH/NdU0xM DB07dmT37t0Z5tnb27Nnzx68vLwy1Jz2XLIK+mnzw8PDeeutt9i+fTuRkZG4urri4+PDhx9+iLe3 d77rlpKrIGOK7wXF+R5fHJYvX0G9enUz/X0ODg7mxImT+Pr2A+D48eNs2bKVV14ZebfLvK8UaEzx +ytbsPjnFynv4sHznZZS1rlqYdWVq23n92BPW7eof1m6t3jXIgwX9vY8KngRcyvSHIgBnm41mWae T/FjyCdMW/8EOw79D4+KzenQ9JVM67rX3Lmf7sbrJCVfdgEyMTGR7du3U69ePR566CHOnTuXqzaP Hz9eoJqWL19O9+7dM51nNBoZN24cCQnZD28zmUwZvtIMGDCA+vXrs2/fPuLi4ggNDWXAgAEsWLCg QHVLyVVSeorv1nt8bhTl+22zZs04diw003nHjoXSrFkzAC5evEhk5NUiqaGkKfDVJ65Gn2X7wbn4 PfIxTzQezto/xmJjtKdj01E8WK0DBoOR0PAd/BAyAzDw36eDiL11je8OfEDnZq+TnJLEluCPcCtd nccbDychKY6NewM4c3kP5V1q0MXrDaq6NcZgsOHvqyFsDp7K9Zi/zQfZ5DVtzG1uDp5Cx6ajMBhs zG3kxp29uLlt28ZozxONh9PIozOl7Fw4H/knW4I/4lrMeYtfgvQ/v7+yRa72T26eS/UK3pyP/NNi WhW3RgCcvvQ7CUlx7D+1iv2nVmVay7h++/lwdetsa4m5dZV9p1bQtoE/k9e0zvY1KetchT6tp1LW 6QF+OTKPxxu/RCk7Fyateggbox0dm77Cg9U6YcDA4fM/8GPIx6SYknP1Gj3Tbg7VK3gxfX0HklMS qFGxBYMf/4IfQz6hU7PXSEiKY9vBOTz64PNE37rCyqAxRMWGY2vjUKDtSsmQ3Zu90WikZs2aTJw4 EYPBwNixY1m8eDEA27dvZ9SoUYSFhdGuXTveffdd2rRpQ6tWrTh37px5+UmTJmW5bFa+/PLLLANq UlISr776KgEBAXzwwQf5es7BwcFs2rSJMmXKAODm5sbgwYMZPHhwvtqTki+znuLFi5fwwgsvZFg2 MDCQQYMG3q3SCiSn99z073PT1j9e6DkFUt9vCzuk161bh99++41r167h5uZmnn7t2jXi4uKoW7cO ABERl2jTpjX79u0r1O0Xp6I6Lgvl6hMXrh0CoIpbQwAebfgfWtbtz56T3/J76Ne0qN2Xxxu9RFJy aq+Ho30ZStmVZuufMyjvUoNeLd8HYMPeibg6Vaaz12gAej40gZqVHmbJL8NZGfQGtSu3oafPBItt p2/TwdaZrX/OsGijIHJqu+2DQ2ldfxDBp9ey6ve3qFnpYZ7yGQ+Qobczvdzsn5yei8FgpFr5JpyP DLGYHnH9GADPPTGf1vUH80C5B4F/esnurCt3r5ULMzZ0ALJ/TTo0HUWVcg3ZdnAOySlJlLJzAcBk SuGxhsN4qE5/fvprJkGhX9Gybn9a1x+U69fiz7AN2Ns6UdP9IQDqPPAIKSlJhIRtBMDe1omUlCR2 H19C5bL1zT3jBd2ulAy5HVM8YMAA9uz55x/QV155halTpxIZGUm/fv0YPz719zttyIPJZGLSpEnZ LpuZ0NBQYmNjqV+/fqbzk5OT6dChA9HR0ZkOr8iN/v37s2nTJtavX8+RI0dKTC+gFJ3MjpFBgwYS GBhoMe1+CsSQ20yS+j5XmDkluxxQGGxsbGjSpHGG3uJjx47RpEljjMbUiOft7ZXZ6ve1ojouCyUU xyfcBMDF0R2ARh5PAhB8eg1/hqVeMLlh9U5A6i+c0WjLsfCdnIr4HQDnUm4cOrfF/LiCiycAX24f ygerWnLx+lHOX03tEa1avskdW/+nzaPh2zO0kZlx/fabv7KXfdtNPLoC8NfZ7zkVEcQHq1ry1c7n c2gzd/snp+dSuWw97G2dOH/VMhSv3v02h85toaxTFTo2HcV/Oi7h5W7rM9lvuavFxmhH8Jl1JCTF Adm/JjUqNgfgWPgOQsMtrwvYoFp7AELDd3Lo3BYAGnt0y2lXmYWG/0x8wk3qV30MgDqVH+FExG/E J9wwL3P07584+vdPqbVUaF4o25WSIbeBsFq1avz999/mx4cOHaJbt244ODjw7LPPsmNH1te7zMuy X375Jb6+vjnWM3nyZN577z3i4+MznW8wGCy+0kt7w/jqq6944okncHd3Z/jw4Vy9qo9RJXNZ/fOY PoDcD4H4zvf4vL3PFUVOKTpNmjTh5MmTFtNOnjxFkyZ3r4biUhTHZaHcvMPR3hWAG3ERALiUqgjA rcQYDP/fS+nsUN5induJMRaPbyVGm382GlPLqlnpYTo3G00FlxoYjTZA6sGblfRtprWRmfz8x5ZZ 22n/BMQlP0k4AAAgAElEQVTcupKntvK6fzJ7LtUreJGYfMvcM5wmOv4Ka/8Yi9FoS1W3RrSs+wwN q3XkKZ9xfL4145twbmpJfwJldq+Jo13qx7RpATq9Mo6VAHir96/maWWdH8iwXFaSUxI4dO57HqzW kV+PLMDdtQ4/H7b8LzE+IZqEpNTwUMrepVC2KyVD+hPUshMWFkatWrXMj3fu3MmYMWM4duwYcXFx pKSkZLlubpdNTk5m8eLF/PLLLznW4+zszH//+1/Gjh3Lxx9/nGF+TsNCnnnmGZ555hkATp06xbx5 8/D19WXbtm05blusj8lkIjk586FlaYHjXg/EkPE9Pq/vc2mKIqcUNicnJypVcic8/AJVq1YhPDyc Bx6ojKOj412roTgV9nFZKKG4eoXUwdx/X/0LSA2JZZ2r4mBXGqMh9SCJjr+c53af8hmPq1NlFm57 jks3TvDfp4vmWogpKUkYjbbYGO2xs8n9XVNibkVS1rkKZRwrcS3mfB7WK/j+qV7BmwvXDmc5NjYl JYnzkSFcjT5Lw2odcXXKPAjmphaT6Z839+xek/jEmzg7uFHGsRKJSZY9WzfjL+NWujqT17Q2fzyV V3+e2cBDdfrTruHzxCfc5MTFXy3mO9g5YWNMvcRg3O2oQtuu3P9y21P85Zdf0rZtW/PjoUOH8v77 79OzZ08MBgMuLi5ZrpvbZTdv3swDDzxA7dq1c1VTu3bt2LBhAzt37sTWNv9/smvXrs1bb72Fh4dH vtuQki2nq0/cD4E4M3l9n8uLu5VTstOsWTP++OMPKlXqzr59+2jduvVdr6E4FeZxWeDhE65OlXm0 4QskJsXzy//33B08txmABlUep0HV9v8/7fs8t21vm/qfTlLybR6q42fugXSwcy5o2RauxqT+h1i7 civqV32M5JTEXK13+PxWABp7dKV25Ta823cvQ9ovNM+PvXUNgAplLC/xVBj7p3r5ZhlOsgPo12Y6 b/X+lQerdcTO1hGvmr0ACLv8zwD79HXltZbsXpNzV4IBaFS9E/WrPmGxXtq+alS9M7UqPcx/n/6d /m1n5uk5R0SFEhEVinfNf3Hk/A93vE4mGlRtT/0qqcMr0k5MLIztyv0vpzHF4eHhfPDBByxatMhi LLC7uzuenp4kJCQwbdo0KlasaP6osk6dOhw4cMB8hYjslk1v4cKF+Pn55an+999/n6lTp2Jnl/se qMGDB/Phhx9y6dIlkpKSiIiIYNKkSbRr1y5P2xbrUVLHnRdWJslMTjklqxxQmCpXrsytW7fZunUr CQmJuLu7F9m2SroCheJx/fYzrPO3RMdfYv62QebhE78eWcDek8tp32QkjzV6gT0nlvHb0YU5tJbR TyEzibsdhV/bT0hKvs3mA1O4ERfBfzouKUjZGfwY8gk34y7RxesNbifGcish9SMSgyH73fPLkS/4 48RSmtfqTd/WUzl16XfW7fnnDTUo9CtuJUbz3OPzLNYr6P4p51wVF8eKGU6yA/jpr5mcvvQH3Zq/ zZv/2slDdXz588x6Nu57L9O68lpLdq/J9oNzuHzjFA/XfTbDx0e/HV3AH8e/4YnGL9O39TTCruxl S/BHuX7OaY6Fb8dgMJpPsEtjMpko41SJzl6jCb92iB0H5xbqduX+ltWbfdpYXG9vb/bv38/evXt5 4IF/PlWZNWsWTz31FD4+PrRr146XXnrJfJmjX3/9laFDh1KtWrUcl01z5coVvvvuu1yNJ06vVKlS BAQE5HiJtvRmzZrFX3/9RdOmTXF2dqZly5bcuHGDRYsW5WnbYj1K6k1uCiuTZCannJJVDihsXl7N OHXqdIa/OQCzZ89h9uw5GX6WjAzfrthoWr92qXn827Jly8y/GMGhYWz6q09x1if3KQc7Z97s9Qsx t67yycbOBW7PYDBSyq40Qzt8Reytayza4W+eVxQ3RpGSI+VITyZOnFhie8FEClPamOK83E539uzZ ANy6dRtjww1FUpe1SznSkzffHFPcZRQbe/vUoa2FeVz2aLoa7/qeQGrHyYABAwpnTLEIwLOPzqVa +aas+v1NnB1Sr5l4KqJwxlc1rt6FHj7jOX1pNz+GZDzhSCQ7CsQiObvf72gnUlAKxVJodhz6H128 RtOvzXQSkuIICdtUaAH24LnN5nFhInmV26tPiFiztKtPBAXtIijo7p8wJpKdu3FcKhRLoblw7TBf bh9617erYROSE5PJZA7G+q7v+p71dwViuRfdreNSY4pFpERLOdKzuEsQsRoaU1w09HesYDSmWEQE vUmLyP1Pf8fujkK5zbOIiIiIyP1MoVhERERErJ5CsYiIiIhYPYViEREREbF6CsUiIiIiYvUUikVE RETE6ikUi4iIiIjVUygWEREREatndHYs7hJERERERIqXeopFRERExOopFIuIiIiI1VMoFhERERGr Z5vTAuP67b8bdYiIiIiI3BXBoWEZpqmnWERERESsnkKxiIiIiFg9hWIRERERsXoKxSIiIiJi9RSK RURERMTqKRSLiIiIiNVTKBYRERERq6dQLCIiIiJWT6FYRERERKxejne0k3tfQEBAcZcgIneYMGFC cZcgIiJ5oFBcQugNWKRwJScn52u9oKBdbN++o5CrERGRoqbhEyIihSQoaBdBQUHFXYaIiOSDeopF RLKRkHA718sqEIuI3L/UUywiIiIiVi/fodjHxydf8wribmyzqGoXERERkXuXeopFRERExOoVeSje t28fb7zxBh06dKBfv35s2bLFPC8lJYUFCxbQs2dP2rdvz3vvvUd8fHyBt5mQkMCMGTPo3LkznTt3 ZsaMGSQkJORYU1ovsY+Pj3qMRcTC4sVLcHJyzvC1ePGS4i5NREQKQZGH4nHjxtG6dWvWrl3LtGnT +PXXX83zli1bxm+//UZAQACLFi0iKiqKzz//vMDbXLhwISdOnGDJkiUsWbKE0NBQvvzyyxxr2rdv n/l72s8iIgCDBg0kMDDQYlpgYCCDBg0spopERKQwFXkoLl++PDExMcTGxuLp6ckHH3xgnrd27VpG jhyJt7c3Hh4eDB8+nO3bt2fbXlov7p1f6W3evJlBgwbh7u6Ou7s7AwcOZPPmzbmqSUQkK+mDsQKx iEjJku9Lstna2pKQkIC9vb3F9ISEBGxt/2n2/fffZ9GiRQwcOBAPDw9GjhxJ8+bNAbh48SLDhg2z WN9ozD6nZ9WDmz4YX7lyhSZNmpgfN2vWjMuXL+eqJhGR7KQFYQViEZGSxTY6JjZfK1avXp3jx4/T uHFji+mhoaF4eHiYH9esWZOAgABMJhPbt29n+vTpLF26FIDKlSszbtw4vLy88v8MMlGxYkUOHjzI I488AkBISAju7u65qslgMJCSkpJjOBcR66VALCJS8hjt7Evla0VfX18mTZrEgQMHiI2NJTY2lv37 9zNp0iT69+9vXm706NGEhoYSFxdHfHw8169fN8/r27cvs2bNYvfu3cTGxnLkyBFef/31Aj+pLl26 sHjxYi5fvszly5dZsmQJXbp0yVVNZcuW5dChQwWuQURERETuH/kePtG3b19KlSrFzJkzOXfuHAAe Hh4MHjyY7t27m5fr0aMHAQEBRERE4O3tbTF+18/PD6PRyPTp04mIiKBWrVr4+/sX4Omk+s9//sOs WbMYODC1N6dTp04W7WZX07///W9GjRpFdHS0TrYTERERsRKGlavXmdasWk5KSgqQekUIg8EAQHBo GN71PYuxPMmNgIAAJkyYUNxliJQoycnJBAXtytetm2/duq3fSRGRe1j6jGsymRgwYIBu3iEikpn8 BmIREbk/5Xv4hIhISdau3aO0a/dovtYNCAgo5GpERKSoKRSXEHoTFhEREck/heISQGMXRURERApG Y4pFRERExOopFIuIiIiI1VMoFhERERGrp1AsIiIiIlZPoVhERERErJ5CsYiIiIhYPYViEREREbF6 CsUiIiIiYvUUikVERETE6ikUi4iIiIjVUygWEREREaunUCwiIiIiVk+hWERERESsnkKxiIiIiFg9 hWIRERERsXoKxSIiIiJi9RSKRURERMTqKRSLiIiIiNUzJibcKu4aRERERESKldGltHNx1yAiIiIi Uqw0fEJERERErJ5CsYiIiIhYPYViEREREbF6CsUiIiIiYvUUikVERETE6ikUi4iIiIjVUygWERER EaunUCwiIiIiVk+hWERERESsnkKxiIiIiFg9hWIRERERsXoKxSIiIiJi9RSKRURERMTqKRSLiIiI iNVTKBYRERERq6dQLCIiIiJWT6FYRERERKyeQrGIiIiIWD2FYhERERGxegrFIiIiImL1FIpFRERE xOopFIuIiIiI1VMoFhERERGrp1AsIiIiIlbPGB0TW9w1iIiIiIgUK6OdfanirkFEREREpFhp+ISI iIiIWD3b4i5ACkdAQEBxlyAiIiJyz5owYUK28xWKS5CcXmwRERERa5SbzkMNnxARERERq6dQLCIi IiJWT6FYRERERKyeQrGIiIiIWD2FYhERERGxegrFBeDj41PcJYiIiIhIIVAoFhERERGrl+/rFGfV S7pv3758F1MQPj4+OW47fc1ubm60bt2a119/HVdX10JpX0RERETuTwW6ecf9GBL37duHyWTi0KFD fPHFF0ybNo1JkyYVd1kiIiIiUoyKZPjE5MmT2bBhg8W0DRs2MHnyZCC113XlypX861//okOHDnz0 0UckJiaal01ISGDGjBl07tyZzp07M2PGDBISEszzfXx8WLduHX369KFly5bmHmAfH59cjfM1GAw0 adKEl19+md9//x2AgwcP8uabb9K+fXsee+wxxowZQ1RUlLndrNr//vvv8fX1pW3btgwZMoSwsLA8 7i0RERERKW5FEorfeOMNNm3axI8//gjADz/8wKZNmxgzZox5mW3btjFv3jyWLVvG6dOn+fLLL83z Fi5cyIkTJ1iyZAlLliwhNDTUYj7A1q1bmThxInv27DH3WO/bty/fvdezZ8+mV69erF+/nqVLl2Jv b8+nn35qbjer9jdt2sTbb7/N2rVrefDBB/nmm2/ytX0RERERKT4FCsVpPafpvwDs7OyYMmUKc+bM 4dNPP+XTTz9lypQp2Nr+M1pj0KBBuLu74+7uzsCBA/n+++/N8zZv3pxh/ubNmy22PWzYMJo0aZLv 2o8cOcLcuXN5+OGHAZg3bx5t2rTBxcWFqlWrMmLECIKCgnJs55VXXqF58+ZUrFgRf39/du7cme+a RERERKR4FNmYYjc3N7p37868efN49dVXcXNzs5ifPtA2bdqUy5cvmx9fuXLFYn6zZs0s5qdNy4+0 4O7m5sbDDz/M66+/DqSG5Dlz5hAaGsrNmzcBMBpz/p+hQYMG5p/Lly/P9evX81WXiIiIiBSfAoXi 7Bw/fpz169czbdo0pk2bxmOPPUb16tXN8w8dOkSbNm2A1PG87u7u5nkVK1bk4MGDPPLIIwCEhIRY zIeMgdVgMJCSkpJjkM0qyL/zzjv07duXqVOnUrp0ac6fP0+fPn3y3L6IiIiI3H+KJBTHx8czfvx4 Jk2aRPPmzbGxseHtt99m4cKFODg4ADB//nxKly4NwIIFC+jatat5/S5durB48WLq1q0LwJIlS+jS pUu22yxbtiyHDh2iadOm+aq5dOnSlClTBoPBQEhICPPmzSvU9kVERETk3lWgUJzZlR727dvHlClT 8PPzo3nz5gA8+uij/P3330ydOpXx48cD0LVrV959911iYmLo3LkzQ4YMMbfxn//8h1mzZjFw4EAA OnXqhL+/f7a1/Pvf/2bUqFFER0fn62S70aNHM3/+fKZPn06lSpV47rnn2LNnT6G1LyIiIiL3LsPK 1etMa1YtJyUlBYBly5ZhMBgACA4Nw7u+Z6FvVDfCKHwBAQFMmDChuMsQERERuefcmZPSZ1yTycSA AQN0m2cREREREYViEREREbF6xRKKNXRCRERERO4l6ikWEREREatnTEy4Vdw1iIiIiIgUK1uX0s7F XYMUkoCAgOIuQUREROS+VGR3tJO7S5djExEREck/jSkWEREREaunUCwiIiIiVk/DJ4rT/985UERE 7jKTqbgrEJF7jHqKRURERMTqKRTfC0ymYvm6ERWF/9ChxbZ9fd27Xzo2tN9K7HMWEcmCQrEVCwsL o0aNGsVdhtyDwsLC8PDwKO4y7jvWuN/0d0RESgqNKS7Brl69yksvvQSAwWCgadOm9O/fn9q1awNw 9uxZq38z8/X1ZcWKFebH6fdZGldXV+bNm2d+HBISwvfff8+JEydwdnbmiSeeoFevXhiNxkzbKFOm DA888ADdu3enVatWFtt65ZVXcHV1Ze7cuRjSjTG/fPkyEyZM4LPPPsuy9tDQUGbNmsWcOXOwsbHJ /04AJk+eTMeOHXnooYeA1GPD09Mzy+Xv3G9FIbPX5q233mL+/Pnmx9kd31m5l/dbZscfQLly5QgM DCxQrUVFf0dEpKRQKC7Bjh8/TosWLXjrrbdISEhg3bp1rFmzhjFjxgCpb2ZNmjQp5irvLen3WWa2 bdvGunXreOaZZxg+fDgnT55k+fLl2Nra0rNnz0zbiI6O5uTJk3z11VfEx8fzxBNPmJdr0qQJ0dHR HDp0yOK1CA0NpV69etnWumHDBrp3717gYAdw5swZatWqZX589uxZGjduXOB2C9Px48ct9klOx3dW 7uX9ltPxdy/S3xERKSkUikuw9CHC3t6erl278vLLL5vnnz17lh49egCpwW3FihUcOHCA6OhoGjRo wAsvvED58uUBiI2N5bXXXiMqKopy5crh5eVFt27dzD1EV69eZcuWLRw8eJBLly7RsGFDevfuTZ06 dXJsO71r164xZswYFixYYJ5248YNXnvtNRYuXFio28pqnzVo0CDTeZcuXWLFihVMnDiRBx54AIAW LVqQlJTE0qVLLUJx+vDm4uKCt7c3pUuXJjAw0CIU169fHzc3N3bs2JFtKL6zh/HixYscPXqUgQMH MnToUF5++WXWrl3LuXPncHd3Z8SIEeYey+xeu9jYWIYMGQJg7qH09/fn7NmztGrVipkzZ3Ls2DGc nJzo378/LVu2zNV+jI+PZ8mSJRw6dIioqCgaNWrE888/T7ly5YiJieHll19m+PDhrFmzhtjYWObM mZNjm5mF4uyO7/txv2V3/AHs2LGDn376iUmTJpk/WVizZg27du1i4sSJGI3GLGtO2+9jx45lxYoV nD59mrJly+Ln50ejRo34+uuvCQkJwdXVFV9fX1q0aMH169cZPXp0tvspL39HRETuZRpTXIKlha40 p06domzZsgAkJSURERFBtWrVSExMZNKkSaSkpPDGG28wY8YM3Nzc+Pzzz83r/v777wwaNIjAwEA+ /PBDKlWqZBFkPvnkE4xGI6+//jqzZs3Cx8eHtWvX5qrt9E6cOEHdunUtpkVERJhDaGFuK6t9llUP 7dq1a+nevbtFLQBNmzbl6tWrFm2k3+9pPDw8uHTpUoZttW7dmsOHDxMXF2eel1NP8aZNm+jQoQMX Llzg9u3b7Ny5k2HDhjFz5kzq1avH+vXrzctm99o5OzszduxYmjZtyooVK1ixYgUdOnQgPDycjRs3 8vDDDzNt2jSeeuopvvnmmxz2Xqro6GjGjh1L6dKleeedd5g+fTqurq7873//A1KDaVxcHKtXr6Zr 165MmTIlV+1mFoqzOr7vx/2W2XO80+OPP05KSgo//vgjAFu3bmXHjh28++67uLi4ZFvzxYsXSUxM ZMWKFXTr1o2ZM2fSsmVLAgMD+fjjj2nQoAFTp06lbdu2LF26FIDTp09nu5/y+ndERORepp7iEiox MZFz586Zx1ceOXKE1atX0759ewDCw8Nxd3fHzs6Ob7/9lgoVKvD888+b13/mmWcYMWKE+XHHjh0t 2u/duzcbNmwwP7527Rr29vakpKTg4uLCE088wRNPPJGrttM7efJkpqG4cuXKhb4twKIXMTExkTNn zljcMrtKlSrMnDkTSA0svXr1ytBGWq9cWhvp93t6kZGR5kCdtlydOnWwt7enVatW7Nq1i06dOhEf H09ERAQ1a9bMtM6bN2+ya9cuPvnkE3766Sc8PDx47bXXzD2Hffr04Y033jAvn9Nrd+rUKYshAOHh 4QC88MILVK1aFQBvb2++/vrrTOu506pVq/Dx8WHAgAHmab6+vowaNQpIfT0dHBx44403qFixYpbt 3PnapN+vOR3fmbVxr++3zI4/ACcnJ7788ksMBgMGg4EhQ4YwefJkkpKS2LhxI++99575+Muu5oiI CJycnHj11VdxdnYG4Mknn2T16tU89dRTeHl5AdC2bVtWrVoFpIbi7PZTXv+OiIjcyxSKS6gzZ85w +/ZtBg0ahMFgoGLFijz++OPmjznTnxwTHBzMmTNn8PX1tWgj7Y0zPj6edevWsXfvXq5evUp8fDyA RaB57bXXWLNmDRs3bsTR0ZFnn32Wtm3b5tj2nU6cOEHv3r0tpl24cMEiFBfWtjLbZzVq1GDy5MmZ zr98+TKurq4Zpu/Zs4eGDRua26hatSoODg4Zljt69Kg5xJ05c4YqVaqYl+vUqROfffYZnTp14sSJ E9SoUQNb28x/Pbdu3UrLli0pV64cp0+f5sknn7Q4Se/WrVvm1yY3r92pU6do166d+fHZs2dp2bKl OdilTcvuBLL09u/fnyHYJSQkmD9Cj4iIoFOnTtkG4jvduV9zOr4zc6/vt5yOvzQxMTEkJCTw9ddf M3369FzXHBERQceOHS1+H/7++2/q1q1rDsQA58+fN9ec037Ky98REZF7nUJxCXX8+HGefPJJhg4d mun89G9mFy9eZMGCBbi4uGS67Mcff0y9evV48803KVeuHA4ODmzevJnDhw+bl6lbty5vvfUWycnJ BAUFsXjxYtq2bZtj25nVlT5E3L59mx07djBo0KBC39adcvrounz58hw+fBgfHx/ztAsXLvDdd98x btw4cxuZDZ24fv06a9asISAgINPlqlWrhq2tLeHh4dkOnUhISGDr1q3m0Hn69Gm6detmscxPP/2E t7c3kLvX7vTp0wwePNj8+OzZsxa91JD6z0qdOnWy3Dfp3bx5M0Og/+mnn2jevDmQerw1a9YsV22l yWzoRHbH953uh/2W0/EHqUH8s88+Y8KECcydO5ezZ89SrVq1XNV88eJFi/Cbts07j9f0Q5hy2k95 +TsiInKv05jiEiqrcJYm/ZtZnTp1+Prrrzl37hy3bt3izJkzBAYGEhkZCaT2MNWoUQNXV1fOnz/P 2rVrWb58ufmj48mTJ7N//37i4uK4ePEix44do0qVKrlq+06urq7s3LmT2NhY/vrrL/73v/8RGxtr HnZQmNvKbJ/lNJ5z9erVBAcHc+PGDYKCgnj//ffx8/OjevXqGdpITEzk/PnzbNmyhXfeeYd+/fqZ e9gy21bHjh3ZuXNnhnnpe9527txJrVq1qF69OtevXycmJoY1a9YQFhbGzZs32bhxI4cOHaJPnz65 eu0gNTBGRUWZH2d2ia3MxnpnpUGDBqxatYrIyEgiIyNZvnw5+/fv51//+pe5pvQ9/7lx5/Gc0/EN 999+y+n4u3TpEh999BHDhw+nXr16DBo0iG+//ZakpKRc1ZzZfs9sm8ePH6du3bq52k95+TsiInKv U09xCXX8+HGL3tU7pX8zGzFiBF9//TXvvfceiYmJeHp60qtXLypUqADA0KFDWblyJXPnzqVKlSp0 6tSJmjVrmnvFunXrxqpVq5g9ezY1atSgcePG9O/fP1dt3+nZZ59l1apVrF+/nlq1auHn58eff/5p fjMvzG3ldZ/17NmTpKQk5s+fT2RkJOXKlWPEiBEWV404fvw4u3fvZtasWZQuXZpKlSrh4eFBQEAA 7u7u2W6rVatWrFu3jsjISF588cUM2zeZTHz33XfmMZunT5+mYcOG+Pj4MH36dOLj4/Hy8mLs2LHY 2dkBOb92AH5+fnz66adcunSJsWPHZhruTp48yQsvvJCr/fjCCy/wxRdfMHr0aFxdXWnUqBGTJk3C yckJSO1RzE8oTr+/cnqt0rtf9lv6Yye94cOH06JFCz788EN8fX3NvbQ+Pj58//33/Pjjj3Tt2jXH mjPb78ePH+c///lPpjXnZj/l5e+IiMi9zrBx40bT0qVLSUlJAWDZsmXm8WPBoWF41/csxvJKuLRx err16H3n4sWLjB8/ntmzZ+Po6HhXtvnHH3+wZs0apk6dCsDKlStJSkqyOKFNMtJ+y58Su5/0d1dE sMy4JpOJAQMGaPiESH488MADeHl58d133921bW7cuJGnnnrK/Pj06dM53r1NtN/yS/tJRKyNhk+I 5NPdvtTUpEmTLB6fPn06w0ffkpH2W/5oP4mItVEoFrlPBQYGFncJ9yXtt9wpzv1kMpkwmUzmazOL iNwNGj4hIiL3lOTkZEJCQoiJiTGf7yIiUtQUikUK0Y0bN/D39y/uMkTua7dv38bb25uDBw8SGRmp YCwid4VCsUghCgsLy3BZLhHJm7QQXK9ePY4cOcK1a9cUjEWkyCkUl2B33m5Vil5m16q934SGhjJ8 +HCSk5OLu5RMTZ48mb1792aYnla3v79/ljeMWLlyJTNmzODq1av4+vqyYsWKDMskJycTEBDASy+9 lGMt+h0rWk8++SReXl4EBwdz/fp1BWMRKVLG6JjY4q5BpMQoCaF4w4YNdO/eHRsbm+IuJVNnzpyx uLNcmrS669Spw/nz5zPMP3/+PD/88AP+/v7mO7kFBwdnWG7+/PkAOd5yWYreiRMn6N27N61ateKP P/7gxo0bCsYiUmRs7exLFXcNcpdcvXqVLVu2cPDgQS5dukTDhg3p3bs3derUITo6mhUrVnDgwAGi o6Np0KABL7zwAuXLlycmJoaXX36Z4cOHs2bNGmJjY7l16xZTpkyhfPny5vaPHz/OzJkzmTFjBo6O jgCpmx0AAAwaSURBVHluc86cORb1Zrc+wI4dO/jpp5+YNGmS+Qz1NWvWsGvXLiZOnIjRaOS1114j KiqKcuXK4eXlRbdu3ahRo4Z5+2PHjmXFihWcPn2asmXL4ufnR6NGjfj6668JCQnB1dUVX19fWrRo wfXr1xk9ejQvv/wya9eu5dy5c7i7uzNixAg8PT2B1FDco0ePXNV/p6ioKL755hsOHTpESkoK/fr1 o2PHjgDEx8ezZMkSDh06RFRUFI0aNeL555+nXLly+Xouae7sLb148SJHjx5l5MiRBdr/o0aNYuLE idnuq9w8p/THx5QpUxgyZAiAuRfX39+fLl26WNR98+ZNzp07Z77zG6R+HP/ZZ5/xzDPPULZsWY4f P07Hjh1ZuXIlN27cwNXVFUi9prGtrS3Vq1enUqVKOf7eSNFKTEzk8OHDDBgwgOXLl7N9+3batWtH mTJlMBr1QaeIFC79VbEin3zyCUajkddff51Zs2bh4+PD2rVrSUxMZNKkSaSkpPDGG28wY8YM3Nzc +Pzzz4HUoBQXF8fq1avp2rUrU6ZMwdPTk7CwMHPbycnJBAYG8u9//xtHR8d8tZleTusDPP7446Sk pPDjjz8CsHXrVnbs2MG7776Li4sLv//+O4MGDSIwMJAPP/yQSpUqmYP3xYsXSUxMZMWKFXTr1o2Z M2fSsmVLAgMD+fjjj2nQoAFTp06lbdu2LF26FEi9buvt27fZuXMnw4YNY+bMmdSrV4/169cDkJSU REREBNWqVctV/endvn2bgIAAPDw8mDp1KhMnTiQ0NBRIDdf/196dxjSVtXEA/xdBwQKVxC0uLEp1 9MPoGIMaNRNnJBLyqomTkRBxIyiCX0SJGx+IhrgSJ5mdcYkBiRaxkkFGjcboTEbjUiGMTmDUUre0 KiAUAliW5/3A25sWqDBQgdf+fwkxnOM99zmH3punp6fnpqWlwd/fH7t370ZmZiY0Gg1+/PHHXvfF lQsXLuDLL7/EkCFD+jT+b968ee9Y9aRPHV8farUaaWlp+PTTT5GXl4e8vDwsWbLEKW5fX19MmjQJ z549c+pXUVERhg8fjkWLFgFofwMXHh6O2bNno6SkBABgMBhw//59rFu3TplJBlxfN/ThNTc3o7m5 GaWlpYiPj8fixYtx48YN1NXVQfhEOiJyt7PnCiQ2NlZiYmIkJiZG2traxO5+WYXQB9T+oNF+O11S UpLk5+eL2Wx2+jufPn1aDh065PR/a2trJS4uTkREfv/9d4mLi5PXr18r9adOnZL8/Hzl9/Pnz8uB Awf61Kaj7o63Ky8vl3Xr1klRUZFs2rTJZXsiIm1tbbJ27Vrl/AkJCVJfX6/U19TUyNdffy3FxcVK WXV1taxZs0ZERPLy8mTnzp1OY1dVVSXr168XERGTySQpKSn/Kn677Oxsyc7O7rLuxIkTkpub61RW XV0tq1ev7nVfulJbWytr166V6urqPo9/d2PVkz519fo4d+5cp+Mc4xYRsVgskpqaqtSbzWaJj49X 2rLZbBIfHy9tbW3y4MEDOXLkiJhMJtm6davU1tZKU1OTxMXFSXNzs4i4vm7ow7FarSIiAkDUarWM GTNGwsPDZf369dLY2Ch6vV5qa2t79/fo5/suEQ1OjjluW1ubxMTECB/e4UFSUlKg1+tRWFgIPz8/ rFq1CgsWLEBxcTEqKio6fWlIrVYDACwWCyIjIzFq1CilLjQ0FLdu3QIAvH79GhcuXHCa7e1Nm466 O96uvr4eNpsN2dnZyMzMVNprbGxEQUEB7t69i6qqKjQ2NgKAUm+xWLB48WKn9l68eAGtVouZM2cq Zc+fP1c+7jcajYiKinJ6mEBTU5PSpuN64p7Gb1daWoqUlJQu6wwGA9LT053KbDabsoyhN33pyuXL lxEREYGgoKA+j393Y9WTPnX1+njy5AkWLlzoMm4AGD16NGpqatDa2govLy9kZWVhxYoVSlsVFRUI Dg6GSqXCtGnT8PPPP+Obb77Bli1bEBgYiL///hshISHw9m6/Pbq6bqh/2Gw2Zcb4zp072L59Ow4f PoyioiJERkbC39+fD/ggIrdgUuxBtFotduzYgdbWVty8eRM5OTlYsGABzGYzjh8/joCAgC6PM5vN mDFjhlNZaGio8lH8sWPHsHz5cowcOdLpmH/bZsf69x0PtCdIP/30E9LT0/HDDz/g6dOnmDBhAgDg yJEjmDJlCrZv346goCAMGzYMFy9exMOHD5X2HRNGoP0j9alTpzqVPXr0CFqtFkB7ohcdHe1Uf/Xq VWXtqmNS3JP4HVksFvj5+XVZZ7ValQTN8byzZs3qdV86stlsuHz5spKo9nX8uxurnvSpq9eH0WjE mjVrXMYNACqVChMmTFDWGdtsNqdY7EsnAMDLywvTpk3DjBkzlDcM5eXlTl+yc3XdUP+wJ8T25PjP P/9Eeno69uzZg99++w2RkZFQq9VMjImoz7im2EPs378fBoMBDQ0NMJvNKCsrw7hx4wAA4eHhyM7O xrNnz9DU1ISKigpkZWUp21pZLBaMHTvWqb1x48bBarXiypUrePv2bacEqDdtOs5Kdnf8q1evcOjQ ISQnJ2PKlClYvXo1zpw5g5aWFqX9kJAQaDQaPH/+HOfPn4dOp1N2Lejq/I7rSB3LtFot3r59i/r6 euj1ephMJlitVhQWFuLBgwf46quvADgnxd3F37G/ISEh0Ov1qKqqwsuXL3Hq1Cml7pNPPkF+fj4q KytRWVkJnU4Hg8GA5cuX96ovXZ3/+vXrmDRpEiZOnNjn8e/JWPWmT0B7ElxTU+MybrvQ0FCUlJRA p9MhKSnJKWH6559/MHnyZOX35ORkzJ8/v8uxe991Q/3HnhDb//3jjz9w+PBhREdH4+rVq2hoaOAa YyLqMybFHiI6OhoFBQVISkrCL7/8Ao1Gg61btwIANm/eDJvNhr179yIxMREnT55ERESEMvNrNps7 JSgqlQrBwcE4efIkNmzY0Gn7rt602dPj6+rqsG/fPqxcuVKZeZw9ezZGjRqlfOkrPj4eBQUF2LRp E44fPw6NRoOwsDCEhYW5PH/HpBEAHj9+DK1WC6PRiOnTp2Pu3LnIzMxESkoKTCYT0tLS4OPjA8A5 Ke6u/x0lJyejpaUFu3btwrfffos5c+YodYmJiaisrMS2bduwd+9e1NTUICMjA4GBgb3qS0cigqKi Iixbtswt49+TsepNnwAgJiYG33//PVauXImSkpJOcduFhYUhNzcXUVFRyuy149i8b+cIxxn19103 1H/ss8WOs8bXrl3Dd999h6ioKFy7dg2NjY1MjImoT1RnzxWIPl+n7P14+vRpZValuNyEz6aGDmB4 Hzn77BVv5IPe2bNn0dLSgtjY2IEOxe1u374NvV6PgwcPuqW9/hord8dNg0ddXR0CAgKcZvj9/Pyg 0Whw48YN5c2nSqWCj48PWltbcf36dXz++efKGy+XeN8lIjjnuCKC2NhYrikm6gmj0ahs5/WxKSws xNKlS93WXn+NlbvjpsFr7NixWLJkCX799Vfk5uYiMTEROp0OAQEB8Pb2xtChQxEWFoaWlpbuk2Ii IheYFBP1gNFoREJCwkCH8UFkZGS4tb3+Git3x02D0/jx43Hr1i2MGDECly5dQk5ODlJTUxEUFIQv vvhCmVH28fHBsGHDBjpcIvo/xjXFRD2QlZXl8kl05IxjRe4yceJE3L59G2VlZXj16hU2btwIq9WK o0ePYt68eRARaDQajBgxAmq1mk+5I6I+4R2EiIgGpTt37qC0tBQNDQ14+PAhUlNT4e3tjaNHjyI4 OBgGg0HZg5yIqK+YFBMR0aB07949iAjmzZuHRYsWoaqqCgkJCaisrMRff/2Fd+/ecdcJInIbrike DLjpPBGRwv7ImP90KA8EkPG/H8yZg4j+DIqIPnqcKSYiIiIij8eZ4oHEj/yIiDoREYgIVCqV017F IoJ3796hvr4eKpUK/v7+GDp0KB/xTERuwaSYiIgGlY7JsGO5r68vfH19ByAqIvrYcfkEEREREXk8 JsVERERE5PGYFBMRERGRx2NSTEREREQej0kxEREREXk8JsVERERE5PGYFBMRERGRx2NSTEREREQe z6vZ1jTQMRARERERDSivAH/1QMdARERERDSg/gsNiJPW5jwHUAAAAABJRU5ErkJggg== --=_d3dc9ed8-f78b-4619-8697-13e954cbc408--
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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".
...
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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". > ...
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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". > > > ...
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message ----- > From: "Einav Cohen" <ecohen@redhat.com> > To: "Andrew Cathrow" <acathrow@redhat.com> > Cc: engine-devel@ovirt.org, "Simon Grinberg" > <sgrinber@redhat.com>, > "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert > Jansen" <gjansen@redhat.com>, "Ori Liel" > <oliel@redhat.com>, > "Yair > Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" > <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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". > > > > > ... >
On 05/11/2012 11:28 PM, Einav Cohen wrote:
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
> > > ----- Original Message ----- >> From: "Einav Cohen" <ecohen@redhat.com> >> To: "Andrew Cathrow" <acathrow@redhat.com> >> Cc: engine-devel@ovirt.org, "Simon Grinberg" >> <sgrinber@redhat.com>, >> "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert >> Jansen" <gjansen@redhat.com>, "Ori Liel" >> <oliel@redhat.com>, >> "Yair >> Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" >> <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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/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". >>>> >>> ... >> >
[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. ---- Thanks, Einav ----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Ayal Baron" <abaron@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@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" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
> ----- Original Message ----- > From: "Ayal Baron" <abaron@redhat.com> > Sent: Thursday, May 10, 2012 10:46:44 PM > >> >> >> ----- Original Message ----- >>> From: "Einav Cohen" <ecohen@redhat.com> >>> To: "Andrew Cathrow" <acathrow@redhat.com> >>> Cc: engine-devel@ovirt.org, "Simon Grinberg" >>> <sgrinber@redhat.com>, >>> "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert >>> Jansen" <gjansen@redhat.com>, "Ori Liel" >>> <oliel@redhat.com>, >>> "Yair >>> Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" >>> <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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/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". >>>>> >>>> ... >>> >> >
This is a multi-part message in MIME format. --------------050403090704050006090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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"<yzaslavs@redhat.com> To: "Einav Cohen"<ecohen@redhat.com> Cc: "Ayal Baron"<abaron@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg"<sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen"<gjansen@redhat.com>, "Ori Liel"<oliel@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow"<acathrow@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"<abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron"<abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message ----- >> ----- Original Message ----- >> From: "Ayal Baron"<abaron@redhat.com> >> Sent: Thursday, May 10, 2012 10:46:44 PM >> >>> >>> ----- Original Message ----- >>>> From: "Einav Cohen"<ecohen@redhat.com> >>>> To: "Andrew Cathrow"<acathrow@redhat.com> >>>> Cc: engine-devel@ovirt.org, "Simon Grinberg" >>>> <sgrinber@redhat.com>, >>>> "Saggi Mizrahi"<smizrahi@redhat.com>, "Geert >>>> Jansen"<gjansen@redhat.com>, "Ori Liel" >>>> <oliel@redhat.com>, >>>> "Yair >>>> Zaslavsky"<yzaslavs@redhat.com>, "Ayal Baron" >>>> <abaron@redhat.com>, "Miki Kenneth"<mkenneth@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/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
--------------050403090704050006090708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 05/13/2012 11:54 AM, Einav Cohen wrote: <blockquote cite="mid:7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com" type="cite"> <pre wrap="">[top posting] GUI Mockup has been updated according to this thread: <a class="moz-txt-link-freetext" href="http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI">http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI</a> Further comments are welcome.</pre> </blockquote> <br> - POSIX, not Posix.<br> - 'POSIX compliant FS', not 'PosixFS' <br> - I'd be happy if we could validate whatever we pass to the mount command against command injection[1] .<br> <br> Y.<br> [1] <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://www.owasp.org/index.php/Command_Injection">https://www.owasp.org/index.php/Command_Injection</a><br> <br> <blockquote cite="mid:7ed17043-96e5-4151-a32c-6ddb8e68d990@zmail04.collab.prod.int.phx2.redhat.com" type="cite"> <pre wrap=""> ---- Thanks, Einav ----- Original Message ----- </pre> <blockquote type="cite"> <pre wrap="">From: "Yair Zaslavsky" <a class="moz-txt-link-rfc2396E" href="mailto:yzaslavs@redhat.com"><yzaslavs@redhat.com></a> To: "Einav Cohen" <a class="moz-txt-link-rfc2396E" href="mailto:ecohen@redhat.com"><ecohen@redhat.com></a> Cc: "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a>, <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>, "Simon Grinberg" <a class="moz-txt-link-rfc2396E" href="mailto:sgrinber@redhat.com"><sgrinber@redhat.com></a>, "Saggi Mizrahi" <a class="moz-txt-link-rfc2396E" href="mailto:smizrahi@redhat.com"><smizrahi@redhat.com></a>, "Geert Jansen" <a class="moz-txt-link-rfc2396E" href="mailto:gjansen@redhat.com"><gjansen@redhat.com></a>, "Ori Liel" <a class="moz-txt-link-rfc2396E" href="mailto:oliel@redhat.com"><oliel@redhat.com></a>, "Miki Kenneth" <a class="moz-txt-link-rfc2396E" href="mailto:mkenneth@redhat.com"><mkenneth@redhat.com></a>, "Andrew Cathrow" <a class="moz-txt-link-rfc2396E" href="mailto:acathrow@redhat.com"><acathrow@redhat.com></a> 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: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">----- Original Message ----- From: "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a> Sent: Friday, May 11, 2012 11:03:04 PM ----- Original Message ----- </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">----- Original Message ----- From: "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a> Sent: Friday, May 11, 2012 11:39:42 AM ----- Original Message ----- </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">----- Original Message ----- From: "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a> Sent: Thursday, May 10, 2012 10:46:44 PM </pre> <blockquote type="cite"> <pre wrap=""> ----- Original Message ----- </pre> <blockquote type="cite"> <pre wrap="">From: "Einav Cohen" <a class="moz-txt-link-rfc2396E" href="mailto:ecohen@redhat.com"><ecohen@redhat.com></a> To: "Andrew Cathrow" <a class="moz-txt-link-rfc2396E" href="mailto:acathrow@redhat.com"><acathrow@redhat.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>, "Simon Grinberg" <a class="moz-txt-link-rfc2396E" href="mailto:sgrinber@redhat.com"><sgrinber@redhat.com></a>, "Saggi Mizrahi" <a class="moz-txt-link-rfc2396E" href="mailto:smizrahi@redhat.com"><smizrahi@redhat.com></a>, "Geert Jansen" <a class="moz-txt-link-rfc2396E" href="mailto:gjansen@redhat.com"><gjansen@redhat.com></a>, "Ori Liel" <a class="moz-txt-link-rfc2396E" href="mailto:oliel@redhat.com"><oliel@redhat.com></a>, "Yair Zaslavsky" <a class="moz-txt-link-rfc2396E" href="mailto:yzaslavs@redhat.com"><yzaslavs@redhat.com></a>, "Ayal Baron" <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a>, "Miki Kenneth" <a class="moz-txt-link-rfc2396E" href="mailto:mkenneth@redhat.com"><mkenneth@redhat.com></a> Sent: Thursday, May 10, 2012 2:05:55 PM Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated </pre> <blockquote type="cite"> <pre wrap="">... 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. </pre> </blockquote> <pre wrap=""> 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)? </pre> </blockquote> <pre wrap=""> I am , does everyone else agree. </pre> </blockquote> <pre wrap=""> either 'path' or 'device' </pre> </blockquote> <pre wrap=""> - "Path" it is. </pre> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> <pre wrap="">+1 on "path" and this was my original implementation by the way. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">- 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? </pre> </blockquote> <pre wrap=""> i.e. "Path to device to mount / remote export" or something? </pre> </blockquote> <pre wrap=""> 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? </pre> </blockquote> <pre wrap=""> 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). </pre> </blockquote> <pre wrap=""> 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? </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">- What should be the exact phrasing of the explanation text? </pre> <blockquote type="cite"> <pre wrap="">"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. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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". </pre> </blockquote> <pre wrap="">... </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap=""> </pre> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> <pre wrap="">_______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <br> </body> </html> --------------050403090704050006090708--
----- Original Message ----- From: "Yaniv Kaul" <ykaul@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" <yzaslavs@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Ayal Baron" <abaron@redhat.com> , engine-devel@ovirt.org , "Simon Grinberg" <sgrinber@redhat.com> , "Saggi Mizrahi" <smizrahi@redhat.com> , "Geert Jansen" <gjansen@redhat.com> , "Ori Liel" <oliel@redhat.com> , "Miki Kenneth" <mkenneth@redhat.com> , "Andrew Cathrow" <acathrow@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" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
----- Original Message ----- From: "Ayal Baron" <abaron@redhat.com> Sent: Thursday, May 10, 2012 10:46:44 PM
----- Original Message -----
From: "Einav Cohen" <ecohen@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: engine-devel@ovirt.org , "Simon Grinberg" <sgrinber@redhat.com> , "Saggi Mizrahi" <smizrahi@redhat.com> , "Geert Jansen" <gjansen@redhat.com> , "Ori Liel" <oliel@redhat.com> , "Yair Zaslavsky" <yzaslavs@redhat.com> , "Ayal Baron" <abaron@redhat.com> , "Miki Kenneth" <mkenneth@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/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
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" <yzaslavs@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Ayal Baron" <abaron@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@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" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
> ----- Original Message ----- > From: "Ayal Baron" <abaron@redhat.com> > Sent: Friday, May 11, 2012 11:39:42 AM > > > ----- Original Message ----- >>> ----- Original Message ----- >>> From: "Ayal Baron" <abaron@redhat.com> >>> Sent: Thursday, May 10, 2012 10:46:44 PM >>> >>>> >>>> ----- Original Message ----- >>>>> From: "Einav Cohen" <ecohen@redhat.com> >>>>> To: "Andrew Cathrow" <acathrow@redhat.com> >>>>> Cc: engine-devel@ovirt.org, "Simon Grinberg" >>>>> <sgrinber@redhat.com>, >>>>> "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert >>>>> Jansen" <gjansen@redhat.com>, "Ori Liel" >>>>> <oliel@redhat.com>, >>>>> "Yair >>>>> Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" >>>>> <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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
On 05/13/2012 02:04 PM, Yaniv Kaul wrote: 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 >>>>>>> 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
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> Sent: Sunday, May 13, 2012 4:51:31 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' - 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" <yzaslavs@redhat.com> To: "Einav Cohen" <ecohen@redhat.com> Cc: "Ayal Baron" <abaron@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert Jansen" <gjansen@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Andrew Cathrow" <acathrow@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" <abaron@redhat.com> Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message ----- >> ----- Original Message ----- >> From: "Ayal Baron" <abaron@redhat.com> >> Sent: Friday, May 11, 2012 11:39:42 AM >> >> >> ----- Original Message ----- >>>> ----- Original Message ----- >>>> From: "Ayal Baron" <abaron@redhat.com> >>>> Sent: Thursday, May 10, 2012 10:46:44 PM >>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Einav Cohen" <ecohen@redhat.com> >>>>>> To: "Andrew Cathrow" <acathrow@redhat.com> >>>>>> Cc: engine-devel@ovirt.org, "Simon Grinberg" >>>>>> <sgrinber@redhat.com>, >>>>>> "Saggi Mizrahi" <smizrahi@redhat.com>, "Geert >>>>>> Jansen" <gjansen@redhat.com>, "Ori Liel" >>>>>> <oliel@redhat.com>, >>>>>> "Yair >>>>>> Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" >>>>>> <abaron@redhat.com>, "Miki Kenneth" <mkenneth@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
On 05/13/2012 02:04 PM, Yaniv Kaul wrote: 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?
+1 It is more compliant with the already-existing NFS storage domain representation in rest-api (that also uses "address" and "path" in the same manner). This is, of course, assuming that we can enforce "address" as mandatory for NFS storage domain and treat it as optional for POSIX storage domain. Geert/Ori/Michael - any thoughts about 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 >>>>>>>> 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
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. Regards, Geert
----- Original Message -----
From: "Geert Jansen" <gjansen@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: "Andrew Cathrow" <acathrow@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Einav Cohen" <ecohen@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
Regards, Geert
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Friday, May 11, 2012 5:15:51 PM
----- Original Message -----
From: "Geert Jansen" <gjansen@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: "Andrew Cathrow" <acathrow@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Einav Cohen" <ecohen@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).
Regards, Geert
----- Original Message -----
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Friday, May 11, 2012 5:15:51 PM
----- Original Message -----
From: "Geert Jansen" <gjansen@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: "Andrew Cathrow" <acathrow@redhat.com>, engine-devel@ovirt.org, "Simon Grinberg" <sgrinber@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Ori Liel" <oliel@redhat.com>, "Yair Zaslavsky" <yzaslavs@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Einav Cohen" <ecohen@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
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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Miki Kenneth" <mkenneth@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@redhat.com>, "Ayal Baron" <abaron@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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.
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
----- Original Message ----- From: "Andrew Cathrow" <acathrow@redhat.com> Sent: Thursday, May 10, 2012 5:16:24 PM
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Miki Kenneth" <mkenneth@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@redhat.com>, "Ayal Baron" <abaron@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
On 05/10/2012 05:16 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Miki Kenneth" <mkenneth@redhat.com> Cc: "Einav Cohen" <ecohen@redhat.com>, "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@redhat.com>, "Ayal Baron" <abaron@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" <ecohen@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com>, "Ayal Baron" <abaron@redhat.com> Cc: "Saggi Mizrahi" <smizrahi@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Miki Kenneth" <mkenneth@redhat.com>, "Simon Grinberg" <sgrinber@redhat.com>, "Eldan Hildesheim" <ehildesh@redhat.com>, "Eldan Hildesheim" <info@eldanet.com>, "Alexey Chub" <achub@redhat.com>, engine-devel@ovirt.org, "Haim Ateya" <hateya@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" <yzaslavs@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
On 05/10/2012 03:28 PM, Einav Cohen wrote:
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?
For generality i am not sure we want to validate this field other than ensuring it contains a non-empty string. Different file systems have different ways in which they specify the block device. Another common form to identify a block device is for example: UUID=<xxxxxxx> Or a file server list: server1:/path,server2:/path Trying to list all possible formats for all possible file systems is IMHO not something that we should try to do. Regards, Geert
participants (8)
-
Andrew Cathrow -
Ayal Baron -
Einav Cohen -
Geert Jansen -
Miki Kenneth -
Saggi Mizrahi -
Yair Zaslavsky -
Yaniv Kaul