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 >> let >> me repeat my suggestion here. I still think it is premature to add plugins >> like >> that to FreeIPA core git. We are not agreed yet how we will distribute >> FreeIPA >> 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 >> it >> 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. 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