On 08/04/2015 02:20 PM, Simo Sorce wrote:
> On Tue, 2015-08-04 at 08:05 +0200, Martin Kosek wrote:
>> On 08/03/2015 10:37 PM, Endi Sukma Dewata wrote:
>>> On 8/3/2015 2:47 PM, Martin Kosek wrote:
>>>> On 08/03/2015 05:36 PM, Endi Sukma Dewata wrote:
>>>>> On 8/3/2015 2:31 AM, Martin Kosek wrote:
>>>>>> On 07/31/2015 05:07 PM, Endi Sukma Dewata wrote:
>>>>>>> The CLIs to manage vault owners and members have been modified
>>>>>>> to accept services with a new parameter. Due to name conflict,
>>>>>>> the existing 'service' parameter has been renamed to
>>>>>>> 'servicename'.
>>>>>>> A new ACL has been added to allow a service to create its own
>>>>>>> service container.
>>>>>>> https://fedorahosted.org/freeipa/ticket/5172
>>>>>> I did not do a full review, I just saw some of the changes that made
>>>>>> me worry -
>>>>>> like renaming API command attribute. Wouldn't that make the older
>>>>>> clients fail?
>>>>>> See for example permission-* commands, we faced similar situation
>>>>>> there and had
>>>>>> to rename command attributes potentially used by old clients in the
>>>>>> new format.
>>>>> Yes, it will break older clients. The problem is I cannot keep the legacy
>>>>> 'service' parameter for backward compatibility:
>>>>>      Str(
>>>>>          'service?',
>>>>>          cli_name='deprecated_service',
>>>>>          doc=_('DEPRECATED: Service name of the service vault'),
>>>>>      ),
>>>>>      Str(
>>>>>          'servicename?',
>>>>>          cli_name='service',
>>>>>          doc=_('Service name of the service vault'),
>>>>>      ),
>>>>> because it will conflict with a new 'service' parameter:
>>>>> [Mon Aug 03 17:19:00.197040 2015] [wsgi:error] [pid 9409] ipa: ERROR:
>>>>> Failed to
>>>>> start IPA: cannot override NameSpace.service value Str('service?',
>>>>> cli_name='deprecated_service', doc=Gettext('DEPRECATED: Service name
>>>>> of the
>>>>> service vault', domain='ipa', localedir=None)) with Str('service*',
>>>>> alwaysask=True, cli_name='services', csv=True, doc=u'services to add',
>>>>> label=u'member service')
>>>>> that was added automatically when I added the 'service' attribute member:
>>>>>      attribute_members = {
>>>>>          'owner': ['user', 'group', 'service'],
>>>>>          'member': ['user', 'group', 'service'],
>>>>>      }
>>>>> If there's a way to use a different parameter name for the 'service'
>>>>> attribute
>>>>> member to avoid conflict with the legacy 'service' parameter please
>>>>> let me know.
>>>>> The other option is to force the client to upgrade to the same version.
>>>>> Please let me know. Thanks.
>>>> Honza, do we have any other options than to break API between 4.2.0 and
>>>> 4.2.1?
>>> Another option is to keep 2 vault plugins. The old plugin (1.0) will handle 
>>> old
>>> IPA 4.2.0 clients. The new plugin (1.1) will handle the new IPA 4.2.1 
>>> clients.
>>> For this to work the plugins need to have different API URLs so they won't
>>> conflict/confuse the clients.
>> We do not have that versions in FreeIPA (yet?).
>>> Please also note that my next patch that adds the ability to change vault 
>>> type,
>>> password, and keys will also require a client upgrade because the 
>>> functionality
>>> is mainly implemented on the client side. In this case API URL versioning 
>>> will
>>> be necessary.
>> Adding new commands and/or attributes is a common thing in FreeIPA. We just 
>> do
>> the work, bump the minor API version and that's it. We planned having better
>> version support in FreeIPA 4.4, we will see how it goes.
> Martin, I do not think going on with business as usual is the right
> thing to do here. We know this is going to bite.
> I suggest Endy adds a *new* API if making it backwards compatible is not
> possible. The era of bumping whole API version must stop, the sooner the
> better.

My point is that we do not know yet how to do this kind of changes long term.
So what I did not want to end up are 2 copy&pasted Vault plugins maintained
forever, differing in just that.

If you know how to do this without copypasting, I will be fine with that.

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to