Publishing salt-server-list.rst back to psf-salt onchanges

[cegerhardson]

One possible avenue to publish any changes in salt-server-list.rst back to our python/psf-salt repository is to:

1. Apply the state git.latest which clones the repository to a local directory. This state would require the force_reset parameter to be set to True, allowing it to always stay up to date with the remote repository.
2. A file.managed state would be used to ensure that salt-server-list.rst is present in the local copy of the repository and it's contents are up to date with its source file.
3. After applying the git.latest state, and tracking your file using file.managed you could then use git.push to push any changes to the remote repository.

It's important to note that the user parameter must have necessary permissions to access the repository. Could possibly create an automated Salt user with limited permissions for the purposes of running these commands and states.

Another avenue may to be establish a githib workflow that runs on a scheduled cron interval, pulls changes from salt using salt-cp, and creates a pull request using create-pull-request action.

[ewdurbin]

I think a variant of this idea might be best:

Another avenue may to be establish a githib workflow that runs on a scheduled cron interval, pulls changes from salt using salt-cp, and creates a pull request using create-pull-request action.

I don't think we can use salt-cp since GitHub Actions runners aren't part of.... and I don't think we want to add them to... our salt installation.

Rather, we could potentially publish files over HTTP from the salt-master that we want to fetch. Similar to the way that we have the salt-master respond to LetsEncrypt acme-challenges in

psf-salt/salt/base/salt.sls

Lines 60 to 81 in 24fae9b

	/etc/nginx/sites.d/letsencrypt-well-known.conf:
	file.managed:
	- source: salt://base/config/letsencrypt-well-known-nginx.conf
	- user: root
	- group: root
	- mode: "0644"
	- require:
	- file: /etc/nginx/sites.d/
	- sls: tls.lego
	/etc/consul.d/service-letsencrypt-well-known.json:
	file.managed:
	- source: salt://consul/etc/service.jinja
	- template: jinja
	- context:
	name: letsencrypt-well-known
	port: 9000
	- user: root
	- group: root
	- mode: "0644"
	- require:
	- pkg: consul-pkgs

, we could:

• Create a new /srv/public directory
• Change the psf_known_hosts and salt-server-list.rst managed files to be created in that directory
• Add an nginx config and consul-service that serves that directory over HTTP
• Add a service to our loadbalancer that exposes that HTTP service to the world
• Outside of salt, we would add a DNS record pointing to that domain on the loadbalancer

Then our scheduled GitHub Action can access the files via HTTP, see if they've changed, and use the create-pull-request action to open a PR when they do.

[ewdurbin]

This is complete. #343