Bug 828864

Summary:	[RFE] Improve output parameters client validation compatibility
Product:	Red Hat Enterprise Linux 7	Reporter:	Dmitri Pal <dpal>
Component:	ipa	Assignee:	Rob Crittenden <rcritten>
Status:	CLOSED DUPLICATE	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.0	CC:	jcholast, jgalipea, mkosek, pviktori
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-27 14:08:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitri Pal 2012-06-05 13:41:27 UTC

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 Severance 2012-06-11 15:54:17 UTC

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 17:22:34 UTC

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 06:25:19 UTC

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 16:15:12 UTC

https://fedorahosted.org/freeipa/ticket/2732

Comment 5 RHEL Program Management 2012-07-10 06:21:40 UTC

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 Program Management 2012-07-10 23:28:26 UTC

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 11:26:15 UTC

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 (pviktori) 2013-02-27 11:53:47 UTC

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 14:08:59 UTC

Ok, closing this Bugzilla as duplicate.

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