Description of problem: ovirt-engine-rename does not take care about existing default OVN provider in 4.2. from mmirecki@: ~~~ A quick look at this: The following key/certs would need to be regenerated: OVN North: /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass /etc/pki/ovirt-engine/certs/ovn-ndb.cer OVN South: /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass /etc/pki/ovirt-engine/certs/ovn-sdb.cer HTTPS: /etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer Then OVN needs to be updated with the keys: ovn-nbctl set-ssl /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass /etc/pki/ovirt-engine/certs/ovn-ndb.cer /etc/pki/ovirt-engine/ca.pem ovn-sbctl set-ssl /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass /etc/pki/ovirt-engine/certs/ovn-sdb.cer /etc/pki/ovirt-engine/ca.pem systemctl restart ovn-northd The new ca cert must be imported into the truststore: keytool -import -alias ovirt-provider-ovn -keystore /var/lib/ovirt-engine/external_truststore -file /etc/pki/ovirt-engine/ca.pem -noprompt -storepass <truststore_password> default password for truststore is: ****** if not, please check: /etc/ovirt-engine/engine.conf/11-setup-sso.conf The OVN internal traffic is done using IPs (no hostnames allowed), so unless the ip changes, no changes should be required in this area. ~~~ Version-Release number of selected component (if applicable): 4.2 How reproducible: 100% Steps to Reproduce: 1. install engine, enable OVN during engine-setup 2. change IP/hostname of engine host 3. run ovirt-engine-rename Actual results: OVN does not work correctly, engine refuses to add new hosts because of bad ip/hostname for OVN provider and related stuff Expected results: either this should be well documented or ovirt-engine-rename should take care of it Additional info:
(In reply to Jiri Belka from comment #0) > Description of problem: > > ovirt-engine-rename does not take care about existing default OVN provider > in 4.2. > > from mmirecki@: > > ~~~ > A quick look at this: > > The following key/certs would need to be regenerated: > OVN North: > /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass I guess we can keep the keys, right? Assuming yes. > /etc/pki/ovirt-engine/certs/ovn-ndb.cer > > OVN South: > /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass Same > /etc/pki/ovirt-engine/certs/ovn-sdb.cer > > HTTPS: > /etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass Same > /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer > > Then OVN needs to be updated with the keys: > ovn-nbctl set-ssl /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass > /etc/pki/ovirt-engine/certs/ovn-ndb.cer /etc/pki/ovirt-engine/ca.pem > ovn-sbctl set-ssl /etc/pki/ovirt-engine/keys/ovn-sdb.key.nopass > /etc/pki/ovirt-engine/certs/ovn-sdb.cer /etc/pki/ovirt-engine/ca.pem > systemctl restart ovn-northd So is that needed? > > The new ca cert must be imported into the truststore: We do not change the ca cert in rename. That was a deliberate decision taken at the time of original implementation and is not likely to change. > > keytool -import -alias ovirt-provider-ovn -keystore > /var/lib/ovirt-engine/external_truststore -file /etc/pki/ovirt-engine/ca.pem > -noprompt -storepass <truststore_password> > > default password for truststore is: ****** > if not, please check: /etc/ovirt-engine/engine.conf/11-setup-sso.conf > > The OVN internal traffic is done using IPs (no hostnames allowed), so unless > the ip changes, no changes should be required in this area. What if it is? It's not exactly the scope of the rename tool, but these often go together. Usually we resolve names to addresses only during run time (not setup), so any IP address change normally requires at most a restart of the relevant services. > ~~~ > > Version-Release number of selected component (if applicable): > 4.2 > > How reproducible: > 100% > > Steps to Reproduce: > 1. install engine, enable OVN during engine-setup > 2. change IP/hostname of engine host > 3. run ovirt-engine-rename > > Actual results: > OVN does not work correctly, engine refuses to add new hosts because of bad > ip/hostname for OVN provider and related stuff Please provide steps to test this. I see that we have some ovn stuff in ovirt-system-tests, perhaps it's enough to run rename there. > > Expected results: > either this should be well documented or ovirt-engine-rename should take > care of it > > Additional info:
Also, do we really need to update the certificates? /etc/pki/ovirt-engine/certs/ovn-ndb.cer /etc/pki/ovirt-engine/certs/ovn-sdb.cer /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer I know that their subject is the old name, but does this matter? Note that among all the certs that engine-setup creates, we only update by rename the one for httpd. If nothing connects to the engine machine using the name, and nothing validates the name in the cert, no need to regenerate it. Check also [1]. It's pretty outdated, but the principle remains: We do, in ovirt-engine-rename, the _minimal_ changes needed to satisfy users connect with a browser to the new name and have the cert validated correctly. We do _not_ try to change the old name everywhere possible. If e.g. you have whatever reasons (say, legal) to completely get rid of the old name, then ovirt-engine-rename is not the tool for you. [1] https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostname/
We also need to update the ovn-controllers (on each host) with the new ip of the ovn db (engine). This can be done either from the hosts (each host): vdsm-tool ovn-config <ovn central ip> <tunneling ip or network name> /usr/libexec/ovirt-provider-ovn/setup_ovn_controller.sh <ovn central ip> <tunneling ip or network name> or centrally from the engine for each cluster: ansible-playbook --private-key=/etc/pki/ovirt-engine/keys/engine_id_rsa -i /usr/share/ovirt-engine-metrics/bin/ovirt-engine-hosts-ansible-inventory --extra-vars " cluster_name=<cluster name> ovn_central=<ovn central ip> ovn_tunneling_interface=<vdsm network name>" ovirt-provider-ovn-driver.yml (this is described in BZ 1565963, although we deal with the name of the tunneling network, not ip of central)
Moving to 4.3.0 not being identified as blocker for 4.2.7 and not being urgent
Changing subject to clarify that this is a bug on ovirt-engine-rename. IP addresses changes are not handled by this tool. They might be, as a side effect, if also the name changed. Please open another bug/RFE, if needed, for IP address changes. Perhaps only a doc bug.
Hi Didi, I took this bug after Jiri. If your needinfo is regarding to your comment 5, then I agree that ovirt-engine-rename should handle only hostnames.
Any update?
Sorry, not yet. I want to reproduce/verify this in OST, but that's progressing rather slowly. (And without reproducing/verifying, I can't be certain about what exactly needs to be done. Perhaps I should do this manually, but I'd also want an OST rename suite anyway...).
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Re-targeting to 4.3.6 not being identified as blocker for 4.3.5.
Sandro - move to 4.4?
Moved to 4.4
*** Bug 1721870 has been marked as a duplicate of this bug. ***
All pending patches merged, OST with patch to run rename passed.
*** Bug 1807242 has been marked as a duplicate of this bug. ***
Verified in ovirt-engine-4.4.1.8-0.7.el8ev Following OVN files are modified by ovirt-engine-rename to update the engine FQDN: /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf /etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer /etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass /etc/pki/ovirt-engine/keys/ovirt-provider-ovn.p12 As was said above, the certificate issuer line still contains the original engine FQDN, but it's rather a cosmetic thing. The CN is updated to the new FQDN. Also in webadmin, the 'ovirt-provider-ovn' provider URL is updated to the new FQDN.
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 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.
Looks good to me.