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

[Martin Kosek]

On 02/18/2014 12:11 AM, Dmitri Pal wrote:
> On 02/17/2014 04:57 PM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote:
>>>> 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
>>>>
>>>
>>> We are trying to predict future here. Say we release it as you suggest.
>>> Tomorrow we point someone upstream who wants to add users to IPA from a
>>> similar proxy to this implementation and say use this as a model.
>>> And then Rich needs the same but for DNS for Designate.
>>>
>>> What would be the best? Rob if you knew that tomorrow two other
>>> developers will create similar proxies for users and DNS would you
>>> change anything? Would you provide some guidelines to them?
>>> If you are close to the problem you should be able to at least tell
>>> them: "copy and paste" vs. "add more APIs to the same proxy".
>>> If your recommendation is copy and paste then I suspect there will be
>>> challenges of running these proxies on the same machine - they will
>>> collide on ports and sockets. If we say "extend" shouldn't we use a more
>>> generic name?
>>>
>>
>> I'd say "use the existing IPA API". The only reason we have to write the
>> smartproxy at all is to interoperate with another service that already has a
>> well-defined remote server API which uses REST.
>>
>> rob
> OK, so you think that proxy is one off. OK I am fine with it.
> I was under assumption that it would be a beginning of a trend but I might be
> wrong as I do not have valid arguments to prove or disprove one way or another.
> I guess time would show.
>
> Any objections to Rob's approach?

If this is a one off, specifically designed only for Foreman use case, my 
question is - do we really want to have this as a part of core FreeIPA repo and 
a part of it's core subpackages? So that when somebody installs all packages 
from our repo, he gets Foreman one-off installed?

Wouldn't it be better then to keep the FreeIPA smartproxy in a separate package 
to avoid having FreeIPA core full of one-offs? In my mind, FreeIPA is a general 
purpose IdM solution and this part does not follow the picture...

Just brainstorming here...

Martin