Open Stack

On Fri, Feb 10, 2017 at 6:35 AM, Y.Rahulan <rahulan.y at gmail.com> wrote:
> Dear All,
>
>
>
> My Name is Yogaratnam Rahulan.  I am a member of the OpenStack community. I
> work for University of Surrey 5G Innovation Centre. At the university I work
> with many industrial mobile partners to integrate OTS software from
> Vodafone, EE, Telefonica, Huawei, Samsung, Fujitsu and other Eu universities
> etc. involved in the 5G telecoms world) onto open source infrastructure.
>
>
>
> We are evaluating the ease of using Open Source components for 5G.  I run
> the NFV-SDN team at the university.
>
>
>
> I am mailing to you today as I have a request to make regarding OpenStack
> and ODL integration.
>
>
>
> We are using OpenStack and OpenDaylight for our NFV-SDN operation running
> with CentOS operating system and are demonstrating state of the art
> communications core networks on our virtualised testbed in order to progress
> standardised mobile communications for the next generation beyond 4G LTE.
>
>
>
> We want to promote open source platform use, particularly OpenStack and we
> had been running with OpenStack and OpenDaylight and had demonstrated many
> major steps toward 5G core network infrastructure up until mid of December
> 2016, without issue.
>
>
>
> However, we wanted to upgrade to Newton in 2017.    So we started to
> re-install our system.  Now we have a problem with the integration of
> OpenStack and OpenDaylight. We are using ODL(Beryllium) but not be able to
> succeed with the ODL as layer 3 forwarding integration.

Is using Beryllium a requirement?

I recently did a bunch of work with OpenDaylight Boron with the
netvirt plugin. With netvirt most OpenDaylight neutron functionality
is at par. I don't mean to push you towards that release, I just
mention it because I recently did some work with it and it went fairly
smoothly. The docs are fairly good [1], and as long as you install the
right networking-odl version for your OpenStack neutron release I
would imagine it would go well.

Otherwise, I would suggest that the OpenDaylight community is your
best bet for getting some help. They certainly helped me. :) Note that
there are separate mailing lists for various components.

Thanks,
Curtis.

[1]: http://docs.opendaylight.org/en/stable-boron/submodules/netvirt/docs/openstack-guide/openstack-with-netvirt.html#installing-opendaylight-on-an-existing-openstack

