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 > > >>>>>>> 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.
+1 However, this is probably 4.2 material, no? If so, let's file a bug and schedule it. This patch still needs to land in 4.1.2, so is it okay as it is? Nathaniel _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
