Re: [Engine-devel] REST vs. UI validation

2013-05-02 Thread Michael Pasternak

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.whitc...@hp.com
 To: Michael Pasternak mpast...@redhat.com, Vered Volansky 
 ve...@redhat.com
 Cc: engine-devel@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.whitc...@hp.com
 To: engine-devel@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@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel

Re: [Engine-devel] REST vs. UI validation

2013-05-02 Thread Vojtech Szocs
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 mpast...@redhat.com
To: Roy Golan rgo...@redhat.com
Cc: Vered Volansky ve...@redhat.com, Vojtech Szocs vsz...@redhat.com, 
engine-devel@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.whitc...@hp.com
 To: Michael Pasternak mpast...@redhat.com, Vered Volansky 
 ve...@redhat.com
 Cc: engine-devel@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

Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Allon Mureinik
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 ve...@redhat.com
 To: Kari Whitcomb kari.whitc...@hp.com
 Cc: engine-devel@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.whitc...@hp.com
  To: engine-devel@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@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Vered Volansky


- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Vered Volansky ve...@redhat.com
 Cc: engine-devel@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 ve...@redhat.com
  To: Kari Whitcomb kari.whitc...@hp.com
  Cc: engine-devel@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.whitc...@hp.com
   To: engine-devel@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@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
   
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Michael Pasternak
On 05/01/2013 10:34 AM, Vered Volansky wrote:
 
 
 - Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Vered Volansky ve...@redhat.com
 Cc: engine-devel@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 ve...@redhat.com
 To: Kari Whitcomb kari.whitc...@hp.com
 Cc: engine-devel@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.whitc...@hp.com
 To: engine-devel@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@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

 ___
 Engine-devel mailing list
 Engine

Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Whitcomb, Kari
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.whitc...@hp.com
  To: engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Vered Volansky


- Original Message -
 From: Kari Whitcomb kari.whitc...@hp.com
 To: Michael Pasternak mpast...@redhat.com, Vered Volansky 
 ve...@redhat.com
 Cc: engine-devel@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.whitc...@hp.com
   To: engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Roy Golan

On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote:



- Original Message -

From: Kari Whitcomb kari.whitc...@hp.com
To: Michael Pasternak mpast...@redhat.com, Vered Volansky 
ve...@redhat.com
Cc: engine-devel@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.whitc...@hp.com
To: engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel



___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-05-01 Thread Michael Pasternak
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.whitc...@hp.com
 To: engine-devel@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 RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


Re: [Engine-devel] REST vs. UI validation

2013-04-30 Thread Vered Volansky


- Original Message -
 From: Kari Whitcomb kari.whitc...@hp.com
 To: engine-devel@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@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


[Engine-devel] REST vs. UI validation

2013-04-29 Thread Whitcomb, Kari
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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel