Bump DevStack to latest master and follow ML2 option rename

[bobuhiro11]

Summary

Update DEVSTACK_COMMIT in both images from a05d26eb to 9b0a0086, the current tip of openstack/devstack master (96 commits). Since DevStack installs nova, neutron and the other components from the tip of their own master branches, this pulls in the latest upstream for all of them.

One change in that range needs a matching change here.

The ML2 option rename

DevStack commit 03db96dc "Start using project_network_types for neutron ML2" now writes project_network_types into ml2_conf.ini instead of tenant_network_types, following the neutron rename where tenant_network_types became a deprecated_name alias.

controller/local.conf still set the deprecated key in its post-config. Since oslo.config prefers the current name when both are present in the same file, DevStack's own project_network_types=geneve would have won over our tenant_network_types=vxlan — leaving project networks on geneve, which the openvswitch agent does not tunnel (tunnel_types=vxlan,gre).

The fix is two lines:

• Q_ML2_TENANT_NETWORK_TYPE=vxlan in localrc, so DevStack itself picks vxlan. Its default is geneve, which is aimed at ML2/OVN — this repo uses ML2/OVS.
• rename the post-config key to project_network_types.

Verification

Image builds and hadolint could not be run in the environment this was prepared in (the container registries' blob hosts are blocked by egress policy), so CI is the first full run. What was checked instead:

Rendered ml2_conf.ini using DevStack's own inc/meta-config parser at the new commit, replaying extract_localrc_section and merge_config_file exactly as stack.sh does:

[ml2]
type_drivers = flat,gre,vlan,vxlan
project_network_types = vxlan
mechanism_drivers = openvswitch,l2population

[ml2_type_vxlan]
vni_ranges = 1:1000

[agent]
tunnel_types = vxlan,gre

The same replay against the pre-change local.conf produces the broken result that motivated the fix:

tenant_network_types = vxlan
project_network_types = geneve

Also reviewed the rest of the 96-commit range for things touching this setup:

• noble (24.04) is still in SUPPORTED_DISTROS in stack.sh.
• "Remove OVS kernel module build support" and "Don't set protocols on OVS bridges" only touch ovs_source / ovn_agent; this repo uses the packaged OVS with Q_AGENT=openvswitch.
• SRBAC and new keystone policy defaults are now on (ENFORCE_NEW_DEFAULTS, KEYSTONE_ENFORCE_NEW_DEFAULTS); test.bash runs as project-scoped admin, which upstream CI exercises with these defaults.
• NOVA_CPU_CONF is still /etc/nova/nova-cpu.conf, so pre-commit.bash is unaffected.

---

Generated by Claude Code

[bobuhiro11]

CI is not running: the workflow is disabled

No checks have appeared on this PR because the action workflow is currently disabled by GitHub:

GET /repos/bobuhiro11/containerized-devstack/actions/workflows/7206437
  "path":  ".github/workflows/action.yaml",
  "state": "disabled_inactivity"

GitHub auto-disables scheduled workflows in repositories with no activity for 60 days. The last run of any kind was the nightly on 2026-08-17 (run #1309), and there have been none since.

This needs a manual re-enable — Actions tab → action workflow → "Enable workflow". I do not have an API method to flip it from here. Once it is on, pushes and pull requests will trigger it again as usual, and this PR will get its first run.

The lint job was also broken, and is fixed here

Worth knowing before that run happens: the nightly on main had been red for 18 consecutive nights (since 2026-07-31, run #1292), and it was the lint job, not DevStack. The test job — build plus test.bash — passed on main as recently as 2026-08-17.

The lint job runs hadolint/hadolint:latest unpinned, and a hadolint release added rule DL3064, "Potentially sensitive data should not be used in the ARG or ENV commands":

-:13 DL3064 warning: Potentially sensitive data should not be used in the `ARG` or `ENV` commands
-:17 DL3064 warning: Potentially sensitive data should not be used in the `ARG` or `ENV` commands

Those are ENV OS_USERNAME=admin and ENV OS_PASSWORD=password, present in both Dockerfiles. hadolint exits 1 on warnings, so the job fails.

a89c85a adds DL3064 to HADOLINT_IGNORE alongside the existing DL3008. Those variables are the DevStack demo credentials — they match ADMIN_PASSWORD=password in local.conf and are what makes the documented docker compose exec controller openstack ... usage work on a development-only image — so ignoring the rule seemed better than dropping them. If you would rather not ignore it, the alternative is to move the OS_* block out of the images and into docker-compose.yaml as environment: entries; happy to do that instead.

Reproduced locally with hadolint 2.15.1: both Dockerfiles emit those two warnings and exit 1 before the change, and exit 0 after it.

Suggestion, not included here to keep the diff focused: pinning the lint image (e.g. hadolint/hadolint:v2.15.1) would stop a future hadolint release from turning the nightly red again the way this one did for two and a half weeks.

---

Generated by Claude Code

[bobuhiro11]

CI is green

The workflow has been re-enabled, and run 33148973944 passed on 5c941f7. Both jobs succeeded, every step included:

Job	Step	Result
lint	hadolint for controller / compute	success
test	Build Images (build + test.bash + pre-commit.bash)	success, 32 min
test	Push to Docker Hub	success
test	Test Images (docker compose up on the pushed images + test.bash)	success

Note that test.bash therefore passed twice — once against the freshly built containers and once against the images after they were pushed. It runs under bash -xe and ends with openstack server show testvm | grep ACTIVE, so a green step means testvm really did reach ACTIVE on the private project network, on both runs. That is the end-to-end confirmation the DevStack bump and the project_network_types change needed: had the network still come up as geneve, the openvswitch agent (tunnel_types=vxlan,gre) could not have bound the port and the VM would not have booted.

Enabling the workflow does not retroactively fire for a PR opened while it was disabled, so the run needed a new push. The hadolint pin in 5c941f7 — which I had suggested in the comment above — served as that push. It is a real change rather than a no-op commit: the DL3064 ignore was verified locally against hadolint 2.15.1, while CI was pulling latest, so the pin makes CI run the version the change was actually checked against. v2.15.1 currently resolves to the same image as latest, so it does not alter today's checks.

lint going green here also fixes the nightly on main, which had been red for 18 consecutive nights.

---

Generated by Claude Code