On 02/06/15 15:21, Jan Cholasta wrote:
Dne 11.5.2015 v 13:41 Jan Cholasta napsal(a):
Dne 6.5.2015 v 08:22 Jan Cholasta napsal(a):
Dne 6.5.2015 v 08:11 Martin Kosek napsal(a):
On 04/29/2015 06:25 PM, Jan Cholasta wrote:
Dne 20.4.2015 v 16:56 Jan Cholasta napsal(a):
Dne 20.4.2015 v 15:14 Martin Basti napsal(a):
On 17/04/15 16:15, Jan Cholasta wrote:
Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a):
the attached patch adds the basics of the new installer
As a next step, I plan to convert the install scripts to use the
framework with their old code (the old code will be gradually
the framework later).
(Note I didn't manage to write docstrings today, expect update
Added some docstrings.
Also updated the patch to reflect little brainstorming David and I
Hello, see comments bellow:
1) We started using new shorter License header in files:
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
2) IMO this will not work, NoneType has no 'obj' attribute
+ if isinstance(value, from_):
+ value = None
3) Multiple inheritance. I do not like it much.
+class CompositeInstaller(Installer, CompositeConfigurator):
I guess you are antagonistic to multiple inheritance because of how
other languages (like C++) do it. In Python it can be pretty elegant
is basis for e.g. the mixin design pattern.
Installer and CompositeConfigurator inherites from Configurator
and all of them implements _generator method.
Both of them call super()._generator(), so it's no problem (same for
If I understand correctly
Installer._generator method will be used in this case.
However in case when CompositeConfigurator has more levels
it is more specialized) of inheritance, it could take precedence
_generator method may be used instead.
The order of precedence is defined by the order of base classes
I'm afraid this may suddenly stop working.
Maybe I'm wrong, please fix me.
As long as you call the super class, it will work fine.
And Multiple inheritance is not easily readable, this is even a
Cooperative inheritance is used by design and IMHO is easily
you know how to read it. Every class defines a single bit of
Without cooperative inheritance, it would have to be hardcoded
hacked around, which I wanted to avoid.
This blog post explains it nicely:
Updated patch attached.
Also attached is patch 425 which migrates ipa-server-install to the
Good job there. I am just curious, will this framework and new option
processing be friendly to other types of option passing than just via
I mean tickets
Especially 4517 is important, we need to be able to run
# cat install.conf
# ipa-server-install --unattended --conf install.conf
I assume yes, but I am just making sure.
Updated patches attached.
Another update, patches attached.
ipa-server-install --uninstall prints 0
The ipa-server-install command was successful
'ServerOptions' object has no attribute 'dnssec_master'
For record, this will be fixed in extra patch.
info messages from ldapupdate are printed to console
+ if default is not _missing:
+ class_dict['default'] = default
Why is new _missing object needed? Isn't NoneType enough?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code