[Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add

[Simo Sorce]

On Tue, 18 Nov 2014 12:27:28 +0100
Martin Kosek <mkosek at redhat.com> wrote:

> On 11/14/2014 08:29 PM, Simo Sorce wrote:
> > On Fri, 14 Nov 2014 20:05:35 +0100
> > Petr Viktorin <pviktori at redhat.com> wrote:
> > 
> >> On 11/14/2014 08:03 PM, Petr Viktorin wrote:
> >>> On 11/14/2014 07:26 PM, Simo Sorce wrote:
> >>>> On Fri, 14 Nov 2014 14:08:24 +0100
> >>>> Petr Viktorin <pviktori at redhat.com> wrote:
> >>>>
> >>>>> On 11/14/2014 01:18 PM, Petr Vobornik wrote:
> >>>>> [...]
> >>>>>>>
> >>>>>>> Nope, defaults are filled in by the client. (And also on the
> >>>>>>> server if they're still missing; it's part of the common
> >>>>>>> validation.)
> >>>>>>
> >>>>>> IMHO this is quite unfortunate behavior which may also fail
> >>>>>> horribly if there is a newer client and an older server ->
> >>>>>> backwards compatibility is on API level, not CLI level.
> >>>>>> Defaults should be filled by server, not a client.  We should
> >>>>>> seriously reconsider the design of our CLI. But that's for
> >>>>>> different, future discussion.
> >>>>>
> >>>>> You can't use a newer client with an older server, you get a
> >>>>> VersionError in that case.
> >>>>
> >>>> Does it break only for this command ?
> >>>> Or in general.
> >>>
> >>> In general. It's been built into the framework since IPA 2.0 [0].
> >>> There have been four years of development assuming this
> >>> compatibility scheme.
> >>
> >> I should clarify – this is only for the API, i.e. the `ipa`
> >> command. Clients of the "ipa-client-install" sort don't use the
> >> API.
> > 
> > I know they don't or it would be a disaster.
> > However it is unreasonable to keep changing the API without any 2
> > way compatibility going forward.
> > 
> > I expect it to be extremely common for an admin to have a much more
> > recent desktop then the server being used. Having to jump through
> > hoops to use the admin cli is not friendly. And we do not change
> > the actual CLI that much, so it would be unexpected.
> > 
> > We need to take seriously in consideration compatibility going both
> > ways (of course new commands should just get "NotSupported" errors
> > when used against old servers. But old commands should work, there
> > is no good reason to break this kind of compatibility, it is just
> > an artefact of botched versioning we did a few years ago and it is
> > about time we seriously address this, also because once we make one
> > of these APIs public and supported we cannot willy nilly break it,
> > and we cannot force people to change their software if all works
> > well except a version number being sent in and out.
> > 
> > Individual interfaces need to be versioned, and one an interface is
> > release it must no change (a new version need to be created if
> > changes are needed).
> 
> Well, it is what it is. This paradigm (forward compatibility only)
> was there since the beginning (read - IPA 2.0) and we cannot change
> it that simply - it is big effort on it's own that needs to be
> planned, designed, implemented.

And needs to be changed, it always was supposed to be "temporary", and
it is time to change it.
now that we have various distributions and not just Fedora with FreeIPA
we cannot make the ipa command useless unless you happen to have the
same exact version that you have on the server, normally clients are
always a few versions ahead of servers which move more slowly.

> To solve this, you would need to introduce some kind of
> version/metadata handshake between new client and old server so that
> the clients knows what API does the old server expects. It would need
> to know which attributes were changed/added in incompatible way
> between it's and server's version.

No, this would be the wrong way to go.
The solution is the same Linux adopted for ABI compatibility in
libraries. We version the single API command, all we need to do is add
a version field in the json structure (or even just in the command
name).
Any time people want to "change" a command a new command is created
instead and the old one stays around for older clients.

This is how all successful and backwards compatible RPC APIs are
built, and we need to follow suite asap.

Simo.

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