March 2019 - openstack-discuss - lists.openstack.org

openstack-placement 1.0.0.0rc2 (stein)
by no-reply＠openstack.org 27 Mar '19

27 Mar '19

Hello everyone, A new release candidate for openstack-placement for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/placement/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/placement/log/?h=stable/stein Release notes for openstack-placement can be found at: https://docs.openstack.org/releasenotes/placement/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/openstack/placement and tag it *stein-rc-potential* to bring it to the openstack-placement release crew's attention.

1 0

Re: [Release-job-failures] Release of openstack/heat failed
by Tony Breeds 27 Mar '19

27 Mar '19

On Mon, Mar 25, 2019 at 01:21:01AM +0000, zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python http://logs.openstack.org/62/628b0544eda77dd7a59d083126e6b94cbaef98a6/relea… : POST_FAILURE in 6m 22s This and the other heat release failures are probably a result of there being confusion between heat and openstack-heat and the project's name: [tony@thor heat]$ for branch in origin/{master,stable/{stein,rocky,queens,pike,ocata}} ; do git grep ^name $branch -- setup.cfg ; done origin/master:setup.cfg:2:name = openstack-heat origin/stable/stein:setup.cfg:2:name = openstack-heat origin/stable/rocky:setup.cfg:2:name = heat origin/stable/queens:setup.cfg:2:name = heat origin/stable/pike:setup.cfg:2:name = heat origin/stable/ocata:setup.cfg:2:name = heat I *think* we can fix this with meta-data in the releases repo but until then older series can't be published to pypi. Yours Tony.

3 2

[tripleo][openstack-ansible] collaboration on os_tempest role update XVI - Mar 27, 2019
by Chandan kumar 27 Mar '19

27 Mar '19

