RHEL package repositories do not have releases > 2.18

[mjyeaney]

Hopefully this isn't noise - apologies if it is.

Trying to run a few deployments today on Azure/RHEL instances, and realized that while the VM image ships with 2.18-1, yum is unable to find any newer versions.

Tried clearing yum caches to no avail; no newer versions are found. Note that Ubuntu is able to see the latest production release of 2.21 after running apt-get update.

Are there known delays/issues with packages getting updated on the RHEL package repositories? I do realize customers can manually install if needed, but curious why we're not even auto-updating when new releases have been available for a while.

[boumenot]

Each Distro determines the version of the agent they ship, and we work with them to accept or not a new version.

The agent ships as two pieces.

1. Provisioning agent that runs from the version installed on the guest.
2. Extension processing agent that can update independently of the version installed on the VM.

When the first starts (after provisioning), it will check if a newer version is available, and install it automatically. This settings is controlled via a /etc/waagent.conf flag.

What are you looking for in a later version? What are your concerns about the current version vs. a later version?

[mjyeaney]

[Apologies for the close/re-open...not the button I was looking for]

Anyway - we're trying to diagnose external communication that is crossing the guest NIC and hitting a customers proxy causing lots of unexpected chatter. There are some proxy updates that occurred in later that may help with this issue based on internal discussions.

Glad to discuss offline if you want to email me (miyean).

[boumenot]

We prefer to be open, unless there's an explicit need to be private.

I recommend upgrading the agent, capturing an image, and deploying the image to see if it addresses your issue. Install instructions are on this repo's README. If that fixes the issue we can go from there.

I recommend http://packer.io for creating images, but that isn't a hard requirement.

[mjyeaney]

(Apologies for the delay - was traveling)

Issue

What we're seeing is Host/local traffic that is still getting directed to the defined proxy as setup in /etc/waagent.conf (via HttpProxy.Host). This is leading to calls to http://168.63.129.16:32526/extensionArtifact hitting the proxy (and failing with HTTP 400), as well as a high-volume of traffic to (I believe) the status page blobs. An example from the squid proxy log is shown below:

1519389179.219    197 10.251.108.17 TCP_TUNNEL/200 4014 CONNECT md-pnhrw3qcnb55.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389179.220     80 10.251.108.17 TCP_TUNNEL/200 4044 CONNECT md-pnhrw3qcnb55.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389179.561    139 10.250.6.5 TCP_TUNNEL/200 4014 CONNECT md-1cgh1mxj5gwx.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389179.563     61 10.250.6.5 TCP_TUNNEL/200 4044 CONNECT md-1cgh1mxj5gwx.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389179.719    187 10.251.224.8 TCP_TUNNEL/200 4014 CONNECT md-n45qlbqh5pmg.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.94 -
1519389179.721     96 10.251.224.8 TCP_TUNNEL/200 4044 CONNECT md-n45qlbqh5pmg.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.94 -
1519389179.922    188 10.251.224.14 TCP_TUNNEL/200 4144 CONNECT md-dj10pfblshds.blob.core.windows.net:443 - HIER_DIRECT/51.141.129.74 -
1519389179.923     65 10.251.224.14 TCP_TUNNEL/200 4176 CONNECT md-dj10pfblshds.blob.core.windows.net:443 - HIER_DIRECT/51.141.129.74 -
1519389179.953    173 10.250.6.6 TCP_TUNNEL/200 4144 CONNECT md-dbwj20fkgfh5.blob.core.windows.net:443 - HIER_DIRECT/51.141.128.36 -
1519389179.954     79 10.250.6.6 TCP_TUNNEL/200 4176 CONNECT md-dbwj20fkgfh5.blob.core.windows.net:443 - HIER_DIRECT/51.141.128.36 -
1519389180.563    110 10.251.108.21 TCP_TUNNEL/200 15612 CONNECT ardfepirv2ln1prdstr02a.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389180.938    203 10.250.2.10 TCP_TUNNEL/200 4144 CONNECT md-g1fgsmltvlvv.blob.core.windows.net:443 - HIER_DIRECT/51.141.128.36 -
1519389180.939     96 10.250.2.10 TCP_TUNNEL/200 4176 CONNECT md-g1fgsmltvlvv.blob.core.windows.net:443 - HIER_DIRECT/51.141.128.36 -
1519389181.360    234 10.251.104.4 TCP_TUNNEL/200 4014 CONNECT md-r2zlts2xxpcl.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142 -
1519389181.361    159 10.251.104.4 TCP_TUNNEL/200 4044 CONNECT md-r2zlts2xxpcl.blob.core.windows.net:443 - HIER_DIRECT/51.140.168.142

Impact

Because this traffic is being directed to the customers' proxy, and because this proxy in located in a peered VNET, this is causing some un-anticipated cost spikes due to egress/ingress charges on VNET peering. Ideally, this traffic should stay on the host.

Desired Resolution

The hope was the fixes in #769 and #800 would alleviate this traffic. However this requires updating to the newer versions - which aren't currently available in the RHEL repo's (note that Ubuntu is already showing 2.21 once apt runs a cache update). Customer could always manually install, but they are not keen on this at the moment (unless absolutely required).

Please let me know if you need additional detail - glad to assist.

[hglkrijger]

I do not see any action to be taken here, the customer can either wait for a repo update or upgrade from source. Closing this issue.