On 10/23/2015 11:24 AM, thierry bordaz wrote:
On 10/23/2015 11:00 AM, thierry bordaz wrote:
On 10/12/2015 01:17 PM, Ludwig Krispenz wrote:
On 10/12/2015 12:44 PM, Martin Basti wrote:
it should be still valid, waiting for review, wanted to rebase
after topology/promotion patches have been checked in and resend
On 23.07.2015 10:46, Ludwig Krispenz wrote:
The attached patch moves the cleaning of the RUV into the topology
I encountered a problem when removing a replica, which disconnects
the topology, but it was fixed with my WIP for #5072.
I want to keep these issues separate, so please review and test
the patch and let me know about issues found
Is this patch still valid and pending review?
The patch looks good. I have few minor remarks:
* Are the hostname in ruv always fqdn ? to retrieve the RUV element
of a given host you use 'strstr'.
If you have host vm-11 and vm-112, I wonder if it could pickup
the wrong RUV element
* In ipa_topo_util_cleanruv_element you need a pblock_done/free (or
* In it fails to add the clearn-ruv task, you should log a message
so that the admin knows what to do.
I will adress the points raised, thank you
Additional question. cleanruv is done with 'replica-force-cleaning:
yes'. Currently ipa-replica-manage does not implement this flag.
Why do you use it in topology plugin.
there are two potential problems with the cleanallruv task:
1] the rid could come back if not all servers were in sync, but with
cleaning the changelog as part of cleanallruv I think the ris is low now
2] the cleanallruv is stuck on waiting for the task to complete on other
servers even if they cannot be reached
I want to avoid 2] therefore I choose this setting
My concern is that if we delete a host before all the updates from
that host has been received, could we receive a late update that will
recreate the ruv element ?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code