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). Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
