On 02/14/2014 12:07 AM, Rob Crittenden wrote:
I will leave functional testing to others, I just read the code.
Martin Kosek wrote:
I think I've addressed most of Petr's suggestions with the
On 01/28/2014 09:35 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 01/23/2014 02:17 PM, Petr Viktorin wrote:
+1 for moving to /ipa/smartproxy/rest, we will want a complete
The URL endpoint /ipa/rest suggests that if we implement a
API for IPA it would live here. Is the API supposed to be
future-compatible? (The API itself seems to be a good subset
complete REST API, but can we easily add an frontend with
authentication, i18n, etc. here later, and keep the
Perhaps /ipa/smartproxy would be a better choice?
It was future-proofing. I'm fine with changing the URI, it is
probably a good
thing to save that name.
in ipa/rest/ in the future. I rather opened a ticket to track
global ipa handle and I stuck with *args, **options as this is
standard in IPA calls.
The gssproxy.conf.snippet just makes it easier to copy/paste. I
drop it if
you want, I suppose it is duplication.
Note that I ran this past the Foreman design again and as a result
another interface, /realm. It was my understanding that this
wasn't set into stone but a patch is working its way through their
followed the spec so I went ahead and added it. It isn't a big
class handles it out of the box.
I also updated the design page a bit to reflect some of the
Right now there are no plans to backport python-kerberos to F20.
quite concerned about the positioning, naming and "branding" of
1) Package name
Currently, it is a host/hostgroup smartproxy, primarily for Foreman
Packaging it as freeipa-server-smartproxy may be ok, but only if we
plan to use
this proxy for all other projects. I.e. if we one day implement
smartproxy, it would need to be part of this otherwise it would
organization, like having freeipa-server-smartproxy and
freeipa-server-smartproxy-users packages. Maybe it should be named
2) ipa-rest stuff
We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest
However, I have the same concerns as above. This is too general
conflict with future core server needs (like when we implement core
interface - #4168). Let us name it consistently with package name:
The same for binary, man, ...
3) Man pages
The same point, you brand it as "IPA REST server". This is too
To sum it up - let us chose one name/brand of this feature and
consistently in FreeIPA infrastructure - subpackage name,
subdirectory in ipatests, man, conf, script, names in man pages.