On Wed, Jul 19, 2017 at 11:37 PM, Ben Nemec <openst...@nemebean.com> wrote:
> > > On 07/18/2017 08:18 AM, Numan Siddique wrote: > >> >> >> On Thu, Jul 13, 2017 at 3:02 PM, Saravanan KR <skram...@redhat.com >> <mailto:skram...@redhat.com>> wrote: >> >> On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openst...@nemebean.com >> <mailto: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/mas >> ter/puppet/services/disabled >> <https://github.com/openstack/tripleo-heat-templates/tree/ma >> ster/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 ? >> > > Re-running the deploy command as you did is the right way to change > configuration. The update stack command is just for updating packages. > > Thanks Ben for the confirmation. Numan > >> >> [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-h >> eat-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-h >> eat-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 <http://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-h >> eat-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-h >> eat-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 <http://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 >> <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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <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:unsubscrib >> e >> 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
