Framework execute callback feedback
by Rob Crittenden
Currently the framework has four types of methods:
- pre_callback: called before any real work is done. Usually used to
tune up incoming options
- execute: does the brute work. For most CRUD plugins this is all done
in baseldap.py in the LDAP* classes
- post_callback: supposed to be data cleanup for presentation to the
caller but in some cases actual work is being done. user-add calls
ldap.add_entry_to_group for example.
- exc_callback: special case handling for exceptions
If you have "work" to be done that would normally be done in execute
there is no way to do it other than to abuse post_callback to get it done.
Overriding execute is only an option if you want to completely replace
the call, otherwise order execution is going to be strange.
Say for example in user_add you want to do work after the execute() is
done so you'd do something like:
class user_add()
def execute(stuff):
result = super(user_add, self).execute(stuff)
# some extra work
return result
The order of execution is:
user_add:pre_callback
user_add:execute()
LDAPCreate:execute()
user_add:post_callback()
user_add:execute()
This is because the LDAP* baseldap methods handle the pre/post/exc
callbacks directly. So in order to be able to insert more "work" in
execute itself we'd need another callback type.
Why do I want this?
One feature of post_callback is that for add/mod methods
ldap.get_entry() is called so we can prepare the final results to be
returned to the user for display.
There are cases where the user doesn't need or case to see that result.
We could save an least one LDAP query by returning only errors in this case.
The use case is mostly around bulk operations where the user doesn't
care about seeing the UID of all users added, for example.
To do this I think we can skip post_callback altogether, assuming it
does no real "work".
In the case of user_add/mod skipping post_callback would save three
queries: fetch the user, has_keytab and has_password.
But before re-architecting this I'd like to get some opinions on it.
I can do a full-blown design if desired.
rob
2 years, 10 months
[freeipa PR#5722][opened] workshop: Use default fedora cloud image
by netoarmando
URL: https://github.com/freeipa/freeipa/pull/5722
Author: netoarmando
Title: #5722: workshop: Use default fedora cloud image
Action: opened
PR body:
"""
Use publicly available Fedora cloud box, removing the necessity of building custom boxes with preinstalled packages.
This removes the burden of maintaining boxes up-to-date, in the other hand one must fetch the packages for all hosts in the topology before starting the curriculum.
Signed-off-by: Armando Neto <abiagion(a)redhat.com>
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/5722/head:pr5722
git checkout pr5722
2 years, 10 months
[freeipa PR#5605][opened] Add ACME profile on replica install in non-ACME environment
by rcritten
URL: https://github.com/freeipa/freeipa/pull/5605
Author: rcritten
Title: #5605: Add ACME profile on replica install in non-ACME environment
Action: opened
PR body:
"""
Always import the default certificate profiles
The default certificate profiles were not imported for
in a promoted client installation.
This could lead to missing profiles, as was seen in the ACME
case, while upgrading from older versions.
The sequence was:
1. Install a non-ACME IPA server
2. Install an ipa client
3. On the client promote to a server with a build that supports
ACME.
The resulting installation is missing the acmeIPAServerCert
profile because it is provided in INCLUDED_PROFILES which isn't
loaded during promotions.
There is already handling to handle issues if the profile already
exists so it is safe to call this on every installation.
https://pagure.io/freeipa/issue/8738
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/5605/head:pr5605
git checkout pr5605
2 years, 11 months
[freeipa PR#5681][opened] Implement simple LDAP cache layer
by rcritten
URL: https://github.com/freeipa/freeipa/pull/5681
Author: rcritten
Title: #5681: Implement simple LDAP cache layer
Action: opened
PR body:
"""
Pretty straightforward caching except for the attribute
handling. We probably won't want to cache the entire entry
since that could be expensive (userCertificate, ssh keys, etc)
but not storing it could lead to multiple requests for the
same thing. Also, requesting * vs a set of attributes may not
return all a plugin needs, as it will skip operational attributes.
Still, this saves 20-50% of queries in my limited testing.
Mar 29: initial implementation works about 80% of the time.
I guarantee the xmlrpc tests will fail. We'll see about the integration tests.
There are still corner cases to find and the member modlist stuff
is a mess.
"""
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/5681/head:pr5681
git checkout pr5681
2 years, 11 months