[Openstack-operators] OpenStack-operators Digest, Vol 76, Issue 11

Y.Rahulan rahulan.y at gmail.com
Fri Feb 10 13:35:20 UTC 2017


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.



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@
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170210/6ef5c177/attachment.html>


More information about the OpenStack-operators mailing list