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

Bug #1789932 reported by Andres Rodriguez on 2018-08-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Critical
Unassigned
2.3
Critical
Mike Pontillo
2.4
High
Unassigned

Bug Description

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.

Related branches

Changed in maas:
importance: Undecided → Critical
status: New → Triaged
status: Triaged → Fix Released
milestone: none → 2.5.0
milestone: 2.5.0 → none
tags: added: rack-proxy track
summary: - [2.3] use_peer_proxy doesn't prompt maas-proxy to be restart
+ [2.3] Setting use_peer_proxy doesn't make MAAS restart maas-proxy
description: updated
Mike Pontillo (mpontillo) wrote :

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) wrote :

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

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers