1:19 a.m.
I've been making use of the oVirt REST api, and have noticed that in several cases the
validation done for a REST request is different than what the admin UI does. It seems
that the UI is generally more restrictive on the data it will accept than the backend. So
you can set things up using the REST api that the UI wouldn't let you do. Two
examples I've hit recently, both in the cluster policy (load balancing section):
- Cluster load balancing policy duration - the UI requires a value between 1 and 100, but
the REST api seems to let you set it to any integer.
- Cluster load balancing high and low thresholds / max and min service levels - The UI
restricts the high value to 51-90% and the low value to 10-50%. But the backend only
requires that the values be 0-100% and that low can't be greater than high.
So my question - is this intended behavior, or is it a bug that the validation is
different? If similar validation should be done through both the UI and REST api, should
the UI be less restrictive, or the backend more restrictive?
Thanks,
Kari
10:15 a.m.
----- Original Message -----
From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
To: engine-devel(a)ovirt.org
Sent: Tuesday, April 30, 2013 1:19:00 AM
Subject: [Engine-devel] REST vs. UI validation
I've been making use of the oVirt REST api, and have noticed that in several
cases the validation done for a REST request is different than what the
admin UI does. It seems that the UI is generally more restrictive on the
data it will accept than the backend. So you can set things up using the
REST api that the UI wouldn't let you do. Two examples I've hit recently,
both in the cluster policy (load balancing section):
- Cluster load balancing policy duration - the UI requires a value between 1
and 100, but the REST api seems to let you set it to any integer.
- Cluster load balancing high and low thresholds / max and min service levels
- The UI restricts the high value to 51-90% and the low value to 10-50%.
But the backend only requires that the values be 0-100% and that low can't
be greater than high.
So my question - is this intended behavior, or is it a bug that the
validation is different? If similar validation should be done through both
the UI and REST api, should the UI be less restrictive, or the backend more
restrictive?
This is the intended behaviour.
The UI is often more restrictive than the api.
By definition the api is more lenient that the UI.
Regards,
Vered
Thanks,
Kari
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:05 a.m.
REST shouldn't have any validations (perhaps maybe only that the passed type is
correct, etc. - Michael, correct me if I'm wrong).
The real validations are in the backend, which both REST and the GUI invoke. Any
validation the GUI does in addition to the backend is just a user-experience enhancement
(e.g., if !@#^!^$) is not a valid DC name, there is no reason to send it to the backend).
Vered - I disagree that this is by design.
There is only one definition of what a correct value is, there should be no ambiguity
about it[1]
If the GUI prohibits you from a legal configuration - it should be fixed.
if the backend allows an illegal configuration - a CDA should be added.
My two cents - this is not OK, please open bugs (or even better - send patches!) for the
specific issues.
[1] Just to be clear, there is a difference between not being able to do something from
the UI and having different validations.
For example, there is no GUI for scanning a storage domain
(http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for that too, but
not having it is just a missing capability, not a disambiguity with REST.
----- Original Message -----
From: "Vered Volansky" <vered(a)redhat.com>
To: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
Cc: engine-devel(a)ovirt.org
Sent: Tuesday, April 30, 2013 10:15:31 AM
Subject: Re: [Engine-devel] REST vs. UI validation
----- Original Message -----
> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
> To: engine-devel(a)ovirt.org
> Sent: Tuesday, April 30, 2013 1:19:00 AM
> Subject: [Engine-devel] REST vs. UI validation
>
> I've been making use of the oVirt REST api, and have noticed that in
> several
> cases the validation done for a REST request is different than what the
> admin UI does. It seems that the UI is generally more restrictive on the
> data it will accept than the backend. So you can set things up using the
> REST api that the UI wouldn't let you do. Two examples I've hit recently,
> both in the cluster policy (load balancing section):
>
> - Cluster load balancing policy duration - the UI requires a value between
> 1
> and 100, but the REST api seems to let you set it to any integer.
>
> - Cluster load balancing high and low thresholds / max and min service
> levels
> - The UI restricts the high value to 51-90% and the low value to 10-50%.
> But the backend only requires that the values be 0-100% and that low can't
> be greater than high.
>
> So my question - is this intended behavior, or is it a bug that the
> validation is different? If similar validation should be done through both
> the UI and REST api, should the UI be less restrictive, or the backend more
> restrictive?
This is the intended behaviour.
The UI is often more restrictive than the api.
By definition the api is more lenient that the UI.
Regards,
Vered
>
> Thanks,
> Kari
> _______________________________________________
> 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:34 a.m.
----- Original Message -----
From: "Allon Mureinik" <amureini(a)redhat.com>
To: "Vered Volansky" <vered(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, May 1, 2013 10:05:34 AM
Subject: Re: [Engine-devel] REST vs. UI validation
REST shouldn't have any validations (perhaps maybe only that the passed type
is correct, etc. - Michael, correct me if I'm wrong).
I never said REST have any validations.
When using REST only the backend validations are invoked.
When using the UI there might be more validations only for UI before the backend
validations are ever invoked.
These validations aren't invoked for REST.
The real validations are in the backend, which both REST and the GUI
invoke.
Any validation the GUI does in addition to the backend is just a
user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there
is no reason to send it to the backend).
Vered - I disagree that this is by design.
There is only one definition of what a correct value is, there should be no
ambiguity about it[1]
If the GUI prohibits you from a legal configuration - it should be fixed.
if the backend allows an illegal configuration - a CDA should be added.
My two cents - this is not OK, please open bugs (or even better - send
patches!) for the specific issues.
This was discussed with Michael (until he answers himself).
More info on the issue -
The backend validations are less restrictive than UI, but not contradicting it.
This IS by design and is not a bug in general.
The specific min-max differences example is for sure by design.
In some (but I guess not all) cases the reasoning is a thought to expand possible values
in the future.
So this is how things are right now.
I agree it looks weird that you might be able to set "illegal" values in REST
and then connect via UI and see these values.
I suppose it can always come up for devel discussion whether that should be changed.
[1] Just to be clear, there is a difference between not being able to do
something from the UI and having different validations.
For example, there is no GUI for scanning a storage domain
(http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for
that too, but not having it is just a missing capability, not a disambiguity
with REST.
----- Original Message -----
> From: "Vered Volansky" <vered(a)redhat.com>
> To: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Tuesday, April 30, 2013 10:15:31 AM
> Subject: Re: [Engine-devel] REST vs. UI validation
>
>
>
> ----- Original Message -----
> > From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
> > To: engine-devel(a)ovirt.org
> > Sent: Tuesday, April 30, 2013 1:19:00 AM
> > Subject: [Engine-devel] REST vs. UI validation
> >
> > I've been making use of the oVirt REST api, and have noticed that in
> > several
> > cases the validation done for a REST request is different than what the
> > admin UI does. It seems that the UI is generally more restrictive on the
> > data it will accept than the backend. So you can set things up using the
> > REST api that the UI wouldn't let you do. Two examples I've hit
> > recently,
> > both in the cluster policy (load balancing section):
> >
> > - Cluster load balancing policy duration - the UI requires a value
> > between
> > 1
> > and 100, but the REST api seems to let you set it to any integer.
> >
> > - Cluster load balancing high and low thresholds / max and min service
> > levels
> > - The UI restricts the high value to 51-90% and the low value to 10-50%.
> > But the backend only requires that the values be 0-100% and that low
> > can't
> > be greater than high.
> >
> > So my question - is this intended behavior, or is it a bug that the
> > validation is different? If similar validation should be done through
> > both
> > the UI and REST api, should the UI be less restrictive, or the backend
> > more
> > restrictive?
>
> This is the intended behaviour.
> The UI is often more restrictive than the api.
> By definition the api is more lenient that the UI.
>
> Regards,
> Vered
> >
> > Thanks,
> > Kari
> > _______________________________________________
> > 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
11:29 a.m.
On 05/01/2013 10:34 AM, Vered Volansky wrote:
----- Original Message -----
> From: "Allon Mureinik" <amureini(a)redhat.com>
> To: "Vered Volansky" <vered(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Wednesday, May 1, 2013 10:05:34 AM
> Subject: Re: [Engine-devel] REST vs. UI validation
>
> REST shouldn't have any validations (perhaps maybe only that the passed type
> is correct, etc. - Michael, correct me if I'm wrong).
>
I never said REST have any validations.
When using REST only the backend validations are invoked.
When using the UI there might be more validations only for UI before the backend
validations are ever invoked.
These validations aren't invoked for REST.
this is correct.
> The real validations are in the backend, which both REST and the GUI invoke.
> Any validation the GUI does in addition to the backend is just a
> user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there
> is no reason to send it to the backend).
the reason for this is user experience in UI, e.g in some cases validation
can be done on a client side (by regex etc showing errors in popup/balloon)
instead of sending heavy request to the backend over the wire and getting an
error in reply.
>
> Vered - I disagree that this is by design.
> There is only one definition of what a correct value is, there should be no
> ambiguity about it[1]
> If the GUI prohibits you from a legal configuration - it should be fixed.
> if the backend allows an illegal configuration - a CDA should be added.
> My two cents - this is not OK, please open bugs (or even better - send
> patches!) for the specific issues.
This was discussed with Michael (until he answers himself).
More info on the issue -
The backend validations are less restrictive than UI, but not contradicting it.
This IS by design and is not a bug in general.
The specific min-max differences example is for sure by design.
In some (but I guess not all) cases the reasoning is a thought to expand possible values
in the future.
So this is how things are right now.
I agree it looks weird that you might be able to set "illegal" values in REST
and then connect via UI and see these values.
I suppose it can always come up for devel discussion whether that should be changed.
you cannot set any illegal value in REST-API, UI is more restrictive indeed,
while api expose all backend capabilities (including those that are restricted in UI)
>
> [1] Just to be clear, there is a difference between not being able to do
> something from the UI and having different validations.
> For example, there is no GUI for scanning a storage domain
> (http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for
> that too, but not having it is just a missing capability, not a disambiguity
> with REST.
>
> ----- Original Message -----
>> From: "Vered Volansky" <vered(a)redhat.com>
>> To: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Tuesday, April 30, 2013 10:15:31 AM
>> Subject: Re: [Engine-devel] REST vs. UI validation
>>
>>
>>
>> ----- Original Message -----
>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>> Subject: [Engine-devel] REST vs. UI validation
>>>
>>> I've been making use of the oVirt REST api, and have noticed that in
>>> several
>>> cases the validation done for a REST request is different than what the
>>> admin UI does. It seems that the UI is generally more restrictive on the
>>> data it will accept than the backend. So you can set things up using the
>>> REST api that the UI wouldn't let you do. Two examples I've hit
>>> recently,
>>> both in the cluster policy (load balancing section):
>>>
>>> - Cluster load balancing policy duration - the UI requires a value
>>> between
>>> 1
>>> and 100, but the REST api seems to let you set it to any integer.
>>>
>>> - Cluster load balancing high and low thresholds / max and min service
>>> levels
>>> - The UI restricts the high value to 51-90% and the low value to 10-50%.
>>> But the backend only requires that the values be 0-100% and that low
>>> can't
>>> be greater than high.
>>>
>>> So my question - is this intended behavior, or is it a bug that the
>>> validation is different? If similar validation should be done through
>>> both
>>> the UI and REST api, should the UI be less restrictive, or the backend
>>> more
>>> restrictive?
>>
>> This is the intended behaviour.
>> The UI is often more restrictive than the api.
>> By definition the api is more lenient that the UI.
>>
>> Regards,
>> Vered
>>>
>>> Thanks,
>>> Kari
>>> _______________________________________________
>>> 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
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
8:12 p.m.
Thanks for the discussion. One clarifying question below...
-Kari
>>
>> Vered - I disagree that this is by design.
>> There is only one definition of what a correct value is, there should be no
>> ambiguity about it[1]
>> If the GUI prohibits you from a legal configuration - it should be fixed.
>> if the backend allows an illegal configuration - a CDA should be added.
>> My two cents - this is not OK, please open bugs (or even better - send
>> patches!) for the specific issues.
>
> This was discussed with Michael (until he answers himself).
> More info on the issue -
> The backend validations are less restrictive than UI, but not contradicting it.
> This IS by design and is not a bug in general.
> The specific min-max differences example is for sure by design.
> In some (but I guess not all) cases the reasoning is a thought to expand
possible values in the future.
>
> So this is how things are right now.
> I agree it looks weird that you might be able to set "illegal" values in
REST
and then connect via UI and see these values.
> I suppose it can always come up for devel discussion whether that should be
changed.
you cannot set any illegal value in REST-API, UI is more restrictive indeed,
while api expose all backend capabilities (including those that are restricted in
UI)
So if I understanding correctly... The backend validations are checking legality. The UI
may in some cases (like the specific ones I mentioned) impose additional
restrictions/validations that further narrow the allowed input and this is by design and
not a bug. Does that sum the current state about right?
Thanks,
Kari
>>> ----- Original Message -----
>>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>
>>>> I've been making use of the oVirt REST api, and have noticed that
in
>>>> several
>>>> cases the validation done for a REST request is different than what the
>>>> admin UI does. It seems that the UI is generally more restrictive on
the
>>>> data it will accept than the backend. So you can set things up using
the
>>>> REST api that the UI wouldn't let you do. Two examples I've
hit
>>>> recently,
>>>> both in the cluster policy (load balancing section):
>>>>
>>>> - Cluster load balancing policy duration - the UI requires a value
>>>> between
>>>> 1
>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>
>>>> - Cluster load balancing high and low thresholds / max and min service
>>>> levels
>>>> - The UI restricts the high value to 51-90% and the low value to
10-50%.
>>>> But the backend only requires that the values be 0-100% and that low
>>>> can't
>>>> be greater than high.
>>>>
>>>> So my question - is this intended behavior, or is it a bug that the
>>>> validation is different? If similar validation should be done through
>>>> both
>>>> the UI and REST api, should the UI be less restrictive, or the backend
>>>> more
>>>> restrictive?
>>>>
>>>> Thanks,
>>>> Kari
8:41 p.m.
----- Original Message -----
From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
To: "Michael Pasternak" <mpastern(a)redhat.com>, "Vered Volansky"
<vered(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, May 1, 2013 8:12:09 PM
Subject: RE: [Engine-devel] REST vs. UI validation
Thanks for the discussion. One clarifying question below...
-Kari
> >>
> >> Vered - I disagree that this is by design.
> >> There is only one definition of what a correct value is, there should be
> >> no
> >> ambiguity about it[1]
> >> If the GUI prohibits you from a legal configuration - it should be
> >> fixed.
> >> if the backend allows an illegal configuration - a CDA should be added.
> >> My two cents - this is not OK, please open bugs (or even better - send
> >> patches!) for the specific issues.
> >
> > This was discussed with Michael (until he answers himself).
> > More info on the issue -
> > The backend validations are less restrictive than UI, but not
> > contradicting it.
> > This IS by design and is not a bug in general.
> > The specific min-max differences example is for sure by design.
> > In some (but I guess not all) cases the reasoning is a thought to expand
> possible values in the future.
> >
> > So this is how things are right now.
> > I agree it looks weird that you might be able to set "illegal" values
in
> > REST
> and then connect via UI and see these values.
> > I suppose it can always come up for devel discussion whether that should
> > be
> changed.
>
> you cannot set any illegal value in REST-API, UI is more restrictive
> indeed,
> while api expose all backend capabilities (including those that are
> restricted in
> UI)
So if I understanding correctly... The backend validations are checking
legality. The UI may in some cases (like the specific ones I mentioned)
impose additional restrictions/validations that further narrow the allowed
input and this is by design and not a bug. Does that sum the current state
about right?
Yep.
Thanks,
Kari
> >>> ----- Original Message -----
> >>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
> >>>> To: engine-devel(a)ovirt.org
> >>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
> >>>> Subject: [Engine-devel] REST vs. UI validation
> >>>>
> >>>> I've been making use of the oVirt REST api, and have noticed
that in
> >>>> several
> >>>> cases the validation done for a REST request is different than
what
> >>>> the
> >>>> admin UI does. It seems that the UI is generally more restrictive
on
> >>>> the
> >>>> data it will accept than the backend. So you can set things up
using
> >>>> the
> >>>> REST api that the UI wouldn't let you do. Two examples
I've hit
> >>>> recently,
> >>>> both in the cluster policy (load balancing section):
> >>>>
> >>>> - Cluster load balancing policy duration - the UI requires a value
> >>>> between
> >>>> 1
> >>>> and 100, but the REST api seems to let you set it to any integer.
> >>>>
> >>>> - Cluster load balancing high and low thresholds / max and min
service
> >>>> levels
> >>>> - The UI restricts the high value to 51-90% and the low value to
> >>>> 10-50%.
> >>>> But the backend only requires that the values be 0-100% and that
low
> >>>> can't
> >>>> be greater than high.
> >>>>
> >>>> So my question - is this intended behavior, or is it a bug that
the
> >>>> validation is different? If similar validation should be done
through
> >>>> both
> >>>> the UI and REST api, should the UI be less restrictive, or the
backend
> >>>> more
> >>>> restrictive?
> >>>>
> >>>> Thanks,
> >>>> Kari
8:29 a.m.
On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
----- Original Message -----
> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
> To: "Michael Pasternak" <mpastern(a)redhat.com>, "Vered
Volansky" <vered(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Wednesday, May 1, 2013 8:12:09 PM
> Subject: RE: [Engine-devel] REST vs. UI validation
>
> Thanks for the discussion. One clarifying question below...
>
> -Kari
>
>>>>
>>>> Vered - I disagree that this is by design.
>>>> There is only one definition of what a correct value is, there should be
>>>> no
>>>> ambiguity about it[1]
>>>> If the GUI prohibits you from a legal configuration - it should be
>>>> fixed.
>>>> if the backend allows an illegal configuration - a CDA should be added.
>>>> My two cents - this is not OK, please open bugs (or even better - send
>>>> patches!) for the specific issues.
>>>
>>> This was discussed with Michael (until he answers himself).
>>> More info on the issue -
>>> The backend validations are less restrictive than UI, but not
>>> contradicting it.
>>> This IS by design and is not a bug in general.
>>> The specific min-max differences example is for sure by design.
>>> In some (but I guess not all) cases the reasoning is a thought to expand
>> possible values in the future.
>>>
>>> So this is how things are right now.
>>> I agree it looks weird that you might be able to set "illegal"
values in
>>> REST
>> and then connect via UI and see these values.
>>> I suppose it can always come up for devel discussion whether that should
>>> be
>> changed.
>>
>> you cannot set any illegal value in REST-API, UI is more restrictive
>> indeed,
>> while api expose all backend capabilities (including those that are
>> restricted in
>> UI)
>
> So if I understanding correctly... The backend validations are checking
> legality. The UI may in some cases (like the specific ones I mentioned)
> impose additional restrictions/validations that further narrow the allowed
> input and this is by design and not a bug. Does that sum the current state
> about right?
Yep.
I disagree. The UI is validating input to fail as fast and save
rountrips for better responsiveness and overall a better UX. This means
validation are duplicated and sometimes, different - which I consider a
bug - there is no good reason an action would be valid using the API
and invalid with UI or vise versa.
the main chalenge is to share the validation code which might be
achievablle if GWT will support our validation annotation on beans
(jsr303) - Vojetech this one I think you'll be able to help with
>
> Thanks,
> Kari
>
>>>>> ----- Original Message -----
>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>>>>> To: engine-devel(a)ovirt.org
>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>
>>>>>> I've been making use of the oVirt REST api, and have noticed
that in
>>>>>> several
>>>>>> cases the validation done for a REST request is different than
what
>>>>>> the
>>>>>> admin UI does. It seems that the UI is generally more
restrictive on
>>>>>> the
>>>>>> data it will accept than the backend. So you can set things up
using
>>>>>> the
>>>>>> REST api that the UI wouldn't let you do. Two examples
I've hit
>>>>>> recently,
>>>>>> both in the cluster policy (load balancing section):
>>>>>>
>>>>>> - Cluster load balancing policy duration - the UI requires a
value
>>>>>> between
>>>>>> 1
>>>>>> and 100, but the REST api seems to let you set it to any
integer.
>>>>>>
>>>>>> - Cluster load balancing high and low thresholds / max and min
service
>>>>>> levels
>>>>>> - The UI restricts the high value to 51-90% and the low value to
>>>>>> 10-50%.
>>>>>> But the backend only requires that the values be 0-100% and that
low
>>>>>> can't
>>>>>> be greater than high.
>>>>>>
>>>>>> So my question - is this intended behavior, or is it a bug that
the
>>>>>> validation is different? If similar validation should be done
through
>>>>>> both
>>>>>> the UI and REST api, should the UI be less restrictive, or the
backend
>>>>>> more
>>>>>> restrictive?
>>>>>>
>>>>>> Thanks,
>>>>>> Kari
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
9:05 a.m.
Hi Roy,
On 05/02/2013 08:29 AM, Roy Golan wrote:
On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
>
>
> ----- Original Message -----
>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>> To: "Michael Pasternak" <mpastern(a)redhat.com>, "Vered
Volansky" <vered(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Wednesday, May 1, 2013 8:12:09 PM
>> Subject: RE: [Engine-devel] REST vs. UI validation
>>
>> Thanks for the discussion. One clarifying question below...
>>
>> -Kari
>>
>>>>>
>>>>> Vered - I disagree that this is by design.
>>>>> There is only one definition of what a correct value is, there should
be
>>>>> no
>>>>> ambiguity about it[1]
>>>>> If the GUI prohibits you from a legal configuration - it should be
>>>>> fixed.
>>>>> if the backend allows an illegal configuration - a CDA should be
added.
>>>>> My two cents - this is not OK, please open bugs (or even better -
send
>>>>> patches!) for the specific issues.
>>>>
>>>> This was discussed with Michael (until he answers himself).
>>>> More info on the issue -
>>>> The backend validations are less restrictive than UI, but not
>>>> contradicting it.
>>>> This IS by design and is not a bug in general.
>>>> The specific min-max differences example is for sure by design.
>>>> In some (but I guess not all) cases the reasoning is a thought to expand
>>> possible values in the future.
>>>>
>>>> So this is how things are right now.
>>>> I agree it looks weird that you might be able to set "illegal"
values in
>>>> REST
>>> and then connect via UI and see these values.
>>>> I suppose it can always come up for devel discussion whether that should
>>>> be
>>> changed.
>>>
>>> you cannot set any illegal value in REST-API, UI is more restrictive
>>> indeed,
>>> while api expose all backend capabilities (including those that are
>>> restricted in
>>> UI)
>>
>> So if I understanding correctly... The backend validations are checking
>> legality. The UI may in some cases (like the specific ones I mentioned)
>> impose additional restrictions/validations that further narrow the allowed
>> input and this is by design and not a bug. Does that sum the current state
>> about right?
> Yep.
I disagree. The UI is validating input to fail as fast and save rountrips for better
responsiveness and overall a better UX. This means validation are duplicated and
sometimes, different - which I consider a bug - there is no good reason an action would
be valid using the API and invalid with UI or vise versa.
you basically repeating told above, if you'll read this tread from the beginning,
kari gives two examples in "Cluster load balancing" both not even near to be
"different",
it's just a different (UI) representation for same thing, UI actually hiding engine
implementation
details over mentioned properties.
the main chalenge is to share the validation code which might be achievablle if GWT will
support our validation annotation on beans (jsr303) - Vojetech this one I think
you'll be able to help with
this is nice to have approach and will work with static validations only (that does
not require dialogue with the engine), in any case api don't have any validation
concept (except
of mandatory parameters existence) and should not have, as engine do this job, - and that
what
we trying to make clear,
but again not always same validations as mentioned above will take place on both client
and engine
sides.
>>
>> Thanks,
>> Kari
>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>>
>>>>>>> I've been making use of the oVirt REST api, and have
noticed that in
>>>>>>> several
>>>>>>> cases the validation done for a REST request is different
than what
>>>>>>> the
>>>>>>> admin UI does. It seems that the UI is generally more
restrictive on
>>>>>>> the
>>>>>>> data it will accept than the backend. So you can set things
up using
>>>>>>> the
>>>>>>> REST api that the UI wouldn't let you do. Two examples
I've hit
>>>>>>> recently,
>>>>>>> both in the cluster policy (load balancing section):
>>>>>>>
>>>>>>> - Cluster load balancing policy duration - the UI requires a
value
>>>>>>> between
>>>>>>> 1
>>>>>>> and 100, but the REST api seems to let you set it to any
integer.
>>>>>>>
>>>>>>> - Cluster load balancing high and low thresholds / max and
min service
>>>>>>> levels
>>>>>>> - The UI restricts the high value to 51-90% and the low value
to
>>>>>>> 10-50%.
>>>>>>> But the backend only requires that the values be 0-100% and
that low
>>>>>>> can't
>>>>>>> be greater than high.
>>>>>>>
>>>>>>> So my question - is this intended behavior, or is it a bug
that the
>>>>>>> validation is different? If similar validation should be
done through
>>>>>>> both
>>>>>>> the UI and REST api, should the UI be less restrictive, or
the backend
>>>>>>> more
>>>>>>> restrictive?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kari
>>
> _______________________________________________
> 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
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
8:11 p.m.
Hi guys,
> the main chalenge is to share the validation code which might be
achievablle if GWT will support our validation annotation on beans (jsr303) - Vojetech
this one I think
> you'll be able to help with
this is nice to have approach and will work with static validations only (that does
not require dialogue with the engine), in any case api don't have any validation
concept (except
of mandatory parameters existence) and should not have, as engine do this job, - and that
what
we trying to make clear,
but again not always same validations as mentioned above will take place on both client
and engine
sides.
AFAIK Java bean validation annotations (JSR-303 a.k.a javax.validation) are used directly
on backend business entities, i.e. org.ovirt.engine.core.common.businessentities.*
Today, GUI works directly with backend business entities, so we can support JSR-303
annotations in GWT code. However, in the long-term, we plan to use REST API, breaking
bonds with Engine with regard to RPC/API protocol.
For static validations (not involving server interaction), we will very likely end up
implementing custom validation code, unrelated to backend validation annotations. For
dynamic validations, I think we should let server handle this, otherwise we're just
introducing more roundtrips and code complexity.
Just an idea: as part of moving GUI to REST API, initiate some work on REST API JavaScript
SDK that would include such "common" validation code. This SDK would be used by
both WebAdmin, UserPortal, and any other web application talking to REST API. I'm the
first one to volunteer for this, if it gets some green flag :)
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Roy Golan" <rgolan(a)redhat.com>
Cc: "Vered Volansky" <vered(a)redhat.com>, "Vojtech Szocs"
<vszocs(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, May 2, 2013 8:05:43 AM
Subject: Re: [Engine-devel] REST vs. UI validation
Hi Roy,
On 05/02/2013 08:29 AM, Roy Golan wrote:
On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:
>
>
> ----- Original Message -----
>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>> To: "Michael Pasternak" <mpastern(a)redhat.com>, "Vered
Volansky" <vered(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Wednesday, May 1, 2013 8:12:09 PM
>> Subject: RE: [Engine-devel] REST vs. UI validation
>>
>> Thanks for the discussion. One clarifying question below...
>>
>> -Kari
>>
>>>>>
>>>>> Vered - I disagree that this is by design.
>>>>> There is only one definition of what a correct value is, there should
be
>>>>> no
>>>>> ambiguity about it[1]
>>>>> If the GUI prohibits you from a legal configuration - it should be
>>>>> fixed.
>>>>> if the backend allows an illegal configuration - a CDA should be
added.
>>>>> My two cents - this is not OK, please open bugs (or even better -
send
>>>>> patches!) for the specific issues.
>>>>
>>>> This was discussed with Michael (until he answers himself).
>>>> More info on the issue -
>>>> The backend validations are less restrictive than UI, but not
>>>> contradicting it.
>>>> This IS by design and is not a bug in general.
>>>> The specific min-max differences example is for sure by design.
>>>> In some (but I guess not all) cases the reasoning is a thought to expand
>>> possible values in the future.
>>>>
>>>> So this is how things are right now.
>>>> I agree it looks weird that you might be able to set "illegal"
values in
>>>> REST
>>> and then connect via UI and see these values.
>>>> I suppose it can always come up for devel discussion whether that should
>>>> be
>>> changed.
>>>
>>> you cannot set any illegal value in REST-API, UI is more restrictive
>>> indeed,
>>> while api expose all backend capabilities (including those that are
>>> restricted in
>>> UI)
>>
>> So if I understanding correctly... The backend validations are checking
>> legality. The UI may in some cases (like the specific ones I mentioned)
>> impose additional restrictions/validations that further narrow the allowed
>> input and this is by design and not a bug. Does that sum the current state
>> about right?
> Yep.
I disagree. The UI is validating input to fail as fast and save rountrips for better
responsiveness and overall a better UX. This means validation are duplicated and
sometimes, different - which I consider a bug - there is no good reason an action would
be valid using the API and invalid with UI or vise versa.
you basically repeating told above, if you'll read this tread from the beginning,
kari gives two examples in "Cluster load balancing" both not even near to be
"different",
it's just a different (UI) representation for same thing, UI actually hiding engine
implementation
details over mentioned properties.
the main chalenge is to share the validation code which might be achievablle if GWT will
support our validation annotation on beans (jsr303) - Vojetech this one I think
you'll be able to help with
this is nice to have approach and will work with static validations only (that does
not require dialogue with the engine), in any case api don't have any validation
concept (except
of mandatory parameters existence) and should not have, as engine do this job, - and that
what
we trying to make clear,
but again not always same validations as mentioned above will take place on both client
and engine
sides.
>>
>> Thanks,
>> Kari
>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>>>>>> To: engine-devel(a)ovirt.org
>>>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>>>
>>>>>>> I've been making use of the oVirt REST api, and have
noticed that in
>>>>>>> several
>>>>>>> cases the validation done for a REST request is different
than what
>>>>>>> the
>>>>>>> admin UI does. It seems that the UI is generally more
restrictive on
>>>>>>> the
>>>>>>> data it will accept than the backend. So you can set things
up using
>>>>>>> the
>>>>>>> REST api that the UI wouldn't let you do. Two examples
I've hit
>>>>>>> recently,
>>>>>>> both in the cluster policy (load balancing section):
>>>>>>>
>>>>>>> - Cluster load balancing policy duration - the UI requires a
value
>>>>>>> between
>>>>>>> 1
>>>>>>> and 100, but the REST api seems to let you set it to any
integer.
>>>>>>>
>>>>>>> - Cluster load balancing high and low thresholds / max and
min service
>>>>>>> levels
>>>>>>> - The UI restricts the high value to 51-90% and the low value
to
>>>>>>> 10-50%.
>>>>>>> But the backend only requires that the values be 0-100% and
that low
>>>>>>> can't
>>>>>>> be greater than high.
>>>>>>>
>>>>>>> So my question - is this intended behavior, or is it a bug
that the
>>>>>>> validation is different? If similar validation should be
done through
>>>>>>> both
>>>>>>> the UI and REST api, should the UI be less restrictive, or
the backend
>>>>>>> more
>>>>>>> restrictive?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kari
>>
> _______________________________________________
> 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
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
8:51 a.m.
On 05/01/2013 08:12 PM, Whitcomb, Kari wrote:
Thanks for the discussion. One clarifying question below...
-Kari
>>>
>>> Vered - I disagree that this is by design.
>>> There is only one definition of what a correct value is, there should be no
>>> ambiguity about it[1]
>>> If the GUI prohibits you from a legal configuration - it should be fixed.
>>> if the backend allows an illegal configuration - a CDA should be added.
>>> My two cents - this is not OK, please open bugs (or even better - send
>>> patches!) for the specific issues.
>>
>> This was discussed with Michael (until he answers himself).
>> More info on the issue -
>> The backend validations are less restrictive than UI, but not contradicting it.
>> This IS by design and is not a bug in general.
>> The specific min-max differences example is for sure by design.
>> In some (but I guess not all) cases the reasoning is a thought to expand
> possible values in the future.
>>
>> So this is how things are right now.
>> I agree it looks weird that you might be able to set "illegal" values
in REST
> and then connect via UI and see these values.
>> I suppose it can always come up for devel discussion whether that should be
> changed.
>
> you cannot set any illegal value in REST-API, UI is more restrictive indeed,
> while api expose all backend capabilities (including those that are restricted in
> UI)
So if I understanding correctly... The backend validations are checking legality. The UI
may in some cases (like the specific ones I mentioned) impose additional
restrictions/validations that further narrow the allowed input and this is by design and
not a bug. Does that sum the current state about right?
yep.
Thanks,
Kari
>>>> ----- Original Message -----
>>>>> From: "Kari Whitcomb" <Kari.Whitcomb(a)hp.com>
>>>>> To: engine-devel(a)ovirt.org
>>>>> Sent: Tuesday, April 30, 2013 1:19:00 AM
>>>>> Subject: [Engine-devel] REST vs. UI validation
>>>>>
>>>>> I've been making use of the oVirt REST api, and have noticed that
in
>>>>> several
>>>>> cases the validation done for a REST request is different than what
the
>>>>> admin UI does. It seems that the UI is generally more restrictive on
the
>>>>> data it will accept than the backend. So you can set things up using
the
>>>>> REST api that the UI wouldn't let you do. Two examples I've
hit
>>>>> recently,
>>>>> both in the cluster policy (load balancing section):
>>>>>
>>>>> - Cluster load balancing policy duration - the UI requires a value
>>>>> between
>>>>> 1
>>>>> and 100, but the REST api seems to let you set it to any integer.
>>>>>
>>>>> - Cluster load balancing high and low thresholds / max and min
service
>>>>> levels
>>>>> - The UI restricts the high value to 51-90% and the low value to
10-50%.
>>>>> But the backend only requires that the values be 0-100% and that low
>>>>> can't
>>>>> be greater than high.
>>>>>
>>>>> So my question - is this intended behavior, or is it a bug that the
>>>>> validation is different? If similar validation should be done
through
>>>>> both
>>>>> the UI and REST api, should the UI be less restrictive, or the
backend
>>>>> more
>>>>> restrictive?
>>>>>
>>>>> Thanks,
>>>>> Kari
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
4222
days inactive
4225
days old
10 comments
6 participants
participants (6)
-
Allon Mureinik -
Michael Pasternak -
Roy Golan -
Vered Volansky -
Vojtech Szocs -
Whitcomb, Kari