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.


Freeipa-devel mailing list

Reply via email to