>
>
>
> Can you please direct me to the right person(s) in the community to contact
> regarding this issues as we really need more help to resolve and progress in
> this respect and continue to promote open source virtualisation into the
> telecoms industry using Open Stack.  … willing to get involved and work with
> you folks, but urgently need to progress.
>
>
> Kind Regards
>
> Rahulan
>
>
> On Fri, Feb 10, 2017 at 12:00 PM,
> <openstack-operators-request at lists.openstack.org> wrote:
>>
>> Send OpenStack-operators mailing list submissions to
>>         openstack-operators at lists.openstack.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> or, via email, send a message with subject or body 'help' to
>>         openstack-operators-request at lists.openstack.org
>>
>> You can reach the person managing the list at
>>         openstack-operators-owner at lists.openstack.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of OpenStack-operators digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Sharing fernet tokens (Matt Fischer)
>>    2. [nova] FYI: live_migration_progress_timeout will default to 0
>>       and be deprecated in Ocata (Matt Riedemann)
>>    3. Re: [LCOO] Intro to Large Contributing (Jeremy Stanley)
>>    4. Re: [LCOO] Intro to Large Contributing (Hayes, Graham)
>>    5. Re: [nova] FYI: live_migration_progress_timeout will default
>>       to 0 and be deprecated in Ocata (David Medberry)
>>    6. [nova] Next minimum libvirt version (Matt Riedemann)
>>    7. Re: [openstack-dev] [nova] Next minimum   libvirt version
>>       (Steve Gordon)
>>    8. Re: [nova] FYI: live_migration_progress_timeout will default
>>       to 0 and be deprecated in Ocata (Belmiro Moreira)
>>    9. neutron-server high cpu usage (David Riedl)
>>   10. Re: neutron-server high cpu usage (Kevin Benton)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 9 Feb 2017 08:19:23 -0700
>> From: Matt Fischer <matt at mattfischer.com>
>> To: Ignazio Cassano <ignaziocassano at gmail.com>
>> Cc: OpenStack Operators <openstack-operators at lists.openstack.org>
>> Subject: Re: [Openstack-operators] Sharing fernet tokens
>> Message-ID:
>>
>> <CAHr1CO-V0QrAOAkYR1JQp825ZrAmpxGVnxRtWz8=-cYEE9BDAA at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Please reply all to the list rather than emailing me directly.
>>
>> Key rotation is done with a keystone-manage command or we just end up
>> effectively renumbering the keys with our deploy process.
>>
>> I'd recommend you watch our presentation from the Austin summit or read my
>> blog posts on this.
>>
>> http://www.mattfischer.com/blog/?p=648
>> https://www.youtube.com/watch?v=702SRZHdNW8
>>
>>
>> On Wed, Feb 8, 2017 at 8:14 AM, Matt Fischer <matt at mattfischer.com> wrote:
>>
>> > I think that you just replied to me directly. But you are asking about
>> > sharing keys.
>> >
>> > Since keys do not need to be in-sync on all nodes at the same time you
>> > can
>> > use any number of sharing mechanisms. We used puppet + ansible (our
>> > normal
>> > deploy process). Key rotation allows them to be out of sync which
>> > simplifies the problem for you.
>> >
>> > On Tue, Feb 7, 2017 at 9:25 PM, Matt Fischer <matt at mattfischer.com>
>> > wrote:
>> >
>> >> Do you mean sharing tokens or keys?
>> >>
>> >> On Feb 7, 2017 11:34 AM, "Ignazio Cassano" <ignaziocassano at gmail.com>
>> >> wrote:
>> >>
>> >>> Hi everybody,
>> >>> Can anyone talk me about Sebring fernet tokens in an openstack with
>> >>> more
>> >>> than one controller?
>> >>> Regards
>> >>> Ignazio
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OpenStack-operators mailing list
>> >>> OpenStack-operators at lists.openstack.org
>> >>>
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >>>
>> >>>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170209/caf039a1/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 9 Feb 2017 10:29:14 -0600
>> From: Matt Riedemann <mriedemos at gmail.com>
>> To: "openstack-operators at lists.openstack.org"
>>         <openstack-operators at lists.openstack.org>
>> Subject: [Openstack-operators] [nova] FYI:
>>         live_migration_progress_timeout will default to 0 and be
>> deprecated in
>>         Ocata
>> Message-ID: <42db0239-4235-4fff-36c9-7f15abae9ba7 at gmail.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> This is just a heads up to anyone running with this since Liberty, there
>> is a patch [1] that will go into Ocata which deprecates the
>> live_migration_progress_timeout config option used in the libvirt
>> driver. The default value will also change to 0, effectively disabling
>> the feature. See the patch and related bug report for more details.
>>
>> If you've seen issues trying to use this feature, and can confirm this
>> or think it's actually wrong, please speak up soon (final Nova ocata tag
>> is on 2/16).
>>
>> [1] https://review.openstack.org/#/c/429798/
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 9 Feb 2017 16:29:52 +0000
>> From: Jeremy Stanley <fungi at yuggoth.org>
>> To: openstack-operators at lists.openstack.org,
>>         user-committee at lists.openstack.org
>> Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing
>> Message-ID: <20170209162952.GQ12827 at yuggoth.org>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On 2017-02-09 00:59:52 +0000 (+0000), UKASICK, ANDREW wrote:
>> [...]
>> > I'm the mysterious "AndyU" who was chatting with you about a year
>> > ago in IRC with questions about how to go about donating hosted
>> > cloud resources for use by the Infra team. It's nice to bump into
>> > you again! ;-) That idea is still stirring btw, but has been much
>> > slower moving than I'd hoped.
>> [...]
>>
>> Always appreciated, and happy to pick that back up if and when
>> you're ready.
>>
>> > I've been having a pretty lengthy conversation with jay Pipes
>> > regarding similar questions. You can catch up on that in the
>> > thread below this one.
>>
>> I've been following it closely, and tried not to duplicate
>> questions/comments as much as possible.
>>
>> > LCOO is unlike any other working groups that I'm familiar with in
>> > some significant ways. You zero'd in on one of those in your
>> > statements above about companies joining as opposed to
>> > individuals. In that regard, LCOO is similar to an entity like
>> > OSIC.org as opposed to a traditional working group.
>> [...]
>>
>> This is probably where some of the confusion comes in for me; I
>> expect it's just one of terminology/semantics. The OpenStack User
>> Committee has specifically tied "Active members and contributors to
>> functional teams and/or working groups" to its electorate in their
>> charter, and also defines working groups as "teams" (which to me
>> implies they're made up of individuals, not organizations):
>>
>>     https://governance.openstack.org/uc/reference/charter.html
>>
>> Maybe LCOO is something other than a "working group" in the formal
>> UC sense? Or maybe the organizations who participate in the LCOO
>> designate representatives (those LCOO "organization coordinators"
>> and "governance board" mentioned in your wiki article) who are the
>> actual working group as far as the UC is concerned? I'm just
>> concerned if, for example, all employees within AT&T suddenly become
>> part of the UC electorate by way of AT&T as an organization being an
>> active "member" of an official UC working group. The only way I can
>> really see this working is if the UC insists that its working groups
>> are made up of individuals and not whole organizations.
>>
>> > Jira provides Kanban boards that can serve as a kind of dashboard
>> > allowing us to visualize activity and current status of Community
>> > activity. But that activity is still happening in Launchpad,
>> > Gerrit, etc.
>> [...]
>>
>> Cool, so it sounds like StoryBoard may work out for you in the
>> long-run. It already has kanban and worklist support with optional
>> automation tied directly to defect/feature tracking and code review.
>> As the current effort to move our community from launchpad.net to
>> storyboard.openstack.org progresses over the next couple of
>> development cycles, I encourage you to check it out and start
>> thinking about whether its features address your needs (or consider
>> pitching in on further development there).
>>
>> > Automating the status updating is something I've begun to discuss
>> > within the PWG's "Story Tracker" team. We have the same challenge
>> > there.
>> [...]
>>
>> Our hope is that once we get further along with the current
>> migration blockers for StoryBoard, we'll implement an "epics"
>> concept in it which ties individual stories and their tasksets to
>> over-arching efforts where their progress can be tracked more
>> holistically.
>>
>> > BTW, Atlassian has always made their tools free for use by open
>> > source projects. Also, although they're commercial products they
>> > do provide the source code and allow users to modify it freely
>> > which makes them much more open-source-ish than most.
>> [...]
>>
>> <soapbox>
>> Yes, I saw you mention it in the other ML thread. "Free as in beer"
>> is a somewhat dirty concept in free software development circles,
>> and our community infrastructure similarly eschews gratis services
>> like GitHub in favor of libre alternatives (we provide read-only
>> mirrors there on request, but don't rely on it in any of our
>> automation and officially recommend git.openstack.org which runs
>> entirely on free software).
>>
>> As an author of free software myself I prefer when people use and
>> help improve OpenStack rather than supporting commercial/proprietary
>> solutions to accomplish the same tasks, and so think it hypocritical
>> to not extend the same courtesy to other free software communities
>> who are attempting to overcome similar hurdles in their respective
>> problem spaces. To quote Harry Tuttle, "We're all in it together."
>> </soapbox>
>>
>> I understand you'll probably end up using whatever tools you're
>> familiar/comfortable with and which help you accomplish your goals,
>> I just ask that you keep in mind that publicly recommending non-free
>> tools in the service of free software development sets an example.
>> OpenStack already has a slightly negative reputation as "not really
>> free" in the wider community... one which we're desperately trying
>> to overcome, bit by bit.
>> --
>> Jeremy Stanley
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 949 bytes
>> Desc: Digital signature
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170209/afd5a1dd/attachment-0001.pgp>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 9 Feb 2017 18:56:46 +0000
>> From: "Hayes, Graham" <graham.hayes at hpe.com>
>> To: Jeremy Stanley <fungi at yuggoth.org>,
>>         "openstack-operators at lists.openstack.org"
>>         <openstack-operators at lists.openstack.org>,
>>         "user-committee at lists.openstack.org"
>>         <user-committee at lists.openstack.org>
>> Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing
>> Message-ID:
>>
>> <CS1PR84MB02152CAC63E88595DF557AF090450 at CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On 09/02/2017 16:37, Jeremy Stanley wrote:
>> > On 2017-02-09 00:59:52 +0000 (+0000), UKASICK, ANDREW wrote:
>> > [...]
>> >> I'm the mysterious "AndyU" who was chatting with you about a year
>> >> ago in IRC with questions about how to go about donating hosted
>> >> cloud resources for use by the Infra team. It's nice to bump into
>> >> you again! ;-) That idea is still stirring btw, but has been much
>> >> slower moving than I'd hoped.
>> > [...]
>> >
>> > Always appreciated, and happy to pick that back up if and when
>> > you're ready.
>> >
>> >> I've been having a pretty lengthy conversation with jay Pipes
>> >> regarding similar questions. You can catch up on that in the
>> >> thread below this one.
>> >
>> > I've been following it closely, and tried not to duplicate
>> > questions/comments as much as possible.
>> >
>> >> LCOO is unlike any other working groups that I'm familiar with in
>> >> some significant ways. You zero'd in on one of those in your
>> >> statements above about companies joining as opposed to
>> >> individuals. In that regard, LCOO is similar to an entity like
>> >> OSIC.org as opposed to a traditional working group.
>> > [...]
>> >
>> > This is probably where some of the confusion comes in for me; I
>> > expect it's just one of terminology/semantics. The OpenStack User
>> > Committee has specifically tied "Active members and contributors to
>> > functional teams and/or working groups" to its electorate in their
>> > charter, and also defines working groups as "teams" (which to me
>> > implies they're made up of individuals, not organizations):
>> >
>> >     https://governance.openstack.org/uc/reference/charter.html
>> >
>> > Maybe LCOO is something other than a "working group" in the formal
>> > UC sense? Or maybe the organizations who participate in the LCOO
>> > designate representatives (those LCOO "organization coordinators"
>> > and "governance board" mentioned in your wiki article) who are the
>> > actual working group as far as the UC is concerned? I'm just
>> > concerned if, for example, all employees within AT&T suddenly become
>> > part of the UC electorate by way of AT&T as an organization being an
>> > active "member" of an official UC working group. The only way I can
>> > really see this working is if the UC insists that its working groups
>> > are made up of individuals and not whole organizations.
>> >
>> >> Jira provides Kanban boards that can serve as a kind of dashboard
>> >> allowing us to visualize activity and current status of Community
>> >> activity. But that activity is still happening in Launchpad,
>> >> Gerrit, etc.
>> > [...]
>> >
>> > Cool, so it sounds like StoryBoard may work out for you in the
>> > long-run. It already has kanban and worklist support with optional
>> > automation tied directly to defect/feature tracking and code review.
>> > As the current effort to move our community from launchpad.net to
>> > storyboard.openstack.org progresses over the next couple of
>> > development cycles, I encourage you to check it out and start
>> > thinking about whether its features address your needs (or consider
>> > pitching in on further development there).
>> >
>> >> Automating the status updating is something I've begun to discuss
>> >> within the PWG's "Story Tracker" team. We have the same challenge
>> >> there.
>> > [...]
>> >
>> > Our hope is that once we get further along with the current
>> > migration blockers for StoryBoard, we'll implement an "epics"
>> > concept in it which ties individual stories and their tasksets to
>> > over-arching efforts where their progress can be tracked more
>> > holistically.
>> >
>> >> BTW, Atlassian has always made their tools free for use by open
>> >> source projects. Also, although they're commercial products they
>> >> do provide the source code and allow users to modify it freely
>> >> which makes them much more open-source-ish than most.
>> > [...]
>> >
>> > <soapbox>
>> > Yes, I saw you mention it in the other ML thread. "Free as in beer"
>> > is a somewhat dirty concept in free software development circles,
>> > and our community infrastructure similarly eschews gratis services
>> > like GitHub in favor of libre alternatives (we provide read-only
>> > mirrors there on request, but don't rely on it in any of our
>> > automation and officially recommend git.openstack.org which runs
>> > entirely on free software).
>> >
>> > As an author of free software myself I prefer when people use and
>> > help improve OpenStack rather than supporting commercial/proprietary
>> > solutions to accomplish the same tasks, and so think it hypocritical
>> > to not extend the same courtesy to other free software communities
>> > who are attempting to overcome similar hurdles in their respective
>> > problem spaces. To quote Harry Tuttle, "We're all in it together."
>> > </soapbox>
>> >
>> > I understand you'll probably end up using whatever tools you're
>> > familiar/comfortable with and which help you accomplish your goals,
>> > I just ask that you keep in mind that publicly recommending non-free
>> > tools in the service of free software development sets an example.
>> > OpenStack already has a slightly negative reputation as "not really
>> > free" in the wider community... one which we're desperately trying
>> > to overcome, bit by bit.
>> >
>>
>> I would also have a request - if these tools are going to be used
>> can we make them world readable, with no requirement to log in to
>> view content?
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 9 Feb 2017 14:21:52 -0700
>> From: David Medberry <openstack at medberry.net>
>> To: Matt Riedemann <mriedemos at gmail.com>
>> Cc: "openstack-operators at lists.openstack.org"
>>         <openstack-operators at lists.openstack.org>
>> Subject: Re: [Openstack-operators] [nova] FYI:
>>         live_migration_progress_timeout will default to 0 and be
>> deprecated in
>>         Ocata
>> Message-ID:
>>
>> <CAJhvMSvh_qgPC4P9DeJX7Ku-nBWmPwXv0_FVHkw=Btc7wfjESQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Thu, Feb 9, 2017 at 9:29 AM, Matt Riedemann <mriedemos at gmail.com>
>> wrote:
>>
>> >
>> Thanks for the heads up Matt, ops appreciate.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170209/626608ad/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 9 Feb 2017 17:29:22 -0600
>> From: Matt Riedemann <mriedemos at gmail.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>         <openstack-dev at lists.openstack.org>,
>>         "openstack-operators at lists.openstack.org"
>>         <openstack-operators at lists.openstack.org>
>> Subject: [Openstack-operators] [nova] Next minimum libvirt version
>> Message-ID: <c7ec3359-3de2-cb05-2c60-a6a7a40a8ec3 at gmail.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Since danpb hasn't been around I've sort of forgotten about this, but we
>> should talk about bumping the minimum required libvirt version in nova.
>>
>> Currently it's 1.2.1 and the next was set to 1.2.9.
>>
>> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
>> had 1.2.2).
>>
>> If we move to require 1.2.9 that effectively kills 14.04 support for
>> devstack + libvirt on master, which is probably OK.
>>
>> There is also the distro support wiki [1] which hasn't been updated in
>> awhile.
>>
>> I'm wondering if 1.2.9 is a safe move for the next required minimum
>> version and if so, does anyone have ideas on the next required version
>> after that?
>>
>> I'm hoping some of the Red Hat people can chime in here.
>>
>> [1] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 9 Feb 2017 18:51:42 -0500 (EST)
>> From: Steve Gordon <sgordon at redhat.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>         <openstack-dev at lists.openstack.org>
>> Cc: Vladik Romanovsky <vromanov at redhat.com>, Sahid Orentino Ferdjaoui
>>         <sahid.ferdjaoui at redhat.com>,
>> openstack-operators at lists.openstack.org
>> Subject: Re: [Openstack-operators] [openstack-dev] [nova] Next minimum
>>         libvirt version
>> Message-ID:
>>         <786189857.103656865.1486684302672.JavaMail.zimbra at redhat.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> ----- Original Message -----
>> > From: "Matt Riedemann" <mriedemos at gmail.com>
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev at lists.openstack.org>,
>> > openstack-operators at lists.openstack.org
>> > Sent: Thursday, February 9, 2017 6:29:22 PM
>> > Subject: [openstack-dev] [nova] Next minimum libvirt version
>> >
>> > Since danpb hasn't been around I've sort of forgotten about this, but we
>> > should talk about bumping the minimum required libvirt version in nova.
>> >
>> > Currently it's 1.2.1 and the next was set to 1.2.9.
>> >
>> > On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
>> > had 1.2.2).
>> >
>> > If we move to require 1.2.9 that effectively kills 14.04 support for
>> > devstack + libvirt on master, which is probably OK.
>>
>> This would also kill off RHEL/CentOS 7.1 support but that would also seem
>> to be OK at this point.
>>
>> > There is also the distro support wiki [1] which hasn't been updated in
>> > awhile.
>>
>> I've added the details I have for Fedora 25 and RHEL/CentOS 7.3, TL;DR:
>>
>> Fedora 25:
>> Libvirt 2.2.0
>> Qemu 2.7.1
>> Libguestfs 1.34.3
>>
>> RHEL 7.3:
>> Libvirt 2.0.0
>> Qemu 2.6.0
>> Libguestfs 1.32.7
>>
>>
>> > I'm wondering if 1.2.9 is a safe move for the next required minimum
>> > version and if so, does anyone have ideas on the next required version
>> > after that?
>> >
>> > I'm hoping some of the Red Hat people can chime in here.
>>
>> I just play someone intelligent on TV so adding Sahid and Vladik who might
>> be better placed to comment in Dan's absence.
>>
>> Thanks,
>>
>> Steve
>>
>> --
>> Steve Gordon,
>> Principal Product Manager,
>> Red Hat OpenStack Platform
>>
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Fri, 10 Feb 2017 08:47:12 +0100
>> From: Belmiro Moreira <moreira.belmiro.email.lists at gmail.com>
>> To: Matt Riedemann <mriedemos at gmail.com>
>> Cc: "openstack-operators at lists.openstack.org"
>>         <openstack-operators at lists.openstack.org>
>> Subject: Re: [Openstack-operators] [nova] FYI:
>>         live_migration_progress_timeout will default to 0 and be
>> deprecated in
>>         Ocata
>> Message-ID:
>>
>> <CAPkQhneQEgwAEE56=bGkyomMB9XPfoByN3HQamO33PnALLO=gg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> +1
>> We use "block-migration" and we needed to disable this timeout.
>>
>> Belmiro
>> CERN
>>
>> On Thu, Feb 9, 2017 at 5:29 PM, Matt Riedemann <mriedemos at gmail.com>
>> wrote:
>>
>> > This is just a heads up to anyone running with this since Liberty, there
>> > is a patch [1] that will go into Ocata which deprecates the
>> > live_migration_progress_timeout config option used in the libvirt
>> > driver.
>> > The default value will also change to 0, effectively disabling the
>> > feature.
>> > See the patch and related bug report for more details.
>> >
>> > If you've seen issues trying to use this feature, and can confirm this
>> > or
>> > think it's actually wrong, please speak up soon (final Nova ocata tag is
>> > on
>> > 2/16).
>> >
>> > [1] https://review.openstack.org/#/c/429798/
>> >
>> > --
>> >
>> > Thanks,
>> >
>> > Matt Riedemann
>> >
>> > _______________________________________________
>> > OpenStack-operators mailing list
>> > OpenStack-operators at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170210/f10667bf/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Fri, 10 Feb 2017 11:10:53 +0100
>> From: David Riedl <david.riedl at wingcon.com>
>> To: openstack-operators at lists.openstack.org
>> Subject: [Openstack-operators] neutron-server high cpu usage
>> Message-ID: <8f480a06-19d4-e164-9f2e-61d5345a6ddb at wingcon.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hello Everyone,
>>
>> I just upgraded my Openstack Installation from Liberty to Mitaka. It is
>> a pretty small cluster with only 3 nodes.
>>
>> Since the upgrade, the neutron-server on my control node produces a very
>> high cpu load. Unfortunately the log files throw no errors and google
>> does not give me any answers either, so I am a bit lost.
>>
>> This is my neutron.conf
>> http://pastebin.com/cQbgeP4H
>> Please tell me if you need any log files or config files.
>>
>>
>> Regards and thanks for any help
>>
>> David
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 10
>> Date: Fri, 10 Feb 2017 03:21:23 -0700
>> From: Kevin Benton <kevin at benton.pub>
>> To: David Riedl <david.riedl at wingcon.com>
>> Cc: OpenStack Operators <openstack-operators at lists.openstack.org>
>> Subject: Re: [Openstack-operators] neutron-server high cpu usage
>> Message-ID:
>>
>> <CAO_F6JNF-vARTpewXWQ3Tw5Mz0MrQGa_BW5Bokkj98T9b_nc6w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Does it calm down if you stop the agents? If so, check the agent logs for
>> exceptions because one may be stuck in a sync loop because it's
>> encountering an error.
>>
>> If you still don't see anything, try reducing the report interval for the
>> agents (and increase agent_down_time on the server accordingly) and see if
>> that helps.
>>
>>
>> On Feb 10, 2017 03:15, "David Riedl" <david.riedl at wingcon.com> wrote:
>>
>> Hello Everyone,
>>
>> I just upgraded my Openstack Installation from Liberty to Mitaka. It is a
>> pretty small cluster with only 3 nodes.
>>
>> Since the upgrade, the neutron-server on my control node produces a very
>> high cpu load. Unfortunately the log files throw no errors and google does
>> not give me any answers either, so I am a bit lost.
>>
>> This is my neutron.conf
>> http://pastebin.com/cQbgeP4H
>> Please tell me if you need any log files or config files.
>>
>>
>> Regards and thanks for any help
>>
>> David
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170210/d6a4bf12/attachment-0001.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> End of OpenStack-operators Digest, Vol 76, Issue 11
>> ***************************************************
>
>
>
>
> --
> Kind Regards
>
> Y. Rahulan
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Blog: serverascode.com