[Freeipa-devel] [PATCH] move replication topology to shared tree

[Petr Viktorin]

On 10/14/2014 10:21 AM, Ludwig Krispenz wrote:
>
> On 10/10/2014 06:21 PM, Simo Sorce wrote:
>> On Fri, 10 Oct 2014 17:52:15 +0200
>> Ludwig Krispenz <lkrispen at 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
> we already have ipa-replica-manage and ipa-csreplica-manage, and
> - I did'n want to integrate the topology management into both and
> duplicate code
> - there is much change on the way to refactor the ipa commands, to move
> code into libraries, to expose to openLMI
> and I have no clear picture yet how this will look like, so I thought
> implementing the management command as subclasses of admintool would be
> a good starting point - I do not insist that ipa-topology-manage will
> survive as a command in the end, but I also do not want to mess with
> ipa-replica-manage and ipa-csreplica-manage now, when these changes also
> probably would have no future.

+1 Given the pending refactoring of ipa-replica-manage, I think a 
separate tool for now is better way to get to the result Simo wants.
For now I'd put a TODO in ipa_topology_manage saying the CLI is not final.

Of course, if anything can be moved to framework commands, that should 
happen now.


Ludwig, please use self.log.info(...) (or .error(), etc.) instead of 
print for messages, unless the message doesn't make sense in a log file 
(e.g. prompting for interactive input).

-- 
Petr³