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. 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. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
