In replication panel the cleanAllRuv is displayed whatever the role of the instance. Could it be displayed only for multimaster instance.
Also minor comment, would it be possible in replication agreement to display the port
NA
not so sure about this - in cockpit we see one instance, we can determine if it is a master, but if it is multimaster could only be derived from the RUV which might not be reliable (deasd rids, no updates seen,,). So in cockpit I would only distinguish master/hub/consumer - it makes sense to allow cleanallruv only on masters, it should be propagated, what about cleanruv ? will it be completely removed or hidden ?
Metadata Update from @lkrispen: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
@tbordaz Yes, I can separate the agmt port number to a new column. I will also hide the CleanAllRUV table on hubs/consumers.
@lkrispen I thought cleanruv was essentially deprecated, but I could easily add a button to run a "cleanruv" task if you want.
no, I think cleanruv should silently go away. what abou the replication roles ? I think it is only master, not single or multi
Thanks Mark for the RA port. I agree with Ludwig, not easy to know if we are single/multi. So just dropping hub/consumer would be good
I'm fine removing the "multi-master" role. I actually just added it the other day, and the idea was that it would "enable" the replication managers" list, and disable it for other roles. But I think it will cause more confusion, so I will drop it and improve the hover text. Thanks for the feedback/suggestions! Keep them coming...
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue tagged with: Cockpit
While we are on the topic...
Replication managers list. It is multivalued, but I don't know if it's actually used that way by customers. I kind of want to make it appear as a single value/field and not a list. I don't want to take functionality away, but it would make the UI a bit cleaner. Thoughts?
While we are on the topic... Replication managers list. It is multivalued, but I don't know if it's actually used that way by customers. I kind of want to make it appear as a single value/field and not a list. I don't want to take functionality away, but it would make the UI a bit cleaner. Thoughts?
In the agreement ? there should only be one. I am not aware that we would chose or fallback to another repl manager
While we are on the topic... Replication managers list. It is multivalued, but I don't know if it's actually used that way by customers. I kind of want to make it appear as a single value/field and not a list. I don't want to take functionality away, but it would make the UI a bit cleaner. Thoughts? In the agreement ? there should only be one. I am not aware that we would chose or fallback to another repl manager
Using the current console you can set many "update" dn's for a backend (sorry I should have been clearer):
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaType: 3 nsDS5Flags: 1 nsDS5ReplicaId: 1 nsds5ReplicaPurgeDelay: 604800 cn: replica nsDS5ReplicaName: 1b3cc804-f60f11e7-b809b747-a7ad338d nsDS5ReplicaBindDN: cn=repl manager1,cn=config nsDS5ReplicaBindDN: cn=repl manager2,cn=config nsDS5ReplicaBindDN: cn=repl manager3,cn=config
@mreynolds do you know if it would be possible to display the config attribute that will be updated by a given field ? Not display it in permanence but something like a comment that popup if you keep the cursor on the field ?
ok, nsDS5ReplicaBindDN, yes that is multivalued and used with multiple values. and, if you not have it already, we now also have a nsDS5ReplicaBindDNGroup which is probably not it the current console, but is used, especially by IPA
It already does this for ALL the attribute settings in the UI - try it ;-) Except for the replication manager list - that one is missing, but the rest are all there :-p
It's there under the replication advanced settings.
So does the bind group obsolete the update dn list?
Going back to my original question, do I leave the Update DN List as is, or change it to look like a single value?
no, the binddngroup is an enhancement, I think there are different deployment strategies. The simplest is to have single repl manager all over the topology, others do explicitely want to set which replica can update which consumer and define lits of repl managere. If, like IPA, the binddn is a kerberos principal and it is dynamic, it is easier to manage a group which is replicated. In short, I think, we need both and support multiple values
Works for me - nothing to change then :-)
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4 backlog
Fixed
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2587
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.