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

[Dmitri Pal]

On 02/21/2014 11:09 AM, Martin Kosek wrote:
> On 02/21/2014 04:37 PM, Rob Crittenden wrote:
>> 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?
>>>
>> Ok, so try to summarize this long-running thread, I'll rename the subpackage to
>> freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now
>> it requires manual configuration so having the package installed should have no
>> negative impacts (other than potentially pulling in additional dependencies).
>>
>> I'll leave it in smartproxy for now, it's just cleaner and better integrates
>> with ipatests IMHO.
> Ok, sounds reasonable to me.
>
>> Foreman supports SSL client auth which is great, by cherrypy does not yet.
>> There is a pull request to add this,
>> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity
>> . Foreman otherwise supports no other authentication method, so we're blocked
>> with this. The certs for this would initially come out of Foreman/puppet.
> Does that then mean that the first version will be without any authentication
> or socket connection? Is that OK with everybody?
>
> Martin
The pull request seems like a year old and suck. Any way to unstuck it?
Can we accept the changes so far by not release it upstream until the 
change is accepted and help with it to be accepted?
We can still start developing and integrating with Foreman using smart 
proxy without authentication for now and include it once the problem 
above is sorted.
It would be a blocker for IPA release though so we should look into it 
but it should not be a blocker for this patch review.
May be we should add a ticket to IPA trac this so that we explicitly 
indicate that we can't release if this cherrypy auth issue is not resolved.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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