2: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