On 02/14/2013 05:01 PM, Simo Sorce wrote:
On Thu, 2013-02-14 at 16:29 +0100, Petr Viktorin wrote:
Then I recommend doing this. It avoids problems with delegation (the
"real" tree permissions are used) and looping (plugin and IPA write to
separate trees).


Virtual objects are not free of issues, you are just trading some issues
for others here, and I do not think you are properly evaluating the
trade here.

I am dead set against using staging areas, and I want to see proof they
are a good idea, not handwaving 'fears' of using json in the server to
forward operations directly to the framework.

  Other operations (deletes, mods) can be either
similarly delegated to the "real" tree,

And *this* is a slippery slope. you are trading delegating one single
operation to the framework directly, with proper error propagation back
to the client, with now implementing full virtualized operations for mod
and delete, and bind ? and search and then ?

You are now basically paving the way for a virtual directory in tree.

Sorry, but no.

or passed through IPA if we want to do that in the future.

Problems with replication can be solved by just not replicating the
separate tree.

More and more hacks, for this supposedly 'cleaner' or 'simpler'
solution ... sorry if I don't bite.

It also doesn't pollute core IPA with special cases, which is what
worries me.

What does this mean ?

We *have* a special case, and we are discussing how to handle it.

The situation here (I do not want to call it a 'problem') is that we
decided to put business logic around user creation in the framework
because we thought that would be easier to prototype and develop in
python code rather than in a plugin.

However this special handling *must* be limited. LDAP is our main
storage, and we must allow LDAP operations against it. Special cases
needs to be limited to things that are really harder done in plugins
rather then python code.

For example if we need triggers for some operations in LDAP, they *must*
be done through a 389ds plugin. Otherwise LDAP quickly becomes a
read-only interface and interoperability quickly goes out of the window.

I always treated the framework as a *management interface* on top. We
can do things that are 'convenient', and 'help' admins avoid mistakes,
but we cannot move core functionality in the framework, it would be a
grave mistake. User creation *is* a special case, but should remain one
of very few special exceptions.

This very thread and the need for the interface proposed in this thread
is a clear example of why we need to be extremely careful not to be too
liberal with what business logic we move in the framework.

LDAP keeps us honest, so we need to limit what we do in the framework,
otherwise we'll keep taking shortcuts and soon enough it goes out of
control and we loose interoperability with anything that is not
purpose-built to talk to our framework.

This should be an unacceptable scenario because it is like putting
ourselves in a getto.

We trade greater interoperability and acceptance for small conveniences
here and there.

We must thread *very* carefully along this line.

Simo.


Ah! This is a point we need to stress more, I didn't get it. All this time I thought of it the other way -- IPA being the main interface, with LDAP being more of an implementation detail -- the storage, and a read-only interface for LDAP consumers.

Thanks for explaining, your solution makes perfect sense then.

However, if there are more people like me, then there's code in IPA that assumes IPA is the only interface modifications, and raw LDAP operations are hacks that happen to work for now.
IPA's command plugins also seem misguided now, as you pointed out.


I don't like this view much but, well, I can adapt.
Allowing writes by tools that aren't purpose-built to talk to our framework, (for example ones that don't honor our schema), still seems like something to be wary of.

--
PetrĀ³

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to