Reviewed by: Sateesh Chodapuneedi, Devdeep Singh
Description:
This is the first in a series of commits for integrating the
Cloudstack Management Server with the Nexus 1000v Virtual
Supervisor Module.
These changes introduce the necessary API command interfaces
to work with a Cisco N1KV VSM. The backend logic is still to
be put in and will be incorporated in subsequent commits.
Please do not attempt to use these APIs until then. Also,
these are not yet filled in into commands.xml, so they are
not currently exposed.
Additional APIs would be added if required.
These changes will not break any current management server
functionality.
Given below is a description of the changes put in here:
Added Cisco N1KV commands to core/api:
These are the added commands -
AddCiscoNexusVSMCmd
DeleteCiscoNexusVSMCmd
ConfigureCiscoNexusVSMCmd
ListCiscoNexusVSMCmd
ListCiscoNexusVSMNetworksCmd
Added a Network Element service file for Cisco N1KV.
Declared the interface functions that we'll need for
the N1KV VSM.
Defined a DeviceVO file for the Cisco Nexus Element.
Created a response file for Cisco Nexus VSM.
Created new event types for external Switching Management devices.
Put in logic to call interface methods in ListCiscoNexusVSMNetworksCmd
and ListCiscoNexusVSMCmd
NOT VSM RELATED:
Fixed minor typo in some of the event types for external load balancers.
Added properties of a VSM in the VSM VO class.
Replaced the "url" input parameter by "ipaddress"
in the AddCiscoNexusVSMCmd API.
Added a new file - CiscoNexusVSMElement.java to
contain the implementation of the functions
declared in the VSMElementService interface, and
put in implementations of the functions for the
Nexus VSM API commands. These functions are
defined in the CiscoNexusVSMElement class.
Added a class for Port Profiles (PortProfile.java).
The fields in this class are still not correctly
declared as of now. We'll make the required changes
going forward.
Added CiscoNexusVSMDeviceManagerImpl class.
Added CiscoNexusVSMResource class.
Created a new class to provide a package to
connect to Cisco Nexus VSMs. This will be a
set of Java wrapper functions that allow us
to connect/disconnect and send commands and
receive the results of those commands via
XML-RPC. These functions are yet to be
implemented, and will be checked in in future
commits.
Added two new classes, VSMCommand and
VSMResponse, to encapsulate XML-RPCcommands
and responses to and from a Ciscon Nexus VSM.
Put in the following function stubs inside the
CiscoNexusVSMService class:
connectToVSM()
disconnectFromVSM()
executeVSMCommand()
Added new field in the Type enum of the "Host"
interface, for Cisco Nexus VSMs.
Added two parameters to AddCiscoNexusVSMCommand
vsmName
zoneId
Modified the CiscoNexusVSMDeviceVO constructor to
take in an zoneId as a parameter when creating
the VO object.
Added new interface and class for the DeviceDao
implementation for Cisco Nexus VSM devices:
CiscoNexusVSMDeviceDao
CiscoNexusVSMDeviceDaoImpl
Removed the vsmvCenterDomainId property, since it's
going to the same as vsmDomainId, which is the VSM's
switch Domain Id.
Have started putting in the following query functions
in the CiscoNexusVSMDeviceDao interface:
Put in DAO implementations of some of the above functions in the CiscoNexusVSMDeviceDaoImpl class.
Added a vsmName parameter to the CiscoNexusVSMDeviceVO class.
Changes:
- Adding a new table 'hypervisor_capabilities' that will record capabilities for each hypervisor version. Added db schema changes for this.
- Currently a few capabilities have been added, namely, 'max_guests_limit' and 'security_group_enabled'
- Added a new column 'hypervisor_version' to host table. StartupRouting command now takes in this parameter. It should be set when a host connects.
- If a host's hypervisor version is not present, we find all the capabilities rows for that hypervisor type and use the first record.
- 'max_guests_limit' is the maximum number of running guest Vms that a host can have for the given hypervisor.
- Host Allocators use this limit and skip a host if the number of running VMs on that host exceeds this limit.
- 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
