Bug 1851773 - When applying tuning configuration via "satellite-installer --tuning <template>" the old configuration still on custom-hiera.yaml file
Summary: When applying tuning configuration via "satellite-installer --tuning <templat...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Documentation
Version: 6.7.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Sergei Petrosian
QA Contact: satellite-doc-list
Suyog Sainkar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-28 20:56 UTC by Waldirio M Pinheiro
Modified: 2020-11-02 11:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-02 11:47:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Waldirio M Pinheiro 2020-06-28 20:56:36 UTC
Description of problem:
When proceeding with the command "satellite-installer --tuning" the old tuning configuration still persistent on the file "/etc/foreman-installer/custom-hiera.yaml" causing some divergent configuration.

Version-Release number of selected component (if applicable):
6.7.z

How reproducible:
100%

Steps to Reproduce:
1. Change the custom-hiera.yaml file and apply it via satellite-installer
2. rerun "satellite-installer --tuning default" or according to your sizing
3. check the values after that

Actual results:
The actual results will be based on the values defined on "/etc/foreman-installer/custom-hiera.yaml"

Expected results:
Installer commenting all the lines on "/etc/foreman-installer/custom-hiera.yaml" and proceeding with the deploy based on the internal tuning profiles.

Additional info:

Comment 1 Waldirio M Pinheiro 2020-06-28 21:06:24 UTC
Hello,

Below the complete steps


// Custom hiera
---
[root@wallsat67 foreman-installer]# cat custom-hiera.yaml 
---
# This YAML file lets you set your own custom configuration in Hiera for the
# installer puppet modules that might not be exposed to users directly through
# installer arguments.
#
# For example, to set 'TraceEnable Off' in Apache, a common requirement for
# security auditors, add this to this file:
#
#   apache::trace_enable: Off
#
# Consult the full module documentation on http://forge.puppetlabs.com,
# or the actual puppet classes themselves, to discover options to configure.
#
# Do note, setting some values may have unintended consequences that affect the
# performance or functionality of the application. Consider the impact of your
# changes before applying them, and test them in a non-production environment
# first.
#
# Here are some examples of how you tune the Apache options if needed:
#
# apache::mod::prefork::startservers: 8
# apache::mod::prefork::minspareservers: 5
# apache::mod::prefork::maxspareservers: 20
# apache::mod::prefork::serverlimit: 256
# apache::mod::prefork::maxclients: 256
# apache::mod::prefork::maxrequestsperchild: 4000
#
# Here are some examples of how you tune the PostgreSQL options if needed:
#
# postgresql::server::config_entries:
#   max_connections: 600
#   shared_buffers: 1024MB

apache::mod::passenger::passenger_max_pool_size: 50
apache::mod::passenger::passenger_max_request_queue_size: 5000
apache::mod::passenger::passenger_max_requests: 5000
[root@wallsat67 foreman-installer]# 
---


// MaxPoolSize value
---
[root@wallsat67 foreman-installer]# passenger-status 
Version : 4.0.18
Date    : 2020-06-28 16:45:36 -0400
Instance: 12601
----------- General information -----------
Max pool size : 50
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
/usr/share/foreman#default:
  App root: /usr/share/foreman
  Requests in queue: 0
  * PID: 13798   Sessions: 0       Processed: 1       Uptime: 7m 17s
    CPU: 1%      Memory  : 419M    Last used: 7m 17s ago

[root@wallsat67 foreman-installer]#
---

// QueueSize and MaxRequests == 5k
---
[root@wallsat67 foreman-installer]# grep -r 5000 /etc/httpd/* | grep -v log
/etc/httpd/conf/magic:# DEC systems (e.g. DECstation 5000) use a variant of the Sun/NeXT format
/etc/httpd/conf/ports.conf:Listen 5000
/etc/httpd/conf.d/03-crane.conf:<VirtualHost *:5000>
/etc/httpd/conf.modules.d/passenger_extra.conf:  PassengerMaxRequestQueueSize 5000
/etc/httpd/conf.modules.d/passenger_extra.conf:  PassengerMaxRequests 5000
[root@wallsat67 foreman-installer]#
---


