- openstack-discuss - lists.openstack.org

Rally verify issue
by shokoofa Hosseini 05 Feb '19

05 Feb '19

Dear Sir / Madam, I recently install Rally version: 1.3.0 with Installed Plugins: rally-openstack :1.3.0 by python 34. on centos 7 It work property. I benchmark my openstack environment correctly with scenarios of rally. But I have some issue with rally verification create, according to the link bellow: https://docs.openstack.org/developer/rally/quick_start/tutorial/step_10_ver… I run the command: " rally verify create-verifier --type tempest --name tempest-verifier " but I get the bellow error message: "TypeError: startswith first arg must be bytes or a tuple of bytes, not str" What should I do? I will appreciate if you could help me your sincerely shokoofa Attachments area

1 0

OpenStack code and GPL libraries
by Ilya Shakhat 05 Feb '19

05 Feb '19

Hi, I am experimenting with automatic verification of code licenses of OpenStack projects and see that one of Rally dependencies has GPL3 license [1]. I'm not a big expert in licenses, but isn't it a violation of GPL? In particular what concerns me is: [2] - " If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL) Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. " and [3] - " This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0. We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. " [1] http://paste.openstack.org/show/744483/ [2] https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL [3] https://www.apache.org/licenses/GPL-compatibility.html Should this issue be fixed? If yes, should we have a gate job to block adding of such dependencies? Thanks, Ilya

4 4

[tripleo][openstack-ansible] collaboration on os_tempest role update IX - Feb 05, 2019
by Chandan kumar 04 Feb '19

04 Feb '19

Hello, Here is the 9 th update (Jan 29 to Feb 05, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: It was a great week, * we unblocked the os_tempest centos gate failure thanks to slaweq (neutron) and jrosser (OSA) to fixing the tempest container vlan issue. * TripleO is now using os_tempest for standalone job and os_tempest is also getted with the same job: -> http://zuul.openstack.org/builds?job_name=tripleo-ci-centos-7-standalone-os… * Few other improvements: * generate stackviz irrespective of tempest tests failure * Port security is now enabled in tempest.conf * Cirros Image got updated from 3.5 to 3.6 * Use tempest run command with --test-list option Things got merged: os_tempest: * Update all plugin urls to use https rather than git - https://review.openstack.org/625670 * Add an ip address to eth12 in OSA test containers - https://review.openstack.org/633732 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 * Enable port security - https://review.openstack.org/617719 * Use tempest_cloud_name in tempestconf - https://review.openstack.org/631708 * Always generate stackviz irrespective of tests pass or fail - https://review.openstack.org/631967 * Update cirros from 3.5 to 3.6 - https://review.openstack.org/633208 * Disable nova-lxd tempest plugin - https://review.openstack.org/633711 * Only init a workspace if doesn't exists - https://review.openstack.org/633549 * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/633931 Tripleo: * Enable standalone-full on validate-tempest role - https://review.openstack.org/634644 Things IN-Progress: os_tempest: * Ping router once it is created - https://review.openstack.org/633883 * Improve overview subpage - https://review.openstack.org/633934 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Use the correct heat tests - https://review.openstack.org/630695 Tripleo: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Goal of this week: * Finish ongoing patches and reusing of skip list in TripleO from validate-tempest which will allow to move standalone scenario jobs to os_tempest Here is the 8th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002151.… Thanks, Chandan Kumar

1 0

[ironic] [thirdparty-ci] BaremetalBasicOps test
by Michael Turek 04 Feb '19

04 Feb '19

Hello all, Our ironic job has been broken and it seems to be due to a lack of IPs. We allocate two IPs to our job, one for the dhcp server, and one for the target node. This had been working for as long as the job has existed but recently (since about early December 2018), we've been broken. The job is able to clean the node during devstack, successfully deploy to the node during the tempest run, and is successfully validated via ssh. The node then moves to clean failed with a network error [1], and the job subsequently fails. Sometime between the validation and attempting to clean, the neutron port associated with the ironic port is deleted and a new port comes into existence. Where I'm having trouble is finding out what this port is. Based on it's MAC address It's a virtual port, and its MAC is not the same as the ironic port. We could add an IP to the job to fix it, but I'd rather not do that needlessly. Any insight or advice would be appreciated here! Thanks, Mike Turek <mjturek> [1] http://paste.openstack.org/show/743191/

3 3

[neutron] CI meeting this week cancelled
by Slawomir Kaplonski 04 Feb '19

04 Feb '19

Hi, I’m traveling this week and I will not be able to run Neutron CI meeting on Tuesday, 5.02. As some other people usually involved in this meeting are also traveling, lets skip it this week. We will have next meeting as usual on Tuesday, 12.02.2019. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[cinder] Proposed mid-cycle schedule available
by Jay Bryant 04 Feb '19

04 Feb '19

All, I have put together a proposed schedule for our mid-cycle that starts tomorrow. You can see the schedule here: https://etherpad.openstack.org/p/cinder-stein-mid-cycle-planning I have tried to keep the topics that are of interest to people in Europe/Asia earlier in the day. If anyone has concerns with the schedule, please add notes in the etherpad. Look forward to meeting with you all tomorrow. Jay

1 0

[karbor][goals][python3] looking for karbor PTL
by Doug Hellmann 04 Feb '19

04 Feb '19

I am trying to reach the Karbor PTL, Pengju Jiao, to ask some questions about the status of python 3 support. My email sent to the address on file in the governance repository has bounced. Does anyone have a current email address? -- Doug

2 1

[goal][python3] week R-9 update
by Doug Hellmann 04 Feb '19

04 Feb '19

This is the periodic update for the "Run under Python 3 by default" goal (https://governance.openstack.org/tc/goals/stein/python3-first.html) == Current Status == We still have a fairly large number of projects without a python 3 functional test job running at all: adjutant aodh ceilometer cloudkitty cyborg freezer horizon karbor magnum masakari mistral monasca-agent monasca-ui murano murano-agent neutron-vpnaas qinling rally searchlight storlets swift tricircle watcher zaqar networking-l2gw and several with the job listed as non-voting: designate neutron-fwaas sahara senlin tacker I have contacted the PTLs of all of the affected teams directly to ask for updates. == Ongoing and Completed Work == There are still a handful of open patches to update tox, documentation, and python 3.6 unit tests. +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | Team | tox defaults | Docs | 3.6 unit | Failing | Unreviewed | Total | Champion | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ | adjutant | 1/ 1 | - | + | 0 | 1 | 2 | Doug Hellmann | | barbican | + | 1/ 3 | + | 1 | 1 | 7 | Doug Hellmann | | heat | 1/ 8 | + | 1/ 7 | 0 | 0 | 21 | Doug Hellmann | | InteropWG | 2/ 3 | + | + | 0 | 0 | 9 | Doug Hellmann | | ironic | 1/ 10 | + | + | 0 | 0 | 35 | Doug Hellmann | | magnum | 1/ 5 | + | + | 0 | 0 | 10 | | | masakari | 1/ 4 | + | - | 0 | 1 | 5 | Nguyen Hai | | monasca | 1/ 17 | + | + | 0 | 1 | 34 | Doug Hellmann | | neutron | 2/ 17 | + | + | 1 | 1 | 44 | Doug Hellmann | | OpenStack Charms | 8/ 73 | - | - | 7 | 2 | 73 | Doug Hellmann | | Quality Assurance | 2/ 10 | + | + | 0 | 1 | 31 | Doug Hellmann | | rally | 1/ 3 | + | - | 1 | 1 | 5 | Nguyen Hai | | sahara | 1/ 6 | + | + | 0 | 0 | 13 | Doug Hellmann | | swift | 2/ 3 | + | + | 1 | 1 | 6 | Nguyen Hai | | tacker | 2/ 4 | + | + | 1 | 0 | 9 | Nguyen Hai | | Telemetry | 1/ 7 | + | + | 0 | 1 | 19 | Doug Hellmann | | tripleo | 1/ 54 | + | + | 0 | 1 | 92 | Doug Hellmann | | trove | 1/ 5 | + | + | 0 | 0 | 11 | Doug Hellmann | | User Committee | 3/ 3 | + | - | 0 | 2 | 5 | Doug Hellmann | | | 43/ 61 | 56/ 57 | 54/ 55 | 12 | 14 | 1071 | | +-------------------+--------------+---------+----------+---------+------------+-------+---------------+ == Next Steps == We need to be wrapping up work on this goal by approving or abandoning the patches listed above (assuming they aren't needed) and adding the functional test jobs to the projects that don't have them. == How can you help? == 1. Choose a patch that has failing tests and help fix it. https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Ve… 2. Review the patches for the zuul changes. Keep in mind that some of those patches will be on the stable branches for projects. 3. Work on adding functional test jobs that run under Python 3. == How can you ask for help? == If you have any questions, please post them here to the openstack-dev list with the topic tag [python3] in the subject line. Posting questions to the mailing list will give the widest audience the chance to see the answers. We are using the #openstack-dev IRC channel for discussion as well, but I'm not sure how good our timezone coverage is so it's probably better to use the mailing list. == Reference Material == Goal description: https://governance.openstack.org/tc/goals/stein/python3-first.html Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-first+is:open Storyboard: https://storyboard.openstack.org/#!/board/104 Zuul migration notes: https://etherpad.openstack.org/p/python3-first Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586 Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3 -- Doug

1 0

[kolla] Magnum K8s cluster creation time out due to "Failed to contact endpoint at https ... certificate verify failed" error in magnum-conductor
by Giuseppe Sannino 04 Feb '19

04 Feb '19

Hi all, this is my first post on this mailing list especially for "kolla" related issues. Hope you can help and hope this is the right channel to reuqest support. I have a problem with Magnum during the creation of a K8S cluster. The request gets timed out. Looking at the magnum-conductor logs I can see: Failed to contact the endpoint at https://<External IP>:5000 for discovery. Fallback to using that endpoint as the base url.: SSLError: SSL exception connecting to https:// <External IP> :5000: HTTPSConnectionPool(host=' <External IP> ', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),)) I had a similar issue with Kuryr. the service is trying to contact keystone over the external IP address without certificates. In kuryr, the workaround was to set the "endpoint_type" for neutron to "internal". In magnum.conf that's already the situation. Any suggestion on how to address this issue ? Here you can find some details about the deployment: --------------------------- Host nodes: Baremetal OS: Queens kolla-ansible: 6.1.0 Deployment: multinode (1+1). Kolla installed on the controller host kolla_install_type: source kolla_base_distro: ubuntu External/internal interfaces: separated kolla_enable_tls_external: "yes" Services: enable_cinder: "yes" enable_cinder_backend_lvm: "yes" enable_etcd: "yes" enable_fluentd: "yes" enable_haproxy: "yes" enable_heat: "yes" enable_horizon: "yes" enable_horizon_magnum: "{{ enable_magnum | bool }}" enable_horizon_zun: "{{ enable_zun | bool }}" enable_kuryr: "yes" enable_magnum: "yes" enable_openvswitch: "{{ neutron_plugin_agent != 'linuxbridge' }}" enable_zun: "yes" glance_backend_file: "yes" nova_compute_virt_type: "qemu" --------------------------- BR and many thanks in advance /Giuseppe

1 0

Regarding supporting version of Nova-Docker Driver
by Nehal Bansal 04 Feb '19

04 Feb '19

Hi, I have done a manual installation of OpenStack Queens version and wanted to run docker containers on it using Nova-Docker driver. But the git repository says it is no longer a maintained project. Could you tell me if it supports the Queens release. Thank you. Regards, Nehal Bansal

2 1