Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #37717 - Update evr extension ownership to foreman #955

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

sjha4
Copy link
Contributor

@sjha4 sjha4 commented Aug 6, 2024

Update ownership of evr extension to owner foreman to allow migrations to operate on it, specifically disable it.

@sjha4 sjha4 force-pushed the change_evr_owner branch 3 times, most recently from 13d9cc2 to 19812e3 Compare August 6, 2024 17:22
@sjha4 sjha4 marked this pull request as ready for review August 6, 2024 17:22
@sjha4 sjha4 changed the title Refs #11098 - Update evr extension ownership after postgresql upgrade Refs #37678 - Update evr extension ownership after postgresql upgrade Aug 6, 2024
@ianballou
Copy link
Contributor

@ekohl mentioned before that the pg_shdepend table might also need updating, but at least functionally it doesn't seem necessary since the migration passes with @sjha4 's changes alone. The bits that would get updated in pg_shdepend may get dropped with the evr extension.

@ianballou
Copy link
Contributor

I confirmed that dropping the extension also drops the related entry from pg_shdepend.

@sjha4
Copy link
Contributor Author

sjha4 commented Aug 6, 2024

I tested the installer with the chages here although I had to put the new code in a separate pre-hook file to be run..Suggestions on where to put this code if not this file?

@evgeni
Copy link
Member

evgeni commented Aug 7, 2024

What about remote db users? Will those need to perform manual steps (we usually don't have enough permissions to change ownership of objects there) before the upgrade?

@sjha4
Copy link
Contributor Author

sjha4 commented Aug 7, 2024

What about remote db users? Will those need to perform manual steps (we usually don't have enough permissions to change ownership of objects there) before the upgrade?

Ya..They'll need to run the update ownership query manually as part of their upgrades. Will need to be documented.

@ianballou
Copy link
Contributor

ianballou commented Aug 7, 2024

@evgeni docs update will go in theforeman/foreman-documentation#3167 unless someone gets to it first.

@ianballou
Copy link
Contributor

Prepping a system for a test.

@ianballou
Copy link
Contributor

Found an issue -- the postgres command cannot run because the postgres service is down during the installer run. We'll need to turn postgres on first.

@sjha4
Copy link
Contributor Author

sjha4 commented Aug 7, 2024

Aside from the postgres issue it's working.

Ok..So couple of changes..

  1. Added a check to run only on local postgres.
  2. Added code to check status of postgresql service, start it if stopped and stop it after the hook.

Should work better now.

@ianballou
Copy link
Contributor

Tested again by upgrading Katello 4.12 to nightly via 4.13. Worked well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please respect noop mode, which you can check with app_value(:noop)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated code to respect no-op and address other review comments..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: What are these numbers before the filenames? I picked 35 cause 34- existed. 🙊

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like foreman release versions..I can update the filename to 311- to follow convention if that is what it is..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They're for order. All hooks get sorted and that determines when they're executed. It allows you to ensure your hook is executed after the PostgreSQL migration itself

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to implement the noop mode slightly different. In our other hooks we log debug statements what would be done. Otherwise you can simply reduce it to if !app_value(:noop) &&local_postgresql? && execute("rpm -q postgresql-evr", false, false).

hooks/pre/35-change-evr-extension-ownership.rb Outdated Show resolved Hide resolved
hooks/pre/35-change-evr-extension-ownership.rb Outdated Show resolved Hide resolved
hooks/pre/35-change-evr-extension-ownership.rb Outdated Show resolved Hide resolved
@sjha4 sjha4 changed the title Refs #37678 - Update evr extension ownership after postgresql upgrade Fixes #37717 - Update evr extension ownership to foreman Aug 7, 2024
@sjha4
Copy link
Contributor Author

sjha4 commented Aug 7, 2024

Not sure if test failure is related.. 😕

@ehelms
Copy link
Member

ehelms commented Aug 8, 2024

Not sure if test failure is related.. 😕

Looks like minitar 1.0.0 was released today and we made need to pin it for the time being -- https://rubygems.org/gems/minitar/versions/1.0.0

@sjha4
Copy link
Contributor Author

sjha4 commented Aug 8, 2024

Not sure if test failure is related.. 😕

Looks like minitar 1.0.0 was released today and we made need to pin it for the time being -- https://rubygems.org/gems/minitar/versions/1.0.0

Ya..That was it..

#956

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to implement the noop mode slightly different. In our other hooks we log debug statements what would be done. Otherwise you can simply reduce it to if !app_value(:noop) &&local_postgresql? && execute("rpm -q postgresql-evr", false, false).

# Update the ownership of the evr extension
unless app_value(:noop)
logger.debug("Updating ownership of the evr extension if it is enabled")
execute!("runuser -l postgres -c \"psql -d foreman -c \\\"UPDATE pg_extension SET extowner = (SELECT oid FROM pg_authid WHERE rolname='foreman') WHERE extname='evr';\\\"\"", false, true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, it can be simplified to use execute_as!. And I think you should look at the answers as well. Then the final version is:

Suggested change
execute!("runuser -l postgres -c \"psql -d foreman -c \\\"UPDATE pg_extension SET extowner = (SELECT oid FROM pg_authid WHERE rolname='foreman') WHERE extname='evr';\\\"\"", false, true)
database = param_value('foreman', 'db_database')
username = param_value('foreman', 'db_username')
sql = "UPDATE pg_extension SET extowner = (SELECT oid FROM pg_authid WHERE rolname='#{username}') WHERE extname='evr'"
execute_as!('postgres', "psql -d #{database} -c \"#{sql}\"", false, true)

But escaping will be tricky, so I'd enhance execute_as! to pass it as an array:

def execute_as!(user, command, do_say = true, do_log = true)
  runuser_command = ['runuser', '-l', user, '-c', command] 
  execute!(runuser_command, do_say, do_log)
end

Then I'd expect it to work if users chose a different DB and/or username as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that Kafo::PuppetCommand.format_command probably doesn't deal with commands as arrays.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to do this:

  database = param_value('foreman', 'db_database') || 'foreman'
  username = param_value('foreman', 'db_username') || 'foreman'
  sql = "runuser -l postgres -c \"psql -d '#{database}' -c \\\"UPDATE pg_extension SET extowner = (SELECT oid FROM pg_authid WHERE rolname='#{username}') WHERE extname='evr';\\\"\""
  logger.debug("Executing: #{sql}")
  execute!(sql, false, true) unless app_value(:noop)

Still using execute! as escaping was being really painful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened theforeman/kafo#374 for that support.

@@ -0,0 +1,26 @@
# In Katello 4.14, the 'evr' extension is removed from PostgreSQL and integrated into the Katello database via a migration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# In Katello 4.14, the 'evr' extension is removed from PostgreSQL and integrated into the Katello database via a migration.
# In Katello 4.15, the 'evr' extension is removed from PostgreSQL and integrated into the Katello database via a migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants