8:16 a.m.
Please review the mock-ups on the feature page:
http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI
Comments are welcome.
----
Thanks,
Einav
8:21 a.m.
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
8:28 a.m.
----- 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
8:39 a.m.
I do express that empty mount options SHOULD NOT send an empty string, rather, omit the
whole argument.
----- 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
>
>
8:51 a.m.
----- 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.
----- 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
8:57 a.m.
----- 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 ?
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(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
9:56 a.m.
----- 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?
- 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
10:06 a.m.
----- 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"
- 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
>
>
>
12: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
> >
> >
> >
>
12:03 p.m.
----- 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?
>
>
> >
> > - 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
> > >
> > >
> > >
> >
>
12:12 p.m.
----- 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.
> >
> >
> > >
> > > - 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
> > > >
> > > >
> > > >
> > >
> >
>
12:18 p.m.
----- 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.
> > >
> > >
> > > >
> > > > - 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
12:42 p.m.
----- 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.
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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
12:57 p.m.
----- 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
1:05 p.m.
...
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".
>
...
1:15 p.m.
----- 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 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".
> >
> ...
2:46 p.m.
----- Original Message -----
----- 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 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".
> > >
> > ...
>
2 a.m.
--=_d3dc9ed8-f78b-4619-8697-13e954cbc408
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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--
3:39 a.m.
----- Original Message -----
> ----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
> > > > >
> > > > ...
> > >
> >
>
6:14 a.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
Sent: Friday, May 11, 2012 11:39:42 AM
----- Original Message -----
> > ----- Original Message -----
> > From: "Ayal Baron" <abaron(a)redhat.com>
> > Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
> > > > > >
> > > > > ...
> > > >
> > >
> >
>
3:03 p.m.
----- Original Message -----
> ----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> Sent: Friday, May 11, 2012 11:39:42 AM
>
>
> ----- Original Message -----
> > > ----- Original Message -----
> > > From: "Ayal Baron" <abaron(a)redhat.com>
> > > Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
> > > > > > >
> > > > > > ...
> > > > >
> > > >
> > >
> >
>
3:28 p.m.
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com>
Sent: Friday, May 11, 2012 11:03:04 PM
----- Original Message -----
> > ----- Original Message -----
> > From: "Ayal Baron" <abaron(a)redhat.com>
> > Sent: Friday, May 11, 2012 11:39:42 AM
> >
> >
> > ----- Original Message -----
> > > > ----- Original Message -----
> > > > From: "Ayal Baron" <abaron(a)redhat.com>
> > > > Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
> > > > > > > >
> > > > > > > ...
> > > > > >
> > > > >
> > > >
> > >
> >
>
2:05 a.m.
On 05/11/2012 11:28 PM, Einav Cohen wrote:
> ----- Original Message -----
> From: "Ayal Baron" <abaron(a)redhat.com>
> Sent: Friday, May 11, 2012 11:03:04 PM
>
>
> ----- Original Message -----
>>> ----- Original Message -----
>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>> Sent: Friday, May 11, 2012 11:39:42 AM
>>>
>>>
>>> ----- Original Message -----
>>>>> ----- Original Message -----
>>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>>> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
>>>>>>>>>
>>>>>>>> ...
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
3:54 a.m.
[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(a)redhat.com>
To: "Einav Cohen" <ecohen(a)redhat.com>
Cc: "Ayal Baron" <abaron(a)redhat.com>, 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>, "Miki Kenneth"
<mkenneth(a)redhat.com>, "Andrew Cathrow" <acathrow(a)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(a)redhat.com>
>> Sent: Friday, May 11, 2012 11:03:04 PM
>>
>>
>> ----- Original Message -----
>>>> ----- Original Message -----
>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>> Sent: Friday, May 11, 2012 11:39:42 AM
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>> ----- Original Message -----
>>>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>>>> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki Kenneth"
<mkenneth(a)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".
>>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
6:04 a.m.
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(a)redhat.com>
> To: "Einav Cohen"<ecohen(a)redhat.com>
> Cc: "Ayal Baron"<abaron(a)redhat.com>, 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>, "Miki Kenneth"
> <mkenneth(a)redhat.com>, "Andrew Cathrow"<acathrow(a)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(a)redhat.com>
>>> Sent: Friday, May 11, 2012 11:03:04 PM
>>>
>>>
>>> ----- Original Message -----
>>>>> ----- Original Message -----
>>>>> From: "Ayal Baron"<abaron(a)redhat.com>
>>>>> Sent: Friday, May 11, 2012 11:39:42 AM
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>> ----- Original Message -----
>>>>>>> From: "Ayal Baron"<abaron(a)redhat.com>
>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki
Kenneth"<mkenneth(a)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(a)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_i...
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">htt...
<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">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------050403090704050006090708--
6:30 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)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(a)redhat.com> To: "Einav Cohen"
<ecohen(a)redhat.com> Cc: "Ayal Baron" <abaron(a)redhat.com> ,
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> , "Miki
Kenneth" <mkenneth(a)redhat.com> , "Andrew Cathrow"
<acathrow(a)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(a)redhat.com> Sent: Friday, May 11, 2012
11:03:04 PM
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com> Sent: Friday, May 11, 2012
11:39:42 AM
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" <abaron(a)redhat.com> Sent: Thursday, May 10, 2012
10:46:44 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> ,
"Miki Kenneth" <mkenneth(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:51 a.m.
On 05/13/2012 02:04 PM, Yaniv Kaul wrote:
On 05/13/2012 11:54 AM, Einav Cohen wrote:
> [top posting]
>
> GUI Mockup has been updated according to this thread:
> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI
>
> Further comments are welcome.
- POSIX, not Posix.
- 'POSIX compliant FS', not 'PosixFS'
- I'd be happy if we could validate whatever we pass to the mount
command against command injection[1] .
Y.
[1] https://www.owasp.org/index.php/Command_Injection
>
> ----
> Thanks,
> Einav
>
> ----- Original Message -----
>> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
>> To: "Einav Cohen" <ecohen(a)redhat.com>
>> Cc: "Ayal Baron" <abaron(a)redhat.com>, 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>, "Miki Kenneth"
>> <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)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(a)redhat.com>
>>>> Sent: Friday, May 11, 2012 11:03:04 PM
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>> ----- Original Message -----
>>>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>>>> Sent: Friday, May 11, 2012 11:39:42 AM
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki
Kenneth" <mkenneth(a)redhat.com>
>>>>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM
>>>>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI mock-ups
have
>>>>>>>>>> been
>>>>>>>>>> updated
>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> The important thing is that it's clear
what it is - eg.
>>>>>>>>>>> the
>>>>>>>>>>> remote/target not the local mount point. That
could be
>>>>>>>>>>> accomplished
>>>>>>>>>>> in the tool tip, etc.
>>>>>>>>>> So if there will be a tool-tip (or similar) in
the GUI
>>>>>>>>>> explaining
>>>>>>>>>> what this field is supposed to be, are you OK
with
>>>>>>>>>> keeping
>>>>>>>>>> the
>>>>>>>>>> term
>>>>>>>>>> "Path" (in both GUI and rest-api)?
>>>>>>>>> I am , does everyone else agree.
>>>>>>>> either 'path' or 'device'
>>>>>>> - "Path" it is.
>> +1 on "path" and this was my original implementation by the way.
Now that I think of it - maybe we can have "Address" as optional
argument AND "Path" as mandatory at REST-API?
Examples -
address: 10.35.16.36
path: /export/share1
Will be translated to mountSpec of "10.35.16.36:/export/share1"
path: /home/someuser/domain1
Will be translated to mounSpec of "/home/some/user/domain1".
Thoughts on this?
>>
>>
>>>>>>> - Instead of a tool-tip, I suggest to use an explanation
>>>>>>> caption
>>>>>>> below the text-box (similar to what we have for NFS storage
>>>>>>> domain
>>>>>>> -
>>>>>>> see attached). Agreed?
>>>>>> i.e. "Path to device to mount / remote export" or
something?
>>>>> Yes, that's a good answer to the question afterwards :)
>>>>> But what do you think about the general idea of using an
>>>>> explanation
>>>>> caption below the "Path" text-box (instead of a tool-tip
that was
>>>>> suggested here earlier)?
>>>>>
>>>>> Also, do you think that the above should be the exact phrasing?
>>>>> The
>>>>> NFS one is:
>>>>> "Please use 'FQDN:/path' or 'IP:/path'
Example
>>>>> 'server.example.com:/export/VMs'"
>>>>> so maybe a "Please use" should be incorporated in this case
as
>>>>> well,
>>>>> maybe also an example, etc.
>>>>> What do you think?
>>>> I replied after viewing the other message and disliking it
>>>> (personal
>>>> opinion). I prefer a static explanation (what the field is)
>>>> rather
>>>> than an action request.
>>>> So in the NFS example I would've phrased it as "Remote path to
NFS
>>>> export, takes either the form: FQDN:/path or IP:/path, e.g.
>>>> server.example.com:/export/VMs".
>>>> But in any event it is better to have consistency (so both
>>>> messages
>>>> should probably be phrased similarly).
>>> There is no problem changing the phrasing for NFS.
>>>
>>> So for NFS, the caption will be:
>>> "Remote path to NFS export, takes either the form: FQDN:/path or
>>> IP:/path, e.g. server.example.com:/export/VMs".
>>>
>>> And for PosixFS, the caption will be:
>>> "Path to device to mount / remote export".
>>> (no 'takes the form' or example provided)
>>>
>>> Agreed?
>>>
>>>>>>
>>>>>>> - What should be the exact phrasing of the explanation text?
>>>>>>>
>>>>>>>> "mount [-fnrsvw] [-t vfstype] [-o options] device
dir"
>>>>>>>>
>>>>>>>> device is what is being mounted and in the case of NFS
is
>>>>>>>> server:path
>>>>>>>>
>>>>>>>> There is a reason why we termed it PosixFS and not
SharedFS
>>>>>>>> and
>>>>>>>> that
>>>>>>>> users can specify local devices/FS's (and there is no
reason
>>>>>>>> to
>>>>>>>> limit it).
>>>>>>>>
>>>>>>>> Note that if user defines a local FS and adds 2 hosts to
the
>>>>>>>> Posix
>>>>>>>> FS
>>>>>>>> DC then 1 host will be non-op
>>>>>>>>
>>>>>>>> Miki - this is not cluster level seeing as PosixFS is a
DC
>>>>>>>> type
>>>>>>>> (afaik) so no need for tooltips about that.
>>>>>>>>
>>>>>>>> In the future when we get rid of the single storage type
in
>>>>>>>> DC
>>>>>>>> limitation then we'll be able to define a local
posixFS
>>>>>>>> domain
>>>>>>>> and
>>>>>>>> a
>>>>>>>> shared one.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>
Andrew/Geert/Simon/Ayal/Miki/Saggi/others: Please
>>>>>>>>>>>> feel
>>>>>>>>>>>> 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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
9:13 a.m.
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
Sent: Sunday, May 13, 2012 4:51:31 PM
On 05/13/2012 02:04 PM, Yaniv Kaul wrote:
> On 05/13/2012 11:54 AM, Einav Cohen wrote:
>> [top posting]
>>
>> GUI Mockup has been updated according to this thread:
>> http://www.ovirt.org/wiki/Features/PosixFSConnection#Changes_in_GUI
>>
>> Further comments are welcome.
>
> - POSIX, not Posix.
> - 'POSIX compliant FS', not 'PosixFS'
> - I'd be happy if we could validate whatever we pass to the mount
> command against command injection[1] .
>
> Y.
> [1] https://www.owasp.org/index.php/Command_Injection
>
>>
>> ----
>> Thanks,
>> Einav
>>
>> ----- Original Message -----
>>> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>> Cc: "Ayal Baron" <abaron(a)redhat.com>,
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>, "Miki Kenneth"
>>> <mkenneth(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)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(a)redhat.com>
>>>>> Sent: Friday, May 11, 2012 11:03:04 PM
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>> ----- Original Message -----
>>>>>>> From: "Ayal Baron" <abaron(a)redhat.com>
>>>>>>> Sent: Friday, May 11, 2012 11:39:42 AM
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Ayal Baron"
<abaron(a)redhat.com>
>>>>>>>>> Sent: Thursday, May 10, 2012 10:46:44 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>, "Miki
Kenneth" <mkenneth(a)redhat.com>
>>>>>>>>>>> Sent: Thursday, May 10, 2012 2:05:55 PM
>>>>>>>>>>> Subject: Re: [Engine-devel] PosixFS: GUI
mock-ups have
>>>>>>>>>>> been
>>>>>>>>>>> updated
>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> The important thing is that it's
clear what it is - eg.
>>>>>>>>>>>> the
>>>>>>>>>>>> remote/target not the local mount point.
That could be
>>>>>>>>>>>> accomplished
>>>>>>>>>>>> in the tool tip, etc.
>>>>>>>>>>> So if there will be a tool-tip (or similar)
in the GUI
>>>>>>>>>>> explaining
>>>>>>>>>>> what this field is supposed to be, are you
OK with
>>>>>>>>>>> keeping
>>>>>>>>>>> the
>>>>>>>>>>> term
>>>>>>>>>>> "Path" (in both GUI and
rest-api)?
>>>>>>>>>> I am , does everyone else agree.
>>>>>>>>> either 'path' or 'device'
>>>>>>>> - "Path" it is.
>>> +1 on "path" and this was my original implementation by the way.
Now that I think of it - maybe we can have "Address" as optional
argument AND "Path" as mandatory at REST-API?
Examples -
address: 10.35.16.36
path: /export/share1
Will be translated to mountSpec of "10.35.16.36:/export/share1"
path: /home/someuser/domain1
Will be translated to mounSpec of "/home/some/user/domain1".
Thoughts on this?
+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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
9:10 a.m.
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
9:15 a.m.
----- Original Message -----
From: "Geert Jansen" <gjansen(a)redhat.com>
To: "Ayal Baron" <abaron(a)redhat.com>
Cc: "Andrew Cathrow" <acathrow(a)redhat.com>, engine-devel(a)ovirt.org,
"Simon Grinberg" <sgrinber(a)redhat.com>, "Saggi
Mizrahi" <smizrahi(a)redhat.com>, "Ori Liel" <oliel(a)redhat.com>,
"Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Miki
Kenneth" <mkenneth(a)redhat.com>, "Einav Cohen"
<ecohen(a)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
9:25 a.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Friday, May 11, 2012 5:15:51 PM
----- Original Message -----
> From: "Geert Jansen" <gjansen(a)redhat.com>
> To: "Ayal Baron" <abaron(a)redhat.com>
> Cc: "Andrew Cathrow" <acathrow(a)redhat.com>, engine-devel(a)ovirt.org,
> "Simon Grinberg" <sgrinber(a)redhat.com>, "Saggi
> Mizrahi" <smizrahi(a)redhat.com>, "Ori Liel"
<oliel(a)redhat.com>,
> "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Miki
> Kenneth" <mkenneth(a)redhat.com>, "Einav Cohen"
<ecohen(a)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
>
2:56 p.m.
----- Original Message -----
> ----- Original Message -----
> From: "Andrew Cathrow" <acathrow(a)redhat.com>
> Sent: Friday, May 11, 2012 5:15:51 PM
>
> ----- Original Message -----
> > From: "Geert Jansen" <gjansen(a)redhat.com>
> > To: "Ayal Baron" <abaron(a)redhat.com>
> > Cc: "Andrew Cathrow" <acathrow(a)redhat.com>,
> > engine-devel(a)ovirt.org,
> > "Simon Grinberg" <sgrinber(a)redhat.com>, "Saggi
> > Mizrahi" <smizrahi(a)redhat.com>, "Ori Liel"
<oliel(a)redhat.com>,
> > "Yair Zaslavsky" <yzaslavs(a)redhat.com>, "Miki
> > Kenneth" <mkenneth(a)redhat.com>, "Einav Cohen"
<ecohen(a)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
> >
>
8:46 a.m.
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(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 4:28:31 PM
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
>
>
9:14 a.m.
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(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 4:28:31 PM
> 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?
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
>>
>>
>
9:16 a.m.
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
To: "Miki Kenneth" <mkenneth(a)redhat.com>
Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Saggi Mizrahi"
<smizrahi(a)redhat.com>, "Andrew Cathrow" <acathrow(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>,
"Ayal Baron" <abaron(a)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(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 4:28:31 PM
>> 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?
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
>>>
>>>
>>
9:27 a.m.
----- Original Message -----
From: "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Thursday, May 10, 2012 5:16:24 PM
----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> To: "Miki Kenneth" <mkenneth(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Saggi Mizrahi"
> <smizrahi(a)redhat.com>, "Andrew Cathrow"
<acathrow(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>,
> "Ayal Baron" <abaron(a)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(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 4:28:31 PM
> >> 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?
> 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:29 a.m.
On 05/10/2012 05:16 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> To: "Miki Kenneth" <mkenneth(a)redhat.com>
> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Saggi Mizrahi"
<smizrahi(a)redhat.com>, "Andrew Cathrow" <acathrow(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>,
> "Ayal Baron" <abaron(a)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(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 4:28:31 PM
>>> 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?
> 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
>>>>
>>>>
>>>
>
>
8:57 a.m.
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
4375
days inactive
4378
days old
37 comments
8 participants
participants (8)
-
Andrew Cathrow -
Ayal Baron -
Einav Cohen -
Geert Jansen -
Miki Kenneth -
Saggi Mizrahi -
Yair Zaslavsky -
Yaniv Kaul