December 2019 - openstack-discuss

[magnum][stein] error
by Ignazio Cassano 02 Dec '19

02 Dec '19

Hello, I've juste installed magnum on centos 7 stein, when magnu-api starts it does not log under /var/log/magnum but under /var/log/messages and it reports the following error: magnum-api: error: [Errno 32] Broken pipe Please , help me on this thread. Regards Ignazio

1 0

[charms] IRC meetings and the holiday season
by Frode Nordahl 02 Dec '19

02 Dec '19

Hello all, We are entering the holiday season, and as such we will stop our IRC meeting activity until we enter the next year. The next meeting will be held Monday January 13th 2020. I want to use this opportunity to say thank you to all activity and contributions to the charms project this year, and I look forward to what the next year might bring. Cheers! -- Frode Nordahl

1 0

[all] Nominations for the "V" release name
by Sean McGinnis 02 Dec '19

02 Dec '19

Hey everyone, There is ongoing discussion about changing our release naming process, but for the time being we are going to stick with what we have been doing. That means it's time to start thinking about the "V" release name! The next developer event will take place in Vancouver, BC. The geographic location for this release will be things starting with "V" in the British Columbia province. The nomination period is now open. Please add suitable names to https://wiki.openstack.org/wiki/Release_Naming/V_Proposals. We will accept nominations until December 6, 2019 23:59:59 UTC. A recap of our current naming rules: * Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again. * The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable. * The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process. * The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo". Names which do not meet these criteria but otherwise sound really cool should be added to a separate section of the wiki page and the TC may make an exception for one or more of them to be considered in the Condorcet poll. The naming official is responsible for presenting the list of exceptional names for consideration to the TC before the poll opens. Additional information about the release naming process can be found here: https://governance.openstack.org/tc/reference/release-naming.html Looking forward to having a name for our next release! Sean

4 7

[neutron] Including networking-ovn-core team into neutron-core
by Slawek Kaplonski 02 Dec '19

02 Dec '19

Hi neutrinos, We recently merged spec [1] and now we are starting to moving networking-ovn code to be in neutron tree. Blueprint to track progress of this is on [2]. As a consequence of this merge of code, I think that we need to also include networking-ovn-core team into neutron-core to give people who are cores on networking-ovn today ability to merge ovn related patches in neutron after this migration will be done. Of course current networking-ovn cores should only approve patches related to ovn driver, and not approve patches related to different areas of neutron code. So if there will be no objections for that until the end of this week, I will include networking-ovn-core group in neutron-core. [1] https://review.opendev.org/#/c/658414/ [2] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge — Slawek Kaplonski Senior software engineer Red Hat

2 2

[blazar] IRC meetings cancelled this week
by Pierre Riteau 02 Dec '19

02 Dec '19

Hello, Due to travel, both Blazar IRC meetings are cancelled this week. Cheers, Pierre

1 0

[neutron] DNS resolution delay after VM launch
by Eric K. Miller 02 Dec '19

02 Dec '19

Hi, I'm trying to resolve an issue that happens about 30% of the time. DVR is being used in this environment. The environment is deployed with Kolla Ansible on CentOS 7 using Stein (the latest Kolla Ansible installer). Physical servers have the latest CentOS 7 patches through November 30th, 2019. This seems to happen on new and existing projects, including newly created subnets, and, so far, it seems to be only related to VM launches. Delaying the time between a subnet creation and the VM launch makes no difference in the behavior. When the problem occurs, after a VM is launched, it takes a longer-than-normal time to boot. This would usually indicate a DNS issue or possible a DHCP issue. After the OS boots (after 60 seconds or so), I can login, but with a delayed login (another 20 seconds or so) due to the DNS issue I'm diagnosing. DHCP works fine - no issues with IP assignment, and the /etc/resolv.conf entries are set to the routers' two private IPs. No DHCP errors in the dmesg output. I can connect to both respective qdhcp network namespaces where dnsmasq is running for the two distributed routers, immediately after the subnet is created (in our test case, it is 192.168.99.0/24), and can resolve names using "nslookup <name> 192.168.99.1" and "nslookup <name> 192.168.99.2" instantly. So, dnsmasq is working properly. A floating IP is assigned to this VM, which is used for the following SSH sessions. After SSH'ing to the VM, I can ping the 192.168.99.1 and 192.168.99.2 addresses, so it does not appear to be a network issue (ICMP works), unless there is a firewall rule either in iptables or OVS that is blocking UDP/TCP port 53 for DNS requests, which would be odd, since the egress security group assigned to this VM is unrestricted. I can also ping external IPs from the VM (Internet-accessible IPs), so the routers are working. I can also perform nslookups against external DNS servers without issue, such as "nslookup <name> 1.1.1.1". If I direct nslookup to the internal DNS servers using "nslookup <name> 192.168.99.1", the lookup times out. We normally use CentOS images, but I tried an Ubuntu 19.04 image and the same problem occurs often. Now, what is ODD - the problem goes away after about 3 minutes! DNS lookups against the internal DNS servers (the router IPs) start working perfectly. So something is taking a while to get configured, but only about 30% of the time. If, during the creation of the subnet, we specify --dns-nameserver options, such as: --dns-nameserver 1.1.1.1 the issue NEVER occurs. So it seems to be limited to DNS traffic between the VM and the dnsmasq service in the qdhcp namespace. All traffic in this environment is switched (we are not routing VXLAN traffic, for example), so there can be no physical network interference at Layers 3 or higher. The problem has also occurred on multiple hosts in the environment (the VM has been launched on various hosts with the same issue). Any ideas how to diagnose this? I'm assuming it has something to do with the iptables or OVS configuration, but if someone knows specifically what could cause this, such as a specific rule that is supposed to be created for DNS traffic to the internal routers, I could dive into the these configurations. Eric

