January 2019 - openstack-discuss - lists.openstack.org

[all] Is the Denver Summit save?
by Frank Kloeker 29 Jan '19

29 Jan '19

Good morning, just a question, out of curiosity: Is the Denver Summit save? I mean, we received a lot of breaking news in the morning, that Huawei is charged in court and is doing a lot of bad things (i.e. stolen a robotics arm). I don't want to bring in any political discussions. But surely as you know, Huawei is one of the top contributor to our Open Source project. They work hard and do not need to steal things. Is there any chance that one of our friends will be caught next? At the summit between political fronts? I feel a little uncomfortable with it. We are an open community and should clarify this inconsistency. kind regards Frank

6 8

[kayobe] Proposing Pierre Riteau for core
by Mark Goddard 29 Jan '19

29 Jan '19

Hi, I'd like to propose Pierre Riteau (priteau) for core. He has contributed a number of good patches and provided some thoughtful and useful reviews. Cores, please respond +1 or -1. Mark

3 3

openstack-summit-Denver-2019
by Najeh Nafti 29 Jan '19

29 Jan '19

Dear OpenStack Project team, My name is Najeh Nafti. I am a master degree student from Tunisia North Africa. I'm currently working for a thesis project based on OpenStack, but i didn't find the need resources that can help me to realize my project. I would like to request your approval to attend OpenStack-summit-Denver-2019 with your financial support. This event is a unique opportunity for me to gain knowledge and insight I need to solve daily challenges and to help me contribute to the overall goals of my study. Although I understand there might be financial constraints in sending me to this event, I believe it will be an investment that results in immediate and longer term benefits. My objectives in attending this event are: - To increase knowledge in my discipline area. - To network with my peers from all over the world to share information, learn how they are solving similar problems, and collaborate to find innovative approaches. OpenStack-summit-Denver-2019 would be a valuable experience for me and one that would benefit my thesis. Thank you for your consideration. Looking forward to hearing from you. Najeh.

2 2

[ops] ops meetups team meeting 2019-1-22 minutes
by Chris Morgan 29 Jan '19

29 Jan '19

Meeting ended Tue Jan 22 15:48:39 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:48 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:48 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:48 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Next meeting in 40 minutes on #openstack-operators see you there! Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[placement] update 19-03
by Chris Dent 29 Jan '19

29 Jan '19

HTML: https://anticdent.org/placement-update-19-03.html Hello, here's a quick placement update. This will be just a brief summary rather than usual tome. I'm in the midst of some other work. # Most Important Work to complete and review changes to deployment to support extracted placement is the main thing that matters. The next placement extraction status checkin will be 17.00 UTC, February 6th. # What's Changed * Changes to allow database status checks in `placement-status upgrade check` have either merged or will soon. These combine with online data migrations to ensure that the state of an upgraded installations has healthy consumers and resource providers. * libvirt vgpu reshaper [code](https://review.openstack.org/#/c/599208/) is ready for review and has an associated functional test. When that stuff merges the main remaining extraction-related tasks are in the deployment tools. * [os-resource-classes](https://pypi.org/p/os-resource-classes) `0.2.0` was released, adding the `PCPU` class. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 14. -1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 16. Stable. # Main Themes ## Nested * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> * <https://review.openstack.org/615695> ## Extraction * [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-5) Deployment related changes: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla and Kolla Ansible](https://review.openstack.org/#/q/topic:split-placement) and [kolla upgrade](https://review.openstack.org/#/q/topic:upgrade-placement) [Delete placement from nova](https://review.openstack.org/618215). # Other Please refer to [last week](https://anticdent.org/placement-update-19-02.html) for lots of pending changes. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 2

[openstack-helm] Support for Docker Registry with authentication turned on ?
by Waines, Greg 29 Jan '19

29 Jan '19

Hey ... We’re relatively new to openstack-helm. We are trying to use the openstack-helm charts with a Docker Registry that has token authentication turned on. With the current charts, there does not seem to be a way to do this. I.e. there is not an ‘imagePullSecrets’ in the defined pods/containers or in the defined serviceAccounts . Our thinking would be to add a default imagePullSecret to all of the serviceAccounts defined in the openstack-helm serviceaccount template. OR is there another way to use openstack-helm charts with a Docker Registry with authentication turned on ? Any info is appreciated, Greg / Angie / Jerry.

2 2

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

29 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 29 Jan '19

29 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 29 Jan '19

29 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

[magnum][queens] issues
by Ignazio Cassano 28 Jan '19

28 Jan '19

