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

Simo Sorce simo at redhat.com
Wed Jun 20 13:57:48 UTC 2012


On Wed, 2012-06-20 at 12:47 +0200, Martin Kosek wrote:
> 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


Given the discussion, I guess this is the best option we have right now.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list