Bug 1600170

description includes 'rhevm' as i tried to workaround it for my env :) so line '6' contains ovirtmgmt in reality.

Please provide DR steps for 4.2 SHE env which was installed in 3.5 version time and still uses 'rhevm' name for bridge.

Re-opening for DR scenario.

The value is not really hardcoded into the code but 'ovirtmgmt' it's just the default value for MGMT_NETWORK ansible variable and the user can easily override it with standard ansible means.

The missing gap is just an implicit sync between OVEHOSTED_NETWORK/bridgeName as used in past otopi based answer files and MGMT_NETWORK as used now.
Or maybe by better: have the playbook querying the engine for the name of the management bridge and use that instead of having it in a variable on playbook side.

(In reply to Simone Tiraboschi from comment #6)
> The value is not really hardcoded into the code but 'ovirtmgmt' it's just
> the default value for MGMT_NETWORK ansible variable and the user can easily
> override it with standard ansible means.
> 
> The missing gap is just an implicit sync between
> OVEHOSTED_NETWORK/bridgeName as used in past otopi based answer files and
> MGMT_NETWORK as used now.
> Or maybe by better: have the playbook querying the engine for the name of
> the management bridge and use that instead of having it in a variable on
> playbook side.

So in plain language, ansible variable is just default but you can't pass the name of your bridge as option of hosted-engine --deploy (ie. --otopi-environment="OVEHOSTED_NETWORK/bridgeName=str:'rhevm'") to overload the default?

> we are already asking to the user to run the vintage flow (with --noansible 
> option) where he can force a custom bridge name exactly as in the past.

...asking where? I was following RHV 4.2 docs and there was no info about this.

(In reply to Jiri Belka from comment #7)
> > The missing gap is just an implicit sync between
> > OVEHOSTED_NETWORK/bridgeName as used in past otopi based answer files and
> > MGMT_NETWORK as used now.
> > Or maybe by better: have the playbook querying the engine for the name of
> > the management bridge and use that instead of having it in a variable on
> > playbook side.
> 
> So in plain language, ansible variable is just default but you can't pass
> the name of your bridge as option of hosted-engine --deploy (ie.
> --otopi-environment="OVEHOSTED_NETWORK/bridgeName=str:'rhevm'") to overload
> the default?

Not directly from otopi answer file, but you can do it at ansible level.

See https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable ,
for variable precedences.

> > we are already asking to the user to run the vintage flow (with --noansible 
> > option) where he can force a custom bridge name exactly as in the past.
> 
> ...asking where? I was following RHV 4.2 docs and there was no info about
> this.

in https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/self-hosted_engine_guide/sect-restoring_she_bkup
7.2.1, point 2.

In order to complete the patch we need to have the ability to rename the management network via ansible module before adding the host.

Unfortunately such an ability on the ovirt-ansible modules yet, so I opened a relevant RFE on ansible : https://github.com/ansible/ansible/issues/43236

Re-targeting to 4.2.7 not being identified as blocker for 4.2.6.

Ansible module fix has been targeted to Ansible 2.8: https://github.com/ansible/ansible/pull/44951

So we can't get this fix in for 4.2.7.

Moved to 4.3.1 since ansible 2.8 won't be available before 4.3.0 GA

*** Bug 1667281 has been marked as a duplicate of this bug. ***

As Ansible 2.8 has been released already, shouldn't this BZ be ON_QA?

(In reply to Martin Tessun from comment #15)
> As Ansible 2.8 has been released already, shouldn't this BZ be ON_QA?

Didi already handled.

Verified on ovirt-hosted-engine-setup-2.4.2-2.el8ev.noarch using ansible-2.9.5-1.el8ae.noarch

Petr, can you please clarify what was the verification flow? I am not sure that merely verifying that we are using ansible >= 2.8 (or 2.9 [1][2], for that matter) is enough, as it seems like we are not actually using it - well, at least not doing what was discussed on [1].

[1] https://gerrit.ovirt.org/#/c/93277/
[2] https://docs.ansible.com/ansible/latest/modules/ovirt_network_info_module.html

I did exactly what was in reproduction steps and during setup it showed it's using whatever I provided as bridge name for mgmt network.

Answering to a private question about what was actually fixed and how, for this bug.

Seems to me like the fix, if at all, was done while copying the code from ovirt-hosted-engine-setup [1] to ovirt-ansible-hosted-engine-setup [2]. Compare [3] (from [1]) with [4] (from [2]). [3] did (it's a removal of below code):

- name: Network interfaces
  hosts: localhost
  connection: local
  vars:
    MGMT_NETWORK: ovirtmgmt
  tasks:
  - name: Detecting interface on existing management bridge
    set_fact:
      bridge_interface="{{ hostvars[inventory_hostname]['ansible_' + MGMT_NETWORK ]['interfaces']|first }}"
    when: "'ansible_' + MGMT_NETWORK in hostvars[inventory_hostname]"
  - debug: var=bridge_interface

Where [4] does:


- name: Network interfaces
  block:
  - name: Detecting interface on existing management bridge
    set_fact:
      bridge_interface="{{ hostvars[inventory_hostname]['ansible_' + item ]['interfaces']|first }}"
    when: "'ansible_' + item in hostvars[inventory_hostname]"
    with_items:
      - 'ovirtmgmt'
      - 'rhevm'
  - debug: var=bridge_interface

If I got it right, this means that the code supports only 'ovirtmgmt' and 'rhevm', still hard-coded, and the idea to use comment 9 and/or command 18 was never implemented. Even that is only for checking existing bridges, perhaps for attempting to re-deploy, or for pre-creation of the bridge (do we support that? not sure).

Also, it seems like the ansible code allows configuring the name using 'he_mgmt_network', but the CLI otopi wrapper does not allow passing it. And the cockpit UI has code to set 'bridgeName' which is passed to ansible as var 'he_bridge', but this var is never used in the ansible code.

Lastly, I see in the ansible code, in README.md:
    | he_bridge_if | eth0 | The network interface ovirt management bridge will be configured on |
    ...
    | he_bridge_if | null | interface used for the management bridge |
so perhaps this was left in the middle of deciding to rename variables or something like that.

Ido, can you please try to recall and clarify? Thanks.

[1] https://gerrit.ovirt.org/94362
[2] https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/commit/db5a0fcc619ab9f15fc2e6482968bd79c05035cd
[3] https://gerrit.ovirt.org/#/c/94362/20/src/ansible/get_network_interfaces.yml
[4] https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/commit/db5a0fcc619ab9f15fc2e6482968bd79c05035cd#diff-e86a8e72cafd097cd373a4ee1161c97e

(In reply to Petr Matyáš from comment #19)
> I did exactly what was in reproduction steps and during setup it showed it's
> using whatever I provided as bridge name for mgmt network.

Can you please attach relevant logs? Thanks.

Nope, machine was reinstalled right after that test as changing bridge name by me was a bit....destructive to network capabilities of that machine. (Definitely not a network expert)

If I recall correctly, Eddi from VDSM team said they aren't support a bridge name that is not 'ovirtmgmt'.
Additionally, in the VDSM repo 'ovirtmgmt' appear hardcoded as well in many places

This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020.

Since the problem described in this bug report should be
resolved in oVirt 4.4.0 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.