Bug 1102542

Summary: [Neutron integration] It's impossible to remove a VNIC with Neutron network on it when the Neutron service is down
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: ovirt-engineAssignee: Moti Asayag <masayag>
Status: CLOSED CURRENTRELEASE QA Contact: GenadiC <gcheresh>
Severity: high Docs Contact:
Priority: medium    
Version: 3.4.0CC: danken, gklein, iheim, lpeer, lvernia, masayag, myakove, nyechiel, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: ovirt-3.5.0_rc1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 17:11:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1063716, 1142923, 1156165    
Attachments:
Description Flags
engine log none

Description GenadiC 2014-05-29 07:39:10 UTC
Created attachment 900259 [details]
engine log

Description of problem:
Error message VdcBLLException: (Failed with error PROVIDER_FAILURE and code 5050) is received when trying to remove NIC with External provider network from VM


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Import network from Neutron Server
2. Attach that network to running VM
3. Disconnect Neutron Server
4. Try to remove the NIC from VM

Actual results:
NIc with External provider network is not removed

Expected results:
It should be possible to remove a VNIC with Neutron network from VM

Additional info:

Comment 1 Moti Asayag 2014-07-13 19:03:54 UTC
The bug deals with a specific case of failure to remove vm which its vnics are provisioned from external provider.

There are other use cases which suffer from the same symptom:
1. Remove VM
2. Restore Snapshot
3. Remove Data-Center
4. Import VM

Hence, it makes sense that for any attempt to remove a port from the external provider, in case of a failure to remove the nic, the action won't be failed.
Instead, an event log will notify the admin what is the port-id and the external provider from which it should remove the port manually.

Nir, Livnat, does that behavior seems ok for the various flows ?

Comment 2 lpeer 2014-07-14 05:58:52 UTC
> Nir, Livnat, does that behavior seems ok for the various flows ?

Yes, I think this is a good start.
Going forward we should think on a batch which can do async cleanup for resources.

Comment 3 Nir Yechiel 2014-07-16 14:50:23 UTC
Makes sense to me. Can we generate a nice warning/error message in the UI instead of just using the event log?

-Nir

Comment 4 Moti Asayag 2014-07-17 06:31:16 UTC
(In reply to Nir Yechiel from comment #3)
> Makes sense to me. Can we generate a nice warning/error message in the UI
> instead of just using the event log?
> 

No, the neutron server is being accessed only during the command execution which is a bit late in the sequence.

In addition, for mass operations (i.e. remove a data-center with several vms and multiple nics) we'd might need to provide a feedback for more than one provider or for multiple networks, and the reason for the failed action might vary from provider not reachable to network doesn't exist on the provider (if action was executed out of band).

In addition, we'd like to save that information so admin could refer to it later (i.e. if the action was executed via the rest-api), or from other session.

Therefore the event log is the right mechanism to use. With the cool feature of events discarding (or is it only for alerts?), the user could refer to the events as check list and remove any event from the engine once the leftovers were cleared from the neutron server.

> -Nir

Comment 5 GenadiC 2014-08-07 12:02:10 UTC
Verified in 3.5.0-0.0.master.20140804172041.git23b558e.el6

Comment 6 Eyal Edri 2015-02-17 17:11:55 UTC
rhev 3.5.0 was released. closing.