On 08/08/2016 01:31 PM, Jan Pazdziora wrote:
> On Mon, Aug 08, 2016 at 12:52:33PM +0200, Martin Kosek wrote:
>> I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so
>> me repeat my suggestion here. I still think it is premature to add plugins
>> that to FreeIPA core git. We are not agreed yet how we will distribute
>> plugins, so I would not rush adding this plugin to FreeIPA core, especially
>> since it is very experimental and not even secure yet. FreeIPA plugin
>> distribution should be more thought through and discussed.
>> As I proposed, this plugin can now live outside of FreeIPA core git, in it's
>> own life cycle (maybe in freeipa-plugins github git repo we create?) so that
>> can be updated without updating whole FreeIPA core. In this effort, I would
>> suggest to only consider updates of
>> * ipaserver/plugins/xmlserver.py
>> * ipaserver/rpcserver.py
>> as these would have to patched by admin deploying this feature and would be
>> overwritten by RPM updates. The plugin itself or server.conf can be deployed
>> and installed separatenly, even via other RPM.
> We want the feature (albeit experimental) to be available to upstream
> users and downstream customers, with as few steps to take and as few
> hoops to jump through as possible. Any bits we can get to users' and
> customers' hands via standard means are bits that they don't need to
> get from elsewhere, via nonstandard means, with us inventing and
> supporting these nonstandards processes.
> Assuming the mere existence of the functionality (which will be
> disabled by default) does not decrease security of the default
> installations and configuration, I don't see why carrying it poses
> a problem.
I see your reasoning, I just think it is not strong enough to rush this new
method of delivering plugins in before discussing it more broadly.
Also, as I mentioned, we may want different life cycle for FreeIPA plugins that
we want for FreeIPA core bits. Thus the different repository suggestion. This
whole feature is (still) non-standard and experimental, so I do not personally
see that big problem in non-standard delivery mechanism.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code