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-engine | Assignee: | Moti Asayag <masayag> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | GenadiC <gcheresh> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.4.0 | CC: | 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: |
|
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. |
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: