whamcloud/iml-update-check

iml-update-check

iml-update-check's Issues

Implement Update check

Background

Prior to 4.1, IML sent a listing of changed packages over the wire from the agent to the manager.

Agent side:

https://github.com/whamcloud/iml-agent/blob/a167f1c8e58585c8c75f5ad1489a63b9c44f39a7/chroma_agent/device_plugins/lustre.py#L92-L125

Manager side:

https://github.com/whamcloud/integrated-manager-for-lustre/blob/0f9129ac8ce9795b371665f4fe399348fc1a5eaf/chroma_core/services/lustre_audit/update_scan.py#L70-L102

This was not a persistent update, but occurred during session establishment. In addition it sent way more data over the wire than was necessary to determine if a package update was available.

In 4.1 IML is no longer delivered wholesale but in a modular fashion via RPMs. This means we need to be checking for updates at a more regular cadence.

Implementation

IML 4.1 has extracted general config to standalone environment files / settings, which allows us to use modular pieces. Here is an example of config on the agent side:

IML_MANAGER_URL=https://adm.local:443/

and on the manager side:

LOG_PATH=/var/log/chroma
REALTIME_PORT=8888
SERVER_HTTP_URL=https://adm.local:443/
ALLOW_ANONYMOUS_READ=true
BUILD=50
IS_RELEASE=true
LOG_PATH=/var/log/chroma
SERVER_HTTP_URL=https://adm.local:443/
SITE_ROOT=/usr/share/chroma-manager
VIEW_SERVER_PORT=8889
VERSION=4.0.6.0-40-g5887f34
API_USER=api
API_KEY=XX
SOURCE_MAP_PATH=/usr/share/iml-manager/iml-gui/main.3ee649d960f624951b75.js.map

Using the extracted config, create two services that run on the agents and manager.

The first service will use the Python DNF API to detect if there are any updates available. It will send a JSON encoded boolean whether there are updates available as a HTTPS POST to the manager.

A partial implementation exists here: #2

It will run under a systemd timer, but will also be callable standalone.

The second service will run on the manager and will receive POSTs from the agents. When updates are available, it will raise an alert via the IML API for that host. When updates are no longer available, it will lower the alert given one currently exists.

This service can be implemented as a systemd service (daemon) and tied into the iml-manager.target. Nodejs or Go are good choices for this service as they don't block on IO and have built-in http servers and clients.

Finally, a new block will need to be added to the nginx config to proxy to this service and add client certificate auth to it.

Need to resolve from yum + dnf, or switch to using only yum

In #9, we started to filter out deps that weren't present already, or had no parents that were present.

However, if a package was installed via yum, it will report @System as it's from_repo.

This means we either need to check both dnf and yum in the service, or switch to only using yum and update this service to use the yum api as well

Resolve from server profiles or remove server profiles

iml-update-check filters to whatever is in /etc/yum.repos.d/Intel-Lustre-Agent.repo, but this may be at odds with what is supplied in a given server profile.

We either need to be aware of specific server profiles and take their repos / packages into account, or remove server profiles and rely on yum metapackages directly instead.

Update check timer does not fire on start

iml-update-check.timer does not fire on startup.

It should have OnActiveSec=10 added to the timer.

metadata should be cleared on start

When starting, we should first ensure yum metadata has been cleared.