[Freeipa-devel] [PATCH] 1106 IPA REST smart proxy

[Rob Crittenden]

Dmitri Pal wrote:
> On 02/17/2014 02:33 PM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote:
>>>> Martin Kosek wrote:
>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote:
>>>>> +1, this was exactly my goal. It is easy to name and organize things
>>>>> now,
>>>>> difficult to do when it is live upstream and/or integrated with
>>>>> Foreman.
>>>>>
>>>>> I think the key for the right naming is a fact if this is really
>>>>> specific to
>>>>> Foreman or it is a truly general design usable also in other use
>>>>> cases. If
>>>>> Foreman-specific, I would go with freeipa-server-smartproxy-host or
>>>>> similar.
>>>>>
>>>>> If general, we can go with
>>>>>
>>>>> freeipa-server-proxy-host
>>>>> freeipa-server-proxy-user
>>>>> freeipa-server-proxy-dhcp
>>>>>
>>>>> The proxies may share the framework and only expose the requested
>>>>> part of the
>>>>> tree - which in advance gives you an option for an API separation, as
>>>>> compared
>>>>> to general freeipa-server-smartproxy.
>>>>
>>>> I still don't get the point of this. Are you proposing having 3
>>>> different servers, each providing a unique service? Or one service
>>>> that one can turn on/off features, or something else? Do you envision
>>>> this as 3 separate subpackages?
>>>>
>>>> There is no "framework" in my current patch, it is a cherrypy server
>>>> that exposes parts of IPA on a given URI. It is the thinnest of layers.
>>>
>>>
>>> Then it seems to make sense to have 3 different packages that can be
>>> optionally coninstalled and would probably share the same principal,
>>> keytab and local REST API socket/port.
>>>
>>
>> Well, what you are designing is a central framework with plugins. What
>> I designed is a quick-and-dirty get something up quickly. We need to
>> pick one. The plugable method is going to require a fair bit of
>> rework, though it will potentially pay dividends in the future.
>
> I think that we can start where you are but drive towards this
> architecture via refactoring. But we need to pick the right name now.
> Even if the architecture is not there yet we should name the package in
> such way that it does not preclude us from moving towards a clean
> architecture I described during the next iteration.

Just having a hard time seeing the value. This would be like making each 
of the IPA plugins a separate package and somehow installing them 
individually.

To do this you'd need at least 2 packages, a high level one with the 
"framework" and then a separate one for each data type.

This could also be achieved, and likely more cleanly, without all these 
extra packages, as a simple configuration file. Once a package, always a 
package.

Maybe I'm too close to the problem, but to me this is a Foreman-specific 
solution. The "smartproxy" is a Foreman creation, I don't know that 
anything else is using it. If you want a RESTful server, then we enable 
REST in IPA directly, but selectively enabling and disabling APIs is not 
something we've done before. It has been controlled by ACIs instead.

rob