Bug 828864 - [RFE] Improve output parameters client validation compatibility
[RFE] Improve output parameters client validation compatibility
Status: CLOSED DUPLICATE of bug 820013
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.0
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Rob Crittenden
IDM QE LIST
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 09:41 EDT by Dmitri Pal
Modified: 2013-02-27 09:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-27 09:08:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri Pal 2012-06-05 09:41:27 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/1721

When input new optional parameter is added to server API, its still usable with old clients with old API, it just cannot use the new parameter.

However, when a new Output parameter is added (for example summary like in the below example), older clients immediately fails with validation error:

{{{
$ ipa sudorule-add-option test2
Sudo Option: foo
ipa: ERROR: non-public: ValueError: 
sudorule_add_option.validate_output(): unexpected keys ['summary'] in 
{'result': {'ipasudoopt': (u'foo',), 'cn': (u'test2',), 
'ipaenabledflag': (u'TRUE',)}, 'summary': u'Added option "foo" to Sudo 
Rule "test2"'}
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 125, 
in execute
     result = self.Command[_name](*args, **options)
   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 443, 
in __call__
     self.validate_output(ret)
   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 895, 
in validate_output
     nice, extra, output)
ValueError: sudorule_add_option.validate_output(): unexpected keys 
['summary'] in {'result': {'ipasudoopt': (u'foo',), 'cn': (u'test2',), 
'ipaenabledflag': (u'TRUE',)}, 'summary': u'Added option "foo" to Sudo 
Rule "test2"'}
ipa: ERROR: an internal error has occurred
}}}

Think about changing the validation process so that unexpected keys are ignored and no exception is raised.
Comment 1 Jenny Galipeau 2012-06-11 11:54:17 EDT
Please add steps to verify this issue ..

Would it be 

Install RHEL 6.3 ipa-server and client.
Upgrade just ipa-server
Run command in the description and get no traceback?  What should be expected?
Comment 2 Rob Crittenden 2012-06-11 13:22:34 EDT
This is for compatibility between older clients and newer servers. The idea is to be able to have data returned to the client that it may not understand but it won't cause the client to not function. It will simply ignore it.
Comment 3 Martin Kosek 2012-06-12 02:25:19 EDT
Currently, this _should not_ be reproducible because there is no known extra output attribute that could cause this traceback. We may come up with some way to reproduce it when the fix is in, but for now, I think regression testing only should be enough.
Comment 4 Dmitri Pal 2012-06-26 12:15:12 EDT
https://fedorahosted.org/freeipa/ticket/2732
Comment 5 RHEL Product and Program Management 2012-07-10 02:21:40 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 6 RHEL Product and Program Management 2012-07-10 19:28:26 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 8 Martin Kosek 2013-02-27 06:26:15 EST
I think we should check if we want to fix this Bugzilla. As far as I understarnd (Petr or Honza can correct me), we will not do the compatibility on a client level, but rather in server by introducing "capabilities" which will send new content only to clients that can handle it (based on the API version number).

I propose to close this Bugzilla as a duplicate of Bug 820013.
Comment 9 Petr Viktorin 2013-02-27 06:53:47 EST
Yes, Martin is right.
Doing this on the client would mean relaxing our validation. That approach was NACKed by Simo.
Comment 10 Martin Kosek 2013-02-27 09:08:59 EST
Ok, closing this Bugzilla as duplicate.

*** This bug has been marked as a duplicate of bug 820013 ***

Note You need to log in before you can comment on or make changes to this bug.