[2.3] Setting use_peer_proxy doesn't make MAAS restart maas-proxy

[Andres Rodriguez]

I recently changed the CI tests so that we test the proxy configuration a bit differently. before, we were simply using an upstream proxy. Now, we are using it as a peer proxy.

THe CI tests do this:

1. configure http_proxy with the external proxy
2. configure use_peer_proxy

While the CI correctly does this, and the maas-proxy.conf file are updated correctly, I noticed that maas-proxy is not being restarted. The reason I noticed is because machines, while they commissioned just fine, they failed to install the required tools because they were unable to reach the archive.

To debug, I logged into the MAAS server, setup apt to use itself as a proxy, and:

1. sudo apt-get update -> it didn't work
2. sudo service maas-proxy restart
3. sudo apt-get update -> it worked.

So that confirms that after /var/lib/maas/maas-proxy.conf was updated, the service was never really restarted.

This is causing consistent CI failures.

NOTE: this does NOT happen in 2.4 or 2.5.

[Mike Pontillo (mpontillo)]

The puzzling thing about this issue is the fact that MAAS always tries to reload the service when it writes out the config (if I'm reading the code correctly in maasserver/proxyconfig.py).

But I just had an idea: what if it's not working because we're using *reload* and not *restart*? (The code has two separate paths depending on whether or not we're running in the snap.)

So, what if it's a bug that occurs because the service is being reloaded and not restated?

If you get a chance, could you repeat your test, and check whether or not the second `apt-get update` works after a *reload* and not a restart?

If it fails with reload and then works with restart, I think we have our answer. It could be that there was a problem with reloading that was fixed with a post-Xenial version of squid.

[Mike Pontillo (mpontillo)]

Let's check if the code in this proposal fixes it:

https://code.launchpad.net/~mpontillo/maas/+git/maas/+merge/354525