1:01 p.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Thursday, May 10, 2012 6:06:23 PM
----- Original Message -----
> From: "Einav Cohen" <ecohen(a)redhat.com>
> To: "Andrew Cathrow" <acathrow(a)redhat.com>, "Geert
Jansen"
> <gjansen(a)redhat.com>, "Ori Liel" <oliel(a)redhat.com>,
"Yair
> Zaslavsky" <yzaslavs(a)redhat.com>, "Ayal Baron"
<abaron(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Simon Grinberg" <sgrinber(a)redhat.com>,
> "Saggi Mizrahi" <smizrahi(a)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(a)redhat.com>
> > Sent: Thursday, May 10, 2012 4:57:44 PM
> >
> > ----- Original Message -----
> > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > To: "Saggi Mizrahi" <smizrahi(a)redhat.com>, "Yair
Zaslavsky"
> > > <yzaslavs(a)redhat.com>
> > > Cc: "Haim Ateya" <hateya(a)redhat.com>, "Eldan
Hildesheim"
> > > <info(a)eldanet.com>, engine-devel(a)ovirt.org, "Eldan
> > > Hildesheim" <ehildesh(a)redhat.com>, "Simon Grinberg"
> > > <sgrinber(a)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(a)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(a)redhat.com>
> > > > > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>,
"Ayal Baron"
> > > > > <abaron(a)redhat.com>
> > > > > Cc: "Saggi Mizrahi" <smizrahi(a)redhat.com>,
"Andrew Cathrow"
> > > > > <acathrow(a)redhat.com>, "Miki Kenneth"
> > > > > <mkenneth(a)redhat.com>, "Simon Grinberg"
> > > > > <sgrinber(a)redhat.com>,
> > > > > "Eldan Hildesheim" <ehildesh(a)redhat.com>,
"Eldan
> > > > > Hildesheim" <info(a)eldanet.com>, "Alexey
Chub"
> > > > > <achub(a)redhat.com>,
> > > > > engine-devel(a)ovirt.org, "Haim Ateya"
> > > > > <hateya(a)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(a)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(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> >
> >
>