status 9873: resolved fixed
Following fixes were made as a part of the checkin:
* When deploy user vm and SG doesn't exist in the DB, create it automatically.
* SecurityGroup enabled use vm start: if map to default group is not present in security_group_vm_map table, create one.
* Added "name" (securityGroupName) parameter back to deleteSecurityGroup/authorizeSecurityGroupIngress/deployVm. Mutually exclusive with security group id parameter.
Conflicts:
api/src/com/cloud/api/commands/AuthorizeSecurityGroupIngressCmd.java
api/src/com/cloud/api/commands/DeleteSecurityGroupCmd.java
api/src/com/cloud/api/commands/DeployVMCmd.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/vm/UserVmManagerImpl.java
Created a table for source cidrs list.
Created necessary Daos and VOs.
Updated PortForwardingRulesDao to persist/update non null list of cidrs.
For deletion depending on ON DELETE CASCADE.
Changes:
- Added a new parameter to pass in deployment plan during vm start
- If a hostId is passed in to the DeployVMCmd (only allowed for a root admin to test a host), a plan is passed in to start the vm in that host's datacenter, pod and cluster and on that host
- If a plan is passed in during start, but if the VM's root volume is READY, then plan of the root volume takes precedence. In that case the plan passed in is not used.
Changes:
- Added a new column `source_template_id` to vm_template table to carry the parent/source template ID from which the tempalte was created
- Added the column in db upgrade 224 to 225
- Changed code to save the source_template_id if there is one associated to the volume/ volume from which the snapshot was taken
- API response returns the sourcetemplateid field, if set, in all template usecases.
- CreateZone API creates a zoneToken, inserts in DB and returns it in the
response
- UpdateZone API takes in 'details' map that is loaded to data_center_details
- Local fix to not log the content for ModifySshKeyCommand.
- For commands that do not want to log the parameters, added the facility to indicate this.
- For such commands, we remove the parameters from the log.
Changes:
- Changed host allocators/planner to use cpu.overprovisioning.factor
- Removed following: while adding a new host, we were setting the total_cpu in op_host_capacity to be actual_cpu * cpu.overprovisioning.factor. Now we set it to actual_cpu.
- ListCapacities response now calculates the total CPU as actual * cpu.overprovisioning.factor (This change does not add anything new - listCapacities was pulling total CPU from op_host_capacity DB earlier which had the cpu.overprovisioning.factor applied already. Now we need to apply it over the DB entry.)
- HostResponse has a new field: 'cpuWithOverprovisioning' that returns the cpu after applying the cpu.overprovisioning.factor
- Db Upgrade 222 to 224 now updates the total_cpu in op_host_capacity to be the actual_cpu for each Routing host.
