Regression 4.21.0: cloud-setup-databases errors out on --schema-only

[bradh352]

Description

PR #11239 introduced a regression when initializing the cloudstack database when the schema already exists and passes the --schema-only command line option.

This PR fixes that issue.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

Not very readable, but here's the output from my ansible playbook on the failure:

TASK [service_cloudstack : Setup cloudstack database on bootstrap node] **************************************************************************************************************************************************************
task path: /Users/bhouse/svn/ansible-scripts/roles/service_cloudstack/tasks/cloudstack-mgmt.yml:166
fatal: [node1.testenv.bradhouse.dev]: FAILED! => {"changed": true, "cmd": "cloudstack-setup-databases 'cloudstack:CloudDBPass@10.10.100.10' --schema-only --mshost=10.10.100.2 --encrypt-type=file --managementserver-secretkey='Test123$' --database-secretkey='ThisIsADbKey'", "delta": "0:00:00.227846", "end": "2025-09-10 12:46:58.209302", "msg": "non-zero return code", "rc": 1, "start": "2025-09-10 12:46:57.981456", "stderr": "\n\nWe apologize for below error:\n***************************************************************\nAborting script as the databases (cloud, cloud_usage) already exist.\nPlease use the --force-recreate parameter if you want to recreate the schemas.\n***************************************************************\nPlease run:\n\n    cloudstack-setup-databases -h\n\nfor full help", "stderr_lines": ["", "", "We apologize for below error:", "***************************************************************", "Aborting script as the databases (cloud, cloud_usage) already exist.", "Please use the --force-recreate parameter if you want to recreate the schemas.", "***************************************************************", "Please run:", "", "    cloudstack-setup-databases -h", "", "for full help"], "stdout": "Mysql user name:cloudstack                                                      [ \u001b[92mOK\u001b[0m ]\nMysql user password:******                                                      [ \u001b[92mOK\u001b[0m ]\nMysql server ip:10.10.100.10                                                    [ \u001b[92mOK\u001b[0m ]\nMysql server port:3306                                                          [ \u001b[92mOK\u001b[0m ]\nUsing specified cluster management server node IP 10.10.100.2                   [ \u001b[92mOK\u001b[0m ]\nChecking Cloud database files ...                                               [ \u001b[92mOK\u001b[0m ]\nChecking local machine hostname ...                                             [ \u001b[92mOK\u001b[0m ]\nChecking SELinux setup ...                                                      [ \u001b[92mOK\u001b[0m ]\nPreparing /etc/cloudstack/management/db.properties                              [ \u001b[92mOK\u001b[0m ]", "stdout_lines": ["Mysql user name:cloudstack                                                      [ \u001b[92mOK\u001b[0m ]", "Mysql user password:******                                                      [ \u001b[92mOK\u001b[0m ]", "Mysql server ip:10.10.100.10                                                    [ \u001b[92mOK\u001b[0m ]", "Mysql server port:3306                                                          [ \u001b[92mOK\u001b[0m ]", "Using specified cluster management server node IP 10.10.100.2                   [ \u001b[92mOK\u001b[0m ]", "Checking Cloud database files ...                                               [ \u001b[92mOK\u001b[0m ]", "Checking local machine hostname ...                                             [ \u001b[92mOK\u001b[0m ]", "Checking SELinux setup ...                                                      [ \u001b[92mOK\u001b[0m ]", "Preparing /etc/cloudstack/management/db.properties                              [ \u001b[92mOK\u001b[0m ]"]}

How Has This Been Tested?

Tested by manually patching a live system being set up.

How did you try to break this feature and the system with this change?

N/A

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache CloudStack community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
Here are some useful points:

• In case of a new feature add useful documentation (raise doc PR at https://github.com/apache/cloudstack-documentation)
• Be patient and persistent. It might take some time to get a review or get the final approval from the committers.
• Pay attention to the quality of your code, ensure tests are passing and your PR doesn't have conflicts.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Issues, Mailing list and Slack.
• Be sure to read the CloudStack Coding Conventions.
  Apache CloudStack is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@cloudstack.apache.org (https://cloudstack.apache.org/mailing-lists.html)
  Slack: https://apachecloudstack.slack.com/

[bradh352]

@nvazquez can you review since you introduced the breaking PR?

[nvazquez]

Thanks @bradh352 - LGTM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 17.36%. Comparing base (8089d32) to head (8da312e).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11609   +/-   ##
=========================================
  Coverage     17.36%   17.36%           
- Complexity    15245    15246    +1     
=========================================
  Files          5888     5888           
  Lines        525831   525831           
  Branches      64183    64183           
=========================================
+ Hits          91298    91303    +5     
+ Misses       424227   424222    -5     
  Partials      10306    10306           

Flag	Coverage Δ
uitests	3.63% <ø> (ø)
unittests	18.40% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[harikrishna-patnala]

@blueorangutan package

[blueorangutan]

@harikrishna-patnala a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 14948

[nvazquez]

Sorry @bradh352 I previously approved but after reviewing the original issue the PR was fixing (#11202) the flag force-recreate was introduced to prevent data loss. So I think a better solution for this use case should be also passing the force-recreate flag along with the schema-only flag instead of this fix. What do you think? cc @DaanHoogland @harikrishna-patnala @weizhouapache

[weizhouapache]

Sorry @bradh352 I previously approved but after reviewing the original issue the PR was fixing (#11202) the flag force-recreate was introduced to prevent data loss. So I think a better solution for this use case should be also passing the force-recreate flag along with the schema-only flag instead of this fix. What do you think? cc @DaanHoogland @harikrishna-patnala @weizhouapache

I agree with you @nvazquez

It has been mentioned in the cloudstack documentation

https://docs.cloudstack.apache.org/en/4.21.0.0/installguide/management-server/_database.html#install-the-database-on-the-management-server-node

@bradh352
I think this is not an issue.
You can update the ansible playbook by adding a flag --force-recreate as @nvazquez suggested

[bradh352]

Ok, thanks. I think the "recreate" part threw me off then since its a fresh install.