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:
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 ?
> 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.
Makes sense to me. Can we generate a nice warning/error message in the UI instead of just using the event log? -Nir
(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
Verified in 3.5.0-0.0.master.20140804172041.git23b558e.el6
rhev 3.5.0 was released. closing.