cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alena Prokharchyk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run
Date Mon, 04 Aug 2014 18:08:13 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084998#comment-14084998
] 

Alena Prokharchyk commented on CLOUDSTACK-7218:
-----------------------------------------------

Jayapal, reassigning the bug to you as you are the one who knows how things are supposed to
work for the secondary ip address. We either disallow more than one static nat per VM (disregarding
its secondary ip) so it works the same way as it used to work before your fix. Or you should
fix all the places where we expect vm to have just one static nat rule enabled:

* either by replacing all findByAssociatedVmId() Dao method with findByAssociatedVmIdAndVmIp
or 

* by changing the findByAssociatedVmId() to return the array of the ips rather than single
ip

Copy/pasting the email sent to the dev list.



Hi Jayapal,

I have a question to you regarding your commit aedb8c47 for secondary ip address in terms
of StaticNat feature. Before this checkin, we didn’t allow Static nat to be enabled on the
1 VM and multiple public Ips. After the checkin, you can create multiple static nat rules
per same vm/different public Ips, as long as each rule is assigned to a different secondary
ip address of the vm.

Here is the check that you do when see if the public ip is ready for static nat:

Method in RulesManagerImpl: protected void isIpReadyForStaticNat(long vmId, IPAddressVO ipAddress,
String vmIp, Account caller, long callerUserId)  

Before the fix:

IPAddressVO oldIP = _ipAddressDao.findByAssociatedVmId(vmId);

After the fix:

//check wether the vm ip is alreday associated with any public ip address
IPAddressVO oldIP = _ipAddressDao.findByAssociatedVmIdAndVmIp(vmId, vmIp);


Just wanted to confirm if that’s the expected behavior. If it is, we have a lot of regression
bugs in the ip addresses cleanup when static nat ip is referenced just by vmId. For instance
one of them is https://issues.apache.org/jira/browse/CLOUDSTACK-7218. During the vm expunge
when we cleanup vm’s resources, we expect only one static nat enabled public ip address
for vm:

    private boolean cleanupVmResources(long vmId) {

        // If vm is assigned to static nat, disable static nat for the ip
        // address and disassociate ip if elasticIP is enabled
        IPAddressVO ip = _ipAddressDao.findByAssociatedVmId(vmId);
        try {
             if (ip != null) {
                if (_rulesMgr.disableStaticNat(ip.getId(), _accountMgr.getAccount(Account.ACCOUNT_ID_SYSTEM),
User.UID_SYSTEM, true)) {
                    s_logger.debug("Disabled 1-1 nat for ip address " + ip + " as a part of
vm id=" + vmId + " expunge”);



And I suspect that the same kind of bugs will happen in all the places where you make a call
to _ipAddressDao.findByAssociatedVmId(vmId) returning only one entry, where there can be more
than one per vm/public ip.

Or if you say that we still shouldn’t allow more than one Static Nat enabled Public IP per
single VM, then the isIpReadyForStaticNat should be fixed by disallowing enabling static nat
on the vm that is already associated with the public ip address, disregarding the vmIp, and
considering the vmId only when make a search.


Can you please take a look and elaborate.

Thank you,
-Alena.

> [Automation] NPE observed while deleting account in automation run
> ------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7218
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.5.0
>         Environment: KVM (RHEL 6.3)
>            Reporter: Rayees Namathponnan
>            Assignee: Alena Prokharchyk
>            Priority: Critical
>             Fix For: 4.5.0
>
>
> This issue is observed in automation log, NPE thrown while deleting account
> 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] (API-Job-Executor-2:ctx-523291d6
job-5302 ctx-28b51397) There are no static nat
>  rules to apply for ip id=28
> 2014-07-31 02:20:56,105 WARN  [c.c.u.AccountManagerImpl] (API-Job-Executor-2:ctx-523291d6
job-5302 ctx-28b51397) Failed to cleanup accou
> nt Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS]
due to
> java.lang.NullPointerException
>         at com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391)
>         at com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321)
>         at com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104)
>         at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>         at com.sun.proxy.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown Source)
>         at com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540)
>         at com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936)
>         at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650)
>         at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2196)
>         at com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793)
>         at com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:667)
>         at com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1441)
>         at sun.reflect.GeneratedMethodAccessor542.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>         at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
>         at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
>         at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>         at com.sun.proxy.$Proxy102.deleteUserAccount(Unknown Source)
>         at org.apache.cloudstack.region.RegionManagerImpl.deleteUserAccount(RegionManagerImpl.java:187)
>         at org.apache.cloudstack.region.RegionServiceImpl.deleteUserAccount(RegionServiceImpl.java:121)
>         at org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd.execute(DeleteAccountCmd.java:104)
>         at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
>         at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
>         at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
>         at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>         at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>         at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>         at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>         at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>         at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message