Skip to content

FortiOS: update logic in the initial playbook#3336

Draft
a-v-popov wants to merge 1 commit intoipspace:devfrom
a-v-popov:fos-initial-update
Draft

FortiOS: update logic in the initial playbook#3336
a-v-popov wants to merge 1 commit intoipspace:devfrom
a-v-popov:fos-initial-update

Conversation

@a-v-popov
Copy link
Copy Markdown
Collaborator

@a-v-popov a-v-popov commented Apr 19, 2026

Fix for #3335

  • Task "Enable multi-VDOM mode if a traffic VDOM is defined" is always executed and it set only the proper vdom-mode.
  • Task "Wait after VDOM mode change" is executed when netlab_vdom_timer > 0 is set
  • Creation of the traffic VDOM is offloaded to the template

netlab_vdom_timer would be 0, if not set. For backward compatibility it might be better choice to set it to 60.

Jinja template is optimized to reduce flow control after VDOM, but I am not sure if system interfaces stanza has always been available from a VDOM.

FortiOS: update logic in the initial playbook
f5372a2 
- Task "Enable multi-VDOM mode if a traffic VDOM is defined"
  is always executed and it set only the proper vdom-mode.
- Task "Wait after VDOM mode change"
  is executed when netlab_vdom_timer > 0 is set
- Creation of the traffic VDOM is offloaded to the template
@a-v-popov a-v-popov force-pushed the fos-initial-update branch from 0fe8965 to f5372a2 Compare April 19, 2026 20:48
@sdargoeuves
Copy link
Copy Markdown
Collaborator

sdargoeuves commented Apr 19, 2026

Thanks for this, it's looking great — and nice tidy-up on the hostname part.

I did a quick test, using a vagrant box on 7.4.8, created without VDOM, just the bare minimum configuration.

Test 1 - no netlab_vdom in the topology file

netlab up completes correctly, I haven't checked much further, but it seems ok!

Test 2 - set netlab_vdom: netlab to let netlab configure a multi-vdom FW

It fails with this error message:

TASK [Ensure `root` VDOM is set as admin] *****************************************************************************************
fatal: [fw1]: FAILED! => {"changed": false, "meta": {"http_status": 429, "raw": "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>429 Too Many Requests</title>\n</head><body>\n<h1>Too Many Requests</h1>\n<p>The user has sent too many requests\nin a given amount of time.</p>\n<p>Additionally, a 429 Too Many Requests\nerror was encountered while trying to use an ErrorDocument to handle the request.</p>\n</body></html>\n"}, "msg": "Error in repo"}

Now if I try to run netlab initial a little while later (I waited more than 1 minute), it works successfully.

Test 3 - set netlab_vdom: netlab and netlab_vdom_timer: 60

It now works correctly, as the 1 minute waits allows for the multi-vdom change to be applied.

My concern is Test 2 — failing unless the user sets an extra variable isn't great. I'd expect the reverse case (multi-VDOM box, topology disables it) to hit the same issue — have you tried it?

You already suggested defaulting netlab_vdom_timer to 60 for backward compatibility — I'd lean that way as the simplest fix.

Alternatively (or additionally), we could add retry logic on this task when we see a 429 (or any failure), which would make the playbook more resilient with or without vdom-mode transition. Hopefully the error response/type is consistent across FortiOS versions!

@sdargoeuves sdargoeuves mentioned this pull request Apr 20, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@a-v-popov @sdargoeuves