On Thu, Jul 13, 2017 at 3:02 PM, Saravanan KR <skram...@redhat.com> wrote:
> On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openst...@nemebean.com> > wrote: > > > > > > On 07/11/2017 10:17 AM, Numan Siddique wrote: > >> > >> Hello Tripleo team, > >> > >> I have few questios regarding migration from neutron ML2OVS to OVN. > Below > >> are some of the requirements > >> > >> - We want to migrate an existing depoyment from Neutroon default > ML2OVS > >> to OVN > >> - We are targetting this for tripleo Queen's release. > >> - The plan is to first upgrade the tripleo deployment from Pike to > >> Queens with no changes to neutron. i.e with neutron ML2OVS. Once the > upgrade > >> is done, we want to migrate to OVN. > >> - The migration process will stop all the neutron agents, configure > >> neutron server to load OVN mechanism driver and start OVN services > (with no > >> or very limited datapath downtime). > >> - The migration would be handled by an ansible script. We have a PoC > >> ansible script which can be found here [1] > >> > >> And the questions are > >> - (A broad question) - What is the right way to migrate and switch the > >> neutron plugin ? Can the stack upgrade handle the migration as well ? > This is going to be a broader problem as it is also require to migrate > ML2OvS to ODL for NFV deployments, pretty much at the same timeline. > If i understand correctly, this migration involves stopping services > of ML2OVS (like neutron-ovs-agent) and starting the corresponding new > ML2 (OVN or ODL), along with few parameter additions and removals. > > >> - The migration procedure should be part of tripleo ? or can it be a > >> standalone ansible script ? (I presume it should be former). > Each service has upgrade steps which can be associated via ansible > steps. But this is not a service upgrade. It disables an existing > service and enables a new service. So I think, it would need an > explicit disabled service [1], stop the required service. And enabled > the new service. > > >> - If it should be part of the tripleo then what would be the command to > do > >> it ? A update stack command with appropriate environment files for OVN ? > >> - In case the migration can be done as a standalone script, how to > handle > >> later updates/upgrades since tripleo wouldn't be aware of the migration > ? > > > I would also discourage doing it standalone. > > Another area which needs to be looked is that, should it be associated > with containers upgrade? May be OVN and ODL can be migrated as > containers only instead of baremetal by default (just a thought, could > have implications to be worked/discussed out). > > Regards, > Saravanan KR > > [1] https://github.com/openstack/tripleo-heat-templates/tree/ > master/puppet/services/disabled > > > > > This last point seems like the crux of the discussion here. Sure, you > can > > do all kinds of things to your cloud using standalone bits, but if any of > > them affect things tripleo manages (which this would) then you're going > to > > break on the next stack update. > > > > If there are things about the migration that a stack-update can't handle, > > then the migration process would need to be twofold: 1) Run the > standalone > > bits to do the migration 2) Update the tripleo configuration to match the > > migrated config so stack-updates work. > > > > This is obviously a complex and error-prone process, so I'd strongly > > encourage doing it in a tripleo-native fashion instead if at all > possible. > > > Thanks Ben and Saravanan for your comments. I did some testing. I first deployed an overcloud with the command [1] and then I ran the command [2] which enables the OVN services. After the completion of [2], all the neutron agents were stopped and all the OVN services were up. The question is is this the right way to disable some services and enable some ? or "openstack overcloud update stack" is the right command ? [1] - openstack overcloud deploy \ --templates /usr/share/openstack-tripleo-heat-templates \ --libvirt-type qemu --control-flavor oooq_control --compute-flavor oooq_compute --ceph-storage-flavor oooq_ceph --block-storage-flavor oooq_blockstorage --swift-storage-flavor oooq_objectstorage --timeout 90 -e /home/stack/cloud-names.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e /home/stack/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml --validation-warnings-fatal --compute-scale 1 --control-scale 3 --ntp-server pool.ntp.org \ ${DEPLOY_ENV_YAML:+-e $DEPLOY_ENV_YAML} "$@" && status_code=0 || status_code=$? [2] - openstack overcloud deploy \ --templates /usr/share/openstack-tripleo-heat-templates \ --libvirt-type qemu --control-flavor oooq_control --compute-flavor oooq_compute --ceph-storage-flavor oooq_ceph --block-storage-flavor oooq_blockstorage --swift-storage-flavor oooq_objectstorage --timeout 90 -e /home/stack/cloud-names.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e /home/stack/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml *-e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ovn.yaml *-e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml --validation-warnings-fatal --compute-scale 1 --control-scale 3 --ntp-server pool.ntp.org \ ${DEPLOY_ENV_YAML:+-e $DEPLOY_ENV_YAML} "$@" && status_code=0 || status_code=$? Thanks Numan >> > >> > >> Request to provide your comments so that we can move in the right > >> direction. > >> > >> [1] - https://github.com/openstack/networking-ovn/tree/master/migration > >> > >> Thanks > >> Numan > >> > >> > >> > >> ____________________________________________________________ > ______________ > >> 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 >
__________________________________________________________________________ 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