[Freeipa-devel] [PATCH] 369 Added CLI param and ACL for vault service operations.

[Simo Sorce]

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York