- introduces Capability in the network offering, which
decides when EIP service is enabled, by defualt public IP
should be assigned to the VM or not
- default network offering with EIP/ELB service will still work with old EIP
semantics, i.e) assign a public IP to each VM on start
the advanced zone
Details:
1). Added validation to check the Vlan Id specified in the createNetwork()
does not overlap with any of the vlan's used by isolated networks or
shared networks in the zone.
2). state change for shared network with services to go to 'Setup' state
on network shutdown instead of 'Allocated'
Bug ID:CLOUDSTACK-312 enable L4-L7 network services in the shared network in the advanced zone
network in the advanced zone
Details : ensure that CIDR specified for shared network does not overlap with any
CloudStack generated CIDR's for isaolated guest networks when using
external networking devices
Bug ID:CLOUDSTACK-312 enable L4-L7 network services in the shared network in the advanced zone
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
network in the advanced zone
Summary: change 'shared network' in advanced zone with L4-L7 services to go through network
implement phase. Add ACL checks to associate IP to shared network in the
advanced zone
Bug ID:CLOUDSTACK-312 enable L4-L7 network services in the shared network in the advanced zone
Conflicts:
server/src/com/cloud/network/NetworkManagerImpl.java
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
Detail: Because of the way most other primary storage types work with cloudstack
(i.e. backing stores) CLVM actually copies the template to a local logical
volume on primary storage, then uses that. This causes all of your primary
storage to be littered with a copy of every template used. Since we're not
using these, dump the template direct to the newly created logical volume.
This is faster as well since the template is sparse; we're not creating a fat
template on primary storage and then copying that to a logical volume when we
deploy from template.
BUG-ID: CLOUDSTACK-508
Bugfix-for: 4.1
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1353221260 -0700
* enable SG provider if the zone is SG enabled
* don't create public traffic type for the zone if there is no public network exist in the zone in 2.2.x
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>
within cloud.server.ConfigurationServerImpl.generateDefaultKeystore
Description:
The reason which failed in generation of the certificate is not displayed now.
At that time, IOException which does not include the reason is raised.
In order to solve the problem quickly, the reason should be included in the message.
(Now)
WARN [cloud.server.ConfigurationServerImpl] (main:) Would use fail-safe keystore to continue.
java.io.IOException: Fail to generate certificate!
at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490)
(Fix)
WARN [cloud.server.ConfigurationServerImpl] (main:) Would use fail-safe keystore to continue.
java.io.IOException: Fail to generate certificate!: sudo: sorry, you must have a tty to run sudo
at com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490)
Testing Completed:
mvn clean install
mvn -pl :cloud-client-ui jetty:run
And generation of the certificate was made to fail, checked it.
Signed-off-by: Chip Childers <chip.childers@gmail.com>
* send StartupAnswer right after StartupCommand is recieved
* if post processor going wrong, send out readycommand with error message to agent, then agent will exit
Any forked process that runs from maven surefire plugin gets it own separate
heap which may cause build issues. Patch fixes the issue by explicity args to
the surefire plugin for cloud-server.
Signed-off-by: Rohit Yadav <bhaisaab@apache.org>
* attache is not forForward()
* and the Disconnect came through cluster notification event
The fix will prevent delayed AgentDisconnect cluster notification processing.
Murali Reddy
Koushik Das
Alena Prokharchyk
Alex Huang
Hiroaki Kawai
Chip Childers
Rohit Yadav
adefanti
Marcus Sorensen
Vijay Venkatachalam
Deepak Garg
Pranav Saxena
Laszlo Hornyak
Satoshi Kobayashi
Dave Cahill
Edison Xu