[GabrielBrascher]

Description

Currently, it is possible to change the template used by virtual routers, but other system VMs do not have the same feature. The virtual router template is configured according to the respective global settings parameters: router.template.hyperv, router.template.kvm, router.template.lxc, router.template.xenserver, router.template.ovm, router.template.vmware.

This PR allows users to configure templates for storage system VMs (SSVMs) and console proxy system VMs with parameters similar with the virtual router template configuration: ssvm.template. and consoleproxy.template.

If a parameter is null then we use the default system VM.

This feature was useful in a practical scenario where the console proxy system VM template was customized.

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)

Screenshots (if appropriate):

How Has This Been Tested?

[wido]

Very nice and interesting! It might even be that in the future we should leverage this even more. This SSVM template is now difficult to manage since it has to be able to handle 3 different scenarios.

[yadvr]

Interesting PR, I'll ping couple of colleagues who may have more operational insights -- @PaulAngus @DagSontebo and others.

[yadvr]

@blueorangutan package

[blueorangutan]

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1572

[rafaelweingartner]

@GabrielBrascher can you rebase and fix conflicts?

[GabrielBrascher]

Sorry by the delay @rafaelweingartner, I will do it soon. Thanks!

[rafaelweingartner]

@GabrielBrascher can you fix the conflicts please?

[yadvr]

This PR may be closed, the global setting names may be confusing but the router.xxx global settings apply for cpvm, ssvm too.

[rafaelweingartner]

@rhtyd are you sure? Take a look at the code that deploys SSVM for instance [1] . Can you check line 645?

[1] https://github.com/apache/cloudstack/blob/8ef131745a5ef0e5e6ddc7e498f3a0208f1bfb71/services/secondary-storage/controller/src/main/java/org/apache/cloudstack/secondarystorage/SecondaryStorageManagerImpl.java

[GabrielBrascher]

Hi @rhtyd, sorry for the delay on this one.

Unfortunately, that parameter (router.xxx) changes only router templates. At least that is what happened when I tested last time. Also, I looked at the code, and right now that parameter is not used to select SSVMs and console proxy templates.

[DaanHoogland]

functionally this is good. I definately would want a marvin test for this that at least proves the success case so we can track regressions if we merge it.

[yadvr]

@GabrielBrascher thanks for replying. When we do update new systemvmtemplate with every release, it does get used for all systemvms and not just only routers so I disagree what you share. We can test of course, see this upgrade path for example where only the new template's name is updated for the router.xxx global settings: https://github.com/apache/cloudstack/blob/master/engine/schema/src/main/java/com/cloud/upgrade/dao/Upgrade41000to41100.java#L175

[yadvr]

I verified that changing systemvmtemplate by following the changes that the upgrade path does, indeed changes the systemvmtemplate for all vrs and systemvms (cpvm/ssvm). This may be closed @GabrielBrascher. If you'd prefer, please perform a test yourself, thanks.

[GabrielBrascher]

Thanks, @rhtyd. I used that code in CloudStack 4.9.3.0 when it was requested to edit system VM template but without that code, it was updated only templates for virtual routers. After that, I created a PR for the master.

I will review all and perform a test here as well to make sure.

[yadvr]

@GabrielBrascher perhaps you can explore refactoring of the systemvmtemplate upgrade code we've as part of the upgrade path, as an service layer API that may also be used via registerTemplate to make it easier to register/use a new systemvmtemplate.

[DennisKonrad]

Hi @GabrielBrascher, @rhtyd,

what's the status of this? The feature looks interesting. Would be nice to specify different templates.

Also I have the feeling you both misunderstood each other. Rhtyd talked about changing the SystemVM-template which leaves CS no other option as to deploy the new template when a systemvm needs to be deployed.

Gabriel talked about the possibility to specify another template to use as CP or SSVM i think. I think that are two different things.

[GabrielBrascher]

That is indeed the main goal, @DennisKonrad. Thanks for pointing that!

[DennisKonrad]

@rhtyd What do you think? Maybe you could clarify on what you disagree with in this request or where/why you want to see changes to this?

[PaulAngus]

@DennisKonrad I'm told by our guys that the router global setting in fact DOES change the temple for the ssvm and cpvm. Which would unfortunately make this redundant.
Some of the ShapeBlue guys are working on a discrete API to update/change the system VMs template at any time.

[DennisKonrad]

@PaulAngus I think so too. But the feature here allows for different templates instead of having the same template for router, ssvm and console proxy.

Feel free to correct me on this :)

[GabrielBrascher]

@PaulAngus @rhtyd this PR allows to have different templates for Virtual Router (VR), Console Proxy VM (CPVM), and Storage System VM (SSVM); thus, a feature that we all know it is not yet implemented for CloudStack. I do not see any technical reason for blocking this PR.

Cases where this can be useful:

