Changes:
- When listing a zone, add clause in the search to check the account_id for a dedicated zone
- When listsing a zone with a domainid, add a similar clause.
- DomainCheck:: checkAccess() for a zone should consider that zone can now be dediacted to a specific account and check access accordingly.
Conflicts:
server/src/com/cloud/api/query/vo/DataCenterJoinVO.java
setup/db/db/schema-410to420.sql
Changes:
createZone API:
- This API takes in domainid, set it to the zone record in the data_center table
updateZone API:
- This API uses 'isPublic' flag to set a private zone to public - if this flag is set and the zone is dedicated, release the dedication and remove the domainid from the data_center table
listZone API:
- This API already has 'domainid' parameter. We should allow list zones by domain for Root admin.
DedicateZone API:
- set domainid in the data_center table
ReleaseDedicatedZone API:
- remove zoneid from the data_center table
Changes:
- Adding mocks in unit tests for new injected components
Conflicts:
server/test/org/apache/cloudstack/networkoffering/ChildTestConfiguration.java
Changes:
- Implict creation of the 'ExplicitDedication' Affinity group during resource dedication
- Only one group per account or per domain will be present
- ListDedicatedResources by affinityGroup
- Deployment should consider dedicated resources associated to the group only
- Deleting affinity group should release the dedicated resouces
- Releasing the dedicated resources should remove the group associated if there are no more resources.
Conflicts:
plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/DedicatedResourceManagerImpl.java
plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/manager/DedicatedApiUnitTest.java
server/src/com/cloud/configuration/ConfigurationManagerImpl.java
Changes:
- 'ExcplicitDedication' type of group can be created/deleted by Root admin only
- Users can no longer create this type of affinity group
- RootAdmin can create this type of affinitygroup at domain level. Such a domain level group is available for all accounts in that domain for listing and for use during deployVM.
- The domain level affinitygroup should be visible to the users in that domain, domain admins and Root admin.
Conflicts:
server/src/com/cloud/api/query/QueryManagerImpl.java
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java
There are three issues in resource_count table
(1) expunge a vm, the public_ip decreases and becomes -1 in basic zone.
(2) recover a vm, the volume increase.
(3) restore a vm, the volume decrease.
deployment fails with error "Message: Invalid configuration for device
'2'."
ensuring that direct network guru assigns a mac address for the nic that
it designs
Improving the error message saying ssh key pair should be assinged to VM to get the encrypted password.
Signed-off-by: Koushik Das <koushik@apache.org>
During host connect multiple listeners gets invoked, one of them is the download listener.
As part of processConnect() method, it checks if templates needs to be downloaded to secondary
store for a particular HV type. As part of that check it computes list of HVs present in the
zone. The earlier logic was to query all hosts (excluding current one) and iterate over them to
make the list. This is not optimal and is bound to have some latency as the number of hosts
increases.
Optimized the logic by querying the list of HVs from the db. directly instead of iterating over
all hosts in the zone.
Conflicts:
server/src/com/cloud/resource/ResourceManagerImpl.java
Initial patch for VXLAN support.
Fully functional, hopefully, for GuestNetwork - AdvancedZone.
Patch Note:
in cloudstack-server
- Add isolation method VXLAN
- Add VxlanGuestNetworkGuru as plugin for VXLAN isolation
- Modify NetworkServiceImpl to handle extended vNet range for VXLAN isolation
- Add VXLAN isolation option in zoneWizard UI
in cloudstack-agent (kvm)
- Add modifyvxlan.sh script that handle bridge/vxlan interface manipulation script
-- Usage is exactly same to modifyvlan.sh
- BridgeVifDriver will call modifyvxlan.sh instead of modifyvlan.sh when VXLAN is used for isolation
Database changes:
- No change in database structure.
- VXLAN isolation uses same tables that VLAN uses to store vNet allocation status.
Known Issue:
- Some resource still says 'VLAN' in log even if VXLAN is used
- in UI, "Network - GuestNetworks" dosen't display VNI
-- VLAN ID field displays "N/A"
The locking code in implement/shutdown network code was not efficient. Even in order to check the current state of the network lock was getting acquired which is not required. This resulted in delays in deploy VM as can be seen from attached logs where the code waited on the lock just to check if network is implemented.
As part of the fix moved out code that is checking if the network is already implemented or shutdowned outside the lock.
For some scenarios like prepare nic, all network service providers are checked which is not efficient and also introduces unnecessary dependencies.
The check to use only the required providers is already there for implement, shutdown operation on network. Put the same check for all missing cases.
If you shut down the agent while VMs are running, the management
server assumes that the VMs are continuing to run. You can then
delete the host while it is in 'disconnected' state, and those VMs
will be unusable, forever in running state. They can't change state
because the host no longer exists. This patch checks for any VMs
that may have been tied to the removed host and resets their state
so that cloudstack can continue to manage them.
