Network Namespace extension should support untagged public networks

Start with the Network Namespace extension script and the public-network setup path, then run the listed Marvin tests: test_05_isolated_network_full_lifecycle, test_06_vpc_multi_tier_and_restart, test_07_vpc_network_acl, and test_09_vpc_source_nat_ip_update. Verify that numeric VLAN configurations retain their current behavior and that explicit untagged configuration completes address, route, ARP, and NAT setup without creating a VLAN sub-interface.

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.