On 07/18/2017 08:18 AM, Numan Siddique wrote:
On Thu, Jul 13, 2017 at 3:02 PM, Saravanan KR <[email protected]
<mailto:[email protected]>> wrote:
On Tue, Jul 11, 2017 at 11:40 PM, Ben Nemec <[email protected]
<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?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:
[email protected]?subject:unsubscribe
<http://[email protected]?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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
