status 9336: resolved fixed
Following changes were made:
* deleteSecurityGroup/authorizeSecurityGroupIngress - removed account/domainId parameters as SG is uniquely identified by id now
* removed account_name field from securityGroup DB table; removed allowed_security_group/allowed_sec_grp_acct from security_ingress_rule.
These values were used for api response generation only for performance purposes; added caching on API level to improve performance
* Added missing security checks for securityGroups/ingressRules
Changes:
- Cluster entry is not removed from the table when a cluster is deleted because there are some foreign key constraints failing if the row delete is attempted. Instead the cluster is marked as 'removed'
- While deleting the pod changed the check to see if pod has any clusters - we now check that there are no clusters with removed column null.
- Also pod entry cannot be deleted from the db due to foreign key constraints. So added 'removed' column to Pod table host_pod_ref
- Now on deleting a pod, the pod will be marked as removed and pod name is set to null.
Changes:
- Now while listing hosts for migration, capacity is calculated as total_capacity -used_capacity
instead of total_capacity -(used_capacity + reserved_capacity)
- Also, the capacity columns in op_host_capacity are now 'signed' type so that the subtractions in queries does not overflow.
- Added this to DB upgrade 222 to 224 change as well.
1) No longer do multiple searches involving "domain" table; only one join with domain is being done.
2) Do join with domain table only when command is executed by domainAdmin
3) Added index for "path" field in "domain" table
4) No longer do joins with account table as account_id is already present in vm_instance table.
1) No longer do multiple searches involving "domain" table; only one join with domain is being done.
2) Do join with domain table only when command is executed by domainAdmin
3) Added index for "path" field in "domain" table
4) No longer do joins with account table as account_id is already present in vm_instance table.
- Added a new flag 'allocation_state' to zone,pod,cluster and host
- The possible values for this flag are 'Enabled' or 'Disabled'
- When a new zone,pod,cluster or host is added, allocation_state is 'Disabled' by default.
- For existing zone,pod,cluster or host, the state is 'Enabled'.
- All Add/Update/List commands for each of zone,pod,cluster or host can now take a new parameter 'allocationstate'
- If 'allocation_state' is 'Disabled', Allocators skip that zone or pod or cluster or pod.
- For a root admin, ListZones lists all zones including the 'Disabled' zones. But for any other user, the 'Disabled' zones are not included in the response.
- For any usecase that creates/deploys/adds/registers a resource and takes in zone as parameter, now we check if the Zone is 'Disabled'. If yes then the operation cannot be performed by a user other than root-admin. Add volume, snapshot, templates are examples of this usecase.
- To enable the root admin to test a particular pod/cluster/host, deployVM command takes in 'host_id' parameter that can be passed in only by root admin.
If this parameter is passed in by the admin, allocators do not search for hosts and use that host only. StoragePools are searched in the cluster of that host.
If VM cannot be deployed to that host, allocators and deployVM fails without retrying
Bug 7723 - merge or re-write host tagging into master / 2.2
Bug 7627 - Need more logging for Allocators
Bug 8317 - Add better resource allocation failure messages
Changes for Deployment Planner to use host and storagePool allocators to find deployment destination.
Also has the changes for host tag feature.
Improved the logging for allocators.
2) Set traffic Type to be Guest for Direct/Virtual non-system default network offerings. Use this guestIpType during the network creation/implementation
status 8412: resolved fixed
1) Don't count domR/Dhcp nic in active nics.
2) Removed domR cleanup thread; Network shutdown thread would shutdown domR/dhcp when network has no active vms
* to enable 1-1 nat for ip/vm use enalbeOneToOneNat api
* to open port range (or multiple port ranges) use createIpForwardingRule api.
* to delete one port range use deleteIpForwardingRule api.
* to disable 1-1 nat use disableOneToOneNat api.
* added new fields to createIpForwardingRule api: startPort/protocol - required, endPort is optional
* updated "firewall_rules" table with a new field "is_one_to_one_nat" (being set when new rule is created)
status 7803: resolved fixed
Fix overview:
1) Parameter "isDefault" should be defined as a part of createNetwork
* Virtual network is always default
* Parameter can be specified only for DirectNetwork
* Once parameter is set, there is no way to change it as we don't provide updateNetwork command.
2) Added isDefault parameter to listNetworks command so you can sort by that.
3) DeployVmCmd:
* at least one default network should be set
* if more than 1 default network is set - throw an error
4) Return isDefault information as a part of Nic object for the vm response in deploy/stop/start/listVm
refine ovs plugin, create a separate plugin instead of messing with vmops
refine gre tunnel, maintains tunnel in database instead of plugin
fix an arp issue cause by overlap vlan range
These include five new API cmds as well as changes to deployVirtualMachine to
specify an optional name of an SSH key to pass to the VM when starting. When
an SSH key is specified with a password-enabled template the newly created
password is encrypted with the SSH public key and can be retrieved via the
getVMPassword cmd. It is then the user's responsibility to decrypt retrieved
passwords with the correct SSH private key.
alena
Kelven Yang
prachi
Frank
anthony
Alex Huang
will
Chiradeep Vittal
Edison Su
kishan
abhishek
nit
Ragnar B. Johannsson
Greenqloud
keshav