[
https://issues.apache.org/jira/browse/CLOUDSTACK-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13635218#comment-13635218
]
Marcus Sorensen commented on CLOUDSTACK-2086:
---------------------------------------------
do you know what the environment was? The scenario suggests an issue with the
hypervisor side. Does the bug require no router in the network in order to be
triggered (if you wait for the newly deployed network to get a router, does the
bug still show up)?
This scenario has been discussed a few times, and certainly the behavior being
seen is wrong, but I don't think we want to remove the configuration just
because it couldn't be applied to the live VM. There's "I want to add a nic to
a VM", which is satisfied since the VM's configuration is modified, and "I want
to add a VM to a network without rebooting" which is both changing the config
and applying it. Consider if the VM were powered off, and the apply failed when
they turned the VM on, not just for nic, but for anything that was changed
while the vm was off, should everything that failed to apply be destroyed? I'd
prefer to see something like "The nic was added, but failed to apply, please
reboot the VM for settings to take effect".
On second thought, after seeing the other bug, I wonder if this is just a
symptom of something else, as they both involve no router found in the shared
network.
I'm not going to assign it to myself yet since 4.2 isn't really on my radar at
the moment, but I've traced through the code a bit and I have an idea of what's
going on.
> UI shows added NIC even if Actual NIC addition has failed
> ----------------------------------------------------------
>
> Key: CLOUDSTACK-2086
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2086
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, UI
> Affects Versions: 4.2.0
> Environment: build: CloudStack-non-OSS-MASTER-219-rhel6.3.tar.gz
> Reporter: shweta agarwal
> Priority: Critical
> Fix For: 4.2.0
>
>
> Repro steps:
> Create a VM
> Create a shared network
> Call Add Nic Api
> Notice Entries in Db is created even though actual addition of NIC has
> failed as a result the newly added nic is shown in UI
> MS log shows
> 2013-04-18 13:03:57,821 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-51:job-41) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd
> java.lang.NullPointerException
> at
> com.cloud.network.element.VirtualRouterElement.getRouters(VirtualRouterElement.java:879)
> at
> com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:826)
> at
> com.cloud.network.NetworkManagerImpl.prepareElement(NetworkManagerImpl.java:1591)
> at
> com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:1702)
> at
> com.cloud.network.NetworkManagerImpl.createNicForVm(NetworkManagerImpl.java:3636)
> at
> com.cloud.vm.VirtualMachineManagerImpl.addVmToNetwork(VirtualMachineManagerImpl.java:2522)
> at
> com.cloud.vm.UserVmManagerImpl.addNicToVirtualMachine(UserVmManagerImpl.java:860)
> at
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd.execute(AddNicToVMCmd.java:109)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:164)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-04-18 13:03:57,823 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-51:job-41) Complete async job-41, jobStatus: 2, resultCode:
> 530, result: Error Code: 530 Error text: null
> 2013-04-18 13:04:01,436 DEBUG [cloud.network.NetworkManagerImpl]
> (Network-Scavenger-1:null) We found network 204 to be free for the first
> time. Adding it to the list: 1334281876
> 2013-04-18 13:04:08,819 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-142:null) Ping from 1
> 2013-04-18 13:04:09,058 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
> (secstorage-1:null) Zone 1 is ready to launch secondary storage VM
> 2013-04-18 13:04:09,373 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
> (consoleproxy-1:nu
> UI snap shot attached :
> DB showing :
> "id" "uuid" "instance_id" "mac_address" "ip4_address" "netmask"
> "gateway" "ip_type" "broadcast_uri" "network_id" "mode"
> "state" "strategy" "reserver_name" "reservation_id" "device_id"
> "update_time" "isolation_uri" "ip6_address" "default_nic" "vm_type"
> "created" "removed" "ip6_gateway" "ip6_cidr"
> "secondary_ip"
> "41" "f12806c9-8792-4fc2-bfc7-4362d2f3015a" NULL NULL "10.147.51.121"
> NULL NULL NULL NULL "212" NULL "Reserved" "PlaceHolder"
> NULL NULL "0" "2013-04-18 13:02:17" NULL NULL "0"
> "DomainRouter" "2013-04-18 17:02:17" NULL NULL NULL "0"
> Even though instance id is null still UI showing this NIC in UI.
> I think entry in DB should only be made once the addnic comand passes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