Hello, Here is the 16th update (Mar 20 to Mar 26, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * we can now install os_tempest dependencies using ansible-galaxy Below is the steps: git clone https://github.com/openstack/openstack-ansible-os_tempest cd openstack-ansible-os_tempest ansible-galaxy install -r requirements.yml; cd .. ansible-galaxy install <path to cloned openstack-ansible-os_tempest> and you are done. * We have added new var tempest_keystone_interface_insecure for doing ssl verification in tempest.conf Thanks for mkopec and odyssey4me for helping on new var and stackviz installation. Things got merged: OS_TEMPEST: * Use requirements.yml for managing os_tempest deps - https://review.openstack.org/644600 * Beautify Generate test-list file shell task - https://review.openstack.org/644499 * Ensure stackviz installs from tarball URL only - https://review.openstack.org/637503 * Bring back the --serial flag alive - https://review.openstack.org/644505 * Use tempest_keystone_interface_insecure var for ssl verification - https://review.openstack.org/644816 Things in progress: OS_TEMPEST: * Include config_template action plugin as a deps for os_tempest - https://review.openstack.org/644830 * User guide for os_tempest - https://review.openstack.org/644570 TripleO: * Added install_os_tempest_deps function to install os_tempest deps - https://review.openstack.org/#/c/647375/ * Remove keystone_service_internaluri_insecure var from os_tempest - https://review.openstack.org/647782 What is coming this week? * use python_venv_build role in os_tempest * port standalone jobs in tripleo side Here is the 15th 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-March/004015.ht… Thanks, Chandan Kumar

1 1

[scientific-sig] IRC Meeting Wednesday, 1100 UTC - machine learning at NIST, summit/forum preparation
by Stig Telfer 26 Mar '19

26 Mar '19

Hi All - We have a Scientific SIG IRC meeting at 1100 UTC on Wednesday in channel #openstack-meeting. Everyone is welcome. The full agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_27th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_27th_2019> This week we have a guest appearance from Maxime and Alex from NIST to talk about their recent study, "Evaluation of hardware-specific machine learning systems orchestrated in an OS cluster at NIST”. We also have some preparation to do for the upcoming forum in Denver. Cheers Stig

1 0

[freezer][releases] It's time for you to create the stable/stein branch
by Trinh Nguyen 26 Mar '19

26 Mar '19

Hi team, It's time for you to create the stable/stein branch on these project as well as the cycle highlights: freezer freezer-api freezer-web-ui python-freezerclient You can look at [1] as an example. I'm also noticing we're missing freezer-dr in this cycle. Do you have any plan for this? [1] https://github.com/openstack/releases/blob/master/deliverables/stein/search… Cheers, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

Requirements unfreeze
by Matthew Thode 26 Mar '19

26 Mar '19

Winter has come, winter has gone. Requirements has branched and will unfreeze after our meeting tomorrow. The following projects have not branched stein yet and will have to be cautious in looking for gate failures. They may wish to change to track stein and then change back once branched or have some other option. Basic projects that need looking at: ec2-api freezer heat karbor kolla kuryr manila monasca murano neutron OpenStackAnsible Quality senlin solum tripleo watcher zun detailed summary from the releases repo: ec2-api ec2-api 8.0.0 service cycle-with-intermediary () freezer-web-ui freezer 7.0.0 horizon-plugin cycle-with-intermediary () freezer freezer 7.0.0 service cycle-with-intermediary () heat-agents heat 1.8.0 other cycle-with-intermediary () heat-dashboard heat 1.5.0 horizon-plugin cycle-with-intermediary () karbor-dashboard karbor 1.2.0 horizon-plugin cycle-with-intermediary () kolla-ansible kolla 8.0.0.0b1 other cycle-trailing () kolla kolla 8.0.0.0b1 other cycle-trailing () kuryr-kubernetes kuryr 0.6.0 other cycle-with-intermediary () kuryr-kubernetes kuryr 0.6.1 other cycle-with-intermediary () kuryr-libnetwork kuryr 3.0.0 other cycle-with-intermediary () manila-ui manila 2.17.0 horizon-plugin cycle-with-intermediary () monasca-agent monasca 2.9.0 other cycle-with-intermediary () monasca-api monasca 2.8.0 service cycle-with-intermediary () monasca-ceilometer monasca 1.9.0 other cycle-with-intermediary () monasca-events-api monasca 0.2.0 service cycle-with-intermediary () monasca-kibana-plugin monasca 1.4.0 other cycle-with-intermediary () monasca-log-api monasca 2.8.0 service cycle-with-intermediary () monasca-notification monasca 1.15.0 other cycle-with-intermediary () monasca-persister monasca 1.13.0 other cycle-with-intermediary () monasca-transform monasca 0.17.0 other cycle-with-intermediary () murano-agent murano 3.6.0 other cycle-with-intermediary (stable:follows-policy) neutron-fwaas-dashboard neutron 2.0.0 horizon-plugin cycle-with-intermediary () neutron-vpnaas-dashboard neutron 1.5.0 horizon-plugin cycle-with-intermediary () openstack-ansible OpenStackAnsible 19.0.0.0b1 other cycle-trailing () os-apply-config tripleo 10.0.0 other cycle-with-intermediary () os-apply-config tripleo 10.1.0 other cycle-with-intermediary () os-apply-config tripleo 10.2.0 other cycle-with-intermediary () os-collect-config tripleo 10.0.0 other cycle-with-intermediary () os-collect-config tripleo 10.1.0 other cycle-with-intermediary () os-collect-config tripleo 10.2.0 other cycle-with-intermediary () os-net-config tripleo 10.0.0 other cycle-with-intermediary () os-net-config tripleo 10.1.0 other cycle-with-intermediary () os-net-config tripleo 10.2.0 other cycle-with-intermediary () os-net-config tripleo 10.3.0 other cycle-with-intermediary () os-refresh-config tripleo 10.0.0 other cycle-with-intermediary () os-refresh-config tripleo 10.1.0 other cycle-with-intermediary () os-refresh-config tripleo 10.2.0 other cycle-with-intermediary () patrole Quality Assurance 0.5.0 other cycle-with-intermediary () paunch tripleo 4.0.0 other cycle-with-intermediary () paunch tripleo 4.1.0 other cycle-with-intermediary () paunch tripleo 4.2.0 other cycle-with-intermediary () paunch tripleo 4.3.0 other cycle-with-intermediary () puppet-tripleo tripleo 10.0.0 other cycle-trailing () puppet-tripleo tripleo 10.1.0 other cycle-trailing () puppet-tripleo tripleo 10.2.0 other cycle-trailing () puppet-tripleo tripleo 10.3.0 other cycle-trailing () python-tripleoclient tripleo 11.0.0 client-library cycle-trailing () python-tripleoclient tripleo 11.1.0 client-library cycle-trailing () python-tripleoclient tripleo 11.2.0 client-library cycle-trailing () python-tripleoclient tripleo 11.3.0 client-library cycle-trailing () senlin-dashboard senlin 0.10.0 horizon-plugin cycle-with-intermediary () solum-dashboard solum 2.6.0 horizon-plugin cycle-with-intermediary () tripleo-common tripleo 10.0.0 other cycle-trailing () tripleo-common tripleo 10.1.0 other cycle-trailing () tripleo-common tripleo 10.2.0 other cycle-trailing () tripleo-common tripleo 10.3.0 other cycle-trailing () tripleo-common tripleo 10.4.0 other cycle-trailing () tripleo-common tripleo 10.5.0 other cycle-trailing () tripleo-common tripleo 10.6.0 other cycle-trailing () tripleo-heat-templates tripleo 10.0.0 other cycle-trailing () tripleo-heat-templates tripleo 10.1.0 other cycle-trailing () tripleo-heat-templates tripleo 10.2.0 other cycle-trailing () tripleo-heat-templates tripleo 10.3.0 other cycle-trailing () tripleo-heat-templates tripleo 10.4.0 other cycle-trailing () tripleo-image-elements tripleo 10.0.0 other cycle-trailing () tripleo-image-elements tripleo 10.1.0 other cycle-trailing () tripleo-image-elements tripleo 10.2.0 other cycle-trailing () tripleo-image-elements tripleo 10.3.0 other cycle-trailing () tripleo-ipsec tripleo 9.1.0 other cycle-with-intermediary () tripleo-puppet-elements tripleo 10.0.0 other cycle-trailing () tripleo-puppet-elements tripleo 10.1.0 other cycle-trailing () tripleo-puppet-elements tripleo 10.2.0 other cycle-trailing () tripleo-ui tripleo 10.0.0 other cycle-with-intermediary () tripleo-ui tripleo 10.1.0 other cycle-with-intermediary () tripleo-ui tripleo 10.2.0 other cycle-with-intermediary () tripleo-ui tripleo 10.3.0 other cycle-with-intermediary () tripleo-validations tripleo 10.0.0 other cycle-with-intermediary () tripleo-validations tripleo 10.1.0 other cycle-with-intermediary () tripleo-validations tripleo 10.2.0 other cycle-with-intermediary () tripleo-validations tripleo 10.3.0 other cycle-with-intermediary () watcher-dashboard watcher 1.12.0 horizon-plugin cycle-with-intermediary () zun-ui zun 3.0.0 horizon-plugin cycle-with-intermediary () -- Matthew Thode

1 0

[infra][cinder] Removal of Cinder 2012.2 from PyPi
by Sean McGinnis 26 Mar '19

26 Mar '19

This is to make sure my request to infra is visible in case there are any concerns. On PyPi we have a "2012.2" release of Cinder. Since our version numbering scheme changed to follow semver, these year-based version tags show up as the latest since the major version is the highest. I would like to have cinder 2012.2 removed from PyPi since this version is surely useless at this point and to avoid any confusion (since there will likely will be enough of that if someone tries to just pip install cinder). Thanks! Sean

6 6

[nova][qa] Does nova need to run the nv tempest-multinode-full job?
by Matt Riedemann 26 Mar '19

26 Mar '19

Nova runs the tempest-multinode-full job as non-voting for some reason: https://github.com/openstack/nova/blob/c993d4fe2ffaadea76d5ae76eedfddc3a4c7… I'm assuming we were running that job initially for live migration testing, but we get that with the voting nova-live-migration and nova-grenade-live-migration jobs. The tempest-multinode-full job is essentially just the tempest-full job with 2 nodes. It doesn't run slow tests. But we have the tempest-slow job which is multinode and runs slow tests only. So it seems we have a lot of overlap between the nova-*live-migration multinode jobs for live migration testing (and evacuate gets tested in the nova-live-migration job as well), the tempest-full single node job, the nova-next single-node job, the tempest-slow job and the non-voting tempest-multinode-slow job, so can we just drop that last one? If someone were really ambitious they could do a diff of the tests that actually get run between say tempest-full/nova-live-migration/tempest-slow and tempest-multinode-full to see if we'd be missing any test coverage. -- Thanks, Matt

2 6

[infra][dev] Options for upcoming git:// to https:// transition
by Ian Wienand 26 Mar '19

26 Mar '19

Hi, In moving repos to OpenDev and a gitea instance [1] we will need to change any git://git.openstack.org references to https://, as gitea does not currently support the native git protocol. First up, from a "gate on fire" point of view, the sky is not falling. Most jobs referencing git repos should be using the local Zuul repositories during their gate CI, and not pulling directly from git. This should minimise issues. Still, we need to fix things up. Some raw numbers: to simply perform a "s|git://git.openstack.org|https://git.openstack.org|" over every openstack/* repository on master and every stable/* branch inside results in ~1200 changes [2]. If we limit that just to projects with a devstack plugin (I would say the main user of git:// urls as every plugin has more or less copied it this way) that's about 420 changes. If you'd like to try it yourself, scripts are at [3]. I can't really categorise this; there's a lot of documentation updates, a lot of devstack plugin changes, a bunch of -1/+1 changes and some weirder ones with manifest files, etc. There was discussion over this in the infra meeting [5]. I think we came up with 3 options: 1. Propose changes now ---------------------- We can propose all these changes to the gate now (slowly, but ultimately in one hit) and let teams review and merge them. Pros: * changes are tested * we get this done _before_ the transition; meaning one less thing * teams get a heads up, can call out anything odd Cons: * sure to be a lot of unrelated gate failures * sure to be a lot of unmerged changes * experience has shown that mass changes can cause confusion. Things happen like others then proposing similar changes or otherwise getting the wrong idea about what is happening. * Ultimately will still be using redirects from openstack.org to opendev.org after transition 2. Merge changes at transition time ----------------------------------- We can have the same changes ready to go, and merge them manually during the transition maintenance period to gitea; bypassing the gate. Pros: * avoids cons of 1 Cons: * one more thing to do during a tricky transition * changes aren't tested. This is a very low risk change; but we all know the xkcd about breaking people's workflows [4] * Ultimately will still be using redirects from openstack.org to opendev.org after transition 3. Merge changes at transition time, with full rename ----------------------------------------------------- Similar to 2, but by timing such that OpenDev gitea will be fully operational we can modify the changes such that they go directly to the OpenDev namespace. This is a more tricky change, essentially (https|git)://git.openstack.org/openstack/project -> https://git.opendev.org/openstack/project Pros: * Pros of 2. * This moves directly to the "final state" Cons: * Cons of 2. * Adds another match, which increases again the risk that things break with the new URLs (internal regex matches, etc). * The "openstack/project" part of the name is, I believe, still under discussion over exactly how we will lay that out, and if projects may have their own namespaces, etc. Adds a synchronization point with this; possible complexity. My personal feeling here is that we have enough to do with the transition, and we would be better to sort this out as much as possible first. Thus I'd suggest we take approach 1 of submitting changes to the gate now. I imagine active projects will appreciate the heads up and merge things quickly. However, given the low risk, I'd suggest we agree on a date to force-merge any outstanding reviews before the cut over. This leaves us relying on the redirects from openstack.org -> opendev.org, but practically there is no way we can avoid having those in place anyway (due to external links), so cleanup of that can be handled by projects asynchronously. Of course, opinions welcome :) I'd suggest we make a concrete decision in the next infra meeting. -i [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.ht… [2] http://paste.openstack.org/show/747762/ [3] https://review.openstack.org/642314 [4] https://xkcd.com/1172/ [5] http://eavesdrop.openstack.org/meetings/infra/2019/infra.2019-03-12-19.01.l…

4 6

[Watcher] Biweekly Watcher meetings
by li.canwei2＠zte.com.cn 26 Mar '19

26 Mar '19

Hi, Watcher team will restart IRC meeting after Stein release. We have meetings in #openstack-meeting-alt channel at 08:00 UTC on odd weeks. If you have any suggestions pls feel free to let us know. Best Regards! Canwei Li

3 2