[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