This reverts commit 97f2b9936a8b9e3a057116d327b058253458b4ef.
Use the following solution instead:
* add unique_name field to the network_offerings table. Use this filed as a unique offering identifier in the code
* Added db upgrade steps to 225to226 sql script
Conflicts:
server/src/com/cloud/offerings/NetworkOfferingVO.java
This reverts commit 97f2b9936a8b9e3a057116d327b058253458b4ef.
Use the following solution instead:
* add unique_name field to the network_offerings table. Use this filed as a unique offering identifier in the code
* Added db upgrade steps to 225to226 sql script
2) Added new config parameter 'allow.subdomain.network.access' - default value is true. If it's set to false, the child domain can't use the network of the parent domain
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
2) Added new config parameter 'allow.subdomain.network.access' - default value is true. If it's set to false, the child domain can't use the network of the parent domain
This patch enable redundant virtual routers.
1. To enable this feature, db need to be updated using follow SQL by now(we
would get a UI way later):
UPDATE network_offerings SET redundant_router=1 WHERE guest_type="Virtual" AND
system_only=0;
2. System would try to start up two routers at different hosts. But if there is
only one host in the zone, system would start up two routers on it.
3. The failover part is using keepalived, and connection tracking part is using
conntrackd. There would be one master router and one backup router. The status
of router(master or backup) can be query from the database table domain_router
now. Management server would update the status every 30s by default.
4. The routers for the same zone would use same external NIC(same ip and mac).
The script used for fail-over would ensure only one external NIC present in the
network at any time.
5. Currently management server don't got the ability to stop one of router is
both of them reported as master. The feature is in the todo list.
After two routers start up, disconnect anyone of them, the guest network
shouldn't be affected, and established connection(http, ssh, etc.) should still
works. The fail-over on gateway part should be 3~4 seconds.
Currently the patch works with KVM. Would deal with vmware and XenServer soon.
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.
status 9688: resolved fixed
To verify that the rule was removed:
* make sure that there is no record with lb id in load_balancer table
* verify that lb.delete event was generated for this rule
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
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.
2) Added networkIds parameter to deployVMCmd - accepts list of networks ids separated by coma.
3) Changed domainRouter/systemVm/userVm response to return list of Nics associated with the vm.
1. manual and recursive snapshot use the same command
2. upgrade from 2.2 beta1 to beta need to execute schema-22beta1to22beta2.sql and data-22beta1to22beta2.sql
3. upgrade from 2.1GA to 2.2GA need to execute schema-21to22.sql and data-21to22.sql
status 7144: resolved fixed
status 7192: resolved fixed
1) Zone has networktype parameter now, 2 values are supported: Basic and Advanced. "networktype" field is created in data_center table. The parameter is being set at creation time; we don't allow to modify it with updateZone command.
2) Only vlan of Untagged Direct type can be created in Basic network zone; any other vlan except for Untagged Direct can be created in Advanced zone
3) Allow NULL guest vlan range for the zone. Only vlan of Direct type can be created in zone with NULL guest vlan.
4) "Default" zone is Basic by default.
5) Changed "vnet" parameter to "vlan" in updateZone command to be consistent with createZone