Open Stack

On Wed, Jul 19, 2017 at 11:37 PM, Ben Nemec <openstack at 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 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/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-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:unsubscrib
>> e
>> 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/20170724/8b347649/attachment.html>