2) Added new parameter to listNetworks command - canUseForDeploy(boolean). When true, list only networks that can be used for vm deployment (networks have enough ip addresses to allocate from for the vm)
Conflicts:
api/src/com/cloud/api/ApiConstants.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/api/ApiResponseHelper.java
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/dao/IPAddressDao.java
When the last rule is removed for vpc ip, networkId is set to null
Conflicts:
api/src/com/cloud/api/commands/AssociateIPAddrCmd.java
api/src/com/cloud/api/commands/EnableStaticNatCmd.java
api/src/com/cloud/network/NetworkService.java
api/src/com/cloud/network/rules/RulesService.java
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
server/src/com/cloud/network/rules/RulesManagerImpl.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
2) Don't allow to add new networks/implement existing ones for VPC in Disabled state. Disabled state indicates that there was unsuccessful attempt to remove the VPC, and the further cleanup will be taken care of by cleanup thread.
Conflicts:
server/src/com/cloud/network/dao/IPAddressDao.java
server/src/com/cloud/server/ManagementServerImpl.java
2) Added services api support for plugging/unplugging the nics to VpcElement
Conflicts:
api/src/com/cloud/network/NetworkService.java
core/src/com/cloud/vm/VMInstanceVO.java
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
1) Added API frameworks for the feature. New commands:
* CreateVPCCmd
* ListVPCsCmd
* DeleteVPCCmd
* UpdateVPCCmd
* CreateVPCOfferingCmd
* UpdateVPCOfferingCmd
* DeleteVPCOfferingCmd
* ListVPCOfferingsCmd
2) New db tables:
* `cloud`.`vpc`
* `cloud`.`vpc_offerings`
* `cloud`.`vpc_offering_service_map`
and corresponding VO/Dao objects.
Added vpc_id field to `cloud.`networks` table - not null when network belongs to VPC
3) New Manager and Service interfaces- VpcManager/VpcService
4) Automatically create new VpcOffering (if doesn't exist) on system start
5) New Action events:
* VPC.CREATE
* VPC.UPDATE
* VPC.DELETE
* VPC.OFFERING.CREATE
* VPC.OFFERING.UPDATE
* VPC.OFFERING.DELETE
Conflicts:
api/src/com/cloud/api/ApiConstants.java
client/tomcatconf/commands.properties.in
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/network/NetworkManagerImpl.java
setup/db/create-schema.sql
Because there are more commands after GetDomRVersion command. Though
GetDomRVersion command itself is not that critical, the commands after it may
including DHCP and firewall related commands. The failure of GetDomRVersion
command would result in the following commands fail to be executed. So it should
fail, and fail loudly.
Description:
Incorporating more changes from Alena's review.
Modified the Nexus Enable and Disable commands
to return CiscoNexusVSMResponse instead of
SuccessResponse.
Put event annotations for enable/disable functions
that the enable/disable nexus commands cal into.
Description:
Removed the vcenter_dc_name and vcenter_ipaddr
fields from the virtual_supervisor_module
table, the CiscoNexusVSMDeviceVO, addClusterCmd,
and all other references to these two fields.
Fixing null pointer exceptions when checking
for nexus related global parameter values in
addClusterCmd.
Conflicts:
api/src/com/cloud/api/commands/AddClusterCmd.java
Description:
Incorporating more changes post review by Alena.
1. Renamed the ListCiscoVSMDetailsCmd command
to ListCiscoNexusVSMsCmd. The command will
return a list of VSMs always, depending on
what parameter is passed to it. If a clusterId
is passed to it, it will return the VSM
associated to that cluster, if present. If
a zoneId is passed in, it will return a list
of all VSMs configured for any clusters of
type VMware within that zone. If neither is
passed, it will return a list of all VSMs
configured in the management server. If no
VSMs are found, it will return an exception
response.
2. Cleaned up miscellaneous code.
Conflicts:
client/tomcatconf/cisconexusvsm_commands.properties.in
server/src/com/cloud/server/ManagementServerImpl.java
Description:
More changes incorporating Alena's review comments:
1. Changed id to clusterId for better naming.
2. Changed the name of GetCiscoVSMByClusterIdCmd
to ListCiscoVSMDetailsCmd.
3. Removed the GetCiscoVSMDetailsCmd command.
4. Removed catch{} blocks in each of the Nexus
related APIs since the exceptions raised in
the API implementations will be caught in the
command dispatcher.
5. Added ActionEvent annotation to
deleteCiscoNexusVSM() function.
6. Modified each Nexus API command's
getEntityOwnerId() to return
Account.ACCOUNT_ID_SYSTEM.
Description:
Putting in code changes as per Alena's reviews:
Replaced references to CiscoNexusVSMDeviceVO
in GetCiscoVSMByClusterIdCmd to work with an
interface that CiscoNexusVSMDeviceVO instead,
since VO objects should not be directly accessed
in APIs.
Made associated changes in other files.
More commits incorporating Alena's review comments
will follow.
Description:
Modified the following commands to be Async:
a. EnableCiscoNexusVSM
b. DisableCiscoNexusVSM
c. DeleteCiscoNexusVSM
Cleaned up miscellaneous code.
Description:
Didn't stage all modified files in previous
commit by mistake. Checking in the rest of
the changes in this commit. Please refer to
immediate previous commit for CS-9919 for
details on what changes went in with this
commit.
Conflicts:
client/tomcatconf/cisconexusvsm_commands.properties.in
Description:
Added a new API GetCiscoVSMDetailsCmd. This
API gets all details of a VSM when provided
with the VSM ID.
Resolved Conflicts:
client/tomcatconf/cisconexusvsm_commands.properties.in
Conflicts:
client/tomcatconf/cisconexusvsm_commands.properties.in
CS-14943: Unable to deploy VM due to Unable to identify the provider by name CiscoNexus1000vVSM
Description:
Ignore the CiscoNexus1000vVSM provider when checking for
providers when applying port forwarding rules.
Avoid detection of public traffic label for basic zones. Check switch types along with global parameter for enabling a particular vmware vswitch types. Move credentials information into resource and load during resource configuration. Cleanup.
Conflicts:
server/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java
Description:
Missed out a file in previous commit when adding
the new API getCiscoVSMByClusterId. Stub file was
added by Sateesh to prevent breakage. Putting the
file in in this commit plus better exception
handling.
Description:
Portprofile shaping policies will be fetched
from nexus vswitch instead of vcenter.
ACLs and Policies won't be synced to vCenter.
Get physical network label while adding cluster.
Cleanup.
Conflicts:
core/src/com/cloud/hypervisor/vmware/manager/VmwareManager.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
Description:
Code changes to manage Cisco Nexus 1000v in CloudStack.
VmwareResource has been modified to leverage Nexus vSwitch.
Providing following global configuration parameters,
vmware.use.nexus.vswitch -
This would decide whether Nexus vSwitch in the VMware
cluster environment would be used/managed by CloudStack
for it's network infrastructure needs.
vmware.guest.network.vswitch.type -
This setting would enable CloudStack to use Nexus vSwitch
in the VMware cluster environment for guest traffic.
vmware.private.network.vswitch.type -
This setting would enable CloudStack to use Nexus vSwitch
in the VMware cluster environment for private traffic.
vmware.public.network.vswitch.type -
This setting would enable CloudStack to use Nexus vSwitch
in the VMware cluster environment for private traffic.
Functional Specification -
http://wiki.cloudstack.org/display/RelOps/Cisco+Nexus+1000v+Support+in+CloudStack+-+Functional+Specification
Documentation / README for usage instructions -
http://wiki.cloudstack.org/display/RelOps/Configuration+instructions+for+CloudStack+Deployment+with+Nexus+vSwitch
Conflicts:
core/src/com/cloud/hypervisor/vmware/manager/VmwareManager.java
core/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
server/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java
vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java
vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java
vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareContext.java
Description:
1. Added the PortProfile infrastructure:
a. PortProfileVO : The VO class to represent a db
record of the table port_profile. Each db record
represents one port profile.
b. PortProfileDao: The interface that declares search
functions on the port_profile table.
c. PortProfileDaoImpl: The class that defines the
interfaces declared in PortProfileDao.
d. PortProfileManagerImpl: The class that contains
routines that will add or delete db records from
the port_profile table. If you want to create/delete
a portprofile, call functions from this class.
e. Changes to create-schema.sql to create the port_profile
table.
2. Cleaned up code:
a. Removed a number of unused Dao and Manager objects in
CiscoNexusVSMDeviceManagerImpl.
b. Removed the ListCiscoNexusVSMNetworksCmd command.
c. Removed a bunch of import statements in a few files.
Description:
1. Modify addCiscoNexusVSMCmd to enable a VSM
by default, when it is added to a cluster.
2. Put in two new APIs exposed to the user -
a. EnableCiscoNexusVSMCmd
b. DisableCiscoNexusVSMCmd
Disabling a VSM does not delete it. It only
prevents the Management Server from using that
VSM. This is useful if the VSM is in
maintenance mode.
Description:
1. Put in invocation to the deleteCiscoNexusVSM()
function in the deleteCiscoNexusVSM command
chain.
2. Put in additional check for physical servers
present in a cluster that still is tied to a
VSM. The previous check would query for all
hosts in a cluster, causing the check to see
if a cluster has any physical servers in it
to always fail and thus block the VSM from
getting deleted. By putting in a check to see
if a host if of type "Routing", we refine this
search to only hypervisors.
3. Other miscallaneous code + cleanup.
Description:
1. Changed AddCiscoNexusVSMCmd to:
a. Extend BaseCmd instead of BaseAsyncCmd.
b. Take in more required parameters (viz
vCenterDCName and vCenterIpAddress)
1a. Changed DeleteCiscoNexusVSMCmd to also
extend BaseCmd.
2. Put in changes that will ensure that
When a VSM is added, it is disabled by default.
3. Fixed code that was leading to exceptions
related to DB reads/writes to VSM related tables.
4. Added new API Constants in ApiConstants.java.
NOTE - Always initialize new attributes in
ApiConstants.java to values in small case.
Never put in upper case there. Also regardless
of what names you give attributes in the
*Cmd.java's class, you pass in parameters via
API calls by specifying <key>=<value> where the
<key> is taken from the value you specified in
ApiConstants.java.
5. Modified the addCiscoNexusVSM() function in
CiscoNexusVSMDeviceManagerImpl.java to write VSM
records to the db.
Description:
1. Missed replacing older table name for VSMs in a few
files (changed the name from
external_virtual_switch_management_devices to
virtual_supervisor_module). Fixed that in this commit.
2. Missed adding the new Dao ClusterVSMMapDao in the Dao
loading in DefaultComponentLibrary. Fixed.
3. Fixed wrong searchbuilder options passed to ipaddrSearch
in CiscoNexusVSMDeviceDaoImpl.
Description:
1. Added a new VO class to represent a new table
"cluster_vsm_map". The class is ClusterVSMMapVO
in ClusterVSMMapVO.java. This table has only
two fields - clusterId, VSMId. The clusterId can
occur only once. But the same VSMId can be tied
to different clusterIds.
2. Added the Dao interface + implementation of the
interface. This provides the functions required
to populate objects of type ClusterVSMMapVO with
records from the cluster_vsm_map table. The
interface is defined in ClusterVSMMapDao.java,
and the implementation is in ClusterVSMMapDaoImpl.java.
3. Changed the table name that represents the VSM to
"virtual_supervisor_module" from the earlier overly
generic "external_virtual_switch_management_devices".
4. Added search/remove functions to the Dao of the VSM.
This is the Dao for the Cisco Nexus VSM -
CiscoNexusVSMDeviceDao:CiscoNexusVSMDeviceDaoImpl
--> This is the Dao Implementation that would let
us query/update records on the
"virtual_supervisor_module" table that contains
the records of all the VSMs that are added to
the Management Server.
NOTE::
======
These were some of the changes made as part of the previous commit (#7):
1. Renamed CiscoNexusVSMResource.java to CiscoNexusVSM.java.
2. Changed it to not implement a true resource, but to be
just a class providing functionality to talk to a VSM.
3. Modified the AddCiscoNexusVSMCmd class to take in clusterId
instead of zoneId + your fix of the String to Long.
Description:
This is work in progress. This set of changes will not
compile. Checking in for team wide code sync up.
Changes are underway to test if VMWareResource can be
leveraged to talk to the VSM, instead of creating a
new resource for the VSM, like we've been doing up
until now.
At this point, the mgmt server comes up, loading the
Nexus related modules without dying.
Description:
1) Added a new properties file for Cisco N1kv VSM commands:
cisconexusvsm_commands.properties.in
2) Added the CiscoNexusVSMElement to the components.xml file.
3) Modified CiscoNexusVSMElement to implement NetworkElement.
The NetworkElement interface functions are not
relevant to the N1KV VSM, so we override them
with noops.
4) Added an addDao() of CiscoNexusVSMDeviceDaoImpl in populateDaos(),
else we'd run into a failure to look up the VSM's dao when the
mgmt server is starting up:
com.cloud.utils.exception.CloudRuntimeException: Unable to find DAO com.cloud.network.dao.CiscoNexusVSMDeviceDao
5) Also added the CiscoNexusVSMElementService in populateServices(),
and modified CiscoNexusVSMElement to implement Manager as well.
6) populateServices() was running into an exception that indicated
that it was unable to find a commands.properties file for the
cisco n1kv vsm service. Fixed it by changing getProperties() in
CiscoNexusVSMElement to return the correct string
"cisconexusvsm_commands.properties", and putting in an @Override
for getProperties() in CiscoNexusVSMElement. Also fixed up all
the other functions in CiscoNexusVSMElement that needed to have
@Override. Also updated build/developers.xml with this file
location. And did other small cleanup.
7) More clean up in CiscoNexusVSMDeviceManagerImpl.
Conflicts:
server/src/com/cloud/configuration/DefaultComponentLibrary.java
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.
With this fix both SSVM and CPVM will get public IP's in case of basic zone with EIP service.
A static NAT rule is implicitly configured on the EIP service provider to map public IP to a
guest IP address associated with SSVM/CPVM
This fix will enable support for multiple NetScaler devices providing EIP service in same zone.
- Introduced global setting "eip.use.multiple.netscalers" to turn multiple netscaler support
- Enhanced configureNetscalerLoadBalancer API to take the PBR setup between the POD's subnet
and NetScaler device
- logic to pick a NetScaler (based on the guest IP and corresponding pod) while configuring INAT rule
Fixed issues with vif scripts on 5.6FP1
Fixed ipv6 issue on 5.6FP1
Plus other various fixes and improvements
Starting to remove debug code
NOTE: Network is configured correctly but instances do not start. Possibly indefinite wait occuring on some commands
Description:
Fixing two other scenarios apart from the reported one
where we were not passing in database IDs for translation
into uuids, in the exception.
Only DHCP entry need to know if no one apply the entries(when VM is starting
up), other rules should be safe when return true anyway.
status 14470: resolved fixed
Reviewed-By: Sheng Yang
Changes:
Added 'removed' column to physical_network_service_providers to avoid the Foreign Key constraint error.
Conflicts:
setup/db/db/schema-30to301.sql
It's not a elegant fix. The status for firewall rules should remain unchanged
before/after ip association/disassociation. But the related change is tricky
than this fix, may not get enough test for 3.0.1. So we would apply existed
firewall rules again, which would work, just result in some unnecessary
commands.
status 14484: resolved fixed
Reviewed-by: Edison Su
Changes:
Fixed as described in the bug.
* CreateVlanIpRangeCmd still accept account/domainId info
* if account owns:
- one Isolated network with source nat service enabled, use this network
- more than one Isolated network with source nat service enabled - error out
- none Isolated networks with source nat service enabled, create it only in
case when there is an Isolated network offering with Availability=Required and
source nat service enabled.
The routing table with two nics may be messed up, due to we sent same
router(gateway) information from different DHCP server, in order to specify
default gateway. E.g.
Network A: 192.168.1.0/24, gw 192.168.1.1
Network B: 192.168.2.0/24, gw 192.168.2.1
User VM: Nic 1 connect to network A, get ip 192.168.1.10; nic 2 connect to
network B, get ip 192.168.2.10.
Set network A as the default network of user VM.
Currently we would send this information to user VM through DHCP offer:
In network A: dhcp-option:router 192.168.1.1
In network B: dhcp-option:router 192.168.1.1
So both NIC in the guest VM would receive 192.168.1.1 as router(gateway).
But, in CentOS 5.6, dhclient-scripts try to tell if the gateway is reachable
for current subnet.
So when we try to enable nic 2(eth1) of user VM, dhclient would receive:
IP: 192.168.2.10
Mask: 255.255.255.0
Router: 192.168.1.1
Then it would found that the specified gateway(router) is not within its own
subnet(192.168.2.0/24). But since we send out this ip(192.168.1.1) as the
gateway for it, dhclient thought that it should got someway to access the
network through this IP. So it would execute:
ip route add 192.168.1.1 dev eth1
ip route replace default via 192.168.1.1 dev eth1
But it can never reach 192.168.1.1(which is in the eth0's subnet and the
gateway of eth0) by go through eth1 interface. So it is messed up.
We've tested Windows 2008 R2, CentOS 5.3, CentOS 5.6 and Ubuntu 10.04. Windows
and Ubuntu are fine with above policy.
To solve this, we send different dhcp:router option according to the guest OS
type now.
We may need expand this list later, but for now we only know that CentOS and
RHEL would behavior in this way.
status 14042: resolved fixed
Description:
Adding overloaded addProxyObject() function to CloudException
and RuntimeCloudException classes and using this function
to stuff exceptions with IDs, to reduce code footprint.
Description:
Modifying the API functions' exception handling to call
addProxyObject() wherever applicable, and removing some
wrong calls to addProxyObject() that were put in in an
earlier commit for this bug.
With this commit, we cover many API functions to use the
new exception handling code, but some pieces may still be
left out. These will be covered as work in progress, when
making changes to the CS API code.
Description:
Removed some wrong invocations to addProxyObject() when
throwing exceptions in NetworkManagerImpl.java.
Replaced db ids with uuids in various points in the code
of NetworkManagerImpl.java, where exceptions are thrown.
Bug 13127: API error text refer to database ids instead of uuids
Code-Reviewers: Ewan Mellor, Kelven Yang
Description:
1. A new class CSExceptionErrorCode has been added to utils.
It contains a list of error codes for each type of
Exception class. Use fully qualified package paths for
Exceptions in CSExceptionErrorCode. We log any exception
name not found in the list of error codes for exceptions.
2. Whenever we throw an exception exobj anywhere in the
CS code, the CSErrorCode is set in the base class
constructor.
3. We add a new field csErrorCode in classes CloudException,
RuntimeCloudException, ExecutionException and
ExceptionResponse.
4. Two places in ApiServer.java were wrongly modified when
putting in changes for bug 13127 to not throw an exception.
This has been corrected in this commit.
Description:
Modify Exception handling to enable addition of multiple
uuids in a single exception thrown by API functions. Both
XML and JSON outputs will store all uuids and Fieldnames.
This will make it easier to provide more information when
an exception occurs - for example, a zone id, a cluster id,
host id, and then a specific property id.
Description:
Added a field name for the db id in the IdentityProxy class, and
modified setProxyObject() to take an additional id name parameter.
This will let us know the name of the uuid that we are returning.
E.g.- domainId, zoneId, etc. The client can view this field in
the json/xml output. Modified the JSON/XML serialization routines
to append this new parameter to the serialized output for Exception
Responses.
Description:
1) Added a setProxyObject() method to CloudException and RuntimeCloudException
2) Modified a bunch of throw exceptions in NetworkManagerImpl.java to call setProxyObject() before throwing an exception.
3) Changed scope of ProxyIdentity attribute to protected.
4) Added routines to ServerApiException to get/set IdentityProxy object, and
routine in RuntimeCloudException to get the Idproxy object.
5) Modified the exception handling around the dispatcher and handlerequest()
to copy over the IdentityProxy information before rethrowing an exception
eventually back to handle().
6) Removed duplicate IdentityProxy object in ServerApiException.
It was extending RuntimeCloudException which already had an
IdentityProxy object.
Description:
1) Moved RuntimeCloudException from api/ to utils/.
Added simple constructor to RuntimeCloudException.
Modified all classes that extended RuntimeException
to extend RuntimeCloudException. These classes
are listed below:
ServerApiException
CloudAuthenticationException
CloudExecutionException
AsyncCommandQueued
HypervisorVersionChangedException
RuntimeCloudException
2) Added overloaded constructed to CloudException.
Modified all classes that extend Exception to extend CloudException instead.
These classes are listed below:
ConcurrentOperationException
ConflictingNetworkSettingsException
ConnectionException
DiscoveryException
InsufficientCapacityException
ManagementServerException
ResourceUnavailableException
VirtualMachineMigrationException
AgentControlChannelException
OperationTimedoutException.java
UnsupportedVersionException.java
UsageServerException.java
UnableDeleteHostException.java
AgentAuthnException.java
HttpCallException.java
ActiveFencingException.java
ClusterInvalidSessionException.java
GreTunnelException.java
OvsVlanExhaustedException.java
Reviewed-by: Kishan
Changes:
- Separated out the External Network Usage task from the ExternalLBDeviceMgr because ExternalLbDeviceMgrImpl :: start() was getting multiple times during management server satrtup. The reason for this is that this is the baseclass for F5 and NetScalarElement.
- This caused us to schedule the ExternalNetworkUsageTask multiple times
- Also we have LBRulesMgr calling this ExternalLbDeviceMgrImpl by creating an instance of this class which is declared abstract
- Hence having a separate implementation to manage the network usage stats should solve this.
- configuring unique persistence profile for each LB rule with sticky method applied
- removing source based sticky method for source based LB method which is not supported by F5
And per Alex's request, add default value directly into the database, rather
than using it at last minute of implemention.
status 13829: resolved fixed
Reviewed-by: Alex
We expect user to use following sequence when update virtual router provided
network offering to external firewall devices offering:
1. Shutdown all the user VMs.
2. Modify network to new offering.
3. Click "Allow CIDR change" in the pop-up dialog, which would pass
changeCidr=true to the updateNetwork API.
We would shutdown guest network before we update the network for new
offering(with changeCidr = true), in order to re-implement the network.
status 13715: resolved fixed
Reviewed-by: Alex
Bug 13641 - OVM add host to OVM cluster results in host remaining in state: Alert
Bug 13652 - OVM add primary storage to OVM cluster FAIL
making Ovm work on Acton
status 13662: resolved fixed
status 13641: resolved fixed
status 13652: resolved fixed
reviewed-by: edison
The ExternalGuestNetworkGuru need to respect some of existed IP assignment,
especially router. Otherwise router can't get correct IP address(gateway IP).
status 13643: resolved fixed
Reviewed-by: Alex
Summary of changes:
- applyLoadBalancerConfig(long lbRuleId) method applies only one rule if it is Netscalar otherwise applies all the rules in add/revoke state.
CIDR may be different after update to a service offering contained external
network element, user is required to acknowledge this, otherwise the update
won't process
- converted all mandatory params to optional, and internally fill with default value before sending to haproxy. default value is available through description.
- accept holdtime without units.
Changes:
- We do not need these global setting anymore. These will be hidden since 3.0
- The default traffic label will be picked from the global setting which is null by default. When traffic label is null it means the resource uses tag on the default gateway
- Changes to invoke discoverer to reload the resource object on host connection
- Since a zone can have many physical networks, there can be multiple guest, public networks. Only the zone wide storage and management traffic label will be stored in host_details henceforth.
- If traffic labels are updated, discoverer should update the host_details
Summary of changes: Database changes will be rollbacked while applying the LB rule to the Netscaler device.
- Database changes will be rollbacked to previous state during the following Lb API's:
1) assignVM to LB rule
2) remove VM from LB rule
3) updateLb rule
4) deleteLb rule
5) create/attach sticky policy to Lb rule
6) delete sticky policy from Lb rule
- Database changes of the Lb rule will be not be rolledback during:
1) Removing IP
2) removing VM
Reviewed-by: Kishan
Changes:
- When an LB rule is deleted or the IP address having an LB rule configured is released, ExternalNetworkUsageCommand is fired to gather the usage
accumulated on that IP after the last run of the ExternalNetworkUsage job.
Summary of Changes:
- created a generic way for LB rule validations, so as LB device(like Haproxy) specific validations can be done syncronously.
- Removed asyncronous validations from Haproxy and done syncronously.
Summary of changes :
- Added a new flag -s to ipassoc command to carry if the ip address is
used for SNAT or not.
- SNAT is completly decoupled from the first flag. first flag is used
to decide if the ip address is first ip address of the interface.
- -s and -f are independent, SNAT can be enabled on the non-first ip
also.
Reviewed-By: Kishan
Changes:
- Added local cache to store the usage answer per LB device per zone
- Also there can be multiple domainRouters for an account. We can avoid processing the same account for usage by maintaining accounts already processed.
Changes:
- After deployment of Router failed, we did not throw out the error inorder to retry the start using another hypervisorType.
- But there is no other hypervisor to try, causing the failed and expunged router to be passed on further leading to an NPE later
- So in case there are no more hypervisors to retry the router start, we should throw out the original error.
When elb capability is enabled on the network offering, we:
1) on each createLB command:
* associate ip address to the LB rule owner
* create LB rule
2) on each deleteLb command:
* delete the rule
* disassociate ip address
The rule belongs to the owner, so proper usage events are generated
2) Added elasticIp and elasticLb network capabilities. Provided support to create network offering with these capabilities.
3) Added one more default network offering having elasticip and elasticlb
4) Public network support to Basic zone. You can associate/disassociate IP addresses now
I haven't figure out why the code can NPE, and in my test the clean up of basic
zone is prevent from API as expected. Anyway, I add this check before cleanup to
ensure even API check failed, no NPE would be throwed.
status 13041: resolved fixed.
The original method of testing source nat didn't consider the situation that
multiply source nat ip can be passed into the function because they belonged to
the different networks.
status 13100: resolved fixed
Admin can either configure system.vm.default.hypervisor which is a global configuration for all zones, or call updatezone add defaultSystemVMHypervisorType
status 12139: resolved fixed
Introduce the concept of Ip Deployer. The IP deployer would be responible for
apply IP to the element. Most element's IP deployer is itself, but it can be
someone else if we want to implement inline mode in the future.
Conserve mode means, we can use same IP for different purposes, in order to
"conserve" ip resources. But in this offering, all the service providers should
be the same, and the network created from this offering may be prohibited from
update to different network offering whose services are provided by different
service providers - because different service providers would need different IPs
for different services.
If user want to update the "conserve mode" network with the network offering
that has different service providers, each public IP should have only one usage,
only them the update is allowed.
- fixed bug in the destroying the VPX instance on SDX
- added method to acuire priavate IP from the zone, needed for the management IP of provisioned LB appliane
We can use the restartNetwork mechanism to recover the disconnected redundant
router.
Also disable HA for redundant router. Admin would take responsibilty to recover
the failure router, because redundant routers themselves are one layer HA.
status 12608: resolved fixed
bug 12318: NaaS: Dynamic CIDR for virtual router
This patch in fact use ExternalGuestNetworkGuru to replace GuestNetworkGuru. The
problem is the virtual router would normally use 10.1.1.0/8 as CIDR, but when we
want to upgrade to external firewall e.g. Netscaler, the CIDR would need to be
changed to different value e.g. 10.x.x.0/24 based on VLAN, because the external
firewall can not support one CIDR for multiply VLAN right now. So we have to use
the same policy for virtual router.
This patch also add one field "specified_cidr" to the networks table. If this
field is true, then it means user specify the CIDR of this network, thus we can
not granutee the CIDR after upgrade is valid, so we would like to prohibit the
upgrade of network offering.
This should also fix bug 12318. The reason for bug 12318 is the pre-set gateway
address of domR is overrided by ExternalGuestNetworkGuru. After this patch,
ExternalGuestNetworkGuru would respect the existed value in Nic, rather than
simply wiping it out. It would do calcuation to get the relevant address after
VLAN changed.
More clean up can be done in the future, when we proved that this policy change
doesn't break...
status 12234: resolved fixed
status 12318: resolved fixed
We do not set the default network labels as 'cloud-private' anymore. Instead it is set to the values set in global config variable. This should avoid the host connect failures requiring the network labels to be setup.
If virtual router provide DHCP but not DNS service, the DHCP response would
contained DNS server address rather than domr itself's address. Then user VM
would use specified DNS server directly.
-made Netscaler, SRX, F5 network elements as pluggable service
-added abstract load balancer device manager ExternaLoadBalancerDeviceManager
-made both F5 and Netscaler pluggable service to extend ExternaLoadBalancerDeviceManager
-added abstract firewall device manager ExternalFirewallDeviceManager
-made SRX pluugable service to extende ExternalFirewallDeviceManager
-added API's to configure and manage netscaler devices
- not use includingRemoved while listing networks
- Processing checkNetworkCommand dummy method to avoid failures connecting to Vmware and hyperv resource
* update network with new networkOfferingId only after the network is shutdown
* fixed NPE happenining when updateNetwork with the networkOffering w/o soucrceNat service in Advance zone
only owner of the network can access it; if it's domain - all accounts in the domain and domain children can have an access.
* aclType replaces 2 old fields: isShared and isDomainSpecific.
* All 2.2.x account specific networks will have aclType=Account; 2.2.x Domain specific networks - aclType=domain; 2.2.x Zone level networks - aclType=Domain with domainId = Root domain id
reviewed-by: Abhi
Summary of Changes:
while adding a primary address to the domR interface, previous primaray addresses(ip) are removed and added as with 32-bit netmask.
This is to avoid two same ip's with different netmask attached to the interface.
- Create Default physicalnetwork and add traffic types while creating a zone
- DeleteProvider should error out if there are networks using the provider.
- Other validations
- ListSupportedNetworkServiceProvidersCmd will now return Providers along with its element's services and boolean 'canEnableIndividualServices' that indicates if for this Provider services can be enabled/disabled
- add & update NetworkServiceProvider changed to take in the list of services to enable. While adding a provider, if list is null then all services supported by the element are enabled by default.
- ListNetworkServices enhanced to take in a provider name and returns services of that specific provider.
* can be specified for Shared network only
* if not specified for the Shared networks, try to locate it based on the zoneId and tags. If tags is not null, pick up first physicalNetwork from the zone that has matching tags. If tags is null, and there are none/more than 1 physical netwroks in the zone, error out.
As DhcpElement/VirtualRouterElement/RedundantVirtualRouterElement is decided to
be the service provider of the physical network, this API should be called to
add a new element, with correlated network service provider ID.
Then e.g. ConfigureVirtualRouterElementCmd should be called to configure and
enable the element.
Added PortForwardingServiceProvider, StaticNatServiceProvider, rename
PasswordServiceProvider to UserDataServiceProvider(may rename to a better name
later).
Add related function for service providers.
DHCP range, domain name, etc. are the property of network, not virtual router
specific.
The focus of virtual router configuration would on separate enable/disable each
service it provided.
2)Re-apply all existing firewall rules as a part of implement call. TODO: Cleanup all existing rules from the backend (leave them in the DB) as a part of shutdown call
TODO:
- Still leaving the provider columns in data_center schema as-is for CloudKit and BareMetal
- ExternalNetworkDeviceMgrImpl still needs to fix the dataCenter.setProviders calls and externalNetworkApplicance usage checks to see if zone has external networking.
Limitations:
* can't upgrade to the network offering with lesser number of services
* can upgrade only when the service provider of the original offering is not external (domR, dhcp, elb) to the external type of the provider
-Bringing add/delete/list of all external network devices under one unified API's (addNetworkDevice, deleteNetworkDevice, listNetworkDevice)
-Refactoring External network manager to work from both sets of API's add/delete/list NetworkDevice and add/delete/list External Firewall/LoadBalancer
- Make all API commands Async and add events
- Make BroadcatsDomainRange case insensitive
- Process all _networkElements to build the Service -> Provider map during NetworkMgr::configure()
It would cover the configuration of DHCPElement, VirtualRouterElement and
RedundantVirtualRouterElement.
Also add foreign key in domain_router table to reflect the domain_router is
created from which element and use what configuration.
Add configure command for these virtual router based elements. The commands
should be different for different elements.
The context of configuration would be added later.
- Create Zone changes and changes to data_center table to remove vlan, securityGroup fields
- Physical Network lifecycle APIs
- Physical Network Service Provider APIs
- DB schema changes
* moved all services to the separate table, map them to the network_offering+provider.
* added state/securityGroupEnabled properties for the networkOffering
* added ability to list by state/securityGroupEnabled in listNetworkOfferings api command
2) New service: SourceNat
Changes:
- Added a new interface 'PluggableService'
- Any component that can be packaged separately from cloudstack, can implement this interface and provide its own property file listing the API commands the component supports
- As an example have made VirtualNetworkApplianceService pluggable and a new configureRouter command is added
- ComponentLocator reads all the pluggable service from componentLibrary or from components.xml and instantiates the services.
- As an example, DefaultComponentLibrary adds the pluggable service 'VirtualNetworkApplianceService'
- Also components.xml.in has an entry to show how a pluggable service can be added, but it is commented out.
- APIServer now reads the commands for each pluggable service and when a command for such a service is called, APIServer sets the required instance of the pluggable service in the coomand.
- To do this a new annotation '@PlugService' is added that is processed by APIServer. This eliminates the dependency on the BaseCmd to instantiate the service instances.
Since we would introduce a way to specify each service provider in the network
offering, it's better for redundant virtual router as a separate service
provider.
Also isRedundant() flag in the network offering would be removed. Redundant
virtual router temporality won't work from now. Until we're able to add
different network elements/service providers in network_offering.
In the past, the NetworkElement would cover almost all the functionality that
e.g. virtual router can cover: firewall, source NAT, static NAT, password,
VPN... So anyone want to implement the NetworkElement would have to implement
these service's specific methods, even it wouldn't support it. Also, if we want
to find a e.g. FirewallServiceProvider, we have to proceed all the current
network service providers, to call a method to know if it support such service.
That's neither elegant nor scaling way to do it.
As the first step, this patch separates each ServiceProvider from NetworkElement
(there are some interface already out of NetworkElement, so this patch slightly
modifies them too), and only the class would implement the correlated interface, would
have the ability to do these services.
This reverts commit 42ab3c94c210d5a29289a5dfd0e44ae99c427f8b.
The commit may not fit for our new network as service framework, because we
would make single router and redundant router as two different service provider,
so the change of network offering should clean up the old network and then setup
new one. Make single router work as redundant router later make no sense in such
condition.
Then every router would have one guest ip. The gateway ip would be used if the
router is not redundant, otherwise the guest ip would be used for guest network.
move all listxxx interface from HostDao to managers(ResourceManager, SecondaryStorageVmManager etc) with decent name using SearchCriteria2
or direct call SearchCriteria2 on demand
1) Introduce new managers - ProjectManager and DomainManager. Moved all domain related code from AccountManager to DomainManager.
2) Moved some code from ManagementServerImpl to the correct managers.
3) New resource limit for Domain - Project
Added two New values "all" and "default" to global config "network.loadbalancer.haproxy.stats.visibility" . With this change, it can take six possible value:
global - stats visible from public network.
guest-network - stats visible only to guestnetwork.
link-local - stats visible only to link local network(for xen and kvm).
disabled - stats disabled.
all - stats available on public,guest and link-local. (Newly added)
default - stats availble on the serving http port, this does need any specific http port.(Newly added)
Except "default" and "disabled", all the rest of 4 need to configure the stats port.
Force stop the router would release all the resources it used, but router may
still running. Add a column "stop_pending" in the database, and stop it when the
router come back.
Admin would able to choose to force destroy such router, then recover the
network using restartNetwork command with cleanup=false.
status 11036: resolved fixed
1) Use row locks instead of global lock when update resource_count table. When update resource_count for account, make sure that we lock account+all related domains
2) Insert resource_count records for account/domain at the moment when account/domain is created.
3) As a part of DB upgrade, insert missing resource_count records for all non-removed accounts/domains
Conflicts:
core/src/com/cloud/alert/AlertManager.java
server/test/com/cloud/agent/MockAgentManagerImpl.java
clean up tests for security group manager v2
move interval to listener -- allows it to be configurable if needed
fix mocks
Enhanced logging for security group manager (from zucchini)
fix merge issues
merge issues
Changes :
- Fixing API doc +response name + errorMessage
- Adding seperate events to Egress rules
- Egress rules Using the same database table as that of ingress with new column type.
Pending Tasks:
- db upgrade
- database table rename from security_ingress_rule to generic name, renaming some of the jave class from ingress to generic name.
- Retesting on kvm
When we apply rules or start new VM, we may encounter some running routers that
we can't program. That can due to network issue or host is down or vCenter is
disconnected, etc. To keep the synchronization, we would stop them, but only
when there is the other router we've successfully updated. If both routers are
unable to communicate with, we simply give up and report it user.
Conflicts:
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
Description :
API's:
- Two new api's authorizeSecurityGroupEgress,revokeSecurityGroupEgressCmd are added. These two API's are similer to ingress rule API's.
- authorizeSecurityGroupEgress :Authorizes a particular egress rule for this security group . Usageof API is very similer to that of authorizeSecurityGroupIngress except that instead of source cidr there will be destination cidr. By default like ingress, all the outgoing flows are blocked.
- revokeSecurityGroupEgress : It is similer to revokeSecurityGroupIngress api, It removes the egress rule.
- listSecurityGroup API's response changed. It include's egress list apart from the existing ingress rules in the output of the API.
Hypervisors :
- It is implemented in Xen and KVM.
Pending Tasks : Blocking using destination security groups.
Previous commits: c9fda641673df7701f44963ef27e1d488f121219 , 24e4e44b8f0712a37147a3777833de3f9e24829e
- adding supprt for Netscaler VPX & MPX load blancers
- implemented for virtual networking
- works only with new fetched public IP, inline support is not added yet
- adding supprt for Netscaler VPX & MPX load blancers
- implemented for virtual networking
- works only with new fetched public IP, inline support is not added yet
more details will be added in the bug
Added New value "link-local" to global config network.loadbalancer.haproxy.stats.visibility . With this change it can take new parameter "link-local" value apart from the existing 3 values global,guest-network,disabled.
global - stats visible from public network
guest-network - stats visible only to guestnetwork.
link-local - stats visible only to link local network
disabled - stats disabled.
previous commit: c9fda641673df7701f44963ef27e1d488f121219 ( this under bug 1067, typing error)
changes: 1) partially implemented listing of egress rules along with ingress rules.
2) partially implemneted egress rules for KVM
Added global config to enable/disable rp_filter for domR.
previous commit: d966906374d4a0cb8fa57326a1f7625c871f64fd
Test Case-1 :
1) Set network.disable.rpfilter global config to true
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 0 , and rest other interfaces should have value of 1
Test Case-2 :
1) set network.disable.rpfilter global config to false
2) Restart the domR
3) check the settings reflected in proc filesystem
- for public interface like eth2,eth3 : /proc/sys/net/ipv4/conf/eth2/rp_filter should have 1 , and rest other interfaces should also have value of 1
It's very like caused by StartRouterCmd sent to the running router. I can
reproduce it by issue a StartRouterCmd to a running redundant router. And this
patch should the following exception:
Exception: com.cloud.exception.ResourceUnavailableException: Resource
[VirtualNetworkApplianceManagerImpl$$EnhancerByCGLIB$$565b4d45:0] is
unreachable: There are already two redundant routers with IP 10.91.32.126, they
are r-5-VM(5) and r-4-VM(4)
status 11214: resolved fixed
status 11029: resolved fixed
Commit also includes the following:
* map firewall rule to pf/lb/staticNat/vpn when the firewall rule is created as a part of pf/lb/staticNat/vpn rule creation
* when delete firewall rules, also delete related firewall rule
1) On enableStaticNat command we actually send the command to the backend (we used to just upgrade the DB in the past). The backend command carries sourceIp and destIp, and creates IP to IP mapping on the domR.
2) On disableStaticNat for the Ip address in addition to cleaning up port ranges, we also delete IP to IP mapping on the domR.
1) Added new apis: createFirewallRule, deleteFirewallRule, listFirewallRules
2) Modified existing apis - added boolean openFirewall parameter to createPortForwardingRule/createIpForwardingRule/createRemoteAccessVpn. If parameter is set to true, open firewall on the domR before creating an actual PF rule there
Modified backend calls appropriately.
3) Schema changes for firewall_rules table:
* startPort/endPort can be null now
* added icmp_type, icmp_code fields (can be not null only when protocol is icmp)
4) Added new manager - FirewallManagerImpl
Conflicts:
api/src/com/cloud/api/BaseCmd.java
client/tomcatconf/commands.properties.in
server/src/com/cloud/api/ApiResponseHelper.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java
server/src/com/cloud/network/rules/RulesManagerImpl.java
1) Added new apis: createFirewallRule, deleteFirewallRule, listFirewallRules
2) Modified existing apis - added boolean openFirewall parameter to createPortForwardingRule/createIpForwardingRule/createRemoteAccessVpn. If parameter is set to true, open firewall on the domR before creating an actual PF rule there
Modified backend calls appropriately.
3) Schema changes for firewall_rules table:
* startPort/endPort can be null now
* added icmp_type, icmp_code fields (can be not null only when protocol is icmp)
4) Added new manager - FirewallManagerImpl
status 10869: resolved fixed
Here is the flow (design is approved by Will Chan):
1) If user specifies custom ip address, and this ip is not the first ip in the range, the dhcp server gets the ip.
2) If user specifies custom ip address, and this ip is the first ip in the range, the dhcp server will get the random ip address from the range.
2) If user doesn't specify custom ip address, we always try to allocate first ip address from the range for the dhcp server; if this ip is already allocated, the dhcp server will get the random ip from the range.
This will work for:
* domR's Guest network
* dhcp's Direct network
status 10869: resolved fixed
Here is the flow (design is approved by Will Chan):
1) If user specifies custom ip address, and this ip is not the first ip in the range, the dhcp server gets the ip.
2) If user specifies custom ip address, and this ip is the first ip in the range, the dhcp server will get the random ip address from the range.
2) If user doesn't specify custom ip address, we always try to allocate first ip address from the range for the dhcp server; if this ip is already allocated, the dhcp server will get the random ip from the range.
This will work for:
* domR's Guest network
* dhcp's Direct network
1. cleanup was scheduled wrong (seconds vs ms)
2. when finding a work item to do, lock one random row to reduce contentions by thundering herds of workers
3. cleanup thread also finds scheduled work items and gets threads to work on them. this way other mgmt servers can take jobs
4. add lots of trace logs
5. commit transactions when returning early
Also:
1. Discard VPN related change.
2. Add network.dns.basiczone.updates in Config.java
3. Add findByNetworkOutsideThePod() for DomainRouterVO
Tested with VLAN and basic mode, works.
Disable redundant virtual router temporaily, would enable it after more testing.
Part 2
commit 797839360c65cd348d2eb20630521177ab0919de
bug 9154: redundant virtual router
commit 8ff7f230204d4d3a7a4adee75523a9a84f4276fe
bug 9154: Replace domain_router.is_master with domain_router.redundant_state in DB
commit 230b99e9e0b152648f1dd2a5eab6f22315b8e7b4
bug 9154: Add redundant state to DomainRouterResponse
commit ccefb5ff5e83d713798a347c99bce1a0d04b4317
bug 9154: Add router fault state report
commit 7a3090378f9785caecf741b70554f6ea17c41764
bug 9154: Send alert if found two virtual routers in master state
commit 66831056e4bf27665871bccd24e6159071564847
bug 9154: Code clean up
commit bf3f58a85741fa7118bd848a42d8b21baa4478d4
bug 9154: Add isRedundantRouter to DomainRouterResponse
Part 1
This backport contained:
commit 52317c718c25111c2535657139b541db0c9d1e1f
bug 9154: Initial check in for enabling redundant virtual router
commit 54199112055d754371bfb141168fb5538bf6d6ea
Add host verification for CheckRouterCommand
commit cef978a228c90056ead9be10cbc4de74c2b8de76
Fix CheckRouterAnswer's isMaster report
commit 4072f0a6991ac3b63601a1764fbe14188965f62f
Some build fixes and code refactoring for redundant router
commit 4d3350b7cd8ee2706a9bace4437fc194e36c8dd5
Redundant Router: Fix OVS
commit 6a228830e7c46d819fa0c3317e159e041337e887
Fix findByNetwork()/findByNetworkAndPod()'s return
commit c627777b3d5bdbcd60db4032cebd349a5b1ecd83
Redundant Router: Fix isVmAlive()
commit e1275d2514adc41f8744f5107d4069c38be195f1
Only issue CheckRouterCommand to redundant routers
And all modification to the scripts till
commit 4e3942462ed3fde3a3d7011e95839e2128fba514
logging changes
in the master branch.
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
It's due to nobody tell getNetworkRate() it's the router who want to get network
throttling rate, then the function failed to follow the policy.
status 9516: resolved fixed
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
Conflicts:
server/src/com/cloud/vm/dao/DomainRouterDao.java
server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
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.
Also fixed a couple of other problems:
* verify security group ids before vm creation
* don't create "default" security group (if missing) as a part of deployVm process when vm is deployed from vmWare template
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.
status 9693: resolved fixed
2 more fixes with this commit:
* bug 9692 is fixed - we don't increment resource count when Direct ip address is allocated.
* as a part of 2.2.2->2.2.4 upgrade resource_count for public_ip records is recalculated - count only Virtual Ip addresses
Conflicts:
server/src/com/cloud/network/NetworkManager.java
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
There's an API call "getCloudIdentifier". it returns some UUID that uniquely identifies a cloud.
This bug is to set the value of the instace metadata field cloud-identifier to "CloudStack-{result of getCloudIdentifier}. This metadata is programmed into
the virtual router by the management server.
Alena Prokharchyk
Murali reddy
Sheng Yang
anthony
Kelven Yang
Sateesh Chodapuneedi
Vijayendra Bhamidipati
Edison Su
Naredula Janardhana Reddy
Salvatore Orlando
root
unknown
David Nalley
frank
prachi
kishan
Sheng Yang
Edison Su
Alex Huang
Murali Reddy
Prasanna Santhanam
Murali Reddy
alena
Nitin
Chiradeep Vittal
Nitin
Edison Su
Abhinandan Prateek
frank
keshav
Alex Huang
Edison Su
Jessica Wang