Open Stack

On Thu, Jul 13, 2017 at 3:02 PM, Saravanan KR <skramaja at redhat.com> wrote:

> On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openstack at 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-request at 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-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170718/1ab7b4f0/attachment.html>