leaving instances in eternal expunged state. This happens when a domain is
deleted while a deleted account is cleaning up. The cleanup looks for the domain
of the account and we hit a null pointer. Adding null pointer check.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1365695448 -0600
Currently, allPossibleIps return the Ip lists which include the gateway,
so we need to remove gateway ip from this list.
Now, for non-VPC network it works, because NetUtils.getAllIpsFromCidr
return the Ip lists which do not include the first IP of the network
(like 192.168.0.1).
We need too add the first IP into the returned Ip list, because it can
be used for VM if it is not the gateway IP (for example, VPC networks).
Signed-off-by: Chip Childers <chip.childers@gmail.com>
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>
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>
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
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.
1) Always fail to authenticate system user.
2) DB - always create system user with RANDOM not null password
3) Don't allow modifying (setting api/secretKeys, etc) system user via API
Conflicts:
server/src/com/cloud/user/AccountManagerImpl.java
setup/db/db/schema-305to306.sql
when host is reconnected, CS try to make sure the host can access primary storage,
CS only do this when primary storage is UP, and even host cannot access primary storage,
that is okay, do not throw exception, just print a warning message
Min Chen
Hugo Trippaers
Joe Brockmeier
Chip Childers
Chip Childers
Chiradeep Vittal
Marcus Sorensen
Wei Zhou
Kishan Kavala
Koushik Das
Mice Xia
David Nalley
Edison Su
Alena Prokharchyk
Rohit Yadav
Sheng Yang
Anthony Xu
Hiroaki Kawai
Marcus Sorensen
Murali Reddy