Feat(eos_designs): Add support for l3_port_channel_interfaces for WAN

[ashenoy-arista]

Change Summary

Revised schema to support L3 Port-Channel interfaces and supporting changes to eos_designs
Primary use-case is to allow such interfaces as wan-facing interfaces.

Related Issue(s)

Fixes #4695

Component(s) name

arista.avd.eos_designs

Proposed changes

How to test

This change introduces revised schema within eos_designs with node key l3_port_channels
to represent L3 port-channel interfaces that may be used as wan-facing interfaces.
Includes logic to support the newly added schema and unit tests to validate handling of newly added schema attributes.

Checklist

User Checklist

• N/A

Repository Checklist

• My code has been rebased from devel before I start
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation and documentation have been updated accordingly.
• I have updated molecule CI testing accordingly. (check the box if not applicable)

[github-actions]

Review docs on Read the Docs

To test this pull request:

# Create virtual environment for this testing below the current directory
python -m venv test-avd-pr-4752
# Activate the virtual environment
source test-avd-pr-4752/bin/activate
# Install all requirements including PyAVD
pip install "pyavd[ansible] @ git+https://github.com/ashenoy-arista/avd.git@samplePRBranch#subdirectory=python-avd" --force
# Point Ansible collections path to the Python virtual environment
export ANSIBLE_COLLECTIONS_PATH=$VIRTUAL_ENV/ansible_collections
# Install Ansible collection
ansible-galaxy collection install git+https://github.com/ashenoy-arista/avd.git#/ansible_collections/arista/avd/,samplePRBranch --force
# Optional: Install AVD examples
cd test-avd-pr-4752
ansible-playbook arista.avd.install_examples

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[gmuloc]

partial review - need to continue but sending initial comments

[gmuloc]

Should the ACL be there? I think it should not be inherited?

[ashenoy-arista]

You might be correct here.
The generated config itself does not have any ACL being applied to Ethernet4 interface.
ACL-INTERNET-IN_Port-Channel4 is being applied for Port-Channel4 interface. So that seems fine.

Issue is with documentation table being generated.
This documentation related snippet appears to be being generated via logic in python-avd/pyavd/_eos_cli_config_gen/j2templates/documentation/ethernet-interfaces.j2 lines 430-440
In the case when ethernet intf is a member of a port-channel, we seem to be setting ip_address, vrf, mtu, shutdown, acl_in, acl_out for ethernet_interface based on values derived from corresponding Port-Channel<> interface.
Would it be correct to inherit values for such attributes?

[gmuloc]

let's set peer_interface here for the example

[gmuloc]

can we move this back to structured_config? If not lets open an issue to add this in eos_cli_config_gen

[gmuloc]

confirmed it is not there - lets open an issue to support this

[ashenoy-arista]

Issue has been opened for eos_cli_config_gen to support dhcp_server_ipv4 attribute when populated for Port-Channel interface within structured config
#4875

Once we have the fix, we could replace raw_eos_cli with block below
structured_config: dhcp_server_ipv4: true

[gmuloc]

just confirming we should not have a tag here for Port-Channel?

(From our discussion I think thats correct but jsut want to make sure)

[ashenoy-arista]

Based on our discussion, we are NOT generating any interface tag for L3 Port-channel and its member ethernet interfaces. Once we have added support in CVaaS side to handle tags/etc associated with Port-Channel interface, we would then revisit this to generate interface tags.

[gmuloc]

lets add a similar test for port-channel to make sure we catch this as well (from a security purposes)

[gmuloc]

@ClausHolbechArista not sure what we can do here

[ClausHolbechArista]

if you call it with ._get("mode") you will only get the value if it was manually given.

[gmuloc]

Suggested change

	msg = f"Port-Channel sub-interface '{l3_port_channel}' has 'member_interfaces' set.This is not a valid setting."
	# TODO: Add better context with source
	msg = f"Port-Channel sub-interface '{l3_port_channel}' has 'member_interfaces' set.This is not a valid setting."

please add a negative unit test for this

[gmuloc]

Wondering if we should not try to be more specifc here by listing all of the ones with issues using set difference:

• refactor error message

Suggested change

	for parent_port_channel in subif_parent_port_channel_names:
	if parent_port_channel not in regular_l3_port_channel_names:
	msg = "At least one L3 Port-Channel subinterface does not have parent Port-Channel interface specified."
	raise AristaAvdInvalidInputsError(msg)
	if (missing_parent_port_channel := subif_parent_port_channel_names.difference(regular_l3_port_channel_names)):
	msg = "At least one L3 Port-Channel subinterface does not have parent Port-Channel interface specified."
	raise AristaAvdInvalidInputsError(msg)

[gmuloc]

no need

Suggested change

	# Note: structured config for individual member ethernet ports of each port-channel
	# would be generated by logic within EthernetInterfacesMixin class.

[gmuloc]

switch if and else and use

if "."  not in interface_name:
  regular_l3_port_channel_names.add(interface_name)
  continue
<continue with code for subif>