I am trying patches you just released for magnum (git fetch git:// git.openstack.org/openstack/magnum refs/changes/30/629130/9 && git checkout FETCH_HEAD) I got same issues on proxy. In the old version I modified with the help of spyros the scripts under /usr/lib/python2.7/dist-packages/magnum/drivers/common/templates/kubernetes/fragments because PROXY variables are not inherited in /etc/sysconfig/heat-params PROXY E NO PROXY variables are present but we must modify configure-kubernetes-master.sh to force them . /etc/sysconfig/heat-params echo "configuring kubernetes (master)" _prefix=${CONTAINER_INFRA_PREFIX:-docker.io/openstackmagnum/} export HTTP_PROXY=${HTTP_PROXY} export HTTPS_PROXY=${HTTPS_PROXY} export NO_PROXY=${NO_PROXY} echo "HTTP_PROXY IS ${HTTP_PROXY}" exporting the above variables when external network has a proxy, the master is installed but stack hangs creating kube master Resource Group Regards Ignazio

2 6

[neutron] CI meeting on 29.01.2019 cancelled
by Slawomir Kaplonski 28 Jan '19

28 Jan '19

Hi, I will not be able to drive Neutron CI meeting on Tuesday 29.01.2019 so lets cancel it for this week. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[qa][tempest] Waiting for interface status == ACTIVE before checking status
by Terry Wilson 28 Jan '19

28 Jan '19

In the networking-ovn project, we hit this bug *very* often: https://bugs.launchpad.net/tempest/+bug/1728600. You can see the logstash here where it has failed 330 times in the last week: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3… The bug has been around since 2017, and there are earlier reports of it than that. The bug happens in some projects outside of networking-ovn as well. At the core of the issue is that _get_server_port_id_and_ip4 loops through server ports to return ones that are ACTIVE, but there is a race where a port could become temporarily inactive if the ml2 driver continually monitors the actual port status. In the case we hit, os-vif started recreating the ovs port during an operation, so we would detect the status of the port as down and change the status, and then when the port is recreated we set the port status back to up. If the check happens while the port is down, the test fails. There have been comments that the port status shouldn't flip w/o any user request that would cause it, but that would mean that a plugin/driver would have to ignore the actual status of a port and that seems wrong. External things can affect what state a port is in. https://review.openstack.org/#/c/449695/7/tempest/scenario/manager.py adds a wait mechanism to checking the port status so that momentary flips of port status will not cause the test to inadvertently fail. The patch currently has 10 +1s. We really need to get this fixed. Thanks! Terry

4 7

[Seachlight] Team meeting today at 13:30UTC
by Trinh Nguyen 28 Jan '19

28 Jan '19

Hi team, We will have the team meeting today at 13:30UTC. Join us at #openstack-searchlight Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[ops] Berlin ops meet up march 2019
by Chris Morgan 25 Jan '19

25 Jan '19

We (the ops meet ups team) just heard that the city of Berlin just decided that March 8th 2019 is to be a public holiday. Our first reaction is to see if we can just pull the ops meet up forward one day (making it the 6th and 7th instead of the 7th and the 8th). Please let us know if this would be a problem for you ASAP. A good example might be if you have already booked flights. Since the even tickets have not been issued yet, we are hoping that's not the case for anyone. Moving to the 6th and 7th allows it to happen during normal business days for the host, Deutsch Telekom. I don't personally like the idea of trying to keep the 8th when it's a public holiday. Regards, Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

[cinder] Proposing new Core Members ...
by Jay Bryant 25 Jan '19

25 Jan '19

Team, I would like propose two people who have been taking a more active role in Cinder reviews as Core Team Members: First, Rajat Dhasmana who has been active in doing reviews the last couple of releases (http://www.stackalytics.com/?module=cinder-group&user_id=whoami-rajat) He has also made efforts to join our PTG and Forum sessions remotely, has helped to stay on top of bugs and has submitted a number of fixes recently. I feel he would be a great addition to our team. Also, I would like to propose Yikun Jiang as a core member. He had big shoes to fill, back-filling TommyLike Hu and he has stood to the challenge. Continuing to implement the features that TommyLike had in progress and taking an active role as a reviewer: (http://www.stackalytics.com/?module=cinder-group&user_id=yikunkero) I think that both Rajat and Yikun will be welcome additions to help replace the cores that have recently been removed. If there is no disagreement I plan to add both people to the core reviewer list in a week. Thanks! Jay Bryant (jungleboyj)

4 4

[dev] Upcoming git-review changes
by Stephen Finucane 25 Jan '19

25 Jan '19

Happy Friday, Just a quick heads up that the upcoming release of git-review, likely 2.0, removes a feature. Currently, git-review will detect the presence of "bug", "lp", "blueprint" or "bp" in commit messages and, if found, set the Gerrit topic for that submitted review to something based on the blueprint/bug. As noted in the commit that removed this [1], this hadn't been updated to support StoryBoard and there was no desire to do so given the OpenStack-specific nature of this feature along with the fact that it often did the wrong thing. We (being the people who authored and reviewed the patch) think this is definitely a good thing to do, but if anyone has genuine concerns about the removal of this functionality, be sure to raise them here or on #openstack-infra before we push that release out next week. Cheers, Stephen [1] https://github.com/openstack-infra/git-review/commit/03768832c4

2 3

[dev][keystone] Keystone Team Update - Week of 21 January 2019
by Colleen Murphy 25 Jan '19

25 Jan '19

# Keystone Team Update - Week of 21 January 2019 ## News ### Technical Vision Statement >From time to time we talk about writing a mission statement for keystone, and then the idea always loses steam due to unfocused motivation. Luckily the TC has now given us some excellent starting points[1] and has requested we publish a similar team statement and/or update the overall guiding document[2]. We started taking notes on how keystone measures up with the overall vision[3] and whoever finds time first will write up an addition to the keystone contributor guide, where we can further discuss on the review. [1] https://governance.openstack.org/tc/reference/technical-vision.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.… [3] https://etherpad.openstack.org/p/keystone-technical-vision-notes ### External and Tokenless Auth (What's old is new again) In working with the Edge computing group and the engineers at Oath we've been revisiting external authentication with X.509 as well as tokenless authentication[4][5], both ancient features in keystone. Though they are under-tested and have suffered mild bitrot they are still useful features. External authentication with mod_ssl can potentially be used as a drop-in replacement for the custom authentication plugin that Oath currently uses for their IdP Athenz. It does not on its own solve the Edge use case in which a client may be unable to connect to the keystone server for long periods of time, but the ideas can be used as a starting point for proper offline authentication. Tokenless authentication is closely tied to X.509 authentication and was a useful idea for starting to reduce the security impact of bearer tokens, but it was never fully implemented. We have been discussing revamping that feature and will be working on cleaning up the bitrot and the documentation around these features. [4] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-01-22-1… [5] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 16 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 80 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 4 new bugs and closed 2. Bug #1813057 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1813057 Bug #1813085 (keystone:Undecided) opened by Tim Buckley https://bugs.launchpad.net/keystone/+bug/1813085 Bug #1813183 (keystone:Undecided) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1813183 Bug #1813265 (keystone:Undecided) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1813265 Bugs fixed (2) Bug #1794864 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1794864 Bug #1804522 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804522 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Feature proposal freeze happens next week, if you are working on a feature for Stein please have at least a WIP on Gerrit ASAP. The feature freeze is five weeks after that, so major features that are not already fairly far along may have to be pushed to Train. ## Shout-outs Thanks Guang for being super helpful with all of our X.509 and tokenless auth questions! ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 0

Re: Ironic ibmc driver for Huawei server
by Julia Kreger 25 Jan '19

25 Jan '19

Greetings, If your CI can vote on ci-sandbox, you should be able to vote on ironic. I don't remember having to grand permissions previously. If not, please let me know and I'll contact the Infrastructure team. -Julia On Thu, Jan 24, 2019 at 7:50 PM xmufive(a)qq.com <sokoban(a)foxmail.com> wrote: > Hi julia， > > It seems the basic features of our 3rd party CI is ready. It now could > verify +1 on openstack-dev/ci-sandbox[1]. > I am writing for asking for permission of review ironic project for > huawei-ironic-ci. > > The account used for huawei-ironic-ci is: > > Username > huawei-ironic-ci > Full Name Huawei Ironic CI > Email Address zhengxianhui(a)huawei.com > Registered Jan 14, 2019 8:00 PM > Account ID 29800 > > [1] https://review.openstack.org/#/c/630893/ > > > Thanks, > > ------------------ 原始邮件 ------------------ > *发件人:* "Julia Kreger"<juliaashleykreger(a)gmail.com>; > *发送时间:* 2019年1月9日(星期三) 晚上10:47 > *收件人:* "xmufive(a)qq.com"<sokoban(a)foxmail.com>; > *抄送:* "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; > *主题:* Re: Ironic ibmc driver for Huawei server > > Ironic does not have a deadline for merging specs. We will generally > avoid landing large features the closer we get to the end of the > cycle. If third party CI is up before the end of the cycle, I suspect > it would just be a matter of iterating the driver code through review. > You may wish to propose it sooner rather than later, and we can begin > to give you feedback from there. > > -Julia > > On Tue, Jan 8, 2019 at 11:21 PM xmufive(a)qq.com <sokoban(a)foxmail.com> > wrote: > > > > Hi Julia， > > > > When is the deadline of approving specs, I am afraid that huawei ibmc > spec will be put off util next release. > > > > Thanks > > Qianbiao NG > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: "Julia Kreger"<juliaashleykreger(a)gmail.com>; > > 发送时间: 2019年1月9日(星期三) 凌晨2:26 > > 收件人: "xmufive(a)qq.com"<sokoban(a)foxmail.com>; > > 抄送: "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; > > 主题: Re: Ironic ibmc driver for Huawei server > > > > Greetings Qianbiao.NG, > > > > Welcome to Ironic! > > > > The purpose and requirement of Third Party CI is to test drivers are > > in working order with the current state of the code in Ironic and help > > prevent the community from accidentally breaking an in-tree vendor > > driver. Vendors do this by providing one or more physical systems in a > > pool of hardware that is managed by a Zuul v3 or Jenkins installation > > which installs ironic (typically in a virtual machine), and configures > > it to perform a deployment upon the physical bare metal node. Upon > > failure or successful completion of the test, the results are posted > > back to OpenStack Gerrit. > > > > Ultimately this helps provide the community and the vendor with a > > level of assurance in what is released by the ironic community. The > > cinder project has a similar policy and I'll email you directly with > > the contacts at Huawei that work with the Cinder community, as they > > would be familiar with many of the aspects of operating third party > > CI. > > > > You can find additional information here on the requirement and the > > reasoning behind it: > > > > > https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-par… > > > > We may also be able to put you in touch with some vendors that have > > recently worked on implementing third-party CI. I'm presently > > inquiring with others if that will be possible. If you are able to > > join Internet Relay Chat, our IRC channel (#openstack-ironic) has > > several individual who have experience setting up and maintaining > > third-party CI for ironic. > > > > Thanks, > > > > -Julia > > > > On Tue, Jan 8, 2019 at 8:54 AM xmufive(a)qq.com <sokoban(a)foxmail.com> > wrote: > > > > > > Hi julia, > > > > > > According to the comment of story< > https://storyboard.openstack.org/#!/story/2004635 >, > > > 1. The spec for huawei ibmc drvier has been post here: > https://storyboard.openstack.org/#!/story/2004635 , waiting for review. > > > 2. About the third-party CI part, we provide mocked unittests for our > driver's code. Not sure what third-party CI works for in this case. What > else we should do? > > > > > > Thanks > > > Qianbiao.NG >

1 0

Why COA exam is being retired?
by Eduardo Gonzalez 25 Jan '19

25 Jan '19

Reading the info in the COA site [0] says the following* "The OpenStack Foundation is winding down the administration of the COA exam".* Is there any reason for retiring the exam? I've tried to find a notice in the mailing list but not found anything at all. [0] https://www.openstack.org/coa/ Regards

6 6

Not getting full bandwidth VXLAN + DVR
by Yedhu Sastri 25 Jan '19

25 Jan '19

Hello, In our OpenStack environment(Newton) we are using 10G network in all our nodes. We are using OVS bridging with VXLAN tunneling and DVR. We also enabled Jumbo frames in NIC and also in physical switches. We also enabled VXLAN offloading in our NIC. irqbalance is running which suppose to distribute the network irqs to all cores of the CPU. But unfortunately we are only getting below 1G bandwidth when communicate with our VM's with floating IP's from compute hosts. We tested it using iperf and results are like Host to VM using floating IP - less than 1Gbits/sec VM to VM using internal IP - ~2.5Gbits/sec Any idea or solutions to solve this issue is much appreciated. -- With kind regards, Yedhu Sastri

2 1

Not getting full bandwidth VXLAN + DVR
by Yedhu Sastri 25 Jan '19

25 Jan '19

Hello, In our OpenStack environment(Newton) we are using 10G network in all our nodes. We are using OVS bridging with VXLAN tunneling and DVR. We also enabled Jumbo frames in NIC and also in physical switches. We also enabled VXLAN offloading in our NIC. irqbalance is running which suppose to distribute the network irqs to all cores of the CPU. But unfortunately we are only getting below 1G bandwidth when communicate with our VM's with floating IP's from compute hosts. We tested it using iperf and results are like Host to VM using floating IP - less than 1Gbits/sec VM to VM using internal IP - ~2.5Gbits/sec Any idea or solutions to solve this issue is much appreciated. -- With kind regards, Yedhu Sastri

1 0

[Keystone] How to retrieve secret key for a given access key id
by Pritha Srivastava 25 Jan '19

25 Jan '19

Hi All, I have a scenario where I need to retrieve the secret key of a given access key id (of EC2 credentials) from Keystone. I know that this can be done by sending a GET request to the following URL: v3/users/{user_id}/credentials/OS-EC2/access_key_id I don't have the user_id required for the above request, but I have the admin username and admin password, that was used to create the EC2 credentials. Is there a way to get the user_id, and then get the secret key from Keystone? Thanks, Pritha

1 0

[nova][dev] stein blueprint tracking status
by melanie witt 25 Jan '19

25 Jan '19

Hi all, I've updated our stein blueprint tracking status etherpad with all of our approved blueprints for the cycle and notes about their current status: https://etherpad.openstack.org/p/nova-stein-blueprint-status Feature freeze s-3 is fast approaching on March 7. Let's use this etherpad to help us focus our work and complete as much as we can in the next 6 weeks. At the top, I've collected status on our cycle themes. TL;DR is that some efforts have stalled and we probably need people to jump in and help. Some people are already helping, and that's awesome! Please use this etherpad as a review guide and a place to communicate notes about blueprint status and progress, anything that will help us all move forward on completing implementations and reviews. Communication will be key as we try to get things done by s-3. Use the etherpad, #openstack-nova on IRC, and the ML to ask questions, get unstuck, and give updates. Let me know if I've missed any blueprints and feel free to add notes about any items that need to be moved, etc. Cheers, -melanie

1 0

[magnum] Persistent Volume Claim with cinder backend
by Christian Zunker 24 Jan '19

24 Jan '19

Hi, we are running Magnum Rocky. I tried to create a persistent volume claim and got it working with provisioner: kubernetes.io/cinder But it failed with provisioner: openstack.org/standalone-cinder The docs state kubernetes.io/cinder is deprecated: https://kubernetes.io/docs/concepts/storage/storage-classes/#openstack-cind… Which one should be used in Rocky? This is our complete config for this case: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: cinder annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: EnsureExists provisioner: openstack.org/standalone-cinder parameters: type: volumes_hdd availability: cinderAZ_ceph --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 42Gi storageClassName: cinder regards Christian

2 1

[ptl][goals][python3] please update your team's status in the wiki
by Doug Hellmann 24 Jan '19

24 Jan '19

I noticed this morning that the last time the Python 3 status page [1] was updated in the wiki was August. I hope we've had changes to the level of support since then. Keeping that page up to date is part of fulfilling the goal this cycle. Please take a few minutes to review the content today and update it if necessary. Thanks! [1] https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projec… -- Doug

2 2

[openstack-dev] [neutron]
by Farhad Sunavala 24 Jan '19

24 Jan '19

Hi, I am open to suggestions.We have a need to switch traffic from our project to other projects without first getting out on the internet, floating IPs, etc. The other projects will be sharing their networks with our project.As shown in figure below, the orange network belongs to our project (10.0.0.0/26) The green network (172.31.0.0/24) belongs to another project andhas an overlapping network with the red tenant (172.31.0.0/16) For now, the solution is to create VMs in our project and make sure none of the interfaceshaving overlapping CIDRs. Thus, there is a VM attached to the 'orange' and 'red' netsand another VM attached to the 'orange' and 'green' nets. Problem: Too much resources (VMs) will need to be created if we have 100 tenants with overlapping networks. Solution:Is there a way I can minimize VM resource in our project by not allocating a separate VMfor shared networks with overlapping CIDRs? thanks,

3 3

[tc][telemetry][horizon] ceilometer-dashboard repository creation
by Jakub Slíva 24 Jan '19

24 Jan '19

Hello, our company created a little plugin to Horizon and we would like to share it with the community in a bit more official way. So I created change request (https://review.openstack.org/#/c/619235/) in order to create official repository under project Telemetry. However, PTL recommended me to put this new repository under OpenStack without any project - i.e. make it unofficial. I have also discussed this with Horizon team during their meeting (http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.…) and now I am bit stuck because I do not know how to proceed next. Could you, please, advise me? All opinions are appreciated. Jakub Sliva Ultimum Technologies s.r.o. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic http://ultimum.io

4 4

[cinder] volume snapshot on queens not working as in ocata
by Ignazio Cassano 24 Jan '19

24 Jan '19

2 3

Re: [docs] Nominating Alex Settle for openstack-doc-core
by Chason 24 Jan '19

24 Jan '19

So glad to see you back to us, Alex! \o/ Absolutely agree with this Nominating. > Date: Fri, 18 Jan 2019 14:42:33 +0100 > From: Petr Kovar <pkovar(a)redhat.com> > To: openstack-discuss(a)lists.openstack.org > Cc: Alex Settle <asettle(a)suse.com> > Subject: [docs] Nominating Alex Settle for openstack-doc-core > Message-ID: <20190118144233.132eb0e427389da15e725141(a)redhat.com> > Content-Type: text/plain; charset=US-ASCII > > Hi all, > > Alex Settle recently re-joined the Documentation Project after a few-month > break. It's great to have her back and I want to formally nominate her for > membership in the openstack-doc-core team, to follow the formal process for > cores. > > Please let the ML know should you have any objections. > > Thanks, > pk > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list > openstack-discuss(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > > ------------------------------ > > End of openstack-discuss Digest, Vol 3, Issue 110 > *************************************************

1 0

[Release-job-failures] Release of openstack/sqlalchemy-migrate failed
by Sean McGinnis 24 Jan '19

24 Jan '19

There were release job failures with the latest sqlalchemy-migrate release. It appears it is another one of the issues with the readthedocs configuration not being correct. Everything else appears to have succeeded, so the new release is available. It just might need the published documentation manually updated. ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 23 Jan 2019 22:54:02 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Release of openstack/sqlalchemy-migrate failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - trigger-readthedocs-webhook http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : FAILURE in 2m 04s - release-openstack-python http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 4m 09s - announce-release http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 5m 51s - propose-update-constraints http://logs.openstack.org/af/af6733baf027501fc2ad8e2e6b0dbae1989658e5/relea… : SUCCESS in 3m 44s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

3 3

[infra][dev] Zuul promote pipeline for container publishing
by corvus＠inaugust.com 24 Jan '19

24 Jan '19

Hi, We recently added a new pipeline to OpenStack's Zuul, and three new jobs and roles to the zuul-jobs repo to support container publishing. If your project publishes containers, or may do so in the future, read on. The new pipeline is the "promote" pipeline. It runs jobs on changes after they merge, but unlike the "post" pipeline, it does not run with the resulting branch state after the merge -- it runs in the context of the change. This means that it's not suitable for building release artifacts, but that's not its purpose. Its purpose is to promote artifacts previously built in the gate pipeline to production. That is safe to do because anything built in the gate pipeline is built with the full future state of in-flight changes to all related projects and branches (even if it's built before they land). We build a lot of artifacts in the gate pipeline now, and then throw them away only to build them again in post. The promote pipeline is an attempt to avoid that waste and instead preserve artifacts built in gate and directly publish them -- but only if and when the changes for which they were built are merged. The first functional use of this system is in building container images and publishing them on Docker Hub. We have begun using this in openstack-infra to build container images of third-party applications, but this will work just as well and as easily for building images of applications in our infrastructure (for example, we are also starting to use this to publish Zuul images). To implement this, we wrote three jobs which are available now from zuul-jobs (and therefore can be used in any project or job in the system): * build-docker-image [1] * upload-docker-image [2] * promote-docker-image [3] The first job should run in the check pipeline and simply runs "docker build" on the arguments passed to it. It is used to verify that the build succeeds. The second job should run in the gate pipeline. It uploads the image to Docker Hub into the final repository location, but it only does so with a single tag with the form "change_123456" where '123456' is the Gerrit change number for the change under consideration. This will mean that docker pulls won't accidentally fetch the image yet. But the image is staged in Docker Hub and is ready to be promoted if the change passes all its tests and merges. The third job runs in the promote pipeline. This job, unlike the others, only performs Docker Hub API calls and requires no build resources. Therefore it is a zero-node job in Zuul -- a job which only runs on the Zuul executor. This job finds a previously uploaded image with a "change_" tag, and re-tags it with any specified tags ("latest" by default, but you can also tag version numbers or anything else). It also cleans up unused "change_" tags so they don't clutter up the repository. The nice thing about zero-node jobs is that they start and finish very quickly (since they don't have to deal with resource allocation and contention). With this system, an image will be fully published within about a minute after the change merges. To use this system, you will need to create (if you haven't done so already) a credential which is permitted to upload to an organization on Docker Hub, and you will need to add a secret [4] to Zuul for it. A complete example .zuul.yaml might look like this: - secret: name: myproject-dockerhub data: username: dockerhubuser password: !encrypted/pkcs1-oaep - DFlbrDM5eUMptMGIVMXV1g455xOJLi92UYF08Z2/JlIGu3t6v052o9FKlVyj1ZmpXs5+2 JTa5jHkLTvTsYs9fCaNcQc2nmViCyWNlbOMzjB17uiZOaYFNs1sMqZcUZbGEz7Y8ds6Qq NBXI10jWFPTah4QxUuBvUbT3vmjnUToCzexl5ZGhKgijcnROWfUsnlCdugpgoNIcPsUki zty5FotDihnrC8n8vIomVK6EClY38ty97pLrADzFDd+Cos/OUlvi2xooUhzx8Bn020rJA lqEU5v8LGXp5QkHx0MSDx6JY6KppJ/4p/yM+4By6l+A20zdcimxmgiNc9rMWPwDj7xsao m7NAZWmWqOO0Xkhgt6WOfugwgt9X46sgs2+yDEfbnI5ok8uRbAB/4FWj/KdpyXwhcf+O2 wEfhxLwDbAoGONQPjb4YcZmCXtmR7Qe5t+n2jyczWXvrbaBDUQP5a+YtVNN/xhmQ7D740 POlxv7bLxJAixzqaQ3d8Rz9ZEv6zzRuhWph32UQtZ1JxSNww+EvmXm2eEi2Q2z6pT1Cx/ j2OrFyA2GL/UJOVb15VHKF6bgHPHWJtpjPFhqdcvBhVute4BWB+KPcWH+y+apHN1enK3H tNJO9iqm34nKwSuj5ExmFw50LtwR5/9FyRuRPq/vBL+8y82v8FDmeYsBeobn5M= - job: name: myproject-build-image parent: build-docker-image description: Build Docker images. vars: &image_vars docker_images: - context: . repository: myproject/imagename - job: name: myproject-upload-image parent: upload-docker-image description: Build Docker images and upload to Docker Hub. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - job: name: myproject-promote-image parent: promote-docker-image description: Promote previously uploaded Docker images. secrets: - name: docker_credentials secret: myproject-dockerhub pass-to-parent: true vars: *image_vars - project: check: jobs: - myproject-build-image gate: jobs: - myproject-upload-image promote: jobs: - myproject-promote-image If you find that you need jobs which behave slightly differently, you may be able to inherit from these jobs and add pre or post playbooks. Or if you need something particularly complicated, you can re-implement the jobs using the underlying roles in zuul-jobs, which have the same names an the jobs which invoke them. [1] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-build-docker-image [2] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-upload-docker-image [3] https://zuul-ci.org/docs/zuul-jobs/jobs.html#job-promote-docker-image [4] https://zuul-ci.org/docs/zuul/user/encryption.html

1 0

[Cinder][nova] queens backup
by Ignazio Cassano 23 Jan '19

23 Jan '19

Hi All, Please, I' d like to know if cinder backup and/or cinder snapshot call qemu guest agent for fsfreezing. If Yes, does it freeze file systems in the volume? Regards Ignazio

6 12

Re: [openstack-dev] [tripleo] reducing our upstream CI footprint
by Wesley Hayutin 23 Jan '19

23 Jan '19

On Thu, Nov 1, 2018 at 5:47 AM Derek Higgins <derekh(a)redhat.com> wrote: > On Wed, 31 Oct 2018 at 17:22, Alex Schultz <aschultz(a)redhat.com> wrote: > > > > Hey everyone, > > > > Based on previous emails around this[0][1], I have proposed a possible > > reducing in our usage by switching the scenario001--011 jobs to > > non-voting and removing them from the gate[2]. This will reduce the > > likelihood of causing gate resets and hopefully allow us to land > > corrective patches sooner. In terms of risks, there is a risk that we > > might introduce breaking changes in the scenarios because they are > > officially non-voting, and we will still be gating promotions on these > > scenarios. This means that if they are broken, they will need the > > same attention and care to fix them so we should be vigilant when the > > jobs are failing. > > > > The hope is that we can switch these scenarios out with voting > > standalone versions in the next few weeks, but until that I think we > > should proceed by removing them from the gate. I know this is less > > than ideal but as most failures with these jobs in the gate are either > > timeouts or unrelated to the changes (or gate queue), they are more of > > hindrance than a help at this point. > > > > Thanks, > > -Alex > > While on the topic of reducing the CI footprint > > something worth considering when pushing up a string of patches would > be to remove a bunch of the check jobs at the start of the patch set. > > e.g. If I'm working on t-h-t and have a series of 10 patches, while > looking for feedback I could remove most of the jobs from > zuul.d/layout.yaml in patch 1 so all 10 patches don't run the entire > suite of CI jobs. Once it becomes clear that the patchset is nearly > ready to merge, I change patch 1 leave zuul.d/layout.yaml as is. > > I'm not suggesting everybody does this but anybody who tends to push > up multiple patch sets together could consider it to not tie up > resources for hours. > > > > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html > > [2] > https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR… > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Greetings, Just a quick update.. The TripleO CI team is just about done migrating multinode scenario 1-4 jobs to the SingleNode job. This update and a few other minor changes have moved the needle with regards to TripleO's upstream resource consumption. In October of 2017 we had the following footprint.. tripleo: 111256883.96s, 52.45% [1] Today our footprint is now.. tripleo: 313097590.30s, 36.70% [2] We are still working the issue and we should see further improvement over the next couple months. I'll update the list again at the end of Stein. Thanks to Clark, Doug, Alex, Emilien and Juan for the work to make this happen!! Also thank you to the folks on the TripleO-CI team, you know who you are :) [1] http://paste.openstack.org/show/733644/ [2] http://paste.openstack.org/show/743188/

1 0

[docs] Nominating Alex Settle for openstack-doc-core
by Petr Kovar 23 Jan '19

23 Jan '19

Hi all, Alex Settle recently re-joined the Documentation Project after a few-month break. It's great to have her back and I want to formally nominate her for membership in the openstack-doc-core team, to follow the formal process for cores. Please let the ML know should you have any objections. Thanks, pk

13 14

oslo.messaging, OpenSSL 1.1.1a, Eventlet and Python 3.7
by Thomas Goirand 23 Jan '19

23 Jan '19

Hi there! Just a quick return from my experience. While testing all what's in the subject in Debian Buster/Sid (testing a full deployment), I noticed that most (if not all) components wouldn't connect to RabbitMQ. The crash was like this: http://paste.openstack.org/show/743089/ This happened in: - cinder-scheduler - nova-conductor - neutron-api - neutron-rpc-server and probably many more. After some search-engine time, I found this patch: https://github.com/eventlet/eventlet/pull/531/commits This fixed the issue for me (on all OpenStack components). I've pushed it in the eventlet Debian package Git repository, and hopefully, I'll be able to push it to Buster before the release (currently waiting on approval from the current package maintainer). Hoping this helps the project and/or some deployment people, Cheers, Thomas Goirand (zigo) P.S: More soon about the latest update of OCI.

2 2

[all][oslo][coordination] remove method get_transport in transport.py
by Herve Beraud 23 Jan '19

23 Jan '19

Hello everybody! Since few months oslo plan to remove an deprecated method (oslo_messaging.get_transport). In a first this method was deprecated to facilitate removing rpc_backend support, get_transport aliases was deprecated to simplify the code and the tests. Aliases were first depreacted in oslo.messaging 5.20.0 during Pike and now we want to definitely remove this method. The support of this aliases was planed to be remove during milestone stein-1. So I propose to all projects who use this deprecated method to start to move to the right oslo.messaging supported transport methods (get_rpc_transport or get_notification_transport depends on your needs). This thread will try to coordinate projects during migrator. I already submit a patch[1] to oslo.messaging to start to remove this method. To move forward on this topic I personaly plan to propose patchs to projects that I know that use it. To ensure a better removing, to be sure that all projects remove usages of this method, and to merge in the right order, I propose to you to use the same topic in your gerrit reviews by using refer the bug https://bugs.launchpad.net/oslo.messaging/+bug/1714945 in your commit (Related-Bug: #1714945). Please ensure that all your projects stop to use this method. If you facing an issue please reply to this thread to centralize support during the migrator. You can track this topic by visiting this page: https://review.openstack.org/#/q/topic:bug/1714945+(status:open+OR+status:m… [1] https://review.openstack.org/632523 Cheers! Best! -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[TripleO][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes: UPDATE
by Bogdan Dobrelya 23 Jan '19

23 Jan '19

Here is an update. The %{systemd_ordering} macro is proposed for lightening containers images and removing the systemd dependency for containers. Please see & try patches in the topic [0] for RDO, and [1][2][3][4][5] for generic Fedora 29 rpms. I'd very appreciate if anyone building Kolla containers for f29/(rhel8 yet?) could try these out as well. PS (somewhat internal facing but who cares): I wonder if we could see those changes catched up automagically for rhel8 repos as well? > I'm tracking systemd changes here [0],[1],[2], btw (if accepted, > it should be working as of fedora28(or 29) I hope) > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1668688 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1668687 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1668678 -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[scientific-sig] IRC meeting Wednesday 1100 UTC: 2FA with FreeIPA, OpenInfra Days London, ISC 2019
by Stig Telfer 23 Jan '19

23 Jan '19

Hi All - We have a Scientific SIG IRC meeting coming up on Wednesday 16th at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Full agenda and details are here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019> We’ve got quite a bit to cover this week. Our headline item is a presentation on experiences configuring 2FA for OpenStack using FreeIPA. We also have some exciting events coming up, and discussion on a possible Scientific OpenStack BoF at the International Supercomputer Conference in Frankfurt in June. Cheers, Stig

2 3

Subject: Re: [Trove] State of the Trove service tenant deployment model
by Darek Król 23 Jan '19

23 Jan '19

On Tue, Jan 22, 2019 at 07:29:25PM +1300, Zane Bitter wrote: > Last time I heard (which was probably mid-2017), the Trove team had > implemented encryption for messages on the RabbitMQ bus. IIUC each DB being > managed had its own encryption keys, so that would theoretically prevent > both snooping and spoofing of messages. That's the good news. > > The bad news is that AFAIK it's still using a shared RabbitMQ bus, so > attacks like denial of service are still possible if you can extract the > shared credentials from the VM. Not sure about replay attacks; I haven't > actually investigated the implementation. > > cheers, > Zane. > Excellent - many thanks for the confirmation. > > Cheers, > Michael Hello Michael and Zane, sorry for the late reply. I believe Zane is referring to a video from 2017 [0]. Yes, messages from trove instances are encrypted and the keys are kept in Trove DB. It is still a shared message bus, but it can be a message bus dedicated for Trove only and separated from message bus shared by other Openstack services. DDOS attacks are also mentioned in the video as a potential threat but there is very little details and possible solutions. Recently we had some internal discussion about this threat within Trove team. Maybe we could user Rabbitmq mechanisms for flow control mentioned in [1,2,3] ? Another point, I'm wondering if this is a problem only in Trove or is it something other services would be interesting in also ? Best, Darek [0] https://youtu.be/dzvcKlt3Lx8 [1] https://www.rabbitmq.com/flow-control.html [2] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-p… [3] https://tech.labs.oliverwyman.com/blog/2013/08/31/controlling-fast-producer…

6 9

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 23 Jan '19

23 Jan '19

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[nova] Do we need to copy pci_devices to target cell DB during cross-cell resize?
by Matt Riedemann 22 Jan '19

22 Jan '19

While working on the code to create instance-related data in the target cell database during a cross-cell resize I noticed I wasn't copying over pci_devices [1] but when looking at the PciDevice object create/save methods, those aren't really what I'm looking for here. And looking at the data model, there is a compute_node_id field which is the compute_nodes.id primary key which won't match the target cell DB. I am not very familiar with the PCI device manager code and data model (it's my weakest area in nova lo these many years) but looking closer at this, am I correct in understanding that the PciDevice object and data model is really more about the actual inventory and allocations of PCI devices on a given compute node and therefore it doesn't really make sense to need to copy that data over to the target cell database. During a cross-cell resize, the scheduler is going to pick a target host in another cell and claim standard resources (VCPU, MEMORY_MB and DISK_GB) in placement, but things like NUMA/PCI claims won't happen until we do a ResourceTracker.resize_claim on the target host in the target cell. In that case, it seems the things I only need to care about mirroring is instance.pci_requests and instance.numa_topology, correct? Since those are the user-requested (via flavor/image/port) resources which will then result in PciDevice and NUMA allocations on the target host. I'm just looking for confirmation from others that better understand the data model in this area. [1] https://review.openstack.org/#/c/627892/5/nova/conductor/tasks/cross_cell_m… -- Thanks, Matt

2 2

[neutron] Neutron Bug Deputy report for week of Jan 14
by Nate Johnston 22 Jan '19

22 Jan '19

Neutron friends, Below is a summary of the neutron bugs that came in last week (Jan 14th). Any bugs with a preceding "(*)" are not yet in "in progress" state. Looks like lajoskatona is this week's bug deputy. Ports/IPAM - https://bugs.launchpad.net/bugs/1811905 Deferred IP allocation, port update with binding_host_id + set new mac address fails - https://bugs.launchpad.net/bugs/1812788 Port with no active binding mark as dead Gate Failures - (*) https://bugs.launchpad.net/bugs/1812364 Error "OSError: [Errno 22] failed to open netns" in l3-agent logs - https://bugs.launchpad.net/bugs/1812404 test_concurrent_create_port_forwarding_update_port failed with InvalidIpForSubnet - (*) https://bugs.launchpad.net/bugs/1812872 Trunk functional tests can interact with each other - https://bugs.launchpad.net/bugs/1812552 tempest-slow tests fails often L3 / DHCP - https://bugs.launchpad.net/bugs/1811873 get_l3_agent_with_min_routers fails with postgresql backend - (*) https://bugs.launchpad.net/bugs/1812118 Neutron doesn't allow to update router external subnets DNS - (*) https://bugs.launchpad.net/bugs/1812168 Neutron doesn't delete Designate entry when port is deleted QoS - https://bugs.launchpad.net/bugs/1812576 L2 agent do not clear old QoS rules after restart Oslo - https://bugs.launchpad.net/bugs/1812922 neutron functional tests break with oslo.utils 3.39.1 and above Docs - (*) https://bugs.launchpad.net/bugs/1812225 Firewall-as-a-Service (FWaaS) in neutron docs for Rocky still refer to plans for Ocata - (*) https://bugs.launchpad.net/bugs/1809578 Documentation might be wrong - https://bugs.launchpad.net/bugs/1812497 create vm failed, RequiredOptError: value required for option lock_path in group

1 0

[scientific-sig] IRC meeting at 2100 UTC: Jitter on SR-IOV IB, Terraform and Kubespray
by Stig Telfer 22 Jan '19

22 Jan '19

Hi All - We have a Scientific SIG IRC meeting in about 30 minutes in channel #openstack-meeting. Everyone is welcome. Today’s agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_22nd_2019 We have Jacob Anders from CSIRO talking about some recent research on latency and jitter for SR-IOV InfiniBand. We also have Martial Michel from DataMachines on Terraform and Kubespray. Cheers, Stig

1 0