On Tue, May 22, 2018 at 5:50 PM, Gianluca Cecchi <gianluca.cec...@gmail.com>

> On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>> On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stira...@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 simply had to manually restart ovn related services on the host to
reestablish correct TLS communication.
No other issue on host side.

> 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...

Yes, no errors from engine-setup; all the OVN related services got
reconfigured and their TLS cert got regenerated.

> Gianluca
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org

Reply via email to