Skip to content
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

feat: add support for auto (safe) interface deletion and a new endpoint to delete a disabled intf #191

Closed
viniarck opened this issue Mar 6, 2024 · 2 comments · Fixed by #196
Assignees
Labels
2024.1 Kytos-ng 2024.1 enhancement New feature or request epic_general Generic enhancement and/or fixes

Comments

@viniarck
Copy link
Member

viniarck commented Mar 6, 2024

This is a feature request from @italovalcy.

Context:

  • It turns out that recently in prod this was needed, when a logical interface got created and then deleted via switch configuration, but still the intf persisted, and actually also resulted in another issue.

Requirements:

  • When handling an interface deleted event '.*.switch.interface.deleted' that comes from a OFPPR_DELETE (you can simulate this by deleting an interface on OvS - sudo ip link delete s1-eth4), if the given interface has no links and no flows (either on in_port match or {"action_type": "output", "port": x} ), no allocated vlans, then it should be OK to automatically hard delete it. Otherwise just log.info that the interface couldn't automatically safely be deleted.
  • Add a new endpoint such as DELETE v3/interfaces/{intf_id} (similar to how @Alopalao implemented for links and switches recentely). On this endpoint, it should only hard delete if the interface has been disabled, has no associated links, and has no associated flows (same as previous paragraph)

To hard delete: The interface should be removed on a switch switch.remove_interface(intf), and then remove from the DB in the switches.interfaces[] collection it should be pulled from the array, and removed from interface_details.

The priority and target will still be defined.

Side note, this following script has been used recently to hard delete a non existing disabled interface (it was also filtering for not active due to special case in prod):

topology = controller.napps[("kytos", "topology")]
dpid = "00:00:00:00:00:20:00:01"
port_no = 1000
switch = controller.switches[dpid]
intf = switch.get_interface_by_port_no(port_no)

print(f"found intf {intf}")

if intf and not intf.is_enabled() and not intf.is_active() and not topology._get_link_from_interface(intf):
    switch_before = switch.as_dict()
    switch.remove_interface(intf)
    upserted = topology.topo_controller.upsert_switch(switch.id, switch.as_dict())
    print(f"upserted switch {upserted} before={switch_before}")

    res = topology.topo_controller.db.interface_details.find_one_and_delete({"_id": intf.id})
    print(f"db.interface_details deleted: {res}")

if not switch.get_interface_by_port_no(port_no):
    print(f"intf {intf} deleted")
else:
    print(f"intf {intf} NOT deleted")
@viniarck viniarck added enhancement New feature or request future_release Planned for the next release labels Mar 6, 2024
@viniarck viniarck added epic_general Generic enhancement and/or fixes 2024.1 Kytos-ng 2024.1 and removed future_release Planned for the next release labels Mar 18, 2024
@Alopalao Alopalao self-assigned this Apr 1, 2024
@Alopalao
Copy link

About VLAN usage, of_lldp uses all the interfaces of a switch or none of them. This would mean that currently to delete an interface, first it is needed to disable its switch to de-allocate all the VLANS from the switch interfaces.
This behavior it is not a blocker but it would require more work from the user. Because, the switch and its component would need to be enabled once the interface is deleted.

Found a partly of_lldp issue related to what was explained. Flows would only be installed in NNIs and allocate the respective VLAN.

@viniarck
Copy link
Member Author

@Alopalao, good observation, maybe we can in the meantime ignore allocated vlans and only rely on the flows in the DB? At the end of the day, the allocated vlans are primarily for validation purposes, in this case as you know it's ensuring that nobody will allocate a vlan that interferes with reserved of_lldp, but in practice as you mentioned there's no flow matching on a particular interface yet, and as far as deletion is concerned it cares about specific flows associated with an interface.

Potentially, in the meantime, you could:

  • Make a request to http GET 'http://0.0.0.0:8181/api/kytos/flow_manager/v2/stored_flows?state=installed&dpid=<dpid>', and then in the client topology here, you filter if you find any match: {"in_port": port_no}, or actions or instructions with output port_no. We could one day support this on flow_manager but for now, since this is the first usage and it's not that intensive it's probably not worth yet to add an index for it.

Let me know if you can see a simpler idea that wouldn't create tech debt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2024.1 Kytos-ng 2024.1 enhancement New feature or request epic_general Generic enhancement and/or fixes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants