RosiKyu commented on PR #14033:
URL: https://github.com/apache/cloudstack/pull/14033#issuecomment-5714475960
Tested this on a 24.0.0 build: OL9 Management server, 2 KVM hosts, Advanced
Networking, single MS. The database was seeded at 4.0.0 and ran the full
upgrade chain, so the new `Upgrade42300to2400` step was exercised end to end.
Two issues found, the first one I would treat as a blocker.
### What I checked
| Area | Checked | Result |
|---|---|---|
| Upgrade 4.23.0.0 to 24.0.0 runs and completes | yes | PASS |
| `version` table stores the 3 part `24.0.0` | yes | PASS |
| Upgrade is idempotent on restart (`DB version = 24.0.0 Code Version =
24.0.0`, no upgrade needed) | yes | PASS |
| `schema-42300to2400.sql` name resolution from the version range | yes |
PASS |
| `NoopDbUpgrade` tail handling for a future 25.x SNAPSHOT | yes | PASS |
| Parsing: 4 part value rejected at major >= 24, legacy 4 part below 24
still accepted | yes | PASS |
| Ordering across the cutover: 24.0.0 > 4.23.0.0, 24.0.2 > 24.0.1, 24.1.0 >
24.0.9 | yes | PASS |
| `toString()` gives `24.0.0` and not `24.0.0.0` from `24.0.0-SNAPSHOT` |
yes | PASS |
| Branding suffix stripping on a shapeblue build | yes | PASS |
| `trimRouterVersion` fallback is itself parseable, and nothing downstream
keys on the old `"0"` | yes | PASS |
| `templateConfig.sh` legacy and cutover paths (the PR's own suite) | yes |
PASS, 16/16 |
| `export-templates.sh` | yes | **FAIL, see issue 1** |
| `listCapabilities.cloudstackversion`, `listManagementServers`,
`listHosts`, `listSystemVms` | yes | PASS, all report 24.0.0-SNAPSHOT |
| `listRouters`: template version 4.22.0 vs software version 24.0.0,
requiresupgrade | yes | PASS |
| `listRouters version=` filter | yes | PASS |
| VR programming end to end (create and delete an egress rule) | yes | PASS |
| `minreq.sysvmtemplate.version` with a valid 3 part value | yes | PASS |
| `minreq.sysvmtemplate.version` with a 4 part value | yes | **FAIL, see
issue 2** |
| UI footer version and Virtual Routers page | yes | PASS |
| UI "new version available" logic across legacy and new tags | yes | PASS,
correct for all realistic inputs |
| RPM and DEB upgrade ordering (24.0.0 > 4.23.0.0 and > 4.24.0.0),
debian/changelog order | yes | PASS |
| All poms, marvin setup.py, Dockerfiles, checkstyle pom, simulator CI
version extraction | yes | PASS, no drift |
| VR health check scripts (`router_version_check.py`,
`get_template_version.sh`) | yes | PASS, plain string compare, not affected |
| Any leftover `since = "4.24"` annotations | yes | PASS, none |
| Installed filesystem scan for stale 4.2x version strings | yes | PASS |
| Usage server and KVM agent package and jar versions | yes | PASS |
### Issue 1: export-templates.sh has a syntax error and does not run at all
The new cutover if/else in `scripts/installer/export-templates.sh` is
missing its closing `fi`, so the script does not parse.
Expected result: the script runs and derives the template filename prefix
from metadata.ini.
Actual result: it aborts immediately with a syntax error, for any input.
```
[root@ref-trl-12372-k-Mol9-nicolas-vazquez-mgmt1 ~]# bash -n
/usr/share/cloudstack-common/scripts/installer/export-templates.sh
/usr/share/cloudstack-common/scripts/installer/export-templates.sh: line
207: syntax error: unexpected end of file
[root@ref-trl-12372-k-Mol9-nicolas-vazquez-mgmt1 ~]#
```
This is not only in the diff, it is in the packaged RPM, and since it ships
in `cloudstack-common` it is on the KVM hosts as well as the management server.
Same result on all three nodes. The same check passes on main.
### Issue 2: a 4 part minreq.sysvmtemplate.version breaks listRouters and
all VR operations
`minreq.sysvmtemplate.version` accepts any string, and with the new rules a
value such as `24.0.0.0` is rejected by `CloudStackVersion.parse` with nothing
catching the exception.
Steps: set `minreq.sysvmtemplate.version` to `24.0.0.0` with
updateConfiguration, then call listRouters, or make any change that reprograms
the VR.
Expected result: either the value is rejected when it is set, or the version
check treats it as "router needs upgrading".
Actual result: the value is accepted with no error, then listRouters fails
and every VR operation fails.
listRouters:
```
"errorcode": 431,
"errortext": "org.apache.cloudstack.utils.CloudStackVersion.parse(String)
passed 24.0.0.0, but major versions at or above 24 do not support legacy
int.int.int.int format"
```
createEgressFirewallRule, job fails with resultCode 530:
```
java.lang.IllegalArgumentException:
org.apache.cloudstack.utils.CloudStackVersion.parse(String) passed 24.0.0.0,
but major versions at or above 24 do not support legacy int.int.int.int format
at
org.apache.cloudstack.utils.CloudStackVersion.parse(CloudStackVersion.java:145)
at
org.apache.cloudstack.utils.CloudStackVersion.compare(CloudStackVersion.java:196)
at
org.apache.cloudstack.utils.CloudStackVersion.compare(CloudStackVersion.java:177)
```
### Still to do
I am building a second environment for the upgrade side: a populated
4.23.0.0 database, mixed hypervisors including VMware, and two management
servers. That will cover the things this environment could not: upgrade of a
database with real data in it, the clustered upgrade guard with both MS up, the
VMware path, and what `minreq.sysvmtemplate.version` ends up as after a real
upgrade rather than a fresh install. Will report back.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
