On 10/14/2014 04:38 PM, Simo Sorce wrote:
On Tue, 14 Oct 2014 11:46:47 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:

On 10/10/2014 06:21 PM, Simo Sorce wrote:
On Fri, 10 Oct 2014 17:52:15 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:

Hello,

this is the current status of my work on #4302, and there are a few
pieces still missing, eg the management command needs more input
checking and error handling, but
- I wanted to give people interested a chance to have a look again
and get feedback
- there came up the following questions I would like to get an
opinion.
First thing, I do not think we want a new command here.
If we need commands outside of the ipa framework they should be
integrated in the ipa-replica-manage tool.
But really one of the reasons to move data in the shared tree was
that we could grow native framework command to handle the topology
so we can manage the topology directly from the UI.
So I am not happy with ipa-tology-manage

when thinking how to move from an existing deployment with direct
management of replication agreement to the new way, there should
not be any intermediate disconnects, and if possible transition
should be made easy. So I think we should have defined a few modes
of operation for the plugin:
- initial/bootstrap [optional] - the plugin detects existing
agreements and transforms it to segments in the shared tree
This should not be optional imo, its the only way to do sane
upgrades. When the plugin starts it needs to check if there are
replication agreements with other freeipa servers (it should ignore
anything else).
it is fine for me if it is not optional, I agree that it is needed
for smooth upgrades.
the reason that I brought this up is that I had the impression that
it is not wanted, that
configuration should be in full responsibility of an admin creating
the shared topology from
scratch.
If we agree that the shared topology should be populated from
existing agreements I'm happy, if not I would make it at least
optional.
Yes I think it makes sense to do so. We want a change as transparent
as possible.

the problem to solve is, when does this auto generation stop ?
My idea is that the new replication agreements in cn=config are tagged
so only those that are untagged get "imported" at startup.

Once the plugin has started we deny access to create arbitrary
agreements between 2 ipa servers, so "import" will simply not happen.

NOTE: I think the code must allow creation of agreements between 1 IPA
server and an unrelated server, but those will not match the 'both
server are IPA servers condition so no "import" will happen.

I think it should be done only once, at the initial startup of the
plugin and not allow to bypass the topology plugin later by stopping
th eserver, editing cn=config to add a new agreement and having it
added at startup to the shared tree,
so there shoul be some way to flag that the initial phase is done.
I do not think this is necessary. I think it is fine to import whatever
untagged agreements are found if both servers they reference are IPA
servers.

I'm not sure if this can and should be handled with naming
conventions.
I think agreements that are generate by the topology must be tagged so
you know this is not a pre-existing agreement that you have to import,
rather an agreement you have to validate or delete.
Tagging can be done via naming convention or by adding some additional
attribute. I think naming convention would be the easiest solution.

Then check if these agreements have been autogenerated (this should
be determined by new naming conventions for agreements in
cn=config) or if they are pre-existing, if they are pre-existing
then new shared entries will be generated in the shared tree.

Note: this upgrade thing could also be done in ipa-upgrade plugins,
at server upgrade time. Whichever is easier (main concern is if 2
servers are upgraded at the same time replication conflicts may
arise).

- pending - the plugin handles and propagates segments in the
shared tree, but does not enforce teh deletion or creation of
replication agreements
Not sure what you mean here, but I think that once the plugin is
active it should stay active and actively prevent manual changes to
automatically created replication agreements.
why I wanted this state had two reasons.
- Since the information in the shared tree is authoritative and if
you start to build the shared tree from scratch (if the above
initialization would not be done)
there is the problem that adding the shared topology is not atomic,
one segment is added, all others do not yet exist and other
replication agreements
would be deleted, in the best case replication is just interrupted.
I am not sure I follow this, can you give an example of how this would
happen ?
If we agree that initially existing replication agreements will be loaded and made into segments this is not a concern.

So I was suggesting a pending mode, you can  add/delete segments from
the shared tree, verify connectivity and then say go and let the
shared tree become authoritative.
Why automatically importing agreements would not work ?
The plugin itself can bypass topology checks when importing so you
should simply end up with whatever is the current situation in your
domain once all servers have been upgraded.

I think it is actually crucial that it can work this way because server
will take some times to be upgraded one after the other, so for some
time there will be some servers with the topology plugin activated and
some that do not have it. Incomplete topology info will be expected.
Also exposing the topology plugin in rootDSE here gain us a big win as
the UI can show which servers still do not have the plugin enabled (as
opposed to malfunctioning servers) and can mark deal appropriately
with missing topology links by showing them grayed out until the old
replica gets updated or something like that.

- A similar problem arises when adding a new replica, we had decided
to leave ipa-replica-install untouched, so it will install a new
server and try to setup replication agreements between the server
replica-prepare was run and the new replica, but it would be rejected
by the plugin when it is enforcing new agreements to be generated
only via shared config. So temporariliy disable the authority of the
plugin could help.
Actually I was not a ware this decision was made, seriously, one of the
main drivers for this feature is to get replica installation to finally
stop needing DM passwords, so I am completely taken back by this
decision to not touch ipa-replica-install/ipa-replica-manage and insted
introduce ipa-topology-manage, I think we are only adding more work
later to reconcile tools and change them and making life harder by
adding this problem that new replicas can't properly add themselves to
the topology until after they are fully installed. Sounds wrong.
maybe that was a misunderstanding or we didn't discuss far enough, but I understand your and Rob's concerns and will rework this.

Simo.

- active - directe management of replicatio agreements is rejected,
existing segments ond their modifications are applied
This should always be.

I did run my tests of the management command as directory manager
since admin did not have permissions to read plugin configuration
in cn=config,
Why would you need to access cn=config ?
All management should happen in the shared tree, moving to be able
to avoid directly touching cn=config and avoid the need for DM
password is one of the main reasons to do this work ...

I can add permissions, probably will also need permissions
for the part in the shared tree, so what is the expected operation
mode, which user needs access to the shared config data and
configuration ?
We need to introduce a role for "Replication Admins" and make the
admins group a member by default, then use normal permissions
framework to regulate access.

Simo.





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

Reply via email to