1. VR has template A, SSVM has template B, and CPVM has template C;
2. VR has template A, SSVM has template A, and CPVM has template B;
3. VR has template A, SSVM has template B, and CPVM has template A; and
4. VR has template A, SSVM has template B, and CPVM has template B;

I created this PR at 2017 because it was a critical feature for a data center in Brazil. For sure this would help multiple CloudStack's users, @DennisKonrad is one of them.

Additionally, I experienced (more than once) a case where it was not possible to configure all system VMs with the same template (VR with template A, SSVM template A, CP template A). I will explain myself.

The method findSystemVMReadyTemplate is called during the creation of SSVM and CPVM.

    @Override
    public VMTemplateVO findSystemVMReadyTemplate(long zoneId, HypervisorType hypervisorType) {
        SearchCriteria<VMTemplateVO> sc = readySystemTemplateSearch.create();
        sc.setParameters("templateType", Storage.TemplateType.SYSTEM);
        sc.setParameters("state", VirtualMachineTemplate.State.Active);
        sc.setJoinParameters("tmplHyper", "type", Host.Type.Routing);
        sc.setJoinParameters("tmplHyper", "zoneId", zoneId);
        sc.setJoinParameters("vmTemplateJoinTemplateStoreRef", "downloadState", VMTemplateStorageResourceAssoc.Status.DOWNLOADED);

        // order by descending order of id
        List<VMTemplateVO> tmplts = listBy(sc, new Filter(VMTemplateVO.class, "id", false, null, null));

        if (tmplts.size() > 0) {
            if (hypervisorType == HypervisorType.Any) {
                return tmplts.get(0);
            }
            for (VMTemplateVO tmplt : tmplts) {
                if (tmplt.getHypervisorType() == hypervisorType) {
                    return tmplt;
                }
            }

        }
        return null;
    }

Thus, SSVMs and CPs templates are selected by descending order of id from table vm_template where the template type is of 'SYSTEM', the state is as 'Active', type of 'Routing', zone id as zoneId, has been downloaded and the hypervisor of the hypervisorType. In some cases more than one templates fit the select (multiple templates of 'SYSTEM', 'Active', 'Routing', same zone Id, same hypervisor), thus it returns the template that has the bigger Id, not the one that is configured for the router. Furthermore, if a root admin registers a new template for the system VM this template will not be owned by the system (type is of 'ROUTING', not 'SYSTEM'). Only during upgrades, the templates that are marked as 'ROUTING' are converted to 'SYSTEM'.

Note that for the VR the template is selected as follows. This DOES NOT happen for SSVM and CPVM:

final String templateName = retrieveTemplateName(hType, routerDeploymentDefinition.getDest().getDataCenter().getId());
final VMTemplateVO template = _templateDao.findRoutingTemplate(hType, templateName);

In conclusion, I am not seeing any technical reason to block this PR. What do you think guys? @DaanHoogland @dhlaluku @nvazquez @dagsonstebo @wido

[PaulAngus]

thanks @DennisKonrad OK, now that I understand why you're doing this, I can see what you're trying to achieve.
IMO what you are trying to achieve is great, but there is a lot around that the feature that would need to take into account before it would be 'safe' for users who are not so familiar with your design intent.

for instance (off the top of my head):
Now that there would potentially be no 'main/default' template, how do we define which system VMs & VRs need updating, when a new system vm template is 'required' for a new release. we check one now, what would we check in future?
Would we potentially need a 'requires update' state for cpvm and ssvm?
If you you've already thought of of this (and maybe more), awesome! then could you maybe share your FS to allay my paranoia .

[GabrielBrascher]

That is a good point @PaulAngus.

What I have in mind is to keep system VM upgrade as it is on current documentation, adding just one point regarding the fact that the user should set the upgraded template for all system VMs, or update his customized templates based on the new template.

Note that for upgrading all templates, one could set the VR, SSVMs and CPVMs templates with the upgraded template, or set SSVM and CPVM as null and the VR template with the upgraded template.

[DennisKonrad]

@PaulAngus I agree with @GabrielBrascher that the default way of upgrading should stay the same. If no 'personalized' templates are set, the vr router template should be used.

The "required update" idea seems more of an enhancement to me that would be great regardles of this pr here ;) If a user does not upgrade his svm's according to the documentation that might not be a problem (if lucky).
But a friendy reminder (in the UI) would be nice.

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✖centos6 ✔centos7 ✔debian. JID-1030

[DaanHoogland]

@blueorangutan test

[DaanHoogland]

@GabrielBrascher can you triage this yourself?
Is it still applicable?
Do we want it in 4.15?

[GabrielBrascher]

@DaanHoogland thanks for the ping. I think that it is more a matter of working with the systemvm upgrade process.

Considering that it was not a top priority and 4.13.1/4.14.0 were on tigh schedule I did not invevst much time on this one. I will take another look on it as soon as 4.14 is released and we faced the python3 migration :)