You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[UI/Bug] Missing "Template type" (ISO type) field in "Upload ISO from local" modal #13876
When uploading an ISO via the "Upload ISO from local" modal, the "Template type" selection field is missing.
In comparison, the "Upload Template from local" modal includes the Template type dropdown (USER, VNF, SYSTEM, BUILTIN, ROUTING). Because this is missing for ISO uploads, the ISO is not assigned the proper type, causing errors and forcing us to manually update the database table (vm_template) to set the type to USER.
versions
CloudStack: 4.19 (or latest main)
The steps to reproduce the bug
Navigate to Images -> ISOs.
Click "Upload ISO from local".
Observe that the "Template type" field is missing.
What to do about it?
The "Upload ISO from local" form/modal should include the "Template type" selection field (similar to "Upload Template from local") to allow selecting or properly defaulting the ISO type to 'USER'.
This looks related to the ISO vm_template.type = NULL regression previously reported in #12104 and fixed by #12151 / c3d6a8c.
There is an important version difference, though: #12104 was a 4.22 regression. The reporter there confirmed 4.21 worked before upgrading to 4.22.
I checked the 4.19 source and current 4.20 branch, and ordinary local ISO uploads already resolve to TemplateType.USER there. Current main also explicitly resolves GetUploadParamsForIsoCmd to USER.
So I don't think adding a UI templatetype selector is the right fix. The ISO upload APIs do not expose that parameter, and the backend is already expected to assign USER.
@MertkanOzlu, could you confirm the exact CloudStack version/build you reproduced this on, and whether vm_template.type is actually NULL immediately after a fresh local ISO upload?
That should tell us whether there is a backend regression here and, if so, whether it matches #12104.
@Dogface2k@MertkanOzlu , I am not sure to what extend the template type is relevant for ISOs. So I have no idea on the severity of this issue and what the fix should be. It is quite possible the upload is victim due to recent changes in teh way templates are handled though. needs-investigation...
Thanks @MertkanOzlu, that confirms the reported runtime symptom.
I checked the 4.22.0.0 and 4.22.0.1 code paths. For a local ISO upload, GetUploadParamsForIsoCmd goes through validateTemplateType(), and on both versions that method does not handle GetUploadParamsForIsoCmd, so it returns null. That matches #12104.
#12151 / c3d6a8c adds the missing ISO case and returns TemplateType.USER. That fix is included in the 4.22.1.0 release.
If you have a 4.22.1.0 environment available, could you confirm whether a fresh local ISO upload results in vm_template.type = USER?
If so, #13876 appears to be the already-fixed #12104 regression rather than a separate UI issue.
Thanks a lot for the detailed explanation and investigation.
I don't have a 4.22.1.0 environment readily available to test at the moment, but the root cause you explained makes total sense. If this is already resolved with #12151 in 4.22.1.0, feel free to close this issue as a duplicate of #12104.
Activity
Dogface2k commentedon Aug 14, 2026
@DaanHoogland
This looks related to the ISO
vm_template.type = NULLregression previously reported in #12104 and fixed by #12151 /c3d6a8c.There is an important version difference, though: #12104 was a 4.22 regression. The reporter there confirmed 4.21 worked before upgrading to 4.22.
I checked the 4.19 source and current 4.20 branch, and ordinary local ISO uploads already resolve to
TemplateType.USERthere. Currentmainalso explicitly resolvesGetUploadParamsForIsoCmdtoUSER.So I don't think adding a UI
templatetypeselector is the right fix. The ISO upload APIs do not expose that parameter, and the backend is already expected to assignUSER.@MertkanOzlu, could you confirm the exact CloudStack version/build you reproduced this on, and whether
vm_template.typeis actuallyNULLimmediately after a fresh local ISO upload?That should tell us whether there is a backend regression here and, if so, whether it matches #12104.
DaanHoogland commentedon Aug 16, 2026
@Dogface2k @MertkanOzlu , I am not sure to what extend the template type is relevant for ISOs. So I have no idea on the severity of this issue and what the fix should be. It is quite possible the upload is victim due to recent changes in teh way templates are handled though. needs-investigation...
MertkanOzlu commentedon Aug 17, 2026
Hi @Dogface2k @DaanHoogland,
Thanks for looking into this. Here are the details regarding the environment and the database state:
CloudStack Version / Build: 4.22.0
Immediately after performing a fresh local ISO upload, the vm_template.type field in the database is indeed NULL
Dogface2k commentedon Aug 17, 2026
Thanks @MertkanOzlu, that confirms the reported runtime symptom.
I checked the 4.22.0.0 and 4.22.0.1 code paths. For a local ISO upload,
GetUploadParamsForIsoCmdgoes throughvalidateTemplateType(), and on both versions that method does not handleGetUploadParamsForIsoCmd, so it returnsnull. That matches #12104.#12151 /
c3d6a8cadds the missing ISO case and returnsTemplateType.USER. That fix is included in the 4.22.1.0 release.If you have a 4.22.1.0 environment available, could you confirm whether a fresh local ISO upload results in
vm_template.type = USER?If so, #13876 appears to be the already-fixed #12104 regression rather than a separate UI issue.
MertkanOzlu commentedon Aug 17, 2026
Hi @Dogface2k,
Thanks a lot for the detailed explanation and investigation.
I don't have a 4.22.1.0 environment readily available to test at the moment, but the root cause you explained makes total sense. If this is already resolved with #12151 in 4.22.1.0, feel free to close this issue as a duplicate of #12104.
Thanks again for your support!
DaanHoogland commentedon Aug 19, 2026
thanks for the analysis @Dogface2k , closing as fixed in #12151 , please revert is 4.22.1 does not remedie your issue @MertkanOzlu