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

Makes postgres-reload-modules conditional #216

Closed
wants to merge 13 commits into from

Conversation

RobRuana
Copy link
Contributor

@RobRuana RobRuana commented Jun 5, 2018

This pull request makes the postgres-reload-modules conditional so it doesn't report changes during every run.

@@ -70,6 +70,7 @@
{{ debian_codename('vivid', '9.4') }}
{{ debian_codename('wily', '9.4') }}
{{ debian_codename('xenial', '9.5') }}
{{ debian_codename('bionic', '10') }}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adds codename for Ubuntu 18.04 "bionic". This was all I needed to change to get Postgres 10 working for Ubuntu 18.04.

@@ -57,6 +57,8 @@ postgres:

bake_image: False

manage_force_reload_modules: True
Copy link
Contributor Author

Choose a reason for hiding this comment

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

New config setting defaults to True to preserve existing behavior.

@@ -15,12 +17,16 @@ include:

{%- endif %}

{%- if needs_client_binaries or postgres.manage_force_reload_modules %}
Copy link
Contributor Author

@RobRuana RobRuana Jun 5, 2018

Choose a reason for hiding this comment

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

I was getting tired of postgres-reload-modules running even when nothing had changed. I hid the state behind a conditional that checks if any new client binaries were installed, or if manage_force_reload_modules was set to True.

NOTE: manage_force_reload_modules defaults to True to preserve the existing behavior.

Copy link
Member

Choose a reason for hiding this comment

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

Maybemange_force_reload_modules should default to False to fix #214 @vunty what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm totally fine with setting mange_force_reload_modules to False by default.

@myii
Copy link
Member

myii commented Jun 6, 2018

@RobRuana Great minds think alike... pipped you to the postgres/codenamemap.yaml change by 3 hours -- see #215. Took it a bit further by updating the list to all of the supported versions and getting rid off the deadwood.

Copy link
Member

@noelmcloughlin noelmcloughlin left a comment

Choose a reason for hiding this comment

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

LGTM, I have just one outstanding query.

Copy link
Contributor

@vutny vutny left a comment

Choose a reason for hiding this comment

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

@RobRuana Thanks for your PR!

Since we already have a PR submitted to add support for Ubuntu 18, I propose to separate concerns and focus on fixing issue #214 here. I found it really annoys people 😃

Also I think you need to add conditional to macros.jinja file, as each state produced by format_state macro has explicit requirement on the postgres-reload-modules.

@RobRuana RobRuana changed the title Adds Ubuntu "bionic" codename & makes reload-modules conditional Makes postgres-reload-modules conditional Jun 6, 2018
@RobRuana
Copy link
Contributor Author

RobRuana commented Jun 6, 2018

Okay, I merged the codename changes from master and made manage_force_reload_modules default to False.

Furthermore, I repositioned the conditional so postgres-reload-modules always runs, so other states will always be able to reference it. The part that's conditional is whether it reports changes or not.

test.succeed_with_changes:
{%- else %}
test.succeed_without_changes:
{%- endif %}
Copy link
Contributor

Choose a reason for hiding this comment

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

@RobRuana This seems like an obvious fix, but that wouldn't work.
Each state generated below explicitly subscribed on changes in postgres-reload-modules. So if you later change PG entities in the Pillar, it will not have any effect.
The only way I see to overcome this: you need to put conditional in format_state macro to depend on modules reload only when postgres.manage_force_reload_modules set True.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@vutny, yes, you are correct that this breaks any state using the format_state() macro.

At first I couldn't understand why onchanges: postgres-reload-modules was being used instead of require: postgres-reload-modules. But then I realized that many instances of format_state() are already using the require conditional, so there would be conflicting require keys when the state is rendered.

Correct me if I'm wrong, but I believe onchanges is being used to force correct ordering of the states, not because we want every format_state() to run when there are changes in postgres-reload-modules.

If that's correct, then we should be able to achieve the same result by using watch instead of onchanges in format_state(). I've made that change. Please let me know if you think that works.

@@ -184,9 +184,6 @@ postgresql-running:
service.running:
- name: {{ postgres.service }}
- enable: True
{% if grains.os not in ('MacOS',) %}
- reload: True
{% endif %}
Copy link
Member

Choose a reason for hiding this comment

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

@RobRuana This has already been resolved by 79ab1a2 during #218:

- watch_in:
- module: postgresql-service-restart
{%- endif %}
# Restart the service where reloading is not sufficient
# Currently when the cluster is created or changes made to `postgresql.conf`
postgresql-service-restart:
module.wait:
- name: service.restart
- m_name: {{ postgres.service }}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the notice! I'm scrambling to get everything working at the moment, and this was my quick and dirty fix. I've synced with upstream.

Copy link
Member

Choose a reason for hiding this comment

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

@RobRuana You're welcome.

@aboe76
Copy link
Member

aboe76 commented Jul 29, 2018

@vutny could you take another look and ping me if it's ok?

@vutny
Copy link
Contributor

vutny commented Aug 1, 2018

@aboe76 @RobRuana My in-line comment above still applies. All latter states in postgres.manage are subscribed on changes from postgres-reload-modules. So if it succeeds without changes in subsequent highstate run, there would be no further states to trigger, even if related Pillar data would be changed.

@@ -176,6 +169,15 @@ postgresql-pg_hba:
{%- endif %}
- require:
- file: postgresql-config-dir
- watch_in:
- module: postgresql-service-restart
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've found that simply reloading the postgres service is not enough to pick up ACL changes in pg_hba.conf. A full restart is required.

This is on ubuntu 18.04 with postgres 10.

@RobRuana
Copy link
Contributor Author

RobRuana commented Aug 1, 2018

I'm going to close this pull request for now. I may revisit this issue, but for now I am okay with the postgres-reload-modules reporting changes all the time.

alxwr added a commit to alxwr/postgres-formula that referenced this pull request May 3, 2019
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