- openstack-discuss - lists.openstack.org

[tripleo][openstack-ansible] collaboration on os_tempest role update VIII - Jan 29, 2019
by Chandan kumar 28 Jan '19

28 Jan '19

Hello, Here is the 8 th update (Jan 22 to Jan 29, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: openstack-ansible-tests: * Setup clouds.yaml on tempest node - https://review.openstack.org/631794 * Gather all facts while preparing hosts - https://review.openstack.org/632609 * Gather different port status on different hosts - https://review.openstack.org/633179 TripleO: * Added requirements for integrating os_tempest role - https://review.openstack.org/628421 * Use os_tempest for running tempest on standalone - https://review.openstack.org/628415 Summary: We have almost completed the work of integrating os_tempest with tripleo-ci, The final patch is about to land by EOD or by tomorrow and here is the latest result: http://logs.openstack.org/00/627500/76/check/tripleo-ci-centos-7-standalone… Things In-Progress: os_tempest: * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * 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 image from 3.5 to 3.6 - https://review.openstack.org/633208 * Added dependencies of os_tempest role - https://review.openstack.org/632726 * Only init a workspace if doesn't exists - https://review.openstack.org/633549 * Add support for aarch64 images - https://review.openstack.org/620032 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 TripleO: * Set keystone specific vars for os_tempest from clouds.yaml - https://review.openstack.org/633185 * Run tempest using os_tempest role in standalone job - https://review.openstack.org/627500 Summary: Currently, os_tempest tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops tests are failing while ssh into cirros image with ssh timeout only on CentOS7. It might be a floating Ip/networking issue. Any help on this appreciated. Failure: http://logs.openstack.org/08/633208/8/check/openstack-ansible-functional-ce… We also find other issues on centOS 7 jobs, work in progress to fix it * Use venv_packages_to_symlink to symlink to import libvirt-python - https://review.openstack.org/633474 * Ensure selinux bindings are linked into the venv - https://review.openstack.org/#/c/633513/ Goal of this week: We will be working on fixing the os_tempest gate and get above patches merged. We are working on fixing it. Thanks to jrosser and odyssey4me for helping us in debugging centOS7 issues while trying to reproduce the issue locally. Here is the 7th 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/001946.… Thanks, Chandan Kumar

1 0

[Cyborg] No IRC meeting on Jan 29 and Feb 05
by Li Liu 28 Jan '19

28 Jan '19

Hi Team, The IRC meetings for the next couple weeks will be canceled due to Chinese New Year and resumed on the week of Feb 12th. Happy Chinese New Year! 新年快乐！ -- Thank you Regards Li Liu

1 0

[Zun] No team meeting at Jan 29 and Feb 05
by Hongbin Lu 28 Jan '19

28 Jan '19

FYI ---------- Forwarded message --------- From: Ji.Wei <17366060309(a)163.com> Date: Mon, Jan 28, 2019 at 9:18 PM Subject: Zun irc meeting suspension notice To: hongbin <hongbin034(a)gmail.com> Hello everyone: Zun's irc meeting will be suspended during the Chinese traditional festival, Chinese New Year (29 January 2019 and 05 February 2019). If you have any questions, please contact me (17366060309(a)163.com) Thank you for your contribution to Zun in the past year :) -- This message was sent from Launchpad by Ji.Wei (https://launchpad.net/~jiwei) to each member of the zun-drivers team using the "Contact this team" link on the zun-drivers team page (https://launchpad.net/~zun-drivers) For more information see https://help.launchpad.net/YourAccount/ContactingPeople

1 0

[tc] Technical Committee status update
by Doug Hellmann 28 Jan '19

28 Jan '19

This is a summary of work being done by the Technical Committee members. The full list of active items is managed in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker We also track TC objectives for the cycle using StoryBoard at: https://storyboard.openstack.org/#!/project/923 == Recent Activity == Project updates: * Renat Akhmerov has replaced Dougal Matthews as Mistral PTL ** https://review.openstack.org/#/c/625537/ * The Sahara team added repositories for extracting their plugins ** https://review.openstack.org/#/c/628210/ * The murano-deployment repository was retired ** https://review.openstack.org/#/c/628860/ * The assert:supports-upgrade tag was added to watcher ** https://review.openstack.org/#/c/619470/ * The openstack-virtual-baremetal repository was added to the TripleO team ** https://review.openstack.org/#/c/631028/ * The charm-interface-cinder-backend repository was added to the OpenStack Charms project ** https://review.openstack.org/#/c/631251/ * The puppet-stackalytics repository has been retired ** https://review.openstack.org/#/c/631820/ Other updates: * Zane drafted a resolution about how we should choose which Python versions to track ** https://review.openstack.org/#/c/613145/ * Sean updated the PTI to reflect the runtimes supported for Stein ** https://review.openstack.org/#/c/611080/ * Thierry and Chris drafted a description of the role of the TC ** https://review.openstack.org/#/c/622400/ * I added a "house rule" for approving simple documentation changes without requiring a full TC vote ** https://review.openstack.org/#/c/625005/ * Jeremy updated the technical vision to cover hiding implementation details ** https://review.openstack.org/#/c/628181/ == TC Meetings == The most recent TC meeting was on 3 January. Logs were sent to the mailing list after the meeting. * http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001376.… The next TC meeting will be 7 February @ 1400 UTC in #openstack-tc. See http://eavesdrop.openstack.org/#Technical_Committee_Meeting for details == Ongoing Discussions == Frank has proposed a list of translators as ATCs for the i18n team. * https://review.openstack.org/#/c/633398/ Ganshyam is working on updating the technical vision to cover feature discovery. * https://review.openstack.org/#/c/621516/ Jean-Philippe has proposed adding openSUSE to the list of supported platforms in the PTI. * https://review.openstack.org/#/c/633460/ == Contacting the TC == The Technical Committee uses a series of weekly "office hour" time slots for synchronous communication. We hope that by having several such times scheduled, we will have more opportunities to engage with members of the community from different timezones. Office hour times in #openstack-tc: - 09:00 UTC on Tuesdays - 01:00 UTC on Wednesdays - 15:00 UTC on Thursdays If you have something you would like the TC to discuss, you can add it to our office hour conversation starter etherpad at: https://etherpad.openstack.org/p/tc-office-hour-conversation-starters Many of us also run IRC bouncers which stay in #openstack-tc most of the time, so please do not feel that you need to wait for an office hour time to pose a question or offer a suggestion. You can use the string "tc-members" to alert the members to your question. You will find channel logs with past conversations at http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ If you expect your topic to require significant discussion or to need input from members of the community other than the TC, please start a mailing list discussion on openstack-discuss at lists.openstack.org and use the subject tag "[tc]" to bring it to the attention of TC members. -- Doug

1 0

[neutron][taas] taas OVS Driver Implementation
by Moshe Levi 28 Jan '19

28 Jan '19

Hi Guys, I was looking to contribute to taas to allow ovs hardware offload [1]. Do any one have some documentation of the ovs pipeline? I see this wired behavior on local mirroring I can see that if the monitor port and the VM production port on the same server the traffic for the monitor port is tagged with the local vlan of the port. I am not sure why it happen because the monitor port is configured to be in access of the local vlan. I proposed the following fix [2] and I wonder if someone can review it [1] - https://github.com/openstack/neutron/blob/master/doc/source/admin/conig-ovs… [2] - https://review.openstack.org/#/c/632679/ Thanks, Moshe

1 0

[all] [uc] OpenStack UC Meeting @ 1900 UTC
by Melvin Hillsman 28 Jan '19

28 Jan '19

Hi everyone, Just a reminder that the UC meeting will be in #openstack-uc in a little more than an hour and a half from now. Please feel empowered to add to the agenda here - https://etherpad.openstack.org/p/uc - and we hope to see you there! -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 1

G8 H8
by Matt Riedemann 28 Jan '19

28 Jan '19

Time for a quick update on gate status. * There were some shelve tests that were failing ssh pretty badly in the tempest-slow job due to a neutron issue: https://launchpad.net/bugs/1812552. It seems https://review.openstack.org/#/c/631944/ might have squashed that bug. * Probably our biggest issue right now is test_subnet_details failing: http://status.openstack.org/elastic-recheck/#1813198. I suspect that is somehow related to using cirros 0.4.0 in devstack as of Jan 20. I have a tempest patch up for review to help debug that when it fails https://review.openstack.org/#/c/633225 since it seems we're not parsing nic names properly which is how we get the mangled udhcpc..pid file name. * Another nasty one that is affecting unit/functional tests (the bug is against nova but the query hits other projects as well) is http://status.openstack.org/elastic-recheck/#1813147 where subunit parsing fails. It seems cinder had to deal with something like this recently too so the nova team needs to figure out what cinder did to resolve this. I'm not sure if this is a recent regression or not, but the logstash trends start around Jan 17 so it could be recent. * https://bugs.launchpad.net/cinder/+bug/1810526 is a cinder bug related to etcd intermittently dropping connections and then cinder services hit ToozConnectionErrors which cause other things to fail, like volume status updates are lost during delete and then tempest times out waiting for the volume to be deleted. I have a fingerprint in the bug but it shows up in successful jobs too which is frustrating. I would expect that for grenade while services are being restarted (although do we restart etcd in grenade?) but it also shows up in non-grenade jobs. I believe cinder is just using tooz+etcd as a distributed lock manager so I'm not sure how valid it would be to add retries on that locking code or not when the service is unavailable. One suggestion in IRC was to not use tooz/etcd for DLM in single-node jobs but that kind of side-steps the issue - but if etcd is lagging because of lots of services eating up resources on the single node, it might not be a bad option. -- Thanks, Matt

4 5

[neutron] Neutron Bug Deputy report for week of Jan 21
by Lajos Katona 28 Jan '19

28 Jan '19

Hi Neutrinos, Here is the summary of neutron bugs that came in last week (starting from Jan. 21st). * Gate failures: * tempest-slow tests fails often (https://bugs.launchpad.net/neutron/+bug/1812552) * TestNetworkBasicOps:test_subnet_details intermittently fails with "cat: can't open '/var/run/udhcpc..pid': No such file or directory" (https://bugs.launchpad.net/neutron/+bug/1813198) => mriedem added extra logs to tempest (https://review.openstack.org/633225) let's see how that helps debugging. * neutron functional tests break with oslo.utils 3.39.1 and above (https://bugs.launchpad.net/neutron/+bug/1812922) => oslo.utils patch is on its way, in requirements the wrong oslo.utils versions were blacklisted. * Functional test neutron.tests.functional.services.portforwarding.test_port_forwarding.PortForwardingTestCase.test_concurrent_create_port_forwarding_delete_port fails (https://bugs.launchpad.net/neutron/+bug/1813540) * Unit test neutron.tests.unit.services.revisions.test_revision_plugin.TestRevisionPlugin. test_port_ip_update_revises failing (https://bugs.launchpad.net/neutron/+bug/1813417) * Medium * L2 agent do not clear old QoS rules after restart (https://bugs.launchpad.net/neutron/+bug/1812576) * In progress (https://review.openstack.org/632014) * Neutron-server takes a long time when creating a port with multiple addresses at once (https://bugs.launchpad.net/neutron/+bug/1813253) * Race during adding and updating same port in L3 agent's info can generate wrong radvd config file (https://bugs.launchpad.net/neutron/+bug/1813279) In progress: https://review.openstack.org/633236 * an instance can see other instances' unicast packages when security group firewall_driver is openvswitch (https://bugs.launchpad.net/neutron/+bug/1813439) * Invalid * Port with no active binding mark as dead (https://bugs.launchpad.net/neutron/+bug/1812788) * DOC: * create vm failed, RequiredOptError: value required for option lock_path in group (https://bugs.launchpad.net/neutron/+bug/1812497) * Fix on master: https://review.openstack.org/632316 * Networking Option 2: Self-service networks in neutron (https://bugs.launchpad.net/neutron/+bug/1812958) * duplicate of 1812497 Regards Lajos Katona (lajoskatona)

1 0

[tc][all] Train Community Goal - CLI
by Artem Goncharov 28 Jan '19

28 Jan '19

Hi everybody, One of the community goals for Train is to work on deprecation of individual clients in favor of unified OpenStackClient. This in turn consists (or might consist) from few individual targets: - bringing current state of the CLI support for each service on par with native service client (especially covering changes added with latest microversions) - ensuring SDK also supports all of the service/resource/attribute/method - switching OSC service to SDK, as soon as it is on the same level, as native service client (someone might argue, that this is a mandatory part for reaching the target, but I personally this should be as important for reaching the goal (in addition to avoid double work)) - deprecating individual clients (when prerequisites are fulfilled) In order to drive a bit the whole goal I have started working on gathering differences we have for services in OSC: https://etherpad.openstack.org/p/osc-gaps-analysis. I tried to analyze current state going from the API side, where for each service we have a set of resources (with corresponding attributes) and methods on those. To achieve that I was "parsing" a service documentation (do not kick me too hard for that ;-) and processing it further, leaving overall info as "yaml" since there is lots of info and in the background there are still some source "documents". Resulting document in some form represent a current status and a todo list. I would be happy if people who feel responsible for implementing CLI would have a look on that and provide a feedback, whether they find the whole analysis helpful or not (if not whether there are better ideas on how to track status and todo). There is still a lot to be done even to figure out the current status, but I feel we need to start moving if we want to achieve the target (even switching just a few services would be already an achievement). So, if you are willing to support the goal - please join me. Any help and work is welcome. Regards, Artem

2 2

Adding type hints to OpenStack (starting with Oslo)
by Cyril Roelandt 28 Jan '19

28 Jan '19

Hello, I have recently been looking at mypy[1], a static type checker for Python. It uses optional type hints[2] to perform type checking. Using mypy has many benefits: - it allows developers to find type-related bugs that could cause a program to crash or display an unexpected behaviour at runtime; - it replaces type information that is usually given in docstrings, and may be outdated; - mypy runs can be integrated into a CI, making sure there are no regressions; - mypy works with both Python 2 and 3; - adding type information may be done incrementally; - library developers may expose type information, helping their users. Type information is available for most of the standard Python library, and for the most popular libraries on PyPI, through typeshed[3]. It is therefore possible to write bad code such as: $ cat test.py import requests requests.get(123) And have mypy warn us that something is wrong: $ mypy test.py test.py:2: error: Argument 1 has incompatible type "int"; expected "Union[str, bytes]" I would like to add type hints to OpenStack, starting with a small project (because it would probably be quick and easy) that is used by a lot of other OpenStack projects (because they would benefit from the type hints as well). Oslo seems like a reasonable choice. I took the liberty of implementing a proof of concept on top of oslo.config[4]. Using this branch, you should be able to: 1) Run "tox -etype" to run mypy on the whole code base 2) Write a badly typed program such as this one: $ cat test.py from oslo_config import cfg common_opts = [ cfg.IntOpt('test', min='3'), cfg.HostAddressOpt('host', version='4'), ] And have mypy show you the type errors: $ mypy test.py test.py:4: error: Argument "min" to "IntOpt" has incompatible type "str"; expected "Optional[int]" test.py:5: error: Argument "version" to "HostAddressOpt" has incompatible type "str"; expected "Optional[int]" Does anyone know about mypy? Would anyone be interested in seeing type hints added to OpenStack? Looking forward to hearing your thoughts, Cyril [1] http://mypy-lang.org/ [2] https://www.python.org/dev/peps/pep-0484/ [3] https://github.com/python/typeshed [4] https://github.com/CyrilRoelandteNovance/oslo.config/tree/type

7 11