Prevent config files from being reverted when they are part of an unmerged PR #133

New Issue

2020-02-15T19:49:37Z

greg commented

2020-02-15 19:49:37 +00:00

This evening the ejabberd config file was reverted when we upgraded Mastodon on andromeda, because #132 is not merged and I didn't warn that the current master branch of this repo would rewrite the config file

We could make it so the firewall rules can be used as a separate recipe. For example, we could temporarily disable changing the ejabberd config by editing the role in the master branch, and leaving out only the firewall rules. The last commit on master explicitly saying why the role has been changed temporarily.

This evening the ejabberd config file was reverted when we upgraded Mastodon on andromeda, because #132 is not merged and I didn't warn that the current master branch of this repo would rewrite the config file We could make it so the firewall rules can be used as a separate recipe. For example, we could temporarily disable changing the ejabberd config by editing the role in the master branch, and leaving out only the firewall rules. The last commit on master explicitly saying why the role has been changed temporarily.

raucao commented

2020-02-15 20:00:45 +00:00

I think the way you frame this issue is not addressing the underlying problems.

Why is there a config in production that hasn't been approved beforehand via a PR?
Why is the firewall rule necessary, but not the rest? Why can the firewall rule be merged/changed, but not the rest? Why wouldn't there be a separate PR for that in the first place?

Edit: For simply removing a role from a node when experimenting manually, I don't see why we even need an open issue here.

I think the way you frame this issue is not addressing the underlying problems. 1. Why is there a config in production that hasn't been approved beforehand via a PR? 2. Why is the firewall rule necessary, but not the rest? Why can the firewall rule be merged/changed, but not the rest? Why wouldn't there be a separate PR for that in the first place? Edit: For simply removing a role from a node when experimenting manually, I don't see why we even need an open issue here.

greg commented

2020-02-17 13:44:45 +00:00

Removing a role from a node will remove the firewall rules included by that role, closing access to the service when someone runs Chef, making everything even more confusing and dangerous

I definitely agree that me setting the ejabberd config manually was not ideal. I think we can close this issue and focus on merging PRs, and not making manual changes to config files

Removing a role from a node will remove the firewall rules included by that role, closing access to the service when someone runs Chef, making everything even more confusing and dangerous I definitely agree that me setting the ejabberd config manually was not ideal. I think we can close this issue and focus on merging PRs, and not making manual changes to config files

greg closed this issue

2020-02-17 13:44:45 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#133