----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Simon Grinberg" <sgrinber(a)redhat.com>,
"Saggi Mizrahi" <smizrahi(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>, "Miki Kenneth" <mkenneth(a)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(a)redhat.com>
> Sent: Thursday, May 10, 2012 8:18:58 PM
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Andrew Cathrow" <acathrow(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org, "Simon Grinberg"
> > <sgrinber(a)redhat.com>,
> > "Saggi Mizrahi" <smizrahi(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>
> > 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(a)redhat.com>
> > > Sent: Thursday, May 10, 2012 8:03:16 PM
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Einav Cohen" <ecohen(a)redhat.com>
> > > > To: "Andrew Cathrow" <acathrow(a)redhat.com>
> > > > Cc: engine-devel(a)ovirt.org, "Simon Grinberg"
> > > > <sgrinber(a)redhat.com>,
> > > > "Saggi Mizrahi" <smizrahi(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>
> > > > 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(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.
> > > >
> > >
> > > 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(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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>