Open Stack

On 07/18/2017 08:18 AM, Numan Siddique wrote:
> 
> 
> On Thu, Jul 13, 2017 at 3:02 PM, Saravanan KR <skramaja at redhat.com 
> <mailto:skramaja at redhat.com>> wrote:
> 
>     On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openstack at nemebean.com
>     <mailto: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
>     <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 ?

Re-running the deploy command as you did is the right way to change 
configuration.  The update stack command is just for updating packages.

> 
> 
> [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 <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-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 <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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>