Changes:
- The event of deleteing an affinity group is published on the MessageBus so that IAM Service can listen and process the event, However the publish operation should not be handled within a DB transaction, since it may take longer and hold the DB transaction for long unnecessarily
- Publish any events to MessageBus outside of the transaction
Conflicts:
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
Changes:
- When there is HA we try to redeploy the affected vm using regular planners and if that fails we retry using the special planner for HA (which skips checking disable threshold)
Now because of job framework the InsufficientCapacittyException gets masked and the special planners are not called. Job framework needs to be fixed to rethrow the correct exception.
- Also the VM Work Job framework is not setting the DeploymentPlanner to the VmWorkJob. So the HA Planner being passed by HAMgr was not getting used.
- Now the job framework sets the planner passed in by any caller of the VM Start operation, to the job
Steps to reproduce if you have this issue:
- Create a VM's volume snapshot
- Remove VM's template and mark the template as removed with timestamp in DB
- Restart mgmt server and create a volume out of snapshot you should get NPE
Fix: In `storagePoolHasEnoughSpace`, we're only searching for a VM's volume's
snapshot's template by Id and not including removed templates. This is a corner
case and NPE hits when template has been marked removed for a VM's volume's
template so we should search including removed templates.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit f189c105d8dde5491697b171b969e757f8f15858)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
On default iptables rules are updated to add ACCEPT egress traffic.
If the network egress default policy is false, CS remove ACCEPT and adds the DROP rule which
is egress default rule when there are no other egress rules.
If the CS network egress default policy is true, CS won't configure any default rule for egress because
router already came up to accept egress traffic. If there are already egress rules for network then the
egress rules get applied on VR.
For isolated network with out firewall service, VR default allows egress traffic (guestnetwork --> public network)
The last commit 513adab51b53ba1acdea908225cfffab90ca1595 didn't fully fix it. Scenario #1 was not handled, only #2 was handled.
Fixed#1 as part of this commit.
1. If VM is in stopped state in CS due to 'PowerMissing' report from old host (hostId is null) and then there is a 'PowerOn' report from new host
2. If VM is in running state in CS and there is a 'PowerOn' report from new host
The previous fix tried to access StatsCollector from UsageManagerImpl
which is not possible due to dependency cycle.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 1e0880cbabfb2c8edbd6a5a35b9417b2f3e6f681)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Conflicts:
server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java
If an auth API call (such as login, logout) is called on unauthenticated port
such as the 8096 integration server port, we need to ignore such API calls
as calling auth APIs on 8096 is un-necessary and is undefined.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 21a6bef53b05d430f2cff53ae37033432603136d)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
If we create VM with shared service offering and attach disk with local disk offering,
and one of storage pool is full(cannot be allocated) and other is not full then
we are not putting the cluster in avoid list which is causing this infinite loop.
Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated)
