[Bug]: nm_ip (new in 3008.3) cannot load: salt.utils.network.nm_managed() does not exist

Abierto
  • ¿Algo no está bien?
#70,463 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
44/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, devops

Línea de trabajo

Start with salt/modules/nm_ip.py and its __virtual__() check, then inspect salt/utils/network.py and salt/modules/rh_ip.py to understand the missing shared condition and provider ownership. Check the module loading behavior on a RedHat-family minion and look for related tests. Done means nm_ip loads under its stated conditions, the other provider defers consistently, and module loading no longer emits the reported errors.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug needs-triage severity-high
What happened?

A bug happened!### Description

salt/modules/nm_ip.py, new in 3008.3, can never load. Its __virtual__() calls salt.utils.network.nm_managed(), and that function does not exist in salt/utils/network.py — not in 3008.3, and not on master. The AttributeError is caught by the loader, which then emits a second, misleading warning telling the operator to contact the module's developer.

Every module-load pass on a RedHat-family minion logs:

[ERROR   ] Exception raised when processing __virtual__ function for salt.loaded.int.module.nm_ip. Module will not be loaded: module 'salt.utils.network' has no attribute 'nm_managed'
[WARNING ] salt.loaded.int.module.nm_ip.__virtual__() is wrongly returning `None`. It should either return `True`, `False` or a new name. If you're the developer of the module 'nm_ip', please fix this.

There appear to be three parts of one change, of which only the first was merged:

  1. salt/modules/nm_ip.py — merged. New in 3008.3; absent at the v3008.2 tag. At line 286:

    def nm_managed():
    ...
    return salt.utils.network.nm_managed()

    and __virtual__() at line 258 gates on it:

    if not nm_managed():
    return (
        False,
        "nm_ip: NetworkManager is not managing this system, or the legacy "
        "ifup/ifdown tooling is present (rh_ip handles it)",
    )

  2. salt.utils.network.nm_managed() — not merged. No such attribute at v3008.2, v3008.3 or master. The module's own docstring states the intent:

    This is the deterministic, load-time-safe condition that decides whether nm_ip or rh_ip owns the ip provider. The check itself lives in :py:func:salt.utils.network.nm_managed`` so both providers share a single definition, exactly one claims ip and no runtime service call is needed during `virtual` resolution.

  3. The corresponding rh_ip change — not merged. nm_ip.__virtual__'s docstring says "rh_ip defers under the same condition and precisely one provider claims ip", but salt/modules/rh_ip.py's __virtual__ is byte-identical between v3008.2 and v3008.3 and contains no reference to nm_managed.

Setup

Salt 3008.3 (Argon), onedir packages, Rocky Linux 9.8, Python 3.14.7. NetworkManager-managed host.

Not environment-specific — it reproduces on any RedHat-family minion on 3008.3, and the missing attribute can be confirmed without a minion at all.

Steps to Reproduce the behavior

On any RedHat-family 3008.3 minion:

/opt/saltstack/salt/bin/python3 -c "import salt.utils.network as n; print(hasattr(n, 'nm_managed'))"
False

The loader errors appear in the minion log on any module-load pass, e.g. salt-call --local test.ping -l debug.

Confirmable straight from the repository as well:

curl -so /dev/null -w '%{http_code}\n' https://raw.githubusercontent.com/saltstack/salt/v3008.2/salt/modules/nm_ip.py   # 404
curl -so /dev/null -w '%{http_code}\n' https://raw.githubusercontent.com/saltstack/salt/v3008.3/salt/modules/nm_ip.py   # 200
curl -s https://raw.githubusercontent.com/saltstack/salt/master/salt/utils/network.py | grep -c nm_managed              # 0
Expected behavior

nm_ip loads on hosts matching its stated condition (RedHat family, NetworkManager active, no legacy ifup/ifdown), and defers cleanly elsewhere — without an exception and without the loader advising the operator to fix a module that ships with Salt.

Screenshots/Logs

The two log lines above, repeated on every module-load pass.

Additional context

Functionally this looks like dead code rather than a regression: rh_ip still claims the ip provider unconditionally on RedHat-family hosts, exactly as in 3008.2, so no existing behavior changed. The practical effects are that the NetworkManager provider 3008.3 appears to add is unavailable, and that affected minions log an error plus a misleading warning continuously.

Since nm_managed is also missing on master, a fix is presumably needed on both branches.

Two possible directions, depending on intent:

  • Add salt.utils.network.nm_managed() and the matching rh_ip deferral, completing the change.
  • Or, if the feature isn't ready, revert nm_ip from the 3008.x branch so it isn't shipping as a module that cannot load.

disable_modules: [nm_ip] looks like the operator-side workaround, though I haven't confirmed whether the blacklist is consulted before __virtual__ is called or after.

Versions Report
salt --versions-report 
(paste output here)
Type of salt install

Official rpm

Major version

3008.x

What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)

rockylinux-9

salt --versions-report output
Salt Version:
          Salt: 3008.3

Python Version:
        Python: 3.14.7 (main, Sep 30 2026, 03:35:11) [GCC 11.2.0]

Dependency Versions:
          cffi: 2.0.0
      cherrypy: 18.10.0
  cryptography: 50.0.1
      dateutil: 2.9.0.post0
     docker-py: Not Installed
         gitdb: 4.0.12
     gitpython: 3.2.0
        Jinja2: 3.1.6
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.2.1
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 24.0
     pycparser: 3.00
      pycrypto: Not Installed
  pycryptodome: 3.23.0
        pygit2: Not Installed
  python-gnupg: 0.5.6
        PyYAML: 6.0.3
         PyZMQ: 27.1.0
        relenv: 0.22.27
         smmap: 5.0.2
       timelib: 0.3.0
       Tornado: 6.5.10
           ZMQ: 4.3.5

Salt Extensions:
 saltext.mysql: 1.1.0
 saltext.vault: 1.6.0

Salt Package Information:
  Package Type: onedir

System Versions:
          dist: rocky 9.8 Blue Onyx
        locale: utf-8
       machine: x86_64
       release: 5.14.0-687.58.1.el9_8.0.1.x86_64
        system: Linux
       version: Rocky Linux 9.8 Blue Onyx
Lenguaje dominante
Python
Estrellas
15.8k
Forks
5.6k
Merge medio
5 d 9 h
PR fusionados (30 d)
99

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de saltstack/salt

Todos los issues de saltstack/salt

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.