New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ensure => absent on Ethernet interfaces fails #424
Comments
Looks related to the I'm not sure the best solution for this, as most logical interfaces have to be removed via the |
@tomcooperca This is an interesting case. As you pointed out physical interfaces are not really ensurable because if they are present they will always exist (can't be destroyed) regardless of their individual attributes. Let me discuss how we might restore a physical interface to it's default state with my development team and get back to you. For now you could use the |
What if "ensure => absent" translated to "default the interface and shutdown"? The administrative state would have to merge with the "shutdown" parameter -- if shutdown was false then it would default the interface and 'no shut'. If shutdown was true or not defined it would default the interface and shutdown. |
@krisamundson The "system default switchport" config settings interfere with shutdown so that probably wouldn't fly. When I originally wrote the interface provider I suggested early on that we support "ensure => absent" for physical interfaces == default interface. It's easy enough to implement in the node utils destroy method but as Mike points out it's difficult to reliably detect idempotency here. I suppose you could just use the output from a "show run interface" command (no "all"), though that would have to take into account the "system default" configs and likely a few other things. I suspect it would be a bit buggy but it's worth reconsidering this idea. |
PS: for my use case, the command_config works fine as it's just to remove test config and is only run once anyways. FWIW, I'm also using the shutdown attribute to admin-down ports that are unused and mark them as "vacant" in the description. I'm almost inclined to think that the ensure remain as-is, as it already removes logical interfaces from the configuration. Looks to be a behaviour inherit to NX-OS where the physical interface is forever "present" in the running config even if it is defaulted or not in use. |
What about |
Sure, 'purged' is probably more meaningful than absent in this case. |
@tomcooperca Good to know that |
Would a regex check on Has
Matches successfully. Has
No match found (there's configuration present below the Could this be sufficient and/or testable? Or would this interfere with existing logical interfaces for the |
Generally speaking, if no attributes are visible under the interface using the |
Got it, makes perfect sense - keep me posted! |
@tomcooperca We tried multiple solutions for this but decided it would be best to add a property that would allow you to purge the config on ethernet interfaces. Let us know if this works for you and we can close this out. |
Hey all,
I'm running through some basic manifests for testing & validation of the module against our config. I have a manifest for each corresponding feature that applies some basic dummy configuration then a removal class that cleans it up.
In this manifest, I have two Ethernet interfaces to become part of a port-channel, which then is configured as a vPC Peer Link. However, when I run through the removal class to un-configure the Ethernet interfaces (using
cisco_interface { 'Ethernet1/10': ensure => absent, }
), a CLI error is produced. See below:vpc.pp
vpc_removal.pp
Here's the
--debug
run while trying to run the vpc_removal class:Manually applying these commands via CLI results in the same error. I believe a fix for this would be to use
default interface EthernetX/X
, which would remove all configuration on a physical interface and restore it to default state, which is essentially what I'm trying to accomplish with the ensure => absent attribute.The text was updated successfully, but these errors were encountered: