- openstack-discuss - lists.openstack.org

[placement] [packaging] [docs] WIP placement install docs
by Chris Dent 03 Jan '19

03 Jan '19

I've started a very wippy work in progress [1] for placement installation docs within the extracted placement repository, using the existing docs from nova as a base. I'd like to draw the attention of rdo, ubuntu, and obs packagers as the docs follow the existing pattern of documenting install on those three distros. However, since placement is not fully packaged yet, I'm making some guesses in the docs about how things will be set up and how packages will be named. So if people who are interested in such things could have a look that would be helpful. I've stubbed out, but not yet completed, a from-pypi page as well, as with placement, installation can become as simple as pip install + run a single command line with the right args, if that's what you want. I think people should be able to see that too. Thanks. [1] https://review.openstack.org/628220 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tc] agenda for Technical Committee Meeting 3 Jan 2019 @ 1400 UTC
by Doug Hellmann 03 Jan '19

03 Jan '19

TC Members, Our next meeting will be this Thursday, 3 Jan at 1400 UTC in #openstack-tc. This email contains the agenda for the meeting, based on the content of the wiki [0]. If you will not be able to attend, please include your name in the "Apologies for Absence" section of the wiki page [0]. [0] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee We have several items of old business to wrap up: * technical vision for openstack We have approved the first draft of the vision [1], and have one update proposed by gmann [2]. What are the next steps for this change to the vision? Are we ready to remove this topic from the tracker now, and treat further updates as individual work items? [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] https://review.openstack.org/#/c/621516/ * next step in TC vision/defining the role of the TC We also approved a document explaining the role of the TC [3]. Is there more work to do here, or are we ready to remove this from the tracker now? [3] https://governance.openstack.org/tc/reference/role-of-the-tc.html * keeping up with python 3 releases We have approved all of the patches for documenting the policy and for selecting the versions to be covered in Stein. What are the next steps for ensuring that any implementation work is handled? * Reviewing TC Office Hour Times and Locations The most recent mailing list thread [4] was resolved with no changes to the number of office hours. Does anyone want to propose different times, or are we happy with the current schedule? [4] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000542… and we also have a couple of items of new business to take up: * Train cycle goals selection update Checking with lbragstad and evrardjp for any updates to share with us this month. * health check status for stein How is it going contacting the PTLs for the health check for stein? Does anyone have anything to raise based on what they have learned in their conversations? -- Doug

1 1

[glance] (Silly) question about container_format and disk_format
by Andre Florath 03 Jan '19

03 Jan '19

Hello! I do not completely understand the parameters 'container_format' and 'disk_format' as described in [1]. The documentation always uses 'the format' but IMHO there might be two formats involved. Are those formats either (A) the formats of the image file that is passed in. Like (from the official documentation [2]) $ openstack image create --disk-format qcow2 --container-format bare \ --public --file ./centos63.qcow2 centos63-image qcow2 / bare are the formats of the passed in image. or (B) the formats that are used internally to store the image Like $ openstack image create --disk-format vmdk --container-format ova \ --public --file ./centos63.qcow2 centos63-image vmdk / ova are formats that are used internally in OpenStack glance to store the image. In this case there must be an auto-detection of the image file format that is passed in and an automatic conversion into the new format. Kind regards Andre [1] https://developer.openstack.org/api-ref/image/v2/index.html?expanded=create… [2] https://docs.openstack.org/glance/pike/admin/manage-images.html

2 2

Re: [Infra][Cinder] Request for voting permission from LINBIT LINSTOR CI (linbit_ci@linbit.com) for Cinder projects
by Woojay Poynter 03 Jan '19

03 Jan '19

Hello, I would like to request a voting permission on LINBIT LINSTOR CI for Cinder project. We are looking to satisfy third-party testing requirement for Cinder volume driver for LINSTOR (https://review.openstack.org/#/c/624233/) The CI's test result of the lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ While the driver itself is still being tweaked on the remaining two failed tests, I hope I can have the CI portion of the requirement ready w/ this request. The testbeds are jenkins slave running fresh installation of devstack w/ target patch triggered from gerrit with lvmthin storage backend managed by LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for block replication. Some of the test results of the LINBIT LINSTOR CI running on openstack-dev/ci-sandbox are here; https://review.openstack.org/#/c/627599/ https://review.openstack.org/#/c/627596/ https://review.openstack.org/#/c/626625/ Thank you for your time during the holidays. Sincerely, Woojay Poynter -- 541-435-1001 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. On Fri, Dec 28, 2018 at 1:51 PM Woojay Poynter <woojay(a)linbit.com> wrote: > Hello, > > I would like to request a voting permission on LINBIT LINSTOR CI for > Cinder project. We are looking to satisfy third-party testing requirement > for Cinder volume driver for LINSTOR ( > https://review.openstack.org/#/c/624233/) The CI's test result of the > lastest patch is at http://us.linbit.com:8080/CI-LINSTOR/33/456/ > > While the driver itself is still being tweaked on the remaining two failed > tests, I hope I can have the CI portion of the requirement ready w/ this > request. > > The testbeds are jenkins slave running fresh installation of devstack w/ > target patch triggered from gerrit with lvmthin storage backend managed by > LINSTOR driver for Cinder. LINSTOR is storage provisioner using DRBD for > block replication. > > Some of the test results of the LINBIT LINSTOR CI running on > openstack-dev/ci-sandbox are here; > https://review.openstack.org/#/c/627599/ > https://review.openstack.org/#/c/627596/ > https://review.openstack.org/#/c/626625/ > > Thank you for your time during the holidays. > > Sincerely, > > Woojay Poynter > -- > 541-435-1001 > woojay(a)linbit.com > > LINBIT | Keeping the Digital World Running > DRBD – Corosync – Pacemaker > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > -- Woojay Poynter – Software Developer +1 503 573-1262 x211 woojay(a)linbit.com LINBIT | Keeping the Digital World Running DRBD – Corosync – Pacemaker DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

2 1

[cinder] Is the cinder Active-Active feature OK？
by Jaze Lee 03 Jan '19

03 Jan '19

Hello, In my opinion, all rest api will get to manager of cinder volume. If the manager is using DLM, we can say cinder volume can support active-active. So, can we rewrite the comments and option's help in page https://github.com/openstack/cinder/blob/master/cinder/cmd/volume.py#L78 ? Thanks a lot. -- 谦谦君子

2 2

[neutron] Bug deputy report 17th~23rd Dec 2018
by Paweł Suder 02 Jan '19

02 Jan '19

Hello Neutrons, Following bugs/RFE/issues have been raised during last week. Some of them were already recognized, triaged, checked: >From oldest: https://bugs.launchpad.net/neutron/+bug/1808731 [RFE] Needs to restart metadata proxy with the start/restart of l3/dhcp agent - IMO need to discus how to do that. https://bugs.launchpad.net/neutron/+bug/1808916 Update mailinglist from dev to discuss - it is done. https://bugs.launchpad.net/neutron/+bug/1808917 RetryRequest shouldn't log stack trace by default, or it should be configurable by the exception - confirmed by Sławek ;) https://bugs.launchpad.net/neutron/+bug/1809037 [RFE] Add anti_affinity_group to binding:profile - RFE connected with another RFE from Nova related to NFV and (anti)affinity of resources like PFs. https://bugs.launchpad.net/neutron/+bug/1809080 reload_cfg doesn't work correctly - change in review, I tried to review, but no comments left - new contributor https://bugs.launchpad.net/neutron/+bug/1809134 - TypeError in QoS gateway_ip code in l3-agent logs - review in progress https://bugs.launchpad.net/neutron/+bug/1809238 - [l3] `port_forwarding` cannot be set before l3 `router` in service_plugins - review in progress https://bugs.launchpad.net/neutron/+bug/1809447 - performance regression from mitaka to ocata - not triaged, I am not sure how to handle it - it is a wide thing.. https://bugs.launchpad.net/neutron/+bug/1809497 - bug noticed on gates related to another bug opened last week: https://bugs.launchpad.net/neu tron/+bug/1809134 Wish you a good time this week and for the next year! :) Cheers, Paweł

2 2

[all][ptl][heat][senlin][magnum]New SIG for Autoscaling? plus Session Summary: Autoscaling Integration, improvement, and feedback
by Rico Lin 02 Jan '19

02 Jan '19

Dear all Tl;dr; I gonna use this ML to give a summary of the forum [1] and asking for feedback for the idea of new SIG. We have a plan to create a new SIG for autoscaling which to cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. So if you have any thoughts for the new SIG (good or bad) please share it here. Here I summarize our discussion in the forum session `Autoscaling Integration, improvement, and feedback`. If you like to learn more or input your thoughts, feel free to put it in etherpad [1] or simply reply to this email. In the forum, we have been discussed the scope and possibility to integrate effort from Heat, Senlin, and also autoscaling across OpenStack to K8s. There are some long-term goals that we can start on like create a document for general Autoscaling on OpenStack, Common library for cross-project usage, or create real scenario cases to test on our CI. And the most important part is how can we help users and satisfied use cases without confuse them or making too much duplication effort across communities/projects. So here's an action we agree on, is to trigger discussion for either we need to create a new SIG for autoscaling. We need to define the scope and the goal for this new SIG before we go ahead and create one. The new SIG will cover the common library, docs, and tests for cross-project services (Senlin, Heat, Monasca, etc.) and cross-community (OpenStack, Kubernetes, etc). And the goal is not just to have a place to keep those resources that make sure we can guarantee the availability for use cases, also to have a force to keep push the effort to integrate across services or at least make sure we don't go to a point where everyone just do their own service and don't care about any duplication. For example, we can have a document about do autoscaling in OpenStack, but we need a place to put it and keep maintain it. And we can even have a place to set up CI to test all scenario for autoscaling. I think it's possible to extend the definition of this SIG, but we have to clear our goal and make sure we actually doing a good thing and make everyone's life easier. On the other hand we also need to make sure we do not duplicate the effort of other SIGs/WGs. Also The reason I add `ptl` tag for this ML is that this SIG or the concept of `autoscaling` might be very deferent to different projects. So I really wish to hear from anyone and any projects who are interested in this topic. [1] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

4 3

[nova] Granular locks in the API
by Matt Riedemann 02 Jan '19

02 Jan '19

I wanted to float something that we talked about in the public cloud SIG meeting today [1] which is the concept of making the lock API more granular to lock on a list of actions rather than globally locking all actions that can be performed on a server. The primary use case we discussed was around a pre-paid pricing model for servers. A user can pre-pay resources at a discount if let's say they are going to use them for a month at a fixed rate. However, once they do, they can't resize those servers without going through some kind of approval (billing) process to resize up. With this, the provider could lock the user from performing the resize action on the server but the user could do other things like stop/start/reboot/snapshot/etc. The pricing model sounds similar to pre-emptible instances for getting a discount but the scenario is different in that these servers couldn't be pre-empted (they are definitely more non-cloudy pets than cattle). An alternative solution for that locked resize issue is using granular policy rules such that pre-paid servers have some other kind of role attached to them so by policy you could restrict users from performing actions on those servers (but the admin could override). In reality I'm not sure how feasible that is in a public cloud with several thousand projects. The issue I see with policy controlling this is the role is attached to the project, not the resource (the server), so if you did this would users have to have separate projects for on-demand vs pre-paid resources? I believe that's what CERN and StackHPC are doing with pre-emptible instances (you have different projects with different quota models for pre-emptible resources). I believe there are probably other use cases for granular locks on servers for things like service VMs (trove creates some service VMs to run a database cluster and puts locks on those servers). Again, definitely a pet scenario but it's one I've heard before. Would people be generally in favor of this or opposed, or just meh? [1] https://etherpad.openstack.org/p/publiccloud-wg -- Thanks, Matt

4 5

[neutron] bug deputy report (Dec 24 - Dec 30)
by Hongbin Lu 02 Jan '19

02 Jan '19

Hi all, Below is the bug deputy report for last week. Since it is on the holiday, there are not too much reporting bugs. REFs: * https://bugs.launchpad.net/neutron/+bug/1809628 [RFE] Enable driver field for the api of service_providers * https://bugs.launchpad.net/neutron/+bug/1809878 [RFE] Move sanity-checks to neutron-status CLI tool Incomplete: * https://bugs.launchpad.net/neutron/+bug/1809907 Unstable ping during zuul testing Best regards, Hongbin

1 0

Re: [Openstack] [Nova][Glance] Nova imports flat images from base file despite ceph backend
by Eugen Block 02 Jan '19

02 Jan '19

Hello and a happy new year! I need to reopen this thread because there are still things going on that I don't fully understand. I changed the disk_format of all the images that were affected by my mistake a couple of weeks ago. I deleted the base files in /var/lib/nova/instances/_base and launched new instances, leading to expected cow clones: ---cut here--- control:~ # openstack image show 5f486361-5468-42a0-9993-9cdda3450b0e | grep disk_format | disk_format | raw| control:~ # rbd children images/5f486361-5468-42a0-9993-9cdda3450b0e@snap images/029bfb90-cbab-4a7c-a51c-27807ab41ce7_disk images/ccd4498f-c0a0-480a-ab4b-6224d63e78fa_disk images/d5379918-40a0-4119-9e47-773c0ab8c0f3_disk ---cut here--- These are only three clones, but I have 16 instances based on the same image: ---cut here--- +--------------------------------------+ | uuid | +--------------------------------------+ | 87dfbb4f-784d-4390-a0c9-d3162a56ea7e | | bb56995d-d3ea-464d-94fe-382880bf2a92 | | d4fde2fe-140e-4904-90e8-996cc418302d | | 7bd4fdc0-d6b7-47cb-adb3-324abff6a0e5 | | bef8e4fe-b2f4-44f5-a144-36ced37007ac | | bcc005fc-fa12-4dd9-b531-cbccfb7c426a | ###| ccd4498f-c0a0-480a-ab4b-6224d63e78fa | ###| 029bfb90-cbab-4a7c-a51c-27807ab41ce7 | ###| d5379918-40a0-4119-9e47-773c0ab8c0f3 | | abd2c0bc-2e66-4e2a-9f4c-f006937c7b27 | | e07c0f5e-403e-4ad3-b04f-fb306e99869e | | edec4aa0-9459-4444-bbb8-03097bccba4c | | ca4449f5-921d-4ce5-8559-fc719cfbc845 | | 8bff1799-391e-4620-9b11-134962084b84 | | 9d927ac4-d7d3-45cb-8628-b267a6d0e668 | | 54cfeede-44f9-49bd-9f49-ef4dcacff953 | +--------------------------------------+ ---cut here--- Those three cow clones were created after adjusting the disk_format, some of the rest were created before the changes, the others have been created after the changes. Can anyone explain why a new base image is created? I downloaded the glance image and double-checked the file format, I also exported the snapshot which should be used to create clones, there's only one discrepancy (disk size), but I don't think this could be relevant: ---cut here--- control:~ # qemu-img info /var/lib/glance/images/image-snap.img image: /var/lib/glance/images/image-snap.img file format: raw virtual size: 5.0G (5368709120 bytes) disk size: 2.5G control:~ # qemu-img info /var/lib/glance/images/image.img image: /var/lib/glance/images/image.img file format: raw virtual size: 5.0G (5368709120 bytes) disk size: 5.0G control:~ # md5sum /var/lib/glance/images/image.img b9b28dd300a6fbb1de2081f1cb8a07d0 /var/lib/glance/images/image.img control:~ # md5sum /var/lib/glance/images/image-snap.img b9b28dd300a6fbb1de2081f1cb8a07d0 /var/lib/glance/images/image-snap.img ---cut here--- I also tried to find something with the glance-cache-manage cli, but I can't even connect to that service, I guess it has never been used. control:~ # glance-cache-manage list-cached Failed to show cached images. Got error: Connect error/bad request to Auth service at URL http://control1.cloud.hh.nde.ag:5000/v3/tokens. I don't know how to fix that yet, but could this be a way to resolve that issue? Regards, Eugen Zitat von melanie witt <melwittt(a)gmail.com>: > On Fri, 12 Oct 2018 20:06:04 -0700, Remo Mattei wrote: >> I do not have it handy now but you can verify that the image is >> indeed raw or qcow2 >> >> As soon as I get home I will dig the command and pass it on. I have >> seen where images have extensions thinking it is raw and it is not. > > You could try 'qemu-img info <image>' and get output like this, > notice "file format": > > $ qemu-img info test.vmdk > (VMDK) image open: flags=0x2 filename=test.vmdk > image: test.vmdk > file format: vmdk > virtual size: 20M (20971520 bytes) > disk size: 17M > > [1] https://en.wikibooks.org/wiki/QEMU/Images#Getting_information > > -melanie > > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack(a)lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

queens heat db deadlock
by Ignazio Cassano 02 Jan '19

02 Jan '19

Hi All, I installed queens on centos 7. Heat seems to work fine with templates I wrote but when I create magnum cluster I often face with db deadlock in heat-engine log: 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource Traceback (most recent call last): 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 918, in _action_recorder 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource yield 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2035, in delete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource *action_args) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, in wrapper 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource step = next(subtask) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 977, in action_handler_task 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource done = check(handler_data) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 587, in check_delete_complete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource return self._check_status_complete(self.DELETE) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 454, in _check_status_complete 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource action=action) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource ResourceFailure: resources[0]: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') (Background on this error at: http://sqlalche.me/e/2j85) 2018-12-13 11:48:46.016 89597 ERROR heat.engine.resource 2018-12-13 11:48:46.030 89597 INFO heat.engine.stack [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] Stack DELETE FAILED (swarm-clustergp27-ebhsalhb4bop-swarm_primary_master-tzgkh3ncmymw): Resource DELETE failed: resources[0]: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction') (Background on this error at: http://sqlalche.me/e/2j85) 2018-12-13 11:48:46.844 89595 INFO heat.engine.resource [req-9a43184f-77d8-4fad-ab9e-2b9826c10b70 - admin - default default] DELETE: ResourceGroup "swarm_primary_master" [6984db3c-3ac1-4afc-901f-21b3e7f230a7] Stack "swarm-clustergp27-ebhsalhb4bop" [b43256fa-52e2-4613-ac15-63fd9340a8be] I read this issue was solved in heat version 10 but seems not. Regards Ignazio

5 14

Re: [heat] Bug : Heat cannot create Octavia Load Balancer
by Jeff Yang 01 Jan '19

01 Jan '19

Please confirm whether "auth_strategy" is set as ''keystone" in configure file. I remember that the value of "auth_strategy" is set as "noauth" in "/usr/share/octavia/octavia-dist.conf" default if you install octavia by rpm. If the value was set as "noauth", you must manually specify "project_id" for octavia. Jeff Yang <yjf1970231893(a)gmail.com> 于2019年1月2日周三下午12:26写道： > Please confirm whether "auth_strategy" is set as ''keystone" in > configure file. I remember that the value of "auth_strategy" is set as > "noauth" in "/usr/share/octavia/octavia-dist.conf" default if you install > octavia by rpm. If the value was set as "noauth", you must manually specify > "project_id" for octavia. > > Zane Bitter <zbitter(a)redhat.com> 于2019年1月2日周三上午11:23写道： > >> On 2/01/19 1:34 AM, Adam Harwell wrote: >> > I'm just on my phone over the holidays, but it kinda looks like the >> code >> > for this was just updated 12 days ago: >> > https://review.openstack.org/#/c/619577/ >> > >> > If you're using that new code, I imagine it's possible there could be a >> > bug that wasn't yet caught... If you're NOT using that code, maybe try >> > it and see if it helps? I'm guessing it's related one way or another. >> If >> > you come to the #openstack-lbaas channel once more people are around >> > (later this week?), we can probably take a look. >> >> That's only the example template (previously it was an example for >> LBaaSv2; now it's an example for Octavia); there's been no recent change >> to the code. >> >> > --Adam Harwell (rm_work) >> > >> > On Sun, Dec 30, 2018, 03:37 Zufar Dhiyaulhaq <zufardhiyaulhaq(a)gmail.com >> > <mailto:zufardhiyaulhaq@gmail.com>> wrote: >> > >> > I have try creating load balancer with Heat. but always get this >> error : >> > >> > Resource CREATE failed: OctaviaClientException: >> > resources.loadbalancer: Validation failure: Missing project ID in >> > request where one is required. (HTTP 400) (Request-ID: >> > req-b45208e1-a200-47f9-8aad-b130c4c12272) >> > >> > OctaviaClientException: resources.loadbalancer: Validation failure: >> > Missing project ID in request where one is required. (HTTP 400) >> > (Request-ID: req-b45208e1-a200-47f9-8aad-b130c4c12272) >> >> What version of OpenStack are you using? >> >> The issue is that Heat is sending a "tenant_id" but Octavia wants a >> "project_id", which is the new name for the same thing. (I think you >> likely modified that template after trying it but before uploading it, >> because there is no "project_id" property in Heat's >> OS::Octavia::LoadBalancer resource type.) >> >> This bug has been reported and there is a patch up for review in Heat: >> https://storyboard.openstack.org/#!/story/2004650 >> >> There was a change to Octavia in Pike >> (https://review.openstack.org/455442) to add backwards compatibility, >> but it was either incomplete or the problem reoccurred and was fixed >> again in Rocky (https://review.openstack.org/569881) My guess is that >> it's likely broken in Pike and Queens. >> >> I'd certainly have expected Heat's gate tests to pick up the problem, >> and it's a bit of a mystery why they didn't. Perhaps we're not >> exercising the case where a project_id is required (using it at all is >> an admin-only feature, so that's not too surprising I guess; it's >> actually more surprising that there's a case where it's _required_). >> >> cheers, >> Zane. >> >> > I create 2 openstack environment : >> > >> > * Heat with Octavia (Octavia Heat Template : >> > http://paste.opensuse.org/view//33592182 ) >> > * Heat with Neutron Lbaasv2 (Neutron LBaaSv2 Heat Template : >> > http://paste.opensuse.org/view//71741503) >> > >> > But always error when creating with octavia : >> > >> > * Octavia Log (https://imgur.com/a/EsuWvla) >> > * LBaaS v2 (https://imgur.com/a/BqNGRPH) >> > >> > Are Heat code is broken to create Octavia Load Balancer? >> > >> > Best Regards, >> > Zufar Dhiyaulhaq >> > >> >> >>

2 1

[heat] Bug : Heat cannot create Octavia Load Balancer
by Zufar Dhiyaulhaq 01 Jan '19

01 Jan '19

I have try creating load balancer with Heat. but always get this error : Resource CREATE failed: OctaviaClientException: resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-b45208e1-a200-47f9-8aad-b130c4c12272) OctaviaClientException: resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-b45208e1-a200-47f9-8aad-b130c4c12272) I create 2 openstack environment : - Heat with Octavia (Octavia Heat Template : http://paste.opensuse.org/view//33592182 ) - Heat with Neutron Lbaasv2 (Neutron LBaaSv2 Heat Template : http://paste.opensuse.org/view//71741503) But always error when creating with octavia : - Octavia Log (https://imgur.com/a/EsuWvla) - LBaaS v2 (https://imgur.com/a/BqNGRPH) Are Heat code is broken to create Octavia Load Balancer? Best Regards, Zufar Dhiyaulhaq

3 2

[Heat][Octavia] Is autoscaling feature missing?
by Viktor Shulhin 01 Jan '19

01 Jan '19

Hi all, I am trying to create Heat template with autoscaling and loadbalancing. I didn't find any similar Heat template examples. Individually, loadbalancing and autoscaling work well, but loadbalancing OS::Octavia::PoolMember can be added only manually. Is there any way to use OS::Heat::AutoScalingGroup as server pool for loadbalancing? Regards, Viktor.

3 2

[Cyborg] no irc meeting this week
by Li Liu 01 Jan '19

01 Jan '19

Hi Team, Since it's public holiday for folks in US and Canada, we will not have the irc meeting this week. Enjoy the new year guys :) Thank you Regards Li Liu

1 0

[dev][karbor]No meeting today
by 焦鹏举 31 Dec '18

31 Dec '18

Hi Karbor Team, We will skip karbor weekly meeting today due to holidays. Next meeting will come on 15 January. Thanks. Pengju Jiao

1 0

[chef] State of the Kitchen: 8th Edition
by Samuel Cassiba 31 Dec '18

31 Dec '18

It has been some time since the last State of the Kitchen. Since the release of Chef OpenStack 17 (Queens), we have been operating in a minimal churn mode to give people time to test/upgrade deployments and handle any regressions that emerge. There are three main areas that are still in progress upstream from Chef OpenStack, but can affect its cadence regardless. As a result, this update focuses more on those areas. Consider this more of a year-end review. ### Important Happenings * *fog-openstack*[^1] Beginning in August, we started receiving reports of breakage due to changes in fog-core. As a reactionary measure, we implemented upper-level constraints in the client resource cookbook to maintain a consistent outcome. The fog-openstack library has continued to receive changes to further align with fog-core, and we are following its progress to find a good time to move ChefDK and Chef OpenStack to a post-1.0 release of fog-openstack. We are targeting the 18th release of Chef OpenStack, due to Keystone endpoint changes that need to happen. * *Sous Chefs*[^2] One of the biggest strengths of Chef and OpenStack is the collective outcome of their unique communities. Within the Chef ecosystem, the Sous Chefs group was formed in response to a need for the continued existence of Chef components, libraries, and utilities that need a long-term home. Across the globe, Sous Chefs work to keep some of the most heavily used cookbooks in existence, such as [apache2](https://supermarket.chef.io/cookbooks/apache2), [mysql](https://supermarket.chef.io/cookbooks/mysql) (and [mariadb](https://supermarket.chef.io/cookbooks/mariadb)!), [postgresql](https://supermarket.chef.io/cookbooks/postgresql), as well as [redisio](https://supermarket.chef.io/cookbooks/redisio), and many more. Chef OpenStack depends on MariaDB, Apache, and their related cookbooks, for compatibility without operators needing to plumb those resources internally. * *poise-python*[^3] In early October, pip 18.1 was released, which made some additional waves in the ecosystem. Workarounds were devised and implemented to limit the fallout. Currently, the fix has been merged to poise-python's master, but cannot be released safely due to CI changes in the current workflow. There are limitations on what the Sous Chefs can reasonably maintain. The maintenance of poise is rather beyond that boundary, not to discount or disparage anyone involved. Anyone interested with spare cycles over the holiday season might consider joining the conversation. ### Upcoming Changes * In Chef OpenStack 18... - The MariaDB version will default to 10.3, consistent with the default in the 2.0 version of the cookbook. Please plan accordingly. - Keystone's endpoint will be changing to drop the hardcoded API version - the cloud primitives (client) cookbook is in the process of migrating from cookbook-openstackclient to cookbook-openstack-client (named openstack_client, to conform with current best practices in the Chef community) - Ubuntu will be upgraded from 16.04 to 18.04, and as such we will be gating against Bionic at that time. Plainly put, previous Chef OpenStack releases will not be moving to Bionic jobs, and will continue to work at best effort until they succumb to the detritus of time. ### Meetings Since the Summit, a few people have reached out through various means about Chef OpenStack and how to work together to improve the outcome. As a result, I would like to propose holding regular meetings for Chef OpenStack once more set aside a dedicated period where we can come together and talk about food, or other things. We have the IRC channel, but IRC has proven less effective for a small group to dedicate time consistently, so I would something more high bandwidth for technical conversations, such as video with a publicized method for joining and viewing. I will follow up with a more expanded proposal outside this update. ### On The Menu This would not be a State of the Kitchen without something to eat. My partner and I try to cook with recipes that are not overly complicated, but can be infinitely complex with just the right nudge. Sometimes we incorporate our own opinions into someone else's recipe to make it our own thing, and sometimes they're great just as they come. *Dat Dough, Doe* * 170g / 6oz grated mozzarella or Edam, or another mild cheese with similar melting consistency * 85g / 3oz almond meal/flour * 28g / 2 tbsp cream cheese or Neufchatel * 1 egg * pinch of salt to taste 1. Mix the shredded/grated cheese and the almond meal in a microwaveable bowl, then add the cream cheese. Microwave on high for 1 minute. Stir the mixture, then microwave on high for another 30 seconds. 2. Add egg, salt, additional spices or flavorings, and mix or fold gently. 3. Shape using parchment paper into the desired outcome, be it flat like a disc or rounded, like a boule. 4. Create vents to ensure that the finished product cooks evenly. 5. Fry, bake, broil or grill as desired. Lipids can be friends here. More commonly known as the "Fat Head" dough, out of these few ingredients, one can make food that can taste every bit like pizza, pasta, bread, even pão de queijo. Or, perhaps, cinnamon rolls, or danishes, as one might consider making. With these basic suggestions, one can apply their own opinions and set of requirements to create complex pieces of work, which can taste every bit like an artform and a science. See you in 2019! Your humble pastry chef, -scas [^1]: https://github.com/fog/fog-openstack/issues/434 [^2]: https://sous-chefs.org/ [^3]: https://github.com/poise/poise-python/issues/133

1 0

[Mistral]
by Deep C 30 Dec '18

30 Dec '18

Hi Team, Could anyone please help me fixing the below issue - Mistral server throws error when i execute workflows - 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier Exception: [9ad86428-59ca-4823-87ad-61915f61410d] Unable to publish event because st2 returned status code 500. { 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier "faultstring": "Internal Server Error" 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier } 2018-12-31 00:49:40.025 59372 ERROR mistral.notifiers.default_notifier Bug also raised for more details - https://bugs.launchpad.net/mistral/+bug/1808668 Please suggest the solution .

1 0

openstack magnum on queens: please help me
by Ignazio Cassano 30 Dec '18

30 Dec '18

Hello Everybody, I created a kubernetes cluster with mugnum under queens. After that I ran the folloquing commands: mkdir -p /root/clusters/kubecertslb/config export KUBECONFIG=/root/clusters/kubecertslb/config $(openstack coe cluster config kubecertslb --dir ~/clusters/kubecertslb) Then the command "kubectl -n kube-system get po" reports: NAME READY STATUS RESTARTS AGE coredns-5864cfd79d-76889 1/1 Running 0 18h heapster-68b976dd7-7vdlq 1/1 Running 0 18h kubernetes-dashboard-846b8b6844-cjp2f 1/1 Running 0 18h the command "kubectl cluster-info" reports: Kubernetes master is running at https://10.102.186.126:6443 Heapster is running at https://10.102.186.126:6443/api/v1/namespaces/kube-system/services/heapster… CoreDNS is running at https://10.102.186.126:6443/api/v1/namespaces/kube-system/services/kube-dns… To further debug and diagnose cluster problems, use 'kubectl cluster-info dump' I deployed nginx: kubectl run nginx --image=nginx --replicas=2 --port=80 Then the command "kubectl get po" reports: NAME READY STATUS RESTARTS AGE nginx-7587c6fdb6-chnw6 1/1 Running 0 18h nginx-7587c6fdb6-m7fr2 1/1 Running 0 18h Exposing nginx service with type NodePort works fine. Exposing with type LoadBalancer does not work: kubectl expose deployment nginx --target-port=80 --type=LoadBalancer kubectl get svc: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 19h nginx LoadBalancer 10.254.97.40 <pending> 80:31568/TCP 165m No load balancer is created. Im not using octavia but standard lbaas v2. Lbaas is working fine because I tried a configuration between two ssh vm. I read somting about the magnum.conf trust section: someone suggested to enable "cluster_user_trust = True" I tried it but with this parameter the kubernetes cluster does not finish: the heat template remains in pending ang goes in timeout during the master creation. I read also something aboud kubernetes cloud provider must be "external" or "openstack" but I think it should the automatically configured by heat. Any help, please ? Thanks and Regards Ignazio

1 0

[Openstack-discuss][Horizon] Domain input in the login page disappeared
by Minjun Hong 30 Dec '18

30 Dec '18

Hi. I'm replacing existing controller node with a new server. After the setup step, I found something weird. The domain input in the horizon login page disappeared as following link https://imgur.com/Vuj7uNT I'm not sure that is normal situation but, horizon login page in the previous system always consisted of Domain, User Name and Password. So, is there anyone who has experienced this problem? Thanks. Regards

1 0

Re: [openstack-discuss][Nova][Horizon] 'Too many connections' error
by Minjun Hong 30 Dec '18

30 Dec '18

Thanks for your reply, Chris. Following your advice, I adjusted the values in 'nova.conf' file. Setting max_connections in the mysql config file to 4096, the modified values are: 1. max_pool_size in [database] section to 1000 2. max_pool_size in [api_database] section to 1000 3. max_overflow in [database] section to 1000 4. max_overflow in [api_database] section to 1000 However, the problem which some services, such as Nova or Neutron, cannot connect to mysql DB occurred again. So that, I also modified the number of workers you had mentioned as follows: 1. osapi_compute_workers in [DEFAULT] section to 128 2. metadata_workers in [DEFAULT] section to 128 3. workers in [conductor] section to 128 And then, I could not use all openstack command at all. I mean, all openstack command did not work with "An unexpected error prevented the server from fulfilling your request. (HTTP 500)" error messages. After looking into some config files of the openstack services, I found out some similar parameters with the parameters you had mentioned were in the config files. For example, in neutron.conf file, max_pool_size also exists and glance-api.conf has worker parameter, either. I'm confused for what parameters should I use. Actually, I'm not sure of functions of the parameters and I need your help more. Thanks! Regards, On Sat, Dec 29, 2018 at 2:11 PM Chris Hoge <chris(a)openstack.org> wrote: > I’ve run into something similar. By default there are a few things going > on with Nova. To begin with, Nova starts up several services multiplied > by the number of cores on your system. When you add to this that Nova > doesn't by default constrain its database connection pool and it's eager > to create new database connections, you can quickly open tens of > thousands of new connections across more than a dozen processes in a > matter of minutes when starting a complete Nova control plane. > > Thankfully, this is easy to fix by setting the max_pool_size and > max_overflow parameters, as well as constraining the number of workers > for the different processes in nova.conf. > > You’ll want to tune your mysql max-connections to match your expected > volume of connections from the control plane. > > Hope that helps. > > On Dec 28, 2018, at 8:26 AM, Minjun Hong <nickeysgo(a)gmail.com> wrote: > > Hi. > I'm currently trying to substitute the existing controller node with a new > server. > After I install the 'Minimal deployment for Queens' on the new server, I > connect all nodes. > > However, when I made an instance on Horizon, there were some error > messages, as below link: > > https://imgur.com/hSfHx4M > > And, when I typed 'openstack flavor list', the result was as follows: > >> # openstack flavor list >> Unexpected API Error. Please report this at >> http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. >> <class 'sqlalchemy.exc.OperationalError'> (HTTP 500) (Request-ID: >> req-666d4e30-081a-429f-88ae-763e62990770) > > > Moreover, I found something regarding this problem in the Nova log: > > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] Unexpected exception in >> API method: OperationalError: (pymysql.err.OperationalError) (1040, u'Too >> many connections') > > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi Traceback (most >> recent call last): >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 788, in >> wrapped >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> f(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", >> line 50, in detail >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> limited_flavors = self._get_flavors(req) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", >> line 117, in _get_flavors >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> limit=limit, marker=marker) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 184, >> in wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi result = >> fn(cls, context, *args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/nova/objects/flavor.py", line 650, in >> get_all >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> marker=marker) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 985, in wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi with >> self._transaction_scope(context): >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.gen.next() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 1035, in _transaction_scope >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> context=context) as resource: >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.gen.next() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 638, in _session >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> bind=self.connection, mode=self.mode) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 403, in _create_session >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._start() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 489, in _start >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> engine_args, maker_args) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line >> 513, in _setup_for_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> sql_connection=sql_connection, **engine_kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/debtcollector/renames.py", line 45, in >> wrapper >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> f(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 184, >> in create_engine >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi test_conn >> = _test_connection(engine, max_retries, retry_interval) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 362, >> in _test_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> engine.connect() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2091, in >> connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self._connection_cls(self, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 90, in >> __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi if >> connection is not None else engine.raw_connection() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2177, in >> raw_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.pool.unique_connection, _connection) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, >> dialect, self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in >> _handle_dbapi_exception_noconnection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> util.raise_from_cause(newraise, exc_info) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in >> raise_from_cause >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> reraise(type(exception), exception, tb=exc_tb, cause=cause) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in >> unique_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionFairy._checkout(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, >> dialect, self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in >> _handle_dbapi_exception_noconnection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> util.raise_from_cause(newraise, exc_info) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in >> raise_from_cause >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> reraise(type(exception), exception, tb=exc_tb, cause=cause) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in >> _wrap_pool_connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in >> unique_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionFairy._checkout(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 766, in >> _checkout >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi fairy = >> _ConnectionRecord.checkout(pool) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 516, in checkout >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi rec = >> pool._do_get() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1138, in _do_get >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._dec_overflow() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 66, >> in __exit__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> compat.reraise(exc_type, exc_value, exc_tb) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1135, in _do_get >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self._create_connection() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 333, in >> _create_connection >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> _ConnectionRecord(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 461, in __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.__connect(first_connect_check=True) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 651, in >> __connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi connection >> = pool._invoke_creator(self) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line >> 105, in connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> dialect.connect(*cargs, **cparams) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 393, >> in connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> self.dbapi.connect(*cargs, **cparams) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/__init__.py", line 90, in Connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return >> Connection(*args, **kwargs) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 699, in >> __init__ >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self.connect() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 936, in >> connect >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> self._request_authentication() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1156, in >> _request_authentication >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> auth_packet = self._read_packet() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1018, in >> _read_packet >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> packet.check_error() >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 384, in >> check_error >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> err.raise_mysql_exception(self._data) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File >> "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 107, in >> raise_mysql_exception >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi raise >> errorclass(errno, errval) >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> OperationalError: (pymysql.err.OperationalError) (1040, u'Too many >> connections') >> 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi >> 2018-12-29 00:58:52.930 3765 INFO nova.api.openstack.wsgi >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] HTTP exception thrown: >> Unexpected API Error. Please report this at >> http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. >> <class 'sqlalchemy.exc.OperationalError'> >> 2018-12-29 00:58:52.931 3765 INFO nova.osapi_compute.wsgi.server >> [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 >> 96ad10a59d114042b8f1ee82c438649a - default default] 10.150.21.195 "GET >> /v2.1/flavors/detail HTTP/1.1" status: 500 len: 638 time: 0.1569352 > > > I already did googling with 'Too many connections' but, there were only > results about 'max_connections' of the mysql config file. > I also set the value as 4096 and I think it is enough. > > Now, I do not know what to look for to resolve this problem. > Please give me any clue. > > Thanks! > Regards, > > >

1 0

Re: Openstack-ansible and HAProxy
by zud0ku 29 Dec '18

29 Dec '18

Hi, I am having same problem. Were you able to solve the situation? Please can you share any updates? Thanks in advance. -- Sent from: http://openstack.10931.n7.nabble.com/Operators-f4774.html

1 0

[tripleo] cleaning-up old reviews
by Emilien Macchi 29 Dec '18

29 Dec '18

Like once a year, we usually clean-up old reviews in Gerrit. Per policy, I've abandoned a lot of patches that were in merge conflict, or not reviewed, or WIP or not passing CI, older than 6 months. If you want to check if one of your patches were abandoned: https://review.openstack.org/#/q/status:abandoned+owner:self Please feel free to re-open it, and let me know if any trouble. I'll also spend time on our Launchpad and also remove old bugs without any activity. Thanks, -- Emilien Macchi

1 0

[I18n] No team meeting
by Frank Kloeker 29 Dec '18

29 Dec '18

Hello, due the vacation period the I18n team will also skip the next team meetings. Our next appointment will be 2019/01/10 07:00 UTC in #openstack-meeting. Enjoy the time and a Happy New Year! Frank

3 2

[Firewall][OpenStack]
by Soheil Pourbafrani 28 Dec '18

28 Dec '18

I tried to configure the firewall for OpenStack Controller and Compute node and here are the rules I added to the firewall: myZone (active) target: default icmp-block-inversion: no interfaces: enp2s0 enp7s4 sources: services: ssh dhcpv6-client ports: 80/tcp 6080/tcp 11211/tcp 9696/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="192.168.0.32" accept rule family="ipv4" source address="192.168.0.31" accept The address of the Controller and the Compute nodes are 192.168.0.31 and 192.168.0.32, respectively. Using these rules I can use Horizon on the browser and the Compute node services can connect to the Controller nodes ports. The problem is when the firewall is enabled on the Controller node, instances that are running on the Controller node (I configure the Controller node as the Compute node, too) just can be pinged and all other VMs and nodes (including the Controller node) cannot connect to it (using SSH or any other connection to a specific port). - There is no firewall running on instances. - I configured an external network to connect VMs to each other - CentOS7 is running on all nodes Here are ports listening on the Controller node: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:8775 0.0.0.0:* LISTEN 4478/python2 tcp 0 0 0.0.0.0:9191 0.0.0.0:* LISTEN 4461/python2 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 10189/httpd tcp 0 0 0.0.0.0:8776 0.0.0.0:* LISTEN 4487/python2 tcp 0 0 0.0.0.0:25672 0.0.0.0:* LISTEN 4466/beam.smp tcp 0 0 0.0.0.0:8778 0.0.0.0:* LISTEN 10189/httpd tcp 0 0 192.168.0.31:3306 0.0.0.0:* LISTEN 4860/mysqld tcp 0 0 192.168.0.31:2379 0.0.0.0:* LISTEN 4464/etcd tcp 0 0 192.168.0.31:11211 0.0.0.0:* LISTEN 4457/memcached tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 4457/memcached tcp 0 0 192.168.0.31:5900 0.0.0.0:* LISTEN 16844/qemu-kvm tcp 0 0 0.0.0.0:9292 0.0.0.0:* LISTEN 4500/python2 tcp 0 0 192.168.0.31:2380 0.0.0.0:* LISTEN 4464/etcd tcp 0 0 192.168.0.31:5901 0.0.0.0:* LISTEN 16982/qemu-kvm tcp 0 0 192.168.0.31:5902 0.0.0.0:* LISTEN 17339/qemu-kvm tcp 0 0 192.168.0.31:5903 0.0.0.0:* LISTEN 17621/qemu-kvm tcp 0 0 192.168.0.31:5904 0.0.0.0:* LISTEN 17840/qemu-kvm tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 10189/httpd tcp 0 0 0.0.0.0:4369 0.0.0.0:* LISTEN 1/systemd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4468/sshd tcp 0 0 192.168.0.31:3260 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:6080 0.0.0.0:* LISTEN 4458/python2 tcp 0 0 0.0.0.0:9696 0.0.0.0:* LISTEN 4473/python2 tcp 0 0 0.0.0.0:8774 0.0.0.0:* LISTEN 4478/python2 tcp6 0 0 :::5672 :::* LISTEN 4466/beam.smp tcp6 0 0 :::22 :::* LISTEN 4468/sshd So, is there any port or something to add to firewall rules for making instances reachable when the firewall is running on the Controller node?

1 0

openstack magnum kubernetes load balancer
by Ignazio Cassano 28 Dec '18

28 Dec '18

Hello All, I created a kuberneted cluster with magnum. Than I would like to create a load balancer for nginx: kubectl run nginx --image=nginx --replicas=2 --port=80 kubectl expose deployment nginx --target-port=80 --type=LoadBalancer But kubectl get service gives: kubernetes ClusterIP 10.254.0.1 <none> 443/TCP 152m nginx LoadBalancer 10.254.161.102 <pending> 80:30648/TCP 2m58s If I use NodePort instead of LoadBalancer it works. Does kubernetes requires octavia ? I am using loadbalance v2 without octavia. Regards Ignazio

1 0

[openstack-discuss][Nova][Horizon] 'Too many connections' error
by Minjun Hong 28 Dec '18

28 Dec '18

Hi. I'm currently trying to substitute the existing controller node with a new server. After I install the 'Minimal deployment for Queens' on the new server, I connect all nodes. However, when I made an instance on Horizon, there were some error messages, as below link: https://imgur.com/hSfHx4M And, when I typed 'openstack flavor list', the result was as follows: > # openstack flavor list > Unexpected API Error. Please report this at > http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. > <class 'sqlalchemy.exc.OperationalError'> (HTTP 500) (Request-ID: > req-666d4e30-081a-429f-88ae-763e62990770) Moreover, I found something regarding this problem in the Nova log: 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] Unexpected exception in > API method: OperationalError: (pymysql.err.OperationalError) (1040, u'Too > many connections') 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi Traceback (most > recent call last): > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py", line 788, in > wrapped > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > f(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", > line 50, in detail > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > limited_flavors = self._get_flavors(req) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/flavors.py", > line 117, in _get_flavors > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > limit=limit, marker=marker) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 184, > in wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi result = > fn(cls, context, *args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/nova/objects/flavor.py", line 650, in > get_all > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > marker=marker) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 985, in wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi with > self._transaction_scope(context): > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.gen.next() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 1035, in _transaction_scope > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > context=context) as resource: > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.gen.next() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 638, in _session > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > bind=self.connection, mode=self.mode) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 403, in _create_session > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._start() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 489, in _start > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > engine_args, maker_args) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/enginefacade.py", line > 513, in _setup_for_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > sql_connection=sql_connection, **engine_kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/debtcollector/renames.py", line 45, in > wrapper > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > f(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 184, > in create_engine > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi test_conn = > _test_connection(engine, max_retries, retry_interval) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py", line 362, > in _test_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > engine.connect() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2091, in > connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self._connection_cls(self, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 90, in > __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi if > connection is not None else engine.raw_connection() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2177, in > raw_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.pool.unique_connection, _connection) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, dialect, > self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in > _handle_dbapi_exception_noconnection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > util.raise_from_cause(newraise, exc_info) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in > raise_from_cause > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > reraise(type(exception), exception, tb=exc_tb, cause=cause) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in > unique_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionFairy._checkout(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2151, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi e, dialect, > self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1461, in > _handle_dbapi_exception_noconnection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > util.raise_from_cause(newraise, exc_info) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 203, in > raise_from_cause > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > reraise(type(exception), exception, tb=exc_tb, cause=cause) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 2147, in > _wrap_pool_connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return fn() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 328, in > unique_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionFairy._checkout(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 766, in > _checkout > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi fairy = > _ConnectionRecord.checkout(pool) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 516, in checkout > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi rec = > pool._do_get() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1138, in _do_get > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._dec_overflow() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 66, > in __exit__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > compat.reraise(exc_type, exc_value, exc_tb) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 1135, in _do_get > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self._create_connection() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 333, in > _create_connection > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > _ConnectionRecord(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 461, in __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.__connect(first_connect_check=True) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/pool.py", line 651, in > __connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi connection > = pool._invoke_creator(self) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/strategies.py", line > 105, in connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > dialect.connect(*cargs, **cparams) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 393, > in connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > self.dbapi.connect(*cargs, **cparams) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/__init__.py", line 90, in Connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi return > Connection(*args, **kwargs) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 699, in > __init__ > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self.connect() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 936, in > connect > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > self._request_authentication() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1156, in > _request_authentication > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi auth_packet > = self._read_packet() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1018, in > _read_packet > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > packet.check_error() > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 384, in > check_error > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > err.raise_mysql_exception(self._data) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi File > "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 107, in > raise_mysql_exception > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi raise > errorclass(errno, errval) > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > OperationalError: (pymysql.err.OperationalError) (1040, u'Too many > connections') > 2018-12-29 00:58:52.928 3765 ERROR nova.api.openstack.wsgi > 2018-12-29 00:58:52.930 3765 INFO nova.api.openstack.wsgi > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] HTTP exception thrown: > Unexpected API Error. Please report this at > http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. > <class 'sqlalchemy.exc.OperationalError'> > 2018-12-29 00:58:52.931 3765 INFO nova.osapi_compute.wsgi.server > [req-666d4e30-081a-429f-88ae-763e62990770 bb1e571e4d64462bac80654b153a88c3 > 96ad10a59d114042b8f1ee82c438649a - default default] 10.150.21.195 "GET > /v2.1/flavors/detail HTTP/1.1" status: 500 len: 638 time: 0.1569352 I already did googling with 'Too many connections' but, there were only results about 'max_connections' of the mysql config file. I also set the value as 4096 and I think it is enough. Now, I do not know what to look for to resolve this problem. Please give me any clue. Thanks! Regards,

1 0

[tripleo] removing MongoDB
by Emilien Macchi 28 Dec '18

28 Dec '18

Hi, MongoDB hasn't been used anywhere and it's even unsupported in TripleO since Pike. I think it's time to clean it up, therefore I propose we remove it from TripleO: https://review.openstack.org/#/q/topic:tripleo/rm/mongodb+(status:open+OR+s… Feedback is welcome, Thanks -- Emilien Macchi

1 0

[Cyborg] Nominating Coco Gao for Cyborg Core Reviewer
by Zhipeng Huang 28 Dec '18

28 Dec '18

Hi folks, Coco has been participating in Cyborg project from Rocky design discussion and has been driving the DB refactoring work ever since. I would like to nominate her as a new core reviewer of the team to recognize her contribution as well as increase the bandwidth of cyborg core team. If you have any concerns by replying to this email thread within a week. Thank you very much ! -- Zhipeng (Howard) Huang Principle Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhipeng(a)huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen

1 0

[Cyborg] Nominating Yumeng Bao for Cyborg Core Reviewer
by Li Liu 27 Dec '18

27 Dec '18

Hi Team, Yumeng Bao has high-quality reviews in the last couple of cycles so I would like to nominate her for Cyborg core Please respond with your +1 or -1 votes. We'll hold voting open for 7 days -- Thank you Regards Li

1 0

[openstack_FWaaS]
by Rania Adouni 27 Dec '18

27 Dec '18

hi, I am looking for instruction to set up FWaaS for openstack queens with multiple node (controller node and network node )!! i did try this : https://docs.openstack.org/neutron/queens/admin/fwaas-v1-scenario.html but nothing was working !! anu help please Best Regards, Rania Adouni

1 0

[Cyborg] Nominating Yumeng Bao for Cyborg Core Reviewer
by Li Liu 27 Dec '18

27 Dec '18

Hi Team, Yumeng Bao has high-quality reviews in the last couple of cycles so I would like to nominate her for Cyborg core Please respond with your +1 or -1 votes. We'll hold voting open for 7 days Thank you Regards Li Liu

1 0

[openstack-dev][sahara] No meeting today
by Telles Nobrega 27 Dec '18

27 Dec '18

Hi Saharans, We won't be having meeting today, we get back next week. Thanks all, -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil <https://www.redhat.com/> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo tenobreg(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil pelo Great Place to Work.

1 0

[openstack-dev] [Neutron] Propose Ryan Tidwell for neutron-dynamic-routing core
by Miguel Lavalle 26 Dec '18

26 Dec '18

Hi Stackers, I want to nominate Ryan Tidwell (irc: tidwellr) as a core reviewer for neutron-dynamic-routing ( https://github.com/openstack/neutron-dynamic-routing) Ryan has a long history with everything L3 in Neutron. He started contributing code back in 2014, helping to implement subnet pools ( https://review.openstack.org/#/c/148698/) Over the years he did great work improving Neutron's IP address manager and was the driving force in the creation and implementation of the neutron-dynamic-routing project. After a hiatus of a few cycles, Ryan came back to the community and has been very active adding support for MP-BGP in neutron-dynamic-routing and the on boarding of subnets in Neutron. The quality and number of his code reviews during the Stein cycle are on par with members of the Neutron core team: http://stackalytics.com/?module=neutron-group. I will keep this nomination open as customary. Thank you. Miguel

7 7

[magnum][octavia] Error provisioning multi master cluster with magnum.
by Zufar Dhiyaulhaq 26 Dec '18

26 Dec '18

Hello, I am success create a single master cluster (docker or kubernetes) using magnum. but always fail when creating magnum. all the log is point into Octavia error. I have tested the Octavia and its working. this is error I get from the stack debug. OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) the full log : *[root@controller3 ~]# openstack stack resource list kubernetes-cluster-multi-maste-txdrmrikn3a4+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+| resource_name | physical_resource_id | resource_type | resource_status | updated_time |+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+| etcd_lb | 7aa39847-3602-4673-973e-26fc12974bb9 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/lb.yaml | CREATE_FAILED | 2018-12-22T20:17:00Z || kube_masters | | OS::Heat::ResourceGroup | INIT_COMPLETE | 2018-12-22T20:17:00Z || network | e8eb37ec-bde3-4f26-b337-7c5fad937212 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/network.yaml | CREATE_COMPLETE | 2018-12-22T20:17:00Z || api_lb | bc59c786-9126-4d97-9edc-ee2127acc8e3 | file:///usr/lib/python2.7/site-packages/magnum/drivers/common/templates/lb.yaml | CREATE_FAILED | 2018-12-22T20:17:00Z || secgroup_kube_minion | 72278f6b-039d-402a-b4df-77d5c8c64a0b | OS::Neutron::SecurityGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || nodes_server_group | 1cf676b0-d09c-44a7-8f4f-7c6e7363390e | OS::Nova::ServerGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || secgroup_kube_master | 1e96573d-0972-4f05-8876-6bbb83246cb8 | OS::Neutron::SecurityGroup | CREATE_COMPLETE | 2018-12-22T20:17:00Z || kube_minions | | OS::Heat::ResourceGroup | INIT_COMPLETE | 2018-12-22T20:17:00Z || api_address_floating_switch | | Magnum::FloatingIPAddressSwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z || api_address_lb_switch | | Magnum::ApiGatewaySwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z || etcd_address_lb_switch | | Magnum::ApiGatewaySwitcher | INIT_COMPLETE | 2018-12-22T20:17:00Z |+-----------------------------+--------------------------------------+--------------------------------------------------------------------------------------+-----------------+----------------------+[root@controller3 ~]# openstack stack resource show kubernetes-cluster-multi-maste-txdrmrikn3a4 etcd_lb| resource_status_reason | OctaviaClientException: resources.etcd_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-4bd9b688-8309-4a51-b6c7-4a617b49fa45) |[root@controller3 ~]# openstack stack resource show kubernetes-cluster-multi-maste-txdrmrikn3a4 api_lb | resource_status_reason | OctaviaClientException: resources.api_lb.resources.loadbalancer: Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-d3bd4431-4b77-45de-b0ce-44b0e3e97618) |* anyone know what is happen? Best Regards, Zufar Dhiyaulhaq

1 0

[Searchlight] Next meeting cancelled
by Trinh Nguyen 26 Dec '18

26 Dec '18

Hi team, Next week I'm on vacation so we will have to cancel the meeting on 31st December. See you next year :) P/S: I'll be at the VietOpenInfra meetup in Ho Chi Minh city this Saturday :) -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[kolla] Today and next week meeting cancelled
by Eduardo Gonzalez 26 Dec '18

26 Dec '18

Dear Kolla Team, Because Christmas holidays many people could not attend the Kolla weekly meeting, we will cancel today (26th December) and next meeting (2nd January). We will resume the weekly meetings on 9th January. Have a nice Christmas Best regards

1 0

[dev] [horizon] No meetings until January, 9th
by Ivan Kolodyazhny 25 Dec '18

25 Dec '18

Hi all, We agreed to skip the next two meetings due to the Christmas and New Year holidays at the last meeting [1]. Enjoy the holidays! [1] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-12-19-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[openstack-discuss][Glance]BP to trace change to store context in request.environ[‘glance.context’]
by Leehom Li (feli5) 25 Dec '18

25 Dec '18

Hi, I encountered an error when enable audit for glance. And a bug is fired to fix the conflict in keystone middleware project. https://bugs.launchpad.net/keystonemiddleware/+bug/1809101 Brief about the bug is both keystone audit middleware and glance are using req.context. They are conflict with each other. I upload a patch to fix this issue for keystone audit middleware. But I think it would be nice to have glance consist with other OpenStack component like nova to store context in request.environ[‘glance.context’]. I checked the code of glance, use of req.context spread cross entire API level code, so I think it would be better to have a BP to trace about the change. Needs your kind advice. Best regards, Leehom Li feli5(a)cisco.com Phone: +86 512 8777 4186

2 1

[security] No meeting Dec 27th & Jan 3rd
by Gage Hugo 25 Dec '18

25 Dec '18

The Security SIG meetings for this week and next week are canceled. We will meet again on Jan 10th. Enjoy the holidays!

1 0

[vitrage] No IRC meeting tomorrow
by Ifat Afek 25 Dec '18

25 Dec '18

Hi, We will skip the IRC meeting this week. We will meet again next Wednesday, January 2nd. Thanks, Ifat

1 0

[self-healing-sig][vitrage][monasca] Vitrage and Monasca integration
by Ifat Afek 25 Dec '18

25 Dec '18

Hi, In the last self-healing SIG meeting, we discussed the integration of Monasca and Vitrage [1]. We talked about the challenge of identifying the resource in Vitrage based on Monasca metric dimensions. As we discussed [2], I wrote an initial spec for mapping the different use cases [3]. I’ll be happy to get your feedback - at this stage our main interest is to collect more use cases and concrete examples. Thanks, Ifat [1] https://review.openstack.org/#/c/622899/ [2] http://eavesdrop.openstack.org/meetings/self_healing/2018/self_healing.2018… [3] https://review.openstack.org/#/c/627180

1 0

[mistral] Let’s meet in IRC after Jan 8
by Renat Akhmerov 25 Dec '18

25 Dec '18

Hi, I guess there won’t be many working people till Jan 9 (Christmas & NY holidays) so I’m hereby calling Mistral contributors to meet after the holidays and discuss the project course and priorities for the next few months. We can do it during one of our allocated office hours slots. Will decide later when exactly. Thanks Renat Akhmerov @Nokia

1 0

[Tacker] No IRC meetings taday and next week.
by Dharmendra Kushwaha 25 Dec '18

25 Dec '18

Dear Folks, Due to the holiday season, we will not have IRC meetings today and the next week. The next meeting will be held on Jan 8th 2019. Good wishes for X-mas & new year. Enjoy holidays. Thanks & Regards Dharmendra Kushwaha

1 0

[heat] No IRC meeting until Jan. 9th
by Rico Lin 24 Dec '18

24 Dec '18

Dear all, these two weeks are Christmas and new year. We will resume our meeting on Jan. 9th, 2019 So I wish you all a merry Christmas and happy new year. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[cyborg] No IRC meetings for until the week of Jan 7th 2019
by Li Liu 24 Dec '18

24 Dec '18

Hi Team, Due to the holiday season, we will not have irc meetings for this week and the week after. The next meeting will be held on Jan 8th 2019 Enjoy the holidays and happy new year. -- Thank you Regards Li

1 0

The design choice of keystone sso
by guoyongxhzhf＠163.com 23 Dec '18

23 Dec '18

The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service.

2 1

[keystone] The design choice of keystone sso
by guoyongxhzhf＠163.com 23 Dec '18

23 Dec '18

The problem is about keystone with sso The situation: 1. the cloud based on OpenStack has use keystone to build its own user account system, and no third user account like ldap or google accounts 2. the cloud may have multi web application/entrance and have multi domain name, so we need sso So there are two choice to implement sso 1. use CAS or other open source components as sso service and use database authentication which query keystone database.(I think it's odd) 2. use cookies(including keystone token) between multi web application/entrance which is the better choice? I think if we use only users from keystone, it's not necessary to use an extra sso service.

1 0

[neutron] Subnet onboard and changing API definitions in neutron-lib
by Ryan Tidwell 23 Dec '18

23 Dec '18

All, I alluded to some concerns about the current state of subnet onboard at the end of today's neutron team meeting. I felt the mailing list was probably the best starting point for a discussion, so here it goes :) As I'm dealing with the last loose ends, I'm starting to deal with the 'subnets' extension to the subnetpool resource on the API [1]. This has me scratching my head at what the intent of this is since there isn't much history to work with. When I look at the definition of the subnet onboard extension in neutron-lib, I can see two possible "meanings" of POST/PUT here: 1. Create a subnet from this subnetpool using the default prefix length of the subnet pool. 2. Onboard the given subnet into the subnet pool. In addition to this ambiguity around the usage of the API, I also have concerns that ONBOARD_SUBNET_SPECS as currently defined makes no sense for either case. ONBOARD_SUBNET_SPECS requires that an id, network_id, and ip_version be sent on any request made. This seems unnecessary for both cases. Case 1 where we assume that we are using an alternate API to create a subnet is problematic in the following ways: - Specifying an ip_version is unnecessary because it can be inferred from the subnet pool - The definition as written doesn't seem to allow us to respond to the user with anything other than a UUID. The user then has to make a second call to actually go read the details like CIDR that are going to be useful for them going forward. - More importantly, we already have an API (and corresponding CLI) for creating subnets that works well and has much more flexibility than this provides. Why duplicate functionality here? Case 2 where we assume that we are onboarding a subnet is problematic in the following ways: - Specifying network_id and ip_version are unnecessary. These values can be read right off the subnet (which we would need to read for onboarding anyway), all that needs to be passed is the subnet UUID. - Again, we would be duplicating functionality here because we have already defined an API for onboarding a subnet in the ACTION_MAP [2] My intent is to figure out where to go from here to make this better and/or alleviate the confusion on my part so this feature can be wrapped up. Here is what I propose: Because subnet onboard is still incomplete and we are not claiming support for it yet, I am proposing we simply remove the 'subnets' extension to the subnetpools resource [3]. This simplifies the API and resolves the concerns I expressed above. It also allows us to quickly finish up subnet onboard without losing any of the desired functionality, namely the ability to move ("onboard") an existing subnet into a subnet pool (and by extension and address scope). The reason I am looking for input here is that it isn't clear to me whether the approach I'm suggesting is acceptable to the team given our policies around changing API definitions in neutron-lib. I'm not aware of a situation where we have had an unreleased feature and have discovered we don't like the API definition in neutron-lib (which has sat for quite a while unimplemented) and want to change it. I'm just not aware of any precedent for this situation, so I'm hoping the team has some thoughts on how best to move forward. For reference, the current review for subnet onboard is https://review.openstack.org/#/c/348080/. Any thoughts on this topic would be greatly appreciated by me, and hopefully this discussion can be useful to a broad audience going forward. -Ryan [1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini… [2] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini… [3] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/defini…

4 3

Re: [infra][storyboard] Project Update/Some New Things
by Jeremy Stanley 23 Dec '18

23 Dec '18

On 2018-09-10 14:34:49 +0000 (+0000), Jeremy Stanley wrote: > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] > > # Finding stories from a task ID > > > > It is now possible to navigate to a story given just a task ID, > > if for whatever reason that's all the information you have > > available. A link like > > > > https://storyboard.openstack.org/#!/task/12389 > > > > will work. This will redirect to the story containing the task, > > and is the first part of work to support linking directly to an > > individual task in a story. > [...] > > As an aside, I think this makes it possible now for us to start > hyperlinking Task footers in commit messages within the Gerrit > change view. I'll try and figure out what we need to adjust in our > Gerrit commentlink and its-storyboard plugin configs to make that > happen. As of Friday (2018-12-21) our Gerrit instance at https://review.openstack.org/ has started hyperlinking task footers in commit messages, leveraging the above feature (the configuration change for it merged months ago but Gerrit has been so stable lately we've not gotten around to restarting it for that to take effect until now). At this point you can omit the story footer if you have a task footer, since all the story footer has been providing is a hyperlink anyway. -- Jeremy Stanley

1 0