> ----- Original Message ----- > From: "Andrew Cathrow" <acath...@redhat.com> > Sent: Thursday, May 10, 2012 6:06:23 PM > > > ----- Original Message ----- > > From: "Einav Cohen" <eco...@redhat.com> > > To: "Andrew Cathrow" <acath...@redhat.com>, "Geert Jansen" > > <gjan...@redhat.com>, "Ori Liel" <ol...@redhat.com>, "Yair > > Zaslavsky" <yzasl...@redhat.com>, "Ayal Baron" <aba...@redhat.com> > > Cc: engine-devel@ovirt.org, "Simon Grinberg" <sgrin...@redhat.com>, > > "Saggi Mizrahi" <smizr...@redhat.com> > > Sent: Thursday, May 10, 2012 10:56:09 AM > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been updated > > > > > ----- Original Message ----- > > > From: "Andrew Cathrow" <acath...@redhat.com> > > > Sent: Thursday, May 10, 2012 4:57:44 PM > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" <eco...@redhat.com> > > > > To: "Saggi Mizrahi" <smizr...@redhat.com>, "Yair Zaslavsky" > > > > <yzasl...@redhat.com> > > > > Cc: "Haim Ateya" <hat...@redhat.com>, "Eldan Hildesheim" > > > > <i...@eldanet.com>, engine-devel@ovirt.org, "Eldan > > > > Hildesheim" <ehild...@redhat.com>, "Simon Grinberg" > > > > <sgrin...@redhat.com> > > > > Sent: Thursday, May 10, 2012 9:51:32 AM > > > > Subject: Re: [Engine-devel] PosixFS: GUI mock-ups have been > > > > updated > > > > > > > > > ----- Original Message ----- > > > > > From: "Saggi Mizrahi" <smizr...@redhat.com> > > > > > Sent: Thursday, May 10, 2012 4:39:49 PM > > > > > > > > > > I do express that empty mount options SHOULD NOT send an > > > > > empty > > > > > string, rather, omit the whole argument. > > > > > > > > Yes, this should be handled on the backend side (Yair - please > > > > note, > > > > maybe it is already implemented like this - don't know): When > > > > getting a null-or-empty "mount options" value from the client, > > > > the > > > > backend needs to make sure to *not* set the relevant parameter > > > > in > > > > the vdsm verb at all. > > > > > > > > So leaving the "mount options" text-box empty in the GUI is > > > > legal, > > > > only needs to be handled in a certain way in the backend. > > > > > > > > > > > > In theory for a PosixFS file system a user could create multiple > > > storage domains of different PosixFS types. Perhaps that's not a > > > problem, but worth noting. > > > > > > Is "Path" the correct term to use for the remote mount? I can > > > imagine > > > customers thinking that is local and messing with fstab. > > > Not sure if there's a better term - filesystem URI ? > > > > - In the initial mock-up, it was called "Mount Spec". Is it better? > > I don't like any of the options - but have a preference for > Filesystem URI, but I'd like others to weigh in here. > My concern with path is that it could mean local or remote, so > another option is "Remote Path"
But it *can* be local or remote, so why "Remote Path"? "Path" actually sounds like a good term. > > > > > > - Note that the current PosixFS implementation in the rest-api > > utilizes the already-existing "<path>" property within the > > "<storage>" tag within the "<storage_domain>" rest-api business > > entity, therefore I put in the mockup the same term. > > Do you think that the rest-api should have a different term as > > well? > > > > > > > > I presume we are doing just not-null validation for path. > > > > > > Obviously we can't validate the mount options but how good is the > > > error reporting back going to be - if the mount options are > > > wrong, > > > or if something fails with the mount will we see "error 12345" in > > > the UI and require the user to go digging in vdsm logs or are we > > > going to pull back and display toe complete message. > > > > Depends on backend/vdsm; Yair/Ayal? > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Einav Cohen" <eco...@redhat.com> > > > > > > To: "Yair Zaslavsky" <yzasl...@redhat.com>, "Ayal Baron" > > > > > > <aba...@redhat.com> > > > > > > Cc: "Saggi Mizrahi" <smizr...@redhat.com>, "Andrew Cathrow" > > > > > > <acath...@redhat.com>, "Miki Kenneth" > > > > > > <mkenn...@redhat.com>, "Simon Grinberg" > > > > > > <sgrin...@redhat.com>, > > > > > > "Eldan Hildesheim" <ehild...@redhat.com>, "Eldan > > > > > > Hildesheim" <i...@eldanet.com>, "Alexey Chub" > > > > > > <ac...@redhat.com>, > > > > > > engine-devel@ovirt.org, "Haim Ateya" > > > > > > <hat...@redhat.com> > > > > > > Sent: Thursday, May 10, 2012 9:28:31 AM > > > > > > Subject: Re: PosixFS: GUI mock-ups have been updated > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Yair Zaslavsky" <yzasl...@redhat.com> > > > > > > > Sent: Thursday, May 10, 2012 4:21:42 PM > > > > > > > > > > > > > > On 05/10/2012 04:16 PM, Einav Cohen wrote: > > > > > > > > Please review the mock-ups on the feature page: > > > > > > > > http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI > > > > > > > > > > > > > > > > Comments are welcome. > > > > > > > > > > > > > > From talking to Haim I understood that path should > > > > > > > include > > > > > > > ":" > > > > > > > > > > > > From talking to Ayal, the path can be similar in its format > > > > > > to > > > > > > a > > > > > > path > > > > > > provided when creating an NFS storage domain (e.g. > > > > > > "server:/dir1/dir2"), *or* to a path provided when creating > > > > > > a > > > > > > Local > > > > > > storage domain (e.g. "/tmp/dir3"), meaning, without ":". > > > > > > @Ayal - any chance for a clarification here? > > > > > > > > > > > > > In addition - if we only support V1, why add the combo > > > > > > > box? > > > > > > > > > > > > We are always showing the combo-box, even if we have only > > > > > > one > > > > > > option > > > > > > in it (so the user will know what is the value that is > > > > > > being > > > > > > sent). > > > > > > However, we disable it. I updated the mock-up to clarify > > > > > > this. > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > ---- > > > > > > > > Thanks, > > > > > > > > Einav > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel@ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel