Don't want to involve IP address management code in NetworkManager.
Conflicts:
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/network/NetworkManager.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
server/test/com/cloud/vpc/MockNetworkManagerImpl.java
Also ass public_ipv6_address for ipv6 address management.
Extend nics and vlans for ipv6 address.
Add dependency to com.googlecode.ipv6(java-ipv6).
Modify dhcpcommand for ipv6.
Conflicts:
api/src/com/cloud/agent/api/routing/DhcpEntryCommand.java
pom.xml
server/src/com/cloud/configuration/ConfigurationManagerImpl.java
server/src/com/cloud/configuration/DefaultComponentLibrary.java
server/src/com/cloud/dc/VlanVO.java
server/src/com/cloud/network/NetworkManager.java
server/src/com/cloud/network/NetworkManagerImpl.java
server/src/com/cloud/network/NetworkVO.java
server/test/com/cloud/network/MockNetworkManagerImpl.java
server/test/com/cloud/network/MockNetworkModelImpl.java
server/test/com/cloud/vpc/MockNetworkManagerImpl.java
NetworkServiceImpl does not need a cache of system network offerings
Ensure mocks build to new APIs.
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
to the api project, ensure that all methods use interfaces from the api project.
By moving it to the api project, it lessens the dependency of plugins on the server components.
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
NetworkManager's exclusive focus is now
- handling plugins during orchestration, and
- to deal with ip address allocation.
Those classes that used to refer to NetworkManager to get access to the datamodel now refer to NetworkModel
Signed-off-by: Chiradeep Vittal <chiradeep@apache.org>
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>
Sheng Yang
Chiradeep Vittal
Murali Reddy
Rohit Yadav
Alena Prokharchyk
Gavin Lee