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

[Rob Crittenden]

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