settingsLogin | Registersettings

[openstack-dev] [TripleO] Migration from Neutron ML2OVS to OVN

0 votes

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 ?
- The migration procedure should be part of tripleo ? or can it be a
standalone ansible script ? (I presume it should be former).
- 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 ?

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 18, 2017 in openstack-dev by nusiddiq_at_redhat.c (820 points)   1

5 Responses

0 votes

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 ?
- The migration procedure should be part of tripleo ? or can it be a
standalone ansible script ? (I presume it should be former).
- 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 ?

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.

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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 11, 2017 by Ben_Nemec (19,660 points)   2 3 3
0 votes

On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec openstack@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.

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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 13, 2017 by Saravanan_KR (1,420 points)   4
0 votes

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

On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec openstack@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 oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=0 ||
status_code=$?

[2] - openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
--libvirt-type qemu --control-flavor oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 18, 2017 by nusiddiq_at_redhat.c (820 points)   1
0 votes

On 07/18/2017 08:18 AM, Numan Siddique wrote:

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

On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openstack@nemebean.com
<mailto:openstack@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 oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=0 ||
status_code=$?

[2] - openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
--libvirt-type qemu --control-flavor oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 19, 2017 by Ben_Nemec (19,660 points)   2 3 3
0 votes

On Wed, Jul 19, 2017 at 11:37 PM, Ben Nemec openstack@nemebean.com wrote:

On 07/18/2017 08:18 AM, Numan Siddique wrote:

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

On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <openstack@nemebean.com
<mailto:openstack@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 oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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 \
${DEPLOY
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=0 ||
status_code=$?

[2] - openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
--libvirt-type qemu --control-flavor oooqcontrol --compute-flavor
oooq
compute --ceph-storage-flavor oooqceph --block-storage-flavor
oooq
blockstorage --swift-storage-flavor oooqobjectstorage --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 \
${DEPLOY
ENVYAML:+-e $DEPLOYENVYAML} "$@" && statuscode=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@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@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@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2017 by nusiddiq_at_redhat.c (820 points)   1
...