On Fri, Feb 10, 2017 at 6:35 AM, Y.Rahulan <[email protected]> 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, > <[email protected]> wrote: >> >> Send OpenStack-operators mailing list submissions to >> [email protected] >> >> 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 >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> 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 <[email protected]> >> To: Ignazio Cassano <[email protected]> >> Cc: OpenStack Operators <[email protected]> >> Subject: Re: [Openstack-operators] Sharing fernet tokens >> Message-ID: >> >> <CAHr1CO-V0QrAOAkYR1JQp825ZrAmpxGVnxRtWz8=-cyee9b...@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 <[email protected]> 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 <[email protected]> >> > wrote: >> > >> >> Do you mean sharing tokens or keys? >> >> >> >> On Feb 7, 2017 11:34 AM, "Ignazio Cassano" <[email protected]> >> >> 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 >> >>> [email protected] >> >>> >> >>> 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 <[email protected]> >> To: "[email protected]" >> <[email protected]> >> Subject: [Openstack-operators] [nova] FYI: >> live_migration_progress_timeout will default to 0 and be >> deprecated in >> Ocata >> Message-ID: <[email protected]> >> 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 <[email protected]> >> To: [email protected], >> [email protected] >> Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing >> Message-ID: <[email protected]> >> 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" <[email protected]> >> To: Jeremy Stanley <[email protected]>, >> "[email protected]" >> <[email protected]>, >> "[email protected]" >> <[email protected]> >> Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing >> Message-ID: >> >> <cs1pr84mb02152cac63e88595df557af090...@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 <[email protected]> >> To: Matt Riedemann <[email protected]> >> Cc: "[email protected]" >> <[email protected]> >> 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=btc7wfj...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> On Thu, Feb 9, 2017 at 9:29 AM, Matt Riedemann <[email protected]> >> 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 <[email protected]> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <[email protected]>, >> "[email protected]" >> <[email protected]> >> Subject: [Openstack-operators] [nova] Next minimum libvirt version >> Message-ID: <[email protected]> >> 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 <[email protected]> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <[email protected]> >> Cc: Vladik Romanovsky <[email protected]>, Sahid Orentino Ferdjaoui >> <[email protected]>, >> [email protected] >> Subject: Re: [Openstack-operators] [openstack-dev] [nova] Next minimum >> libvirt version >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset=utf-8 >> >> ----- Original Message ----- >> > From: "Matt Riedemann" <[email protected]> >> > To: "OpenStack Development Mailing List (not for usage questions)" >> > <[email protected]>, >> > [email protected] >> > 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 <[email protected]> >> To: Matt Riedemann <[email protected]> >> Cc: "[email protected]" >> <[email protected]> >> Subject: Re: [Openstack-operators] [nova] FYI: >> live_migration_progress_timeout will default to 0 and be >> deprecated in >> Ocata >> Message-ID: >> >> <CAPkQhneQEgwAEE56=bGkyomMB9XPfoByN3HQamO33PnALLO=g...@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 <[email protected]> >> 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 >> > [email protected] >> > 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 <[email protected]> >> To: [email protected] >> Subject: [Openstack-operators] neutron-server high cpu usage >> Message-ID: <[email protected]> >> 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 <[email protected]> >> To: David Riedl <[email protected]> >> Cc: OpenStack Operators <[email protected]> >> Subject: Re: [Openstack-operators] neutron-server high cpu usage >> Message-ID: >> >> <cao_f6jnf-vartpewxwq3tw5mz0mrqga_bw5bokkj98t9b_n...@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" <[email protected]> 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 >> [email protected] >> 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 >> [email protected] >> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Blog: serverascode.com _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
