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

User not notified when creating a new EVC using a disabled interface #440

Open
RenataFrez opened this issue Jan 24, 2024 · 2 comments
Open
Labels
enhancement New feature or request future_release Planned for the next release priority_medium Medium priority

Comments

@RenataFrez
Copy link

While adding a new EVC using one or more endpoints that are disabled on Kytos, the Web Interface creates the EVC without any warning, just the usual message showing the EVC was created.

We can see the EVC as "Not Active" by checking the Web Interface.

Checking the Kytos logs, we can see that the EVC wasn't deployed:

2024-01-24 14:26:11,081 - WARNING [kytos.napps.kytos/mef_eline] [evc.py:740:deploy_to_path] (Thread-442602) EVC(fb4b6602ea7a40, Vlan_699_Loop_test_temp) was not deployed. No available path was found.

A user/admin can be led to believe there is something wrong with the network, but it is just a matter of enabling the interface or not using it.

Also, even if the interface is later enabled, the EVC will work only after a redeploy.

@viniarck viniarck added the enhancement New feature or request label Jan 24, 2024
@viniarck
Copy link
Member

Hi @RenataFrez, thanks for bringing this up. Yes, that's the currently behavior.

We can provide stronger validation guarantees if it's not desirable to even allow the EVC to be created if an UNI is disabled. Sometime ago, a related discussion was started on issue kytos-ng/mef_eline#332, please check it out.

I believe the first step is indeed to map the rest of the use cases / scenarios where network operators do not want to allow an EVC creation then it can get implemented, also let us know the priority of this issue and we can eventually prioritize it.

@viniarck viniarck added the priority_medium Medium priority label Jan 24, 2024
@viniarck
Copy link
Member

viniarck commented Feb 27, 2024

I'll set this on 2024.1 to keep on our radar to be discussed in the next planning

@viniarck viniarck added future_release Planned for the next release and removed 2024.1 labels Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request future_release Planned for the next release priority_medium Medium priority
Projects
None yet
Development

No branches or pull requests

2 participants