Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
On 08/06/15 15:17, Martin Basti wrote: On 08/06/15 12:12, Jan Cholasta wrote: Dne 3.6.2015 v 15:02 Martin Basti napsal(a): 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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. Updated patches attached. Another update, patches attached. thank you, 1) ipa-server-install --uninstall prints 0 ... Unconfiguring ipa_memcached Unconfiguring ipa-otpd 0 The ipa-server-install command was successful Fixed. 2) ipa-server-install --setup-dns 'ServerOptions' object has no attribute 'dnssec_master' Fixed. 3) For record, this will be fixed in extra patch. info messages from ldapupdate are printed to console Could you provide the patch? 4) +if default is not _missing: +class_dict['default'] = default Why is new _missing object needed? Isn't NoneType enough? None is a valid value here, there needs to be a distinction between value is not set and value is set to None. Updated patches attached. Note you first have to apply my patches 436-438. NACK Please provide a realm name [ABC.EXAMPLE.COM]: 'installer(Server)' object has no attribute 'unattended' also please fix private_ccache import. This function should be imported directly from ipautil, not via installutils I forgot to paste the traceback, here it is: DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipapython/install/cli.py, line 216, in run cfgr.run() File /usr/lib/python2.7/site-packages/ipapython/install/core.py, line 278, in run self.validate() File
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
Dne 8.6.2015 v 15:19 Martin Basti napsal(a): On 08/06/15 15:17, Martin Basti wrote: On 08/06/15 12:12, Jan Cholasta wrote: Dne 3.6.2015 v 15:02 Martin Basti napsal(a): 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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. Updated patches attached. Another update, patches attached. thank you, 1) ipa-server-install --uninstall prints 0 ... Unconfiguring ipa_memcached Unconfiguring ipa-otpd 0 The ipa-server-install command was successful Fixed. 2) ipa-server-install --setup-dns 'ServerOptions' object has no attribute 'dnssec_master' Fixed. 3) For record, this will be fixed in extra patch. info messages from ldapupdate are printed to console Could you provide the patch? 4) +if default is not _missing: +class_dict['default'] = default Why is new _missing object needed? Isn't NoneType enough? None is a valid value here, there needs to be a distinction between value is not set and value is set to None. Updated patches attached. Note you first have to apply my patches 436-438. NACK Please provide a realm name [ABC.EXAMPLE.COM]: 'installer(Server)' object has no attribute 'unattended' also please fix private_ccache import. This function should be imported directly from ipautil, not via installutils Fixed. I forgot to paste the traceback, here it is: DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipapython/install/cli.py, line 216, in run cfgr.run() File /usr/lib/python2.7/site-packages/ipapython/install/core.py, line 278, in run self.validate() File
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
Dne 8.6.2015 v 17:27 Martin Basti napsal(a): On 08/06/15 15:53, Jan Cholasta wrote: Dne 8.6.2015 v 15:19 Martin Basti napsal(a): On 08/06/15 15:17, Martin Basti wrote: On 08/06/15 12:12, Jan Cholasta wrote: Dne 3.6.2015 v 15:02 Martin Basti napsal(a): 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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. Updated patches attached. Another update, patches attached. thank you, 1) ipa-server-install --uninstall prints 0 ... Unconfiguring ipa_memcached Unconfiguring ipa-otpd 0 The ipa-server-install command was successful Fixed. 2) ipa-server-install --setup-dns 'ServerOptions' object has no attribute 'dnssec_master' Fixed. 3) For record, this will be fixed in extra patch. info messages from ldapupdate are printed to console Could you provide the patch? 4) +if default is not _missing: +class_dict['default'] = default Why is new _missing object needed? Isn't NoneType enough? None is a valid value here, there needs to be a distinction between value is not set and value is set to None. Updated patches attached. Note you first have to apply my patches 436-438. NACK Please provide a realm name [ABC.EXAMPLE.COM]: 'installer(Server)' object has no attribute 'unattended' also please fix private_ccache import. This function should be imported directly from ipautil, not via installutils Fixed. I forgot to paste the traceback, here it is: DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipapython/install/cli.py, line 216, in run cfgr.run() File
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
On 08/06/15 15:53, Jan Cholasta wrote: Dne 8.6.2015 v 15:19 Martin Basti napsal(a): On 08/06/15 15:17, Martin Basti wrote: On 08/06/15 12:12, Jan Cholasta wrote: Dne 3.6.2015 v 15:02 Martin Basti napsal(a): 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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. Updated patches attached. Another update, patches attached. thank you, 1) ipa-server-install --uninstall prints 0 ... Unconfiguring ipa_memcached Unconfiguring ipa-otpd 0 The ipa-server-install command was successful Fixed. 2) ipa-server-install --setup-dns 'ServerOptions' object has no attribute 'dnssec_master' Fixed. 3) For record, this will be fixed in extra patch. info messages from ldapupdate are printed to console Could you provide the patch? 4) +if default is not _missing: +class_dict['default'] = default Why is new _missing object needed? Isn't NoneType enough? None is a valid value here, there needs to be a distinction between value is not set and value is set to None. Updated patches attached. Note you first have to apply my patches 436-438. NACK Please provide a realm name [ABC.EXAMPLE.COM]: 'installer(Server)' object has no attribute 'unattended' also please fix private_ccache import. This function should be imported directly from ipautil, not via installutils Fixed. I forgot to paste the traceback, here it is: DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipapython/install/cli.py, line 216, in run cfgr.run() File /usr/lib/python2.7/site-packages/ipapython/install/core.py, line
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. Updated patches attached. Another update, patches attached. thank you, 1) ipa-server-install --uninstall prints 0 ... Unconfiguring ipa_memcached Unconfiguring ipa-otpd 0 The ipa-server-install command was successful 2) ipa-server-install --setup-dns 'ServerOptions' object has no attribute 'dnssec_master' 3) For record, this will be fixed in extra patch. info messages from ldapupdate are printed to console 4) +if default is not _missing: +class_dict['default'] = default Why is new _missing object needed? Isn't NoneType enough? -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
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):
Hi,
the attached patch adds the basics of the new installer framework.
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
ported to
the framework later).
(Note I didn't manage to write docstrings today, expect update
tomorrow.)
Added some docstrings.
Also updated the patch to reflect little brainstorming David and I
had
this morning.
Honza
Hello, see comments bellow:
1) We started using new shorter License header in files:
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
OK.
2) IMO this will not work, NoneType has no 'obj' attribute
+else:
+if isinstance(value, from_):
+value = None
+stack.append(value.obj)
+continue
Right.
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
and
is basis for e.g. the mixin design pattern.
Installer and CompositeConfigurator inherites from Configurator
class,
and all of them implements _generator method.
Both of them call super()._generator(), so it's no problem (same for
other methods).
If I understand correctly
(https://www.python.org/download/releases/2.3/mro/) the
Installer._generator method will be used in this case.
However in case when CompositeConfigurator has more levels
(respectively
it is more specialized) of inheritance, it could take precedence
and its
_generator method may be used instead.
The order of precedence is defined by the order of base classes in the
class definition.
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
diamond
inheritance model.
Cooperative inheritance is used by design and IMHO is easily
readable if
you know how to read it. Every class defines a single bit of behavior.
Without cooperative inheritance, it would have to be hardcoded and/or
hacked around, which I wanted to avoid.
This blog post explains it nicely:
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/.
Updated patch attached.
Also attached is patch 425 which migrates ipa-server-install to the
install
framework.
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
options?
I mean tickets
https://fedorahosted.org/freeipa/ticket/4517
https://fedorahosted.org/freeipa/ticket/4468
Especially 4517 is important, we need to be able to run
# cat install.conf
ds_password=Secret123
admin_password=Secret456
ip_address=123456
setup_dns=False
# ipa-server-install --unattended --conf install.conf
I assume yes, but I am just making sure.
Yes, definitely.
Updated patches attached.
Another update, patches attached.
--
Jan Cholasta
From 1426620a2bc89ab74689ca6ede075ebc398bab9e Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Tue, 2 Jun 2015 12:04:25 +
Subject: [PATCH 1/2] install: Introduce installer framework ipapython.install
https://fedorahosted.org/freeipa/ticket/4468
---
freeipa.spec.in | 2 +
ipapython/Makefile| 1 +
ipapython/install/__init__.py | 7 +
ipapython/install/cli.py | 253 +
ipapython/install/common.py | 114 ++
ipapython/install/core.py | 506 ++
ipapython/install/util.py | 169 ++
ipapython/setup.py.in | 4 +-
8 files changed, 1055 insertions(+), 1 deletion(-)
create mode 100644 ipapython/install/__init__.py
create mode 100644 ipapython/install/cli.py
create mode 100644 ipapython/install/common.py
create mode 100644 ipapython/install/core.py
create mode 100644 ipapython/install/util.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 09dd66e..bedcb6d 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -882,6 +882,8 @@ fi
%{python_sitelib}/ipapython/*.py*
%dir %{python_sitelib}/ipapython/dnssec
%{python_sitelib}/ipapython/dnssec/*.py*
+%dir %{python_sitelib}/ipapython/install
+%{python_sitelib}/ipapython/install/*.py*
%dir %{python_sitelib}/ipalib
%{python_sitelib}/ipalib/*
%dir %{python_sitelib}/ipaplatform
diff --git a/ipapython/Makefile b/ipapython/Makefile
index b2cf719..8527643 100644
--- a/ipapython/Makefile
+++ b/ipapython/Makefile
@@ -10,6 +10,7 @@ all:
(cd
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Updated patch attached. Also attached is patch 425 which migrates ipa-server-install to the install framework. 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 options? I mean tickets https://fedorahosted.org/freeipa/ticket/4517 https://fedorahosted.org/freeipa/ticket/4468 Especially 4517 is important, we need to be able to run # cat install.conf ds_password=Secret123 admin_password=Secret456 ip_address=123456 setup_dns=False # ipa-server-install --unattended --conf install.conf I assume yes, but I am just making sure. Yes, definitely. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
On 17/04/15 16:15, Jan Cholasta wrote: Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza 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 +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue 3) Multiple inheritance. I do not like it much. +class CompositeInstaller(Installer, CompositeConfigurator): Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. I'm afraid this may suddenly stop working. Maybe I'm wrong, please fix me. And Multiple inheritance is not easily readable, this is even a diamond inheritance model. -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
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): Hi, the attached patch adds the basics of the new installer framework. 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 ported to the framework later). (Note I didn't manage to write docstrings today, expect update tomorrow.) Added some docstrings. Also updated the patch to reflect little brainstorming David and I had this morning. Honza Hello, see comments bellow: 1) We started using new shorter License header in files: # # Copyright (C) 2015 FreeIPA Contributors see COPYING for license # OK. 2) IMO this will not work, NoneType has no 'obj' attribute +else: +if isinstance(value, from_): +value = None +stack.append(value.obj) +continue Right. 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 and is basis for e.g. the mixin design pattern. Installer and CompositeConfigurator inherites from Configurator class, and all of them implements _generator method. Both of them call super()._generator(), so it's no problem (same for other methods). If I understand correctly (https://www.python.org/download/releases/2.3/mro/) the Installer._generator method will be used in this case. However in case when CompositeConfigurator has more levels (respectively it is more specialized) of inheritance, it could take precedence and its _generator method may be used instead. The order of precedence is defined by the order of base classes in the class definition. 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 diamond inheritance model. Cooperative inheritance is used by design and IMHO is easily readable if you know how to read it. Every class defines a single bit of behavior. Without cooperative inheritance, it would have to be hardcoded and/or hacked around, which I wanted to avoid. This blog post explains it nicely: https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. -- Martin Basti -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 424] install: Introduce installer framework ipapython.install
Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a):
Hi,
the attached patch adds the basics of the new installer framework.
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 ported to
the framework later).
(Note I didn't manage to write docstrings today, expect update tomorrow.)
Added some docstrings.
Also updated the patch to reflect little brainstorming David and I had
this morning.
Honza
--
Jan Cholasta
From 2245f992185a6f03b27afa50b10c811797c6dda4 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 16 Apr 2015 14:35:24 +
Subject: [PATCH] install: Introduce installer framework ipapython.install
---
ipapython/install.py | 468 +++
1 file changed, 468 insertions(+)
create mode 100644 ipapython/install.py
diff --git a/ipapython/install.py b/ipapython/install.py
new file mode 100644
index 000..1c0c646
--- /dev/null
+++ b/ipapython/install.py
@@ -0,0 +1,468 @@
+# Authors:
+# Jan Cholasta jchol...@redhat.com
+#
+# Copyright (C) 2015 Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+
+
+Installer framework.
+
+
+import sys
+import inspect
+import abc
+import itertools
+
+_VALIDATE_PENDING = 'VALIDATE_PENDING'
+_VALIDATE_RUNNING = 'VALIDATE_RUNNING'
+_EXECUTE_PENDING = 'EXECUTE_PENDING'
+_EXECUTE_RUNNING = 'EXECUTE_RUNNING'
+_STOPPED = 'STOPPED'
+_FAILED = 'FAILED'
+_CLOSED = 'CLOSED'
+
+_missing = object()
+
+
+class from_(object):
+__slots__ = ('obj',)
+
+def __init__(self, obj):
+self.obj = obj
+
+
+def _run_generator_with_yield_from(gen):
+exc_info = None
+value = None
+
+stack = [gen]
+while stack:
+prev_exc_info, exc_info = exc_info, None
+prev_value, value = value, None
+
+gen = stack[-1]
+try:
+if prev_exc_info is None:
+value = gen.send(prev_value)
+else:
+value = gen.throw(*prev_exc_info)
+except StopIteration:
+stack.pop()
+continue
+except BaseException:
+exc_info = sys.exc_info()
+stack.pop()
+continue
+else:
+if isinstance(value, from_):
+value = None
+stack.append(value.obj)
+continue
+
+try:
+value = (yield value)
+except BaseException:
+exc_info = sys.exc_info()
+
+if exc_info:
+raise exc_info #pylint: disable=raising-bad-type
+
+
+class InvalidStateError(Exception):
+pass
+
+
+class Knob(object):
+
+Public argument of a Configurator.
+
+
+__counter = itertools.count()
+
+def __init__(self, type, default=_missing, label=None):
+
+Initialize the knob.
+
+self.type = type
+if default is _missing:
+self.required = True
+self.default = None
+else:
+self.required = False
+self.default = default
+self.label = label
+self.order = next(self.__counter)
+
+def _set(self, obj, value):
+setattr(obj, '_knob{0}'.format(id(self)), value)
+
+def __get__(self, obj, obj_type):
+if obj is None:
+return self
+return getattr(obj, '_knob{0}'.format(id(self)))
+
+
+class Configurator(object):
+
+Base class of all configurators.
+
+FIXME: details of validate/execute, args and knobs
+
+
+__metaclass__ = abc.ABCMeta
+
+@classmethod
+def args(cls):
+
+Iterate over arguments of the configurator.
+
+for super_cls in cls.__mro__:
+if not issubclass(super_cls, Configurator):
+continue
+
+try:
+init = super_cls.__dict__['__init__']
+except KeyError:
+continue
+
+argspec = inspect.getargspec(init)
+for name in argspec.args[1:]:
+if not name.startswith('_'):
+yield name
+
+for knob_cls, name, obj in cls.knobs():
+yield name
+
+@classmethod
+def knobs(cls):
+
+Iterate over knobs defined for the configurator.
+
+result = []
+for name in dir(cls):
+
