[Freeipa-devel] [PATCH] 0062 Don't crash when server returns extra output

[Martin Kosek]

On Wed, 2012-06-20 at 11:10 +0200, Petr Viktorin wrote:
> On 06/12/2012 02:39 PM, Petr Viktorin wrote:
> > On 06/12/2012 02:38 PM, Simo Sorce wrote:
> >> On Tue, 2012-06-12 at 13:12 +0200, Petr Viktorin wrote:
> >>> This will make older clients usable if new output items get added to
> >>> commands.
> >>>
> >>> Since there might be important information in the extra output, it's not
> >>> ignored as the ticket asks. Instead it's printed, but not formatted
> >>> nicely as the client doesn't have enough info for that.
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/1721
> >>
> >> Patch is missing.
> >>
> >> Simo.
> >>
> >
> > My apologies
> >
> 
> 
> We decided off-list that relaxing validation is not the right thing to do.
> A better approach would be to notify the server that the client can 
> accept extended data (through a header or a version parameter).
> So, ticket 1721 is invalid, but we need a better solution to make 
> https://fedorahosted.org/freeipa/ticket/2732 "Provide means of 
> displaying warning and informational messages on clients" possible.
> 
> I think that using the existing "version" parameter (which gets added to 
> RPC calls automatically) would be perfect for this.

I agree, API version is exactly what we want. We should not care about
client version or if the client is in Fedora, RHEL or Ubuntu.

> 
> Simo mentioned that we don't want to make the API depend on the version 
> of our client version, so other clients don't need to copy our 
> versioning scheme.
> 
> However, in the version argument we send the API version, not our client 
> version. I think other clients should know and advertise what API 
> version they are using, and the number shouldn't be specific to our client.
> It's the perfect place to learn the client's capabilities from, if we're 
> okay with a linear evolution of the API (as opposed to the client 
> advertising individual features).
> 
> Simo, can you comment? Hopefully I didn't mishear anything on the meeting.
> 

The biggest asset about API version is that we already have this number
available for clients that were already released, we don't have to
backport anything.

I would keep linear evolution of the API version number as is, but it
would be also good to assign new API capabilities with the number and
have a simple way of checking if client has the capability, i.e.
something like this:

def post_callback(self, ..., *keys, **options):
    if 'warnings' in version.client_capabilities(options['version']):
        send_warning('forward record added, but reverse zone not found')
        continue
    else:
        raise errors.NonFatalError(...)

Martin