apache / apache/cloudstack-extensions

Network Namespace extension should support untagged public networks

オープン
#8 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
言語のデータがありません
スター
4
フォーク
4
平均マージ
1時間
マージ済み PR(30日)
3

説明

## 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 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.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

Network Namespace extension script とパブリックネットワークのセットアップパスから始め、次に一覧にある Marvin テストを実行します: 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。数値 VLAN 構成が現在の動作を維持すること、および明示的な untagged 構成によって VLAN サブインターフェースを作成せずにアドレス、ルート、ARP、NAT のセットアップが完了することを確認します。

索引モデルが issue の本文から書いたものです。

評価

領域
networking
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
55/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。