Description of problem: [AutoDefine] - The external sync of the AutoSyncCommand attaching all external_networks to all clusters types. As requested in BZ 1530027 - the external_net that is created with auto-define should be attached only to OVS type clusters. The external sync of the provider, attaching the external_net to legacy clusters as well if auto sync enabled on provider and the cluster has external provider enabled. Version-Release number of selected component (if applicable): 4.2.4-0.1.el7 How reproducible: 100% Steps to Reproduce: 1. Have ovn provider with auto sync enabled 2. Create DC with 2 clusters, ovs and legacy 3. Enable ovn external provider on both clusters 4. Create net1 in DC Actual results: external_net is auto defined and created, on creation the external_net is attached only to ovs type cluster. But on the next sync cycly, it is attached to the legacy type cluster. Expected results: external_net is auto defined and created, remain attached only to ovs type clusters. Additional info: See also - BZ 1530027
Created attachment 1445194 [details] engine log
It is a bit problematic to solve the bug. We don't have an indication whether the network was auto-defined or not. Once auto-syncing, the network is added to all the clusters that have the provider defined. We don't have a way to differentiate between a regular network to a one that was auto-defined. Let's schedule a meeting to decide how to solve the issue. One possibility may be to change the requirements and define the auto-defined network in all the clusters and not just the ovs ones. Meanwhile, moving the bug to 4.2.5.
Another option is to change the auto sync provider process so that external networks with a physical network will be automatically attached only to ovs clusters.
(In reply to Alona Kaplan from comment #3) > Another option is to change the auto sync provider process so that external > networks with a physical network will be automatically attached only to ovs > clusters. That is actually what we have discussed with Dominik and I am trying to implement this.
FailedQa on - 4.2.5.2_SNAPSHOT-76.g2d45cde.0.scratch.master.el7ev
2d45cde is https://code.engineering.redhat.com/gerrit/#/c/143700/ which is upstream 20e078765 which is ovirt-engine-4.2.5.1 which is does not have the code yet. This is a bug in the nightly builds: 4.2.5.2_SNAPSHOT-76.g2d45cde.0.scratch.master.el7ev is based on a code that is older than that of ovirt-engine-4.2.5.1_SNAPSHOT-75.gde294d4.0.scratch.master (9199da9 restapi: Fix APIv3 deprecated/removed message)
comment 6 is incorrect. build: post ovirt-engine-4.2.5.1 is three commits after restapi: Fix APIv3 deprecated/removed as is evident on https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs/heads/ovirt-engine-4.2
Verified on - 4.2.5.2_SNAPSHOT-79.gffafd93.0.scratch.master.el7ev
This bugzilla is included in oVirt 4.2.5 release, published on July 30th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.5 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.