Ability to delete and down all connection profiles for a given interface about network HOT 12 CLOSED

Desired behavior is I, I want to remove all configuration for a physical interface port. That includes any way that port is defined (initscripts, networkmanager, other).

If interface is a member of a bond (or other aggregate technology such as teaming), it should be removed from bond membership but not delete parent bond or other members.

from network.

also, do not require a type to be specified when deleting by hardware identifier:

        network_connections:
          - name: net1
            state: down
            persistent_state: absent

fatal: [rhel7]: FAILED! => {"changed": false, "msg": "error: Connection not found on system and 'type' not present"}

from network.

also, do not require a type to be specified when deleting by hardware identifier:

I suppose the issue is that in order to down the interface a temporary profile is created and then deleted. And to create the profile one needs to specify type (type has really a special meaning, its presence means that the profile is fully specified in the dictionary - which is unexpected as well). @tyll is that right?

from network.

Desired behavior is I, I want to remove all configuration for a physical interface port. That includes any way that port is defined (initscripts, networkmanager, other).

I suspect the underlying issue is the conceptual decision to let the role manage network connections, not interfaces. Which is somewhat dubious from the user point of view (why should the user care about connections? They are NetworkManager specific things and not a general networking concept and the goal of system roles is to abstract away such details. What we will do when NetwokManager is replaced by something else which does not use the "connection" abstraction?) It will be hard to change now, though.

from network.

Desired behavior is I, I want to remove all configuration for a physical interface port. That includes any way that port is defined (initscripts, networkmanager, other).

It is possible to define everything that you would like to keep and then remove everything else with a single 'persistent_state: absent' profile that will match all remaining profiles and remove them. It will work only for initscripts or networkmanager since we support only one backend at the same time. To me this seems to be sufficient for the normal case where people would like one configuration for their server, they can specify it completely and apply it. The matching on the device name will cause additional ambiguities, say we have:

- interface_name: eth0
  persistent_state: absent

• what if there is a profile that does not specify a MAC address or interface name, therefore the profile can be valid for eth0 - should it be removed?
• what if there is a profile that specifies the MAC address of the card that is currently named eth0 - should the profile be removed?

AFAICS, there are scenarios where all of this makes sense.

If interface is a member of a bond (or other aggregate technology such as teaming), it should be removed from bond membership but not delete parent bond or other members.

This would require to also down the profiles, since the persistent_state affects only the persistency for the profile on disk.

from network.

Profiles are a bundle of settings that define how to configure a networking interface. That concept is not novel, and initscipts' ifcfg and systemd-networkd's .network files are a similar thing.

Usually, profiles are matched on an (ethernet) device based on certain properties, like the interface-name (hopefully predictable) or the MAC address. Already here, some users need to it by name, some by MAC address, or even other ideas like physical location. If the role would for example model configuration strictly per-device, it would need to define whether to match it by name of by MAC (or both, or configurable?). Such a model might be suitable for some users, but not for others. The profile-based model is the more powerful one, which can accommodate all use-cases.

But sure, the role could also present a quite different configuration model to the user. Would it be better? Maybe, that was IMO not shown yet.

The role can currently delete profiles by name (the ID) or all profiles which are not explicitly named. Sure, the absent command could also accept more filters and delete profiles based on things like the MAC address. Is that really a useful feature? IMO, the role is not to replace command nmcli ..., nor should it offer such an API. Instead it provides a declarative API where the playbook describes the desired state. Do we really need the flexibility to define absence of profiles based on what's inside the profile?

@tabowling why is it not sufficient to define/declare the profiles you want to keep, and delete all others?

from network.

also, do not require a type to be specified when deleting by hardware identifier:

I suppose the issue is that in order to down the interface a temporary profile is created and then deleted. And to create the profile one needs to specify type (type has really a special meaning, its presence means that the profile is fully specified in the dictionary - which is unexpected as well). @tyll is that right?

There is #70 to ignore errors for absent interface - @pcahyna also argued that this could be the default behaviour. The type is the least information that is required to fully specify a profile since there are then defaults for the other values if not specified (for example for DHCP).

from network.

I suspect the underlying issue is the conceptual decision to let the role manage network connections, not interfaces. Which is somewhat dubious from the user point of view (why should the user care about connections? They are NetworkManager specific things and not a general networking concept and the goal of system roles is to abstract away such details. What we will do when NetwokManager is replaced by something else which does not use the "connection" abstraction?) It will be hard to change now, though.

There is no problem with supporting something that allows only one configuration for an interface because then the one configuration of the interface can be treated as a profile. It will just not be possible to specify multiple profiles for the same interface. Also the user does not need to care about profiles as long as they only use the role to manage networking since then they can just use one connection/profile per interface. The problem happens when there are already multiple profiles because the networking was configured in a different way as well.

Btw. with the inconsistent network naming, using profiles also allows to specify one profile that would match every interface and for example configure DHCP. This would work great for single NIC machines where the interface name can be different because of different hardware.

from network.

also, do not require a type to be specified when deleting by hardware identifier:

I suppose the issue is that in order to down the interface a temporary profile is created and then deleted. And to create the profile one needs to specify type (type has really a special meaning, its presence means that the profile is fully specified in the dictionary - which is unexpected as well). @tyll is that right?

Well, I guess that depends on if a profile already existed. In my case, a profile did already exist, so a temporary one should not be needed.

But regardless, whether an existing profile exists, as a user I expect the tool to auto detect the type and profile and take care of that for me.

from network.

The role can currently delete profiles by name (the ID) or all profiles which are not explicitly named. Sure, the absent command could also accept more filters and delete profiles based on things like the MAC address. Is that really a useful feature? IMO, the role is not to replace command nmcli ..., nor should it offer such an API. Instead it provides a declarative API where the playbook describes the desired state. Do we really need the flexibility to define absence of profiles based on what's inside the profile?

@tabowling why is it not sufficient to define/declare the profiles you want to keep, and delete all others?

If I want to provision new servers in an automated way, I likely want to remove any default configurations and profile names that do not meet my environment standards. Particularly when I want to name connections with user friendly, descriptive names such as "mgmt_net" or "db_pub"

If I have to manually look this up, especially when our installer has inconsistently named the profiles different than the linux device name, then this breaks my automation.

Clearly you have all raised multiple scenarios that we must be careful with and we should discuss them thoroughly.

from network.

If I want to provision new servers in an automated way, I likely want to remove any default configurations and profile names that do not meet my environment standards.

There is a way to remove all existing profiles that are not specified in the list, is that enough?

But regardless, whether an existing profile exists, as a user I expect the tool to auto detect the type and profile and take care of that for me.

Sure. I was describing the origin of the current behaviour, not necessarily the desired state.

from network.

If I want to provision new servers in an automated way, I likely want to remove any default configurations and profile names that do not meet my environment standards.

There is a way to remove all existing profiles that are not specified in the list, is that enough?

To this seems to address the concerns/user story and there is no obvious next step for the role. Therefore I close this issue considering there was no activity for some time. Please re-open a file a new one, if you disagree.

from network.