unassignIPFromVpcNetwork processing should not execute when
EnableStaticNat succeed. Without this patch, unassignIPFromVpcNetwork
will execute whenever EnableStaticNat is successful or failed
Reviewed-by: https://reviews.apache.org/r/9443/
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
Detail: This is now controlled by a variable in /etc/default/libvirt-bin
BUG-ID: CLOUDSTACK-1150
Bugfix-for:
Reviewed-by: Wido den Hollander <wido@widodh.nl>
Reported-by: Logan McNaughton <logan@bacoosta.com>
Signed-off-by: Wido den Hollander <wido@widodh.nl> 1360178633 +0100
Conflicts:
docs/en-US/hypervisor-host-install-libvirt.xml
commands send to virtual router, instead of keeping silence.
Test:
Before change:
(1) Acquire IP. always in "Allocating" state.
(2) EnableStaticNat, the result is success(it is incorrect).
(3) DisableStaticNat, will get error message.. This is correct.
(4) Add Firewalls. always in "Adding" state.
(5) The AgentManager report statistics every 60 minutes(normally it
should be router.stats.interval=5 minutes).
After change:
(1) Acquire IP, will get error message.
(2) EnableStaticNat, will get error message.
(3) DisableStaticNat, will get error message.
(4) Add Firewalls, will get error message. But the firewall rules are
saved in database.
(5) The AgentManager report statistics every 5 minutes, except the
network with read-only FS virtual router.
The issue occur in two conditions
(1) If I use two sessions or browsers to EnableStaticNat on CloudStack
UI. one is successful, the other is failed. However, there is no ip in
database.
(2) If I use API call EnableStaticNat several times The first time
succeed, the second failed, the third succeed. the result is
success-fail-success-fail-success-fail, which it is not correct.
Reported-by: Wei Zhou <w.zhou@leaseweb.com>
Reviewed-by: https://reviews.apache.org/r/9254/
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
This was done for performance reasons.
I also refined the regex strings and added more test cases for different
string scenarios.
Signed-off-by: Chip Childers <chip.childers@gmail.com>
As noted in the bug, several of the API command in question
are async calls. I've added a simple regex-based string cleaning
function, and have the request and response strings running through
it prior to being appended to the audit log.
Unit tests added for the new cleaning function as well.
The call to skip logging the createSSHKeyPair response remains intact
for now, although it should probably be scrubbed similarly to the
password fields.
Signed-off-by: Chip Childers <chip.childers@gmail.com>
Conflicts:
utils/src/com/cloud/utils/StringUtils.java
Detail: There are several places in the code that do a
"brctl show | grep bridgeName" or similar, which causes all sorts
of problems when you have for example a cloudVirBr50 and a
cloudVirBr5000. This patch attempts to stop relying on the output
of brctl, instead favoring sysfs and /sys/devices/virtual/net.
It cuts a lot of bash out altogether by using java File. It was
tested in my devcloud-kvm against current 4.0, as well as by the
customer reporting initial bug.
BUG-ID: CLOUDSTACK-938
Fix-For: 4.0.1
Signed-off-by: Marcus Sorensen <marcus@betterservers.com>
Issue seen during system vm template upgrade and restoreVM command
scenarios for vmware. In these cases CS tries to recreate root disk with
same name as the existing one, in case of vmware this results in creation
of vmdk file with same name for both existing and new root volume.
This results in undesired behavior when storage cleanup thread tries to
cleanup old volume. Made the vmdk file name unique by adding the volume
id to it. This will ensure that during volume recreation in the scenarios
mentioned vmdk will get created with a new name and there will be
no undesired side effects of running the storage cleanup thread.
Joe Brockmeier
David Nalley
Brian Federle
Sebastien Goasguen
Jessica Wang
anthony
radhikap
Chip Childers
Min Chen
Wei Zhou
Chiradeep Vittal
Wido den Hollander
Logan McNaughton
Marcus Sorensen
Sheng Yang
Edison Su
Kishan Kavala
Koushik Das
Murali Reddy