Comments (12)
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.
Related Issues (20)
- Feature request: support adding tun devices HOT 14
- Routing rules improvement HOT 6
- Eliminate non-inclusive language HOT 5
- Address CodeQL warnings HOT 4
- Network override HOT 1
- add 'auto-dns' option also to network_connections HOT 6
- How to keep existing profile name HOT 3
- Verify and document no-aaaa DNS option HOT 2
- network_state should not change IPv6 state when not configured HOT 2
- Question Changing the IP of the remote host HOT 3
- ipv4.dns-data: unknown property (7) HOT 6
- RFE: Add support for DNS caching HOT 3
- WireGuard support HOT 1
- Rename the task `name: Check if rpm ostree system - cannot test` into a meaningful name explaining the reason for skipping test HOT 2
- Add support for veth pair HOT 3
- Add support for scope and src route options HOT 4
- not idempotent HOT 4
- Need further output from "check" mode HOT 7
- VRF Support HOT 2
- EL-7 tests fails because there is no EPEL-7 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from network.