On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:

On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos@redhat.com> wrote:

Hi,

Adding also Marcin here.
I reproduced it as well and I can confirm that the external provider was called 'OVN' by default at 4.1 time but now engine-setup will create by default a new provider called 'ovirt-provider-ovn'.
Both the two providers are now configured in the engine to be reached at https://<enginevm_ip>:9696

The engine can successfully talk with ovirt-provider-ovn while I get errors like 'Error while listing external networks: EngineException: (Failed with error Connection reset and code 5050)' when I try to query the old OVN provider.

Logical networks previously attached to the old OVN provider are still there in the engine and they are still attached to the old OVN provider.

Unfortunately I'm not able to start/restart VMs with interfaces on a logical network defined on the OVN provider.

I manually recreated the missing networks on the new 'ovirt-provider-ovn' provider and I reattached my VMs there and at that point I was finally able to start again my VMs.

Another strange behavior.

I was't able to remove the old OVN provider since a few logical networks was still attached to that.

So I removed all of them from the engine and then I manually removed the old OVN provider and only at this point all of my old logical networks manually reappeared in the engine as attached to the new 4.2 'ovirt-provider-ovn'.

 

Thank you very much Simone for your tests!

This is a test environment, but with about 40 VMs of a certain importance and I would like to preserve it in 4.2

So with your tests you are confirming that the engine-setup for updating engine completes without problems and impacts on current databases and then the  update of the hosts doesn't go into exception, correct?

I can manage to have a temporary downtime for the few VMs defined on ovn (mainly used as intracluster network) and re-setup them on the new provider in 4.2

Just a curiosity: does this mean that when the engine-setup should configure the Northbound and Southbound DBs (and not... bridge... as I wrote before ;-) it simply skips without aborting?

This was one of my major concerns...

Gianluca