Network Namespace extension should support untagged public networks

Commencez par le Network Namespace extension script et le chemin de configuration du réseau public, puis exécutez les tests Marvin indiqués : test_05_isolated_network_full_lifecycle, test_06_vpc_multi_tier_and_restart, test_07_vpc_network_acl et test_09_vpc_source_nat_ip_update. Vérifiez que les configurations VLAN numériques conservent leur comportement actuel et qu’une configuration untagged explicite termine la configuration de l’adresse, de la route, d’ARP et de NAT sans créer de sous-interface VLAN.

Summary

The current Network Namespace extension code does not support an untagged public network. It treats the public VLAN value as a numeric VLAN ID and attempts to create a VLAN sub-interface. In an environment where the public network is intentionally untagged, this causes the following Marvin tests to fail if the Public network is not tagged (a valid scenario):

• test_05_isolated_network_full_lifecycle
• test_06_vpc_multi_tier_and_restart
• test_07_vpc_network_acl
• test_09_vpc_source_nat_ip_update

The later Static NAT and port-forwarding errors appear to be consequences of the initial public-network setup failure, rather than four unrelated test failures.

Environment

• CloudStack Marvin smoke tests
• Network Namespace extension
• Public network is untagged and uses the existing bridge/uplink path
• No tagged public VLAN is available on this test network

Observed behavior

The extension attempts to create a VLAN interface using the literal value untagged, resulting in an error similar to:

Error: argument "untagged" is wrong: id is invalid

The Network Namespace extension script then exits with code 2, and the dependent network operations fail.

Expected behavior

When the configured public network is untagged, the extension should:

1. Skip creation of an ethX.<vlan> VLAN sub-interface.
2. Use the existing bridge or physical uplink directly.
3. Continue with the required address, route, ARP, and NAT setup.
4. Preserve the current behavior for numeric VLAN configurations.

A public network does not inherently require VLAN tagging; both tagged and untagged deployments are valid. Supporting the explicit untagged mode would allow the same tests to run on simple bridge/NAT-based lab networks without requiring an artificial VLAN configuration.

Validation

Please consider adding coverage for both:

• Numeric VLAN configuration, preserving current tagged behavior.
• Explicit untagged configuration, without creating a VLAN sub-interface.

It would also be helpful if the extension scripts used by a test run could be pinned to a commit or release, rather than fetched from a moving branch at runtime, so that failures remain reproducible.

This issue concerns the Network Namespace extension only; it is not a change to the default CloudStack Virtual Router path.