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

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

Reply via email to