Only one depot is updated of 4 default ones

[i3laze]

Code of Conduct

• I have read and agree to the Code of Conduct.
• Vote on this issue by adding a 👍 reaction to the original issue initial description to help the maintainers prioritize.
• Do not leave "+1" or other comments that do not add relevant information or questions.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

VMware Cloud Foundation

8.0 U3g

PowerShell Version

7.6.2

PowerCLI Version

9.1.0

Guest Operating System

Windows 11

Environment Details

vCenter 8.0 U3g with Update Depot cleansed after 7.0 upgrade.
(/usr/lib/vmware-updatemgr/bin/updatemgr-utility.py reset-db)

No Internet connectivity for vCenter on script first run.

Description

Initially, my vCenter 8.0U3g had no Internet connectivity, so script was failing on after step:
[INFO] Beginning depot update operations...

Later current release 1.0.0.0.55 patched only 1 depot and was happy about it.

Error or Debug Output

[WARNING] https://dl.broadcom.com//PROD/COMP/ESX_HOST/vmtools-main/vmw-depot-index.xml has already been added as an ESX Depot to "". No changes are required.

Expected Behavior

All 4 depots cloned with with Broadcom tokens embedded.
"3. Check depot configurations" menu option to mark an issue of depots missing.

VMwareDepotChange - Fixed by Claude.zip

Actual Behavior

First depot populated and stopped.
Check depot configurations passing fine.

Steps to Reproduce

Haven't actually tried, but sharing my experience:

1. Disable Internet connectivity for vCenter, leave only DNS and local network access.
2. Try "4. Update depot configurations" with download token - 1 depot should become updated and script stopped with warning.
3. Script will never update remaining depots later.

Log Fragments and Files

Claude.Ai Fable5 suggested following changes:

Line (orig) | Change | Effect 2151 | Premature } removed; foreach now closes after the create block | All four depot URLs get created, not just the last (vmtools-main) 2159 | return → continue (spec-creation failure) | One bad depot skips, doesn't abort the rest 2182 | return → continue (vCenter validation failure) | Same — your original no-internet scenario would now report 4 errors instead of dying on the first

I've attached the working copy, that actually did the job on populating all 4 repos.
Sorry, no Pool Request, as I didn't check thoroughly that code.

Screenshots

References

No response

[nathanthaler]

Thanks for the bug report and proposed solution, @i3laze !

You're spot on, this is a genuine issue. The code was expecting only two conditions: all depots configured for the new repo structure or none of them configured. Supporting a non "clean-slate" run is important.

While analyzing your fix, I found a few other places where we need to follow a pattern of "continue" rather than "return" in the face of incomplete configuration.

I should have a tested fix in a few days.