On 18.11.2014 17:27, Nathaniel McCallum wrote:
On Tue, 2014-11-18 at 07:45 -0500, Simo Sorce wrote:
On Tue, 18 Nov 2014 12:27:28 +0100
Martin Kosek <mko...@redhat.com> wrote:

On 11/14/2014 08:29 PM, Simo Sorce wrote:
On Fri, 14 Nov 2014 20:05:35 +0100
Petr Viktorin <pvikt...@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 <pvikt...@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

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

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
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.


However, this is probably 4.2 material, no? If so, let's file a bug and
schedule it.

Yes, https://fedorahosted.org/freeipa/ticket/4739

This patch still needs to land in 4.1.2, so is it okay as it is?

I don't think the label is necessary but it doesn't hurt either, at least it's clear, so ACK.


Petr Vobornik

Freeipa-devel mailing list

Reply via email to