[katello-devel] Installer review (allow to run katello-configure multiple times)

Lukas Zapletal lzap at redhat.com
Mon Jul 23 13:31:47 UTC 2012


Guys.

We have been working hard on katello-configure to improve the way it
works. Since the installer is Puppet based, our main goal was to allow
users to run it multiple times. Like Puppet does, installer do check
everything and correct all deviations from what you configured using
parameters. This was not possible since some dependency issues and usage
of idempotent scripts like cpsetup.

Lots of changes were incorporated - various workarounds were removed and
installer was tested with various scenarios. From now on, if you
provision a clean installation or if you have existing one, you can
always run katello-configure to make sure everything is okay. Please
note all the katello-configure options are stored in the
/etc/katello/katello-configure.conf so you can use it as an answer file:

katello-configure --answer-file=/etc/katello/katello-configure.conf

You can also provide different parameters and installer will
re-configure everything. Please check logs carefully when changing
options and report errors if you encouter any. Also note that changing
org-name, user-name, user-pass and user-email will require resetting
database.

And this also means you can easily switch between katello and headpin.
Yes, this is possible and as easy as installing thumbslug plus:

katello-configure --deployment=headpin
katello ping
katello-configure --deployment=katello
katello ping

There is a new option --reset-data which drops all databases: katello,
candlepin, pulp (also repos which were generated), elasticsearch and
then starts initial configuration again. Since this is dangerous option,
you need to provide case-sensitive "YES" to get the desired behavior.

Additional second option --reset-cache just removes all pulp downloaded
RPMs from /var/lib/pulp/packages. If you provide them both, katello
instance should be completly "clean". Please note all --reset-* options
are not stored in the answer file for obvious reasons.

Example of full reset of a katello installation:

katello-configure --answer-file=/etc/katello/katello-configure.conf
--reset-data=YES --reset-cache=YES

Basically this does the very same as katello-reset-dbs, but also makes
sure all configuration values are correct. We will keep
katello-reset-dbs script in git since it can be easily used for
development setups.

Katello-configure will also work for upgrades. To upgrade existing
installation, use katello-upgrade script first which will do all data
migrations which are needed and THEN you can run katello-configure as
many times as you want to re-configure stuff, because it always should
describe correct state of an installation. It is not recommended to run
katello-configure BEFORE katello-upgrade.

IMPORTANT: Since there are big changes in the installer, you need to do
clean installation for the first time. If you try to upgrade to the new
version of the installer, it will likely fail with a puppet error.

Please report all katello-configure failures along with katello-debug
output. It creates nice tarball with all the important logs there
(passwords are removed). We recommend to attach it as private comments
into bugzilla. Before you report, please try to restart all backend
engines and then katello to see if it helps and provide this
information.

There are also two more options -b and -d. The first one turns off
progress bars logging puppet also on the standard output and the second
enables debug messages to be avaiable also on stdout (hidden by
default). New version also strips out annoying color codes in the
katello-configure log files.

As a side effect, I created a page describing installation of katello
via puppet itself (without katello-configure script which only collects
params and runs puppet):

https://fedorahosted.org/katello/wiki/InstallViaPuppet

Git pull request is here: https://github.com/Katello/katello/pull/345

List of things that has been changed should be obvious from commit
messages. It should be roughly this list:

* remove reconfiguration message
* remove /var/log/katello permission mangling
* make sure certs and tomcat conf are not regenerated during rounds
* parametrize hardcoded elasticsearch heap sizes
* do not generate candlepin.conf in the cpsetup anymore
* make tomcat password file to survive multiple runs
* add warning header to all puppet-controlled config files
* remove hardcoded values from seeds.rb
* secure "hacky" initdb password handover
* tomcat keystore_password_file fix
* fix and test puppet when initial pg superuser password is set
* do not regenerate oauth_secret every puppet run
* notify services when changing config files (review them all)
* get rid of cpsetup and use dpdb directly
* remove generated string from all config headers
* do not rewrite pulp user pass everytime
* use refreshonly for cert generation
* implement --reset-data and --reset-cache options
* test with deploy arguments: katello, headpin, cfse, sam
* handle upgrades correctly

Feel free to review, I am currently testing it with Fedoras and I would
maybe get rid of reseting oauth in the post RPM section. (Why do we
actually do it here?)

Comments appreciated. This was on my TODO for a long time.

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine




More information about the katello-devel mailing list