traditional UNIX approach is to have some sane defaults and allow users
to uncomment (or add) configuration values for particular behavior.
Katello answer file is working in the same way - there are sane defaults
and user can override only those he is interested in.
But our new installer currently takes all the default values taken from
puppet manifests and put them into the answer file which breaks this
(good) habit. Also, the file is more difficult to read/edit.
More importantly, changing default behavior is now more difficult as all
default values are "fixed" in advanced during the first run and manual
edit is always necessary from now on. I understand this can be seen as
an advantage (puppet is fragile thing), but on the other hand after few
releases and some changes in default options, initial answer file will
become totally outdated and we will start seeing reports of failing
upgrade.
What I would like to have in 1.3 is answer file with only values that
has been changed by user (interactively or non-interactively). That
would mean in the simplest case, answer file would be empty if no
options were provided.
I know Marek did great job with the new kafo script and it is tight in
regard to RC1, but if we want to discuss this, it's better to do it now,
then migrating this after the release.
> Hey,
>
> traditional UNIX approach is to have some sane defaults and allow users
> to uncomment (or add) configuration values for particular behavior.
>
> Katello answer file is working in the same way - there are sane defaults
> and user can override only those he is interested in.
>
> But our new installer currently takes all the default values taken from
> puppet manifests and put them into the answer file which breaks this
> (good) habit. Also, the file is more difficult to read/edit.
run installer again nothing changes unless explicitly told so the run is
idempotent. Default values can change in time (not just because of puppet
module update) but I think we want to keep setting same as we had it last
time.
> More importantly, changing default behavior is now more difficult as all
> default values are "fixed" in advanced during the first run and manual
> edit is always necessary from now on. I understand this can be seen as
> an advantage (puppet is fragile thing), but on the other hand after few
> releases and some changes in default options, initial answer file will
> become totally outdated and we will start seeing reports of failing
> upgrade.
We can write a "foreman-upgrade-1.3" script which just runs something like
foreman-install --foreman-webserver=passenger
> What I would like to have in 1.3 is answer file with only values that
> has been changed by user (interactively or non-interactively). That
> would mean in the simplest case, answer file would be empty if no
> options were provided.
>
> I know Marek did great job with the new kafo script and it is tight in
> regard to RC1, but if we want to discuss this, it's better to do it now,
> then migrating this after the release.
Agreed, better to solve now. I'm for storing of values that were used for the
last run.
···
On Tuesday 10 of September 2013 14:41:46 Lukas Zapletal wrote:
From my side, this has a good reason. We want to make sure, that later when we
I'm fine with this, but we need to either a) look up the actual default
value and write it into the file (so server_enc_api: 'v2', not
server_enc_api: <nothing>), or b) fix the issues with 2.6 writing ""
instead of <nothing> for default values, or c) drop 2.6 support. I'm for b)
if it's easy enough…
···
On 10 September 2013 13:46, Marek Hulan wrote:
Agreed, better to solve now. I’m for storing of values that were used for
the
last run
> FYI (b) is reported as issue #3066 - if we can fix that I'm happy with
> storing everything.
But the way it is designed right now is:
We install the /etc/foreman/foreman-installer-answers.yaml as a
configuration file through foreman-installer RPM (DEB) package with the
following content:
Once the installer is executed, it is overwritten to something like:
During upgrade we will decide either to do rpmnew or rpmsave (replace or
noreplace *). There is no other option with RPM (not speaking for DEB
package format here). It is non-interactive mode.
Now, the result is essentially the same as what I recommend - user needs
to merge his answer file anyway. Having all the possible default values
there can be a messy for users to merge those changes.
What I think is better is to keep our default options (the file what is
installed by default with those four lines - see above) in a separate
file called foreman-installer-defaults.yaml somewhere in the /usr/share
directory. This can be config replace option in the SPEC.
And only values which are different from this file would be saved in teh
foreman-installer-answers.yaml which would be taken out of the RPM.
Since there are only options which are set by the user, it is not need
to track the file in the RPM database, except ghost entry of course.
I push hard, because changing basic concepts of an installer is more
difficult once it is in the wild.
> > FYI (b) is reported as issue #3066 - if we can fix that I'm happy with
> > storing everything.
>
> But the way it is designed right now is:
>
> 1) We install the /etc/foreman/foreman-installer-answers.yaml as a
> configuration file through foreman-installer RPM (DEB) package with the
> following content:
>
> foreman: true
> foreman_proxy: true
> puppet:
> server: true
>
> 2) Once the installer is executed, it is overwritten to something like:
>
> https://gist.github.com/lzap/6513480
>
> During upgrade we will decide either to do rpmnew or rpmsave (replace or
> noreplace *). There is no other option with RPM (not speaking for DEB
> package format here). It is non-interactive mode.
>
> Now, the result is essentially the same as what I recommend - user needs
> to merge his answer file anyway. Having all the possible default values
> there can be a messy for users to merge those changes.
>
> What I think is better is to keep our default options (the file what is
> installed by default with those four lines - see above) in a separate
> file called foreman-installer-defaults.yaml somewhere in the /usr/share
> directory. This can be config replace option in the SPEC.
Note that if we add new parameters we don't have to merge them to existing
answer file. They will be added automatically next run. In fact if we change a
default value for existing we should never overwrite that. That's why I added
%config(noreplace) to answer file.
Suppose I as a user rely on default values so I don't overwrite them all
manually to the same value. Then with a new update I run installer again,
existing (tested and working) configuration is changed unexpectedly because
someone decided that a default value is different.
>
> And only values which are different from this file would be saved in teh
> foreman-installer-answers.yaml which would be taken out of the RPM.
> Since there are only options which are set by the user, it is not need
> to track the file in the RPM database, except ghost entry of course.
>
> I push hard, because changing basic concepts of an installer is more
> difficult once it is in the wild.
>
> * - currently we have this in the SPEC file
>
> %attr(600, root, root) %{_sysconfdir}/foreman/%{name}-answers.yaml
>
> which just silently replaces user's configuration on upgrade which is
> not what we want: Bug #3069: We replace users answer file in the SPEC - Installer - Foreman
I sent a PR fixing this
···
On Tuesday 10 of September 2013 20:37:18 Lukas Zapletal wrote:
