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

[Dmitri Pal]

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?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/