// Calling satellite-installer passing the "--tuning" flag
---
[root@wallsat67 foreman-installer]# satellite-installer --tuning default
Package versions are locked. Continuing with unlock.
Installing             Done                                               [100%] [..................................................................................................................................................]
  Success!
  * Satellite is running at https://wallsat67.usersys.redhat.com

  * To install an additional Capsule on separate machine continue by running:

      capsule-certs-generate --foreman-proxy-fqdn "$CAPSULE" --certs-tar "/root/$CAPSULE-certs.tar"

  * To upgrade an existing 6.6 Capsule to 6.7:
      Please see official documentation for steps and parameters to use when upgrading a 6.6 Capsule to 6.7.

  The full log is at /var/log/foreman-installer/satellite.log
Package versions are being locked.
[root@wallsat67 foreman-installer]#
---


// The MaxPoolSize once
---
[root@wallsat67 foreman-installer]# passenger-status 
Version : 4.0.18
Date    : 2020-06-28 16:50:48 -0400
Instance: 12601
----------- General information -----------
Max pool size : 50
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
/usr/share/foreman#default:
  App root: /usr/share/foreman
  Requests in queue: 0
  * PID: 13798   Sessions: 0       Processed: 2       Uptime: 12m 29s
    CPU: 0%      Memory  : 422M    Last used: 1m 20s ago

[root@wallsat67 foreman-installer]#
---


// The values again
---
[root@wallsat67 foreman-installer]# grep -r 5000 /etc/httpd/* | grep -v log
/etc/httpd/conf/magic:# DEC systems (e.g. DECstation 5000) use a variant of the Sun/NeXT format
/etc/httpd/conf/ports.conf:Listen 5000
/etc/httpd/conf.d/03-crane.conf:<VirtualHost *:5000>
/etc/httpd/conf.modules.d/passenger_extra.conf:  PassengerMaxRequestQueueSize 5000
/etc/httpd/conf.modules.d/passenger_extra.conf:  PassengerMaxRequests 5000
[root@wallsat67 foreman-installer]#
---

As we can see, independent of the template, if the values still on custom-hiera.yaml will overwrite the template values passed via "--tuning" flag.

Waldirio

Comment 2 Waldirio M Pinheiro 2020-06-28 21:20:02 UTC
So,

Commenting on the line
---
[root@wallsat67 ~]# cat /etc/foreman-installer/custom-hiera.yaml 
---
# This YAML file lets you set your own custom configuration in Hiera for the
# installer puppet modules that might not be exposed to users directly through
# installer arguments.
#
# For example, to set 'TraceEnable Off' in Apache, a common requirement for
# security auditors, add this to this file:
#
#   apache::trace_enable: Off
#
# Consult the full module documentation on http://forge.puppetlabs.com,
# or the actual puppet classes themselves, to discover options to configure.
#
# Do note, setting some values may have unintended consequences that affect the
# performance or functionality of the application. Consider the impact of your
# changes before applying them, and test them in a non-production environment
# first.
#
# Here are some examples of how you tune the Apache options if needed:
#
# apache::mod::prefork::startservers: 8
# apache::mod::prefork::minspareservers: 5
# apache::mod::prefork::maxspareservers: 20
# apache::mod::prefork::serverlimit: 256
# apache::mod::prefork::maxclients: 256
# apache::mod::prefork::maxrequestsperchild: 4000
#
# Here are some examples of how you tune the PostgreSQL options if needed:
#
# postgresql::server::config_entries:
#   max_connections: 600
#   shared_buffers: 1024MB

#apache::mod::passenger::passenger_max_pool_size: 50
#apache::mod::passenger::passenger_max_request_queue_size: 5000
#apache::mod::passenger::passenger_max_requests: 5000
[root@wallsat67 ~]# 
---


and running again the installer
---
# satellite-installer
---

We can see the correct configuration in place
---
[root@wallsat67 ~]# passenger-status 
Version : 4.0.18
Date    : 2020-06-28 17:17:26 -0400
Instance: 19603
----------- General information -----------
Max pool size : 12
Processes     : 3
Requests in top-level queue : 0

----------- Application groups -----------
/usr/share/foreman#default:
  App root: /usr/share/foreman
  Requests in queue: 0
  * PID: 20076   Sessions: 0       Processed: 2       Uptime: 2m 39s
    CPU: 0%      Memory  : 218M    Last used: 2m 37s ago
  * PID: 20102   Sessions: 0       Processed: 2       Uptime: 2m 38s
    CPU: 2%      Memory  : 419M    Last used: 2m 38s ago
  * PID: 20121   Sessions: 0       Processed: 0       Uptime: 2m 37s
    CPU: 0%      Memory  : 164M    Last used: 2m 37s ago
---


---
[root@wallsat67 ~]# grep -r 5000 /etc/httpd/* | grep -v log
/etc/httpd/conf/magic:# DEC systems (e.g. DECstation 5000) use a variant of the Sun/NeXT format
/etc/httpd/conf/ports.conf:Listen 5000
/etc/httpd/conf.d/03-crane.conf:<VirtualHost *:5000>
[root@wallsat67 ~]# 
---



And here the default template
---
[root@wallsat67 ~]# cat /usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml 
---
lookup_options:
  postgresql::server::config_entries:
    merge: hash

apache::mod::passenger::passenger_max_pool_size: 12
apache::mod::passenger::passenger_max_instances_per_app: 6
apache::mod::passenger::passenger_max_request_queue_size: 250
apache::mod::passenger::passenger_stat_throttle_rate: 120
apache::mod::passenger::passenger_max_requests: 10000
apache::mod::passenger::passenger_min_instances: 1
apache::mod::passenger::passenger_max_preloader_idle_time: 0

qpid::open_file_limit: 65536
qpid::router::open_file_limit: 150100

postgresql::server::config_entries:
  checkpoint_completion_target: 0.9
  max_connections: 500
  shared_buffers: 512MB
  work_mem: 4MB
  log_line_prefix: '%t '
  log_min_duration_statement: 1000
  log_rotation_size: 200000
[root@wallsat67 ~]#
---

Comment 3 wclark 2020-07-20 15:27:20 UTC
The user needs the ability to apply additional custom parameters via custom-hiera.yaml, and these need to have a higher priority than the assigned tuning profile and not be overwritten by the installer.

What we need instead then is a note on the tuning documentation and a KCS explaining this behavior so that the customer can review their custom-hiera.yaml before applying a tuning profile. The ideal process would be to make a backup of the custom-hiera.yaml and remove it, then apply the new tuning profile and start from that point as a baseline, then make further changes in custom-hiera.yaml as needed on top of the tuning profile. But the installer shouldn't do this automatically because we don't want to automatically overwrite configuration in custom-hiera.yaml without the user's intent.

Re-assigning this BZ to documentation. What we need is clarification in the tuning guide ( https://access.redhat.com/sites/default/files/attachments/performance_tuning_for_red_hat_satellite_6.7.pdf ) regarding the following points:

1. The new tuning profiles are not applied via custom-hiera.yaml (this is different from how the previous version of tuning profiles worked, where the user would download a specific custom-hiera.yaml from the SatelliteSupport GitHub repository)

2. custom-hiera.yaml has a higher priority than the assigned tuning profile. this is intended so that the user can apply further tuning on top of the tuning profile and override the tuning profile where desired.

3. Users should review custom-hiera.yaml vs. the tuning profile in /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes before applying the tuning profile.

4. After applying the tuning profile as a new baseline, they can do further fine tuning by making changes in custom-hiera.yaml

Comment 6 wclark 2020-07-20 16:37:52 UTC
Thinking about this some more, if we are planning to move `--tuning` into an installer hook, https://github.com/theforeman/foreman-installer/pull/542 , then an option here is to have the installer print some warning/confirmation dialog explaining to the user that custom-hiera.yaml should be reviewed first since it will have priority over the tuning profile.

Comment 7 wclark 2020-07-20 16:43:37 UTC
Moving this back to the installer component.

We do need to have the docs updated as well to make the intended behavior clearer to the user. We can create another BZ for that.

Comment 8 Sergei Petrosian 2020-10-14 08:36:11 UTC
Hi Waldrio,

Please check the procedure 4.8. Tuning Satellite Server with Predefined Profiles:
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.8-beta/html/upgrading_and_updating_red_hat_satellite/post_upgrade_tasks#tuning-upgraded-satellite-server-with-predefined-profiles

This procedure describes how profiles are applied and tells what users need to do to avoid loosing their configurations. Does it suits your requirements?

The procedure that you linked in the Install guide has less detailes because it is aimed at those users who just install Satellite and configure it at day 1. I see an issue here, we probably need to give all the details right away because some users with custom custom-hiera might bump onto a procedure at take it for granted.

Thank you

Comment 9 Sergei Petrosian 2020-10-14 08:37:41 UTC
Sorry, Waldirio, I misspelled your name in the previous comment.


Note You need to log in before you can comment on or make changes to this bug.