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

nginxplus: only the configs in our config directory should exist on the server #2750

Closed
hackartisan opened this issue Feb 10, 2022 · 5 comments

Comments

@hackartisan
Copy link
Member

e.g. if an old config is removed from ansible it should also be removed from the remote server.

Current behavior is that the old config is still there after the playbook has been run.

@acozine
Copy link
Contributor

acozine commented Feb 14, 2022

The current role has a tasks file with a single task that "cleans up" the config. It removes the entire config directory. The role includes that file only when the variable nginx_cleanup_config is set to true - that var is set to false in the role defaults.

Do we want that task to run every time we upload new configs? So that each time the playbook runs (unless it runs with -t SSL) , it would delete the config directory and upload all configs from scratch? If so, we can put it in the upload_config.yml tasks file, before the upload task, and tag it with tags: update_conf.

If we only want that task to run occasionally, we can update the README and playbooks to document the existing behavior: "To remove all existing config files before uploading, pass -e nginx_cleanup_config=true when you run the playbook."

@acozine
Copy link
Contributor

acozine commented Feb 14, 2022

Per @tpendragon we can use the synchronize module with delete.

@acozine
Copy link
Contributor

acozine commented Feb 14, 2022

Add a test for this new behavior. Probably needs a pre-task in molecule/default/converge.yml that adds an extraneous file, then a test in molecule/default/verify.yml that checks to be sure the file disappears when the playbook runs.

@acozine
Copy link
Contributor

acozine commented Dec 29, 2022

Test for this as part of #3439

@acozine
Copy link
Contributor

acozine commented Feb 9, 2024

Related to #4654 - I think that PR should fix/close this ticket, except we are not testing for this behavior yet.

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

No branches or pull requests

2 participants