Details:
- changed associateIPAddr API to accept shared network Id and account Id. Ip will be owned by tuple (account Id, network Id)
- chaged createNetwork API to accpet CIDR when network offering has external networking device providers
Bug ID:CLOUDSTACK-312 enable L4-L7 network services in the shared
network in the advanced zone
The code that would propage userdata to router, when updateVirtualMachine api
is called, was missing. As per the docs [0], userdata should be a base64 encoded
string upto 2KB which is put on domr's html directory adn using HTTP GET the
userdata information can be obtained from the domr.
The updateVirtualMachine api [0] would accept a base64 encoded string
and decoded and put into the domr's /var/www/html/userdata/<uservm ip>/user-data
file. The operation does not require the VM to be in stopped state, though it is
advised to stop and call this api in case the user vm has a script which gets
the userdata information from domr while starting.
For example, this script can be used to fetch the data:
server_ip=$(grep dhcp-server-identifier /var/lib/dhclient-eth0.leases | tail -1 | awk '{print $NF}' | tr '\;' ' ')
wget http://${server_ip}/latest/user-data
This feature can be useful, for example to use into puppet facts [1], or to do
automation and horizontal scaling etc. based on userdata.
[0] http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/domain_admin/updateVirtualMachine.html
[1] http://geek.jasonhancock.com/2011/11/09/cloudstack-userdata-into-puppet-facts/
BUG-ID : CLOUDSTACK-424
Reviewed-by: Rohit Yadav <bhaisaab@apache.org>
Reported-by: Nick Wales
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
If cleanup=true, network elements and resources are shutdown and
reimplemented. Else, shutdown/reimplementation is skipped. Enabled
cleanup checkbox in CS UI.
For both cases, VRs are only deployed for Pods with no running
or starting VRs and Pods having running or starting user vms.
New DAO helpers introduced:
HostPodDao: listByDataCenterIdVMTypeAndStates
DomainRouterDao: listByPodId and listByPodIdAndStates
VMInstanceDao: listByPodId and corrected definition of listByTypeAndState
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
If cleanup=true, removes all VRs and creates VR, implements network.
If cleanup=false, skips running VRs, implements network for stopped/deleted VRs.
Signed-off-by: Rohit Yadav <rohit.yadav@citrix.com>
Changes:
- Since Now a zone can have multiple physical networks, we need to find the physical network Id from the networkOffering's tag and zoneId and trafficType when we create a guest network
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/vm/UserVmManagerImpl.java
1) When account/domainId or projectId are passed in:
* list all account specific networks of the account/project
* list all domain level networks from the domainId + subdomains if the targeted network has allowSubdomainAccess = true
In other words, we use all the networks that can be used for vm deployment by account/domainId.
If listAll is not specified in the request, account/domainId are being defaulted to the account/domainId of the caller
listAll is ignored if the call is being done by the regular user.
2) listAll is passed in by the Root admin, we list:
* all Account specific networks in the system
* all domain specific networks in the system
3) listAll is passed by the Domain admin, we list:
* All Account specific networks belonging to domain/subdomains of the domain admin.
* All domain specific networks belonging to domain/subdomains of the domain admin
* All domain specific networks allowing subdomain access belonging to the parent domain.
4) domainId - can be passed either with or without listAll. We list:
* all account specific networks belonging to the domain
* all domain specific networks of the domain
* all domain specific networks of the subdomains if isRecursive = true is passed in
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
