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