If operator haven't explicitly defined live_migration_tunnelled param in nova.conf, after upgrade is done it's default value will be set to False. If operator set this param explicitly, everything will be unchanged. To notify about this change I'm proposing to use release notes, as It's usually done. So there will be no upgrades impact related to this change.
On Tue, Aug 2, 2016 at 10:51 PM, Chris Friesen <chris.frie...@windriver.com> wrote: > On 08/02/2016 09:14 AM, Timofei Durakov wrote: > >> Hi, >> >> Taking into account everything above I'd prefer to see >> live_migration_tunnelled(that corresponds to VIR_MIGRATE_TUNNELLED) >> defaulted to >> False. We just need to make a release note for this change, and on the >> host >> startup do LOG.warning to notify the operator that there are no tunnels >> for >> live-migration. For me, it will be enough. Then just put [1] on top of it. >> > > How would upgrades work? Presumably you'd have to get all the existing > compute nodes able to handle un-tunnelled live migrations, then you'd > live-migrate from the old compute nodes to the new ones using tunnelled > migrations (where live migration is possible), but after that everything > would be un-tunnelled? > > Chris > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
