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

[Rob Crittenden]

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.
>
> 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.
>
> I'll submit a new patch with an updated spec but I think otherwise I've
> addressed the isuses Petr has raised. This thread has taken a lot of
> turns so it is very possible I missed something though :-)

Updated patch based on feedback from Foreman team. I added a new URI, 
/features, which Foreman uses to determine what capabilities a proxy has.

rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-1106-6-rest.patch
Type: text/x-patch
Size: 47452 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140227/b9722bb5/attachment.bin>