1 0

[Usage][Designate] Salve Bind servers
by Steven Relf 02 Dec '19

02 Dec '19

Hi list.... I'm looking at making use of Designate, and have so farmanaged to get designate configured and working against a single bind9 server. The issue I'm having, and this could be due to notunderstanding bind config well, is how do I configure other bind servers to beslaves of the server used by designate. I keep running into an issue where theslave doesn’t want to do a transfer and errors with "received notify forzone 'domain': not authoritative" I'm assuming this has something to do with the slave notknowing about the zone. So the question, do I have to have all my bind servershooked upto designate, and managed with a mdns service, or am I missingsomething obvious. Rgds Steve. The future has already arrived. It's just not evenlydistributed yet - William Gibson

2 1

[Magnum] Virtual PTG planning
by Feilong Wang 01 Dec '19

01 Dec '19

Hi team, As we discussed on last weekly team meeting, we'd like to have a virtual PTG before the Xmas holiday to plan our work for the U release. The general idea is extending our current weekly meeting time from 1 hour to 2 hours and having 2 sessions with total 4 hours. My current proposal is as below, please reply if you have question or comments. Thanks. Pre discussion/Ideas collection: 20th Nov 9:00AM-10:00AM UTC 1st Session: 27th Nov 9:00AM-11:00AM UTC 2nd Session: 4th Dec 9:00AM-11:00AM UTC -- Cheers & Best regards, Feilong Wang (王飞龙) Head of R&D Catalyst Cloud - Cloud Native New Zealand -------------------------------------------------------------------------- Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

3 4

Openstack - Rocky Install
by doug schmidt 01 Dec '19

01 Dec '19

Hi, I'm having an issue with httpd not starting on my install. I have installed rocky on a windows 10 laptop with virtualbox and centos 7 guests. So far I have 2 controllers and 3 compute nodes. I have followed the install docs for rocky. https://docs.openstack.org/install-guide/openstack-services.html#minimal-de… Minimal services have been installed and configured.keystone, glance, nova, neutron are configured and running. I followed the install for horizon dashboard, and that is where I'm getting httpd.service failing. I have gone over the configuration a few times, but I can not find what the issue is. Any ideas of where to look or what to fix? Thanks for any help with this ------------------------ [root@openstack-cntr1 ~]# systemctl | egrep -i 'openstack|neutron|httpd' ● httpd.service loaded failed failed The Apache HTTP Server neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent neutron-linuxbridge-agent.service loaded active running OpenStack Neutron Linux Bridge Agent neutron-metadata-agent.service loaded active running OpenStack Neutron Metadata Agent neutron-server.service loaded active running OpenStack Neutron Server openstack-glance-api.service loaded active running OpenStack Image Service (code-named Glance) API server openstack-glance-registry.service loaded active running OpenStack Image Service (code-named Glance) Registry server openstack-nova-api.service loaded active running OpenStack Nova API Server openstack-nova-conductor.service loaded active running OpenStack Nova Conductor Server openstack-nova-consoleauth.service loaded active running OpenStack Nova VNC console auth Server openstack-nova-novncproxy.service loaded active running OpenStack Nova NoVNC Proxy Server openstack-nova-scheduler.service loaded active running OpenStack Nova Scheduler Server [root@openstack-cntr1 ~]# systemctl start httpd.service Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details. [root@openstack-cntr1 ~]# systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/httpd.service.d └─openstack-dashboard.conf Active: failed (Result: exit-code) since Sat 2019-11-30 09:45:46 EST; 15s ago Docs: man:httpd(8) man:apachectl(8) Process: 12855 ExecStartPre=/usr/bin/python /usr/share/openstack-dashboard/manage.py collectstatic --noinput --clear -v0 (code=exited, status=1/FAILURE) Nov 30 09:45:46 openstack-cntr1 python[12855]: File "/usr/share/openstack-dashboard/openstack_dashboard/settings.py", line 376, in <module> Nov 30 09:45:46 openstack-cntr1 python[12855]: from local.local_settings import * # noqa: F403,H303 Nov 30 09:45:46 openstack-cntr1 python[12855]: File "/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py", line 399 Nov 30 09:45:46 openstack-cntr1 python[12855]: 'supported_vnic_types': ['*'], Nov 30 09:45:46 openstack-cntr1 python[12855]: ^ Nov 30 09:45:46 openstack-cntr1 python[12855]: IndentationError: unexpected indent Nov 30 09:45:46 openstack-cntr1 systemd[1]: httpd.service: control process exited, code=exited status=1 Nov 30 09:45:46 openstack-cntr1 systemd[1]: Failed to start The Apache HTTP Server. Nov 30 09:45:46 openstack-cntr1 systemd[1]: Unit httpd.service entered failed state. Nov 30 09:45:46 openstack-cntr1 systemd[1]: httpd.service failed. [root@openstack-cntr1 ~]#

3 2