[Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add

[Petr Vobornik]

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

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.

>
> Nathaniel
>
-- 
Petr Vobornik