April 2020 - openstack-discuss - lists.openstack.org

[all][PTL] U Community Goal: Project PTL & Contrib Docs Update #8
by Kendall Nelson 28 Apr '20

28 Apr '20

Hello Everyone! More excellent progress[1] has been made since last week! Again, thank you for all the hard work! Projects missing progress/merged status according to the story[4] are as follows: - Adjutant - Barbican - Cloudkitty - Congress - Cyborg - Ec2-API - Freezer - Heat - Horizon - Karbor - Kuryr - LOCI - Masakari - Mistral - Monasca - Murano - OpenStack Charms - openstack-chef - OpenStackAnsible - OpenStackClient - Oslo - Packaging-RPM - Placement - Puppet OpenStack - Rally - Release Management - Requirements - Senlin - Solum - Storlets - Swift - Tacker - Telemetry - Tricircle - TripleO - Winstackers - Zaqar If you are on this list, please get started IMMEDIATELY. All told, if you are doing the bare minimum of only filling out the template[2] it shouldn't take more than 5-10 minutes per repo. Please add me if you need help with reviews and let me know if there is any other help I can provide. If you have questions about the goal itself, here is the link to that[3]. And as you push patches, please be sure to update the StoryBoard story[4]. Thanks! -Kendall (diablo_rojo) [1] Progress: https://review.opendev.org/#/q/topic:project-ptl-and-contrib-docs+(status:o… [2] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Accepted Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [4] Task Tracking: https://storyboard.openstack.org/#!/story/2007236

1 0

[scientific-sig] IRC Meeting today 2100 UTC - Open Infra labs, Train upgrade experiences
by Stig Telfer 28 Apr '20

28 Apr '20

Hi All, We have a Scientific SIG IRC meeting in #openstack-meeting at 2100 UTC (about 45 minutes). Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_28th_2020 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_28th_2020> This week we have a discussion on the Open Infra Labs project, plus we are looking to share operational experiences on OpenStack Train. Cheers, Stig

1 0

[tripleo] ptg
by Wesley Hayutin 28 Apr '20

28 Apr '20

Greetings, Just a reminder to review the TripleO time slots for PTG [1] Looking for feedback on the times. We'll start a schedule etherpad for folks to align their topics to a particular time slot soon. Note, the time slot for Q&A or really anything for folks not able to join the 13-17UTC time slot. Thanks [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.opendev.org/p/tripleo-victoria-topics

1 0

Announcing the general availability of Debian packages for Ussuri
by Thomas Goirand 28 Apr '20

28 Apr '20

Hi, Even after 9 years packaging OpenStack, I'm still excited to announce the availability of the last release of OpenStack in Debian. Indeed, today, I was able to launch my first VM using Ussuri, running on top of Debian Buster. Even if we haven't run Tempest on this release yet, it's already usable, and I wanted everyone to know about it. Packages are available either from Debian Experimental (they will be uploaded to Unstable the day of the official release, then hopefully migrate automatically to Debian Testing) or from the debian.net backports to Buster, from both of these repos: deb http://buster-ussuri.debian.net/debian buster-ussuri-backports main deb-src http://buster-ussuri.debian.net/debian buster-ussuri-backports main deb http://buster-ussuri.debian.net/debian buster-ussuri-backports-nochange main deb-src http://buster-ussuri.debian.net/debian buster-ussuri-backports-nochange main *OR* from this server (which contains all release of OpenStack since the Kilo release): deb http://osbpo.debian.net/debian buster-ussuri-backports main deb-src http://osbpo.debian.net/debian buster-ussuri-backports main deb http://osbpo.debian.net/debian buster-ussuri-backports-nochange main deb-src http://osbpo.debian.net/debian buster-ussuri-backports-nochange main Please make sure to configure your servers to use *both* buster-ussuri-backports and buster-ussuri-backports-nochange suites. The first one contains packages maintained by the Debian OpenStack team, while the later are backports of packages maintained by other people in Debian (like those maintained in the Debian Python Module Team, but not only). Still missing from this release... - vitrage-dashboard: There's some new XStatic packages to make, work is ongoing. - some neutron plugins: Many aren't released yet... - heat: It just got released a few hours ago, and I didn't have time yet to figure out what's wrong with these 3 unit tests: http://paste.openstack.org/show/792781/ Hopefully, this will be addressed tomorrow. Note that OCI, the Debian cluster installer for OpenStack, already supports that version (that's how I launched my first instance), and is running the latest version of all puppet modules of puppet-openstack: https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer Some fun statistics: 187 packages were updated in the OpenStack team's Git repository to make this release (plus some updates of packages not within the team). Note that the last piece of software (cinder) was converted to uwsgi, so this release comes with absolutely all API servers running under uwsgi. Please try these packages and report bugs to the Debian BTS as usual, so we can fix as many bugs as possible before the final release. Some packages are still waiting for the FTP master's approval before they can reach Debian proper. Noticeably, many Tempest plugins (as I decided to package them all in Debian). 6 of these are pending, and probably more will be packaged. Stay tuned. Cheers, Thomas Goirand (zigo)

5 5

[neutron] Low-throughput over high-latency connections
by Eric K. Miller 28 Apr '20

28 Apr '20

Hi, I'm at a loss after quite a bit of testing, so thought I'd see if someone has any ideas... We have a Stein cluster that was/is deployed with Kolla Ansible with DVR without OVS+DPDK - rather just the standard kernel OVS. Everything appears to work well with low-latency local and Internet destinations, but as the latency increases, throughput drops significantly. I would have blamed the standard bandwidth-delay product and TCP window size not being large enough, etc., but that definitely isn't the issue, since we have shown that VMs on our VMware clusters (VLAN-based, not NSX-based) do not have the issue and use the same many-10Gbps-connected ISPs to our routers as the OpenStack configuration. I am using a Vultr machine in London as a test destination since the latency is around 86ms - a good high-latency test. The good environment we are testing against: Using iperf3 with 1 thread on a VMware VM results in an average of 155Mbits/sec sent to Vultr London with a few retries recorded that lower the window size to around 1.78MiBytes. This is roughly what we expect, if not more, with faster machines. The problem: Performing the same test on a "much" faster server (E-2288G based, without hyperthreading enabled, so 4.5GHz on all 8 cores), with no other VMs on it, a VM with iperf3 with 1 thread results in an average of only around 32Mbits/sec with a window size that drops significantly at the start and increases to only about 386KiBytes before retries start to happen. This average does not change when using other machines in our cluster, including some Xeon Gold and EPYC processor machines. The only thing I can point to is OVS and/or something in Linux. However, both tests (VMware and KVM) were performed with the same fresh installation and configuration (CentOS 7 with all updates and the standard kernel). So, my doubts are that it has something to do with Linux. On the physical host, the vhost process barely registers any CPU usage, and neither does the VM - as expected on such a fast machine. I even tried to enable multiqueue, since we had it disabled. With a 2 vCPU VM, ethtool -l eth0 displays that 2 queues are in use. Same results - 32Mbits/sec throughput to Vultr London. All machines are connected via 100Gbps or 25Gbps connections with Mellanox Connect-X 4 and 5 cards with Mellanox switches, and iperf can saturate these links between the physical hosts when run on the physical hosts' CentOS. No errors (tx errors, rx errors, packet loss, etc.) are being reported on any of the logical or physical links. I thought a queue got full somewhere, so I looked for where queues were used and found that virtio has a tx_queue_size that can be adjusted, but unfortunately, it appears this can only be done with vhost-user, which I believe is specific to OVS+DPDK. The default tx_queue_size in virtio is 256 elements. I'm not sure what this represents, though, much less how to measure the queue usage statistics. Running iperf3 in "Reverse mode", so the Vultr London machine sends data back to the KVM VM, bandwidth averages around 254Mbits/sec! So the issue appears to be only in one direction - sending network traffic outbound. Running the same iperf3 test from the KVM VM to a Vultr machine that is very close to us (latency of 2ms or so), results in an average bandwidth of 373Mbits/sec, but with 39 retries per second on average. The window size never adjusts low enough to stop the retries - it averages 146KiBytes in size. Using "Reverse mode" results in an average of 1.21Gbits/sec! So, the OVS software isn't slow, but something is causing issues when transmitting data when latency is large - something that doesn't happen with the VMware VMs with the same network and Internet connections. Also, pings from the VMware and KVM VMs are nearly identical - so there isn't some crazy amount of latency caused by OVS - at least when it is essentially idle. I'm not sure where to go from here in terms of diagnostics. Any ideas? Thanks for any help, in advance! Eric

1 0

[tc][puppet][Glare] Propose retirement of puppet-glare
by Takashi Kajinami 27 Apr '20

27 Apr '20

Hi, Currently Glare[1] project is located under x instead of openstack, and IIUC this means that Glare is no longer maintained and has been retired already. [1] https://opendev.org/x/glare Regarding its status, I'll propose to retire puppet-glare[2] because it doesn't make sense to maintain a puppet module for the retired project. [2] https://github.com/openstack/puppet-glare May I ask TC to confirm my understanding about Glare project status ? Also, please let me know if anybody has concern with retiring puppet-glare. Thank you, Takashi Kajinami

4 4

[all] Virtual PTG Tooling Requirements & Suggestions
by Kendall Nelson 27 Apr '20

27 Apr '20

Hello Everyone :) We want to get your input on tooling for the PTG. We have a general idea of what we have for requirements, but wanted to get the community's input- i.e. make sure we aren't missing any. Here is the list of requirements we have right now[1]. Also, if anyone has suggestions of tools that meet these criteria, we would love to hear them! We are gathering and vetting options for the event and want to make sure nothing gets overlooked. -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/virt-ptg-requirements

4 3

Openstacksdk
by Tom Schoonjans 27 Apr '20

27 Apr '20

Hi all, I am trying to use the openstacksdk to get a list of my projects. I have not been successful at doing this, as it always tries to get all projects, which doesn’t work for me as I am not an admin: the error message I get is "Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed." This is certainly possible though, because it works fine with the client: openstack project list --my-projects Any thoughts on how I can accomplish this? Many thanks in advance, Tom

1 0

trove image
by 会水的鸟 27 Apr '20

27 Apr '20

您好：     我在使用openstack trove镜像时，一直处于build状态，我应该如何解决。      镜像链接：      https://tarballs.opendev.org/openstack/trove/images/trove-train-mysql-ubuntu-xenial-dev.qcow2                                                                                                                         谢谢 hello：     When I was using the openstack trove image，Always in build state，What should I do。     https://tarballs.opendev.org/openstack/trove/images/trove-train-mysql-ubunt…                                                                                                                             thank you

2 4

[ironic]: multiple compute nodes
by fsbiz＠yahoo.com 27 Apr '20

27 Apr '20

Hi folks, We are seeing some weird issues with multiple compute nodes and would appreciate your thoughts. Background:We are on stable Queens.As part of an upgrade to accomodate 3X more servers, we decided to add three more compute nodes+ three more ICs for a total of 6 compute nodes and 6 ICs.As soon as we added these in preparation for the 3X increase in servers I am seeing weirdbehaviour. A general question to everyone:How many of you run your baremetal clouds with 5+ computes and ICs?Are things stable with the setup ? Logs and Analysis:all compute and conductor services are up and running. 1) Baremetal node c1bda753-d46c-4379-8d07-7787c2a4a7f2 mapped to sc-ironic08root@stg-cl1-dev-001:~# openstack hypervisor show c1bda753-d46c-4379-8d07-7787c2a4a7f2 | grep ironic | | service_host | sc-ironic08.nvc.nvidia.com 2)Mac address is 6c:b3:11:4f:8a:c0root@stg-cl1-dev-001:~# openstack baremetal port list --node c1bda753-d46c-4379-8d07-7787c2a4a7f2+--------------------------------------+-------------------+| UUID | Address |+--------------------------------------+-------------------+| a517fb41-f977-438d-8c0d-21046e2918d9 | 6c:b3:11:4f:8a:c0 |+--------------------------------------+-------------------+ 2)Provisioning starts: ironic06 receives the VIF update: WHY ?2020-04-21 15:05:47.509 71431 INFO ironic.conductor.manager VIF 657fea31-3218-4f10-b6ad-8b6a0fa7bab8 successfully attached to node c1bda753-d46c-4379-8d07-7787c2a4a7f2 ironic08 (correct one) also receives updates.[root@sc-ironic08 master_images]# tail -f /var/log/ironic/ironic-conductor.log | grep c1bda753-d46c-4379-8d07-7787c2a4a7f22020-04-21 15:08:04.943 27542 INFO ironic.conductor.task_manager [req-259b0175-65bc-4707-8c88-a65189a29954 - - - - -] Node c1bda753-d46c-4379-8d07-7787c2a4a7f2 moved to provision state "deploying" from state "wait call-back"; target provision state is "active" For now we have backed down to 3 and are stable again but I would really like to overprovision our computes and conductors if possible. Please let me know your thoughts and if anything rings a bell. thanks,Fred.

3 4

[glance][ptg[ Virtual PTG
by Abhishek Kekane 27 Apr '20

27 Apr '20

Hi Stackers, As you have noticed due to the current Covid-19 situation we will be having a virtual PTG for Victoria [1]. The PTG will take place from 1st to 5th June 2020 with various slots [2]. So I created a doodle to ask You what would be the best time slots for You to participate - it's available at [3]. If You are planning to attend this event, please mark what time slots are best for You. I will try to book some slots to fit the needs of the team. If You can attend only on some specific slots, and You will have some topics to discuss, we can try to book some slots in time which will work for You and schedule discussions about Your topics on that slot. As we should book slots in about next 2 weeks, it would be great if You could do this doodle before e.g. end of next week (Friday 24th of April). We also have our etherpad [4] - please add Your name to it (at top) if You are planning to attend this virtual event. And please also add proposals of the topics which You want to be discussed there. If you have any suggestions or doubt you can ping me on IRC (abhishekk) or any glance core member at #openstack-glance. I will compile the responses on 24th April and will book the slots accordingly. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://doodle.com/poll/6a46283tii7gt2aa [4] https://etherpad.opendev.org/p/Glance-Victoria-PTG-planning Thanks & Best Regards, Abhishek Kekane

1 2

[release] Ussuri for vitarge
by Eyal B 27 Apr '20

27 Apr '20

Hi, Is there a reason Vitrage, vitrage client and vitrage-dashboard didn't get a patch for creating the Ussuri branch ? Eyal

2 1

[neutron] Bug deputy report for week of April 20th
by Nate Johnston 27 Apr '20

27 Apr '20

Nate bug deputy notes - 2020-04-20 to 2020-04-27 ------------------------------------------------ Untriaged: - "[VPNaas-DVR]The Traffic is unreachable after the virtual machine is bound to the floating IP" * URL: https://bugs.launchpad.net/bugs/1874392 * Note: Need a VPNaaS expert to look at this one. - "After the vm unbinds the floating ip, there are residual ip rules in the qrouter namespace" * URL: https://bugs.launchpad.net/bugs/1874420 * Version: stable/stein * Unable to reproduce locally Critical: - "[stable/stein] Neutron-tempest-plugin jobs are failing due to wrong python version" * URL: https://bugs.launchpad.net/bugs/1873776 * Version: stable/stein * Assignee: bcafarel * Fix: https://review.opendev.org/721277 - "[L3HA] Keepalived 2.x.x tracks state of virtual_ipaddresses interfaces and router now" * URL: https://bugs.launchpad.net/bugs/1874211 * Assignee: slaweq * Fix: https://review.opendev.org/721799 https://review.opendev.org/721805 High: - "[OVN] Tempest test neutron_tempest_plugin.scenario.test_trunk.TrunkTest.test_trunk_subport_lifecycle fails randomly" * URL: https://bugs.launchpad.net/bugs/1874447 * Unassigned - "[OVN] Stale ports can be present in OVN NB leading to metadata errors" * URL: https://bugs.launchpad.net/bugs/1874733 * Assignee: maciejjozefczyk/lucasgomes * Fix: https://review.opendev.org/722789 https://review.opendev.org/723404 Medium: - "test_multicast_between_vms_on_same_network failures" * URL: https://bugs.launchpad.net/bugs/1873798 * Assignee: lucasgomes * Fix: https://review.opendev.org/721262 - "[OVN] extra_dhcp_opts does not validate any options" * URL: https://bugs.launchpad.net/bugs/1874282 * Assignee: lucasgomes * Fix: https://review.opendev.org/722025 - "Cleanup in neutron_tempest_plugin.api.admin.test_external_network_extension.ExternalNetworksRBACTestJSON may fail in dvr deployments" * URL: https://bugs.launchpad.net/bugs/1875344 * Assignee: slaweq * Fix: https://review.opendev.org/723387 Low: - "[agent][dhcp] When revision_number matches the one in cache it is not considered stale" * URL: https://bugs.launchpad.net/bugs/1874400 * Unassigned Invalid/Incomplete: - "Cannot create fip namespace when dhcp pool is insufficient" * URL: https://bugs.launchpad.net/bugs/1875153 Last week's report by tidwellr: http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014332.ht…

1 0

[ops][cinder] Policy for volume attach/detach
by Massimo Sgaravatto 27 Apr '20

27 Apr '20

I would like to set a policy so that attachments operations can be done only by the user who created that volume. To do that I created this [*] policy.yaml file. I verified that with such policy file: - I am able to attach volumes only for the volumes I created - I can attach my volumes also to instances owned by other users - I can not attach volumes belonging to other users to my instances So far so good. But I am allowed to detach any volume from any instance, even if I am not the owner of that volume, and this is not what I want What am I doing wrong ? Thanks, Massimo [*] # # To be used when another member of the same project can't change something # created by another user of the same project "admin_or_user": "is_admin:True or (role:admin and is_admin_project:True) or user_id:%(user_id)s" # Create attachment. # POST /attachments "volume:attachment_create": "rule:admin_or_user" # Update attachment. # PUT /attachments/{attachment_id} "volume:attachment_update": "rule:admin_or_user" # Delete attachment. # DELETE /attachments/{attachment_id} "volume:attachment_delete": "rule:admin_or_user" # Mark a volume attachment process as completed (in-use) # POST /attachments/{attachment_id}/action (os-complete) "volume:attachment_complete": "rule:admin_or_user"

2 2

[neutron] Virtual PTG planning
by Slawek Kaplonski 26 Apr '20

26 Apr '20

Hi neutrinos, As You probably noticed, there is already plan for Virtual PTG in June. See mail from Kendall [1] for details. So I created doodle to ask You what would be the best time slots for You to participate - it's available at [2]. If You are planning to attend this event, please mark what time slots are best for You. I will try to book some slots to fit needs of the team. If You can attend only on some specific slots, and You will have some topics to discuss, we can try to book some slot in time which will work for You and schedule discussions about Your topics on that slot. As we should book slots in about next 2 weeks, it would be great if You could do this doodle before e.g. end of next week (Friday 24th of April). BTW, we also have our etherpad [3] - please add Your name to it if You are planning to attend this virtual event. And please also add proposals of the topics which You want to be discussed there. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://doodle.com/poll/xcd82ea6svs5dben [3] https://etherpad.opendev.org/p/neutron-victoria-ptg -- Slawek Kaplonski Senior software engineer Red Hat

2 2

[release] Release countdown for week R-2, April 27 - May 1
by Sean McGinnis 25 Apr '20

25 Apr '20

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the Ussuri deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/ussuri branch creation for all deliverables that have not branched yet, using the latest available Ussuri release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/ussuri branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/ussuri branch before releasing out of the stable/ussuri branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for Victoria development, though the focus should still be on finishing up Ussuri until the final release. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final Ussuri release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the Ussuri version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: May 7 (R-1 week) Final Ussuri release: May 13 Virtual Victoria PTG: June 1-5

2 1

[goals][Drop Python 2.7 Support] Week R-3 Update
by Ghanshyam Mann 25 Apr '20

25 Apr '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-3 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * Storlets is also keeping py2.7 support. py2.7 drop patches are reverted. * Aduit is finished and missing repos patches are also proposed. * Requesting projects listed below to merge the open patches asap. Project not completed the py2.7 drop: ============================ * adjutant-ui: https://review.opendev.org/#/c/714636/ * pythonclient: ** python-barbicanclient: https://review.opendev.org/#/c/699096/ *** gate is already broken. The last patch merged in this repo was 6 months ago so I am not sure it is maintained or not. ** python-zaqarclient: https://review.opendev.org/#/c/692011/ *** This also the same story, not maintained and job is broken already. ** python-adjutantclient https://review.opendev.org/#/c/723128/ * Deployment projects: *** Openstack Charms - Most of them merged, few failing on func job. *** Openstackansible - Centos7 jobs are failing on a few projects. *** Openstack-Helm - No conclusion yet on what else to do from Helm team. *** TripleO: Below repo are found to drop py2.7 during audit **** paunch: https://review.opendev.org/#/c/700560/ **** https://review.opendev.org/#/c/723125/ **** https://review.opendev.org/#/c/723126/ **** https://review.opendev.org/#/c/723127/ * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: I did the audit and found a few repos were missed. I have proposed the patches for those (listed above). All other projects have complete the work. I will discuss with the requirement team is anything needs to be done on the requirement side. I feel we should keep going with py2.7 cap in u-c. -gmann

1 0

[openstack-dev] [Tacker]
by Ivandro 24 Apr '20

24 Apr '20

Hello, I have been trying to install the tacker project in a VM, following the instruction from this url: https://docs.openstack.org/tacker/train/install/devstack.html based on devstack but unsuccessful. Is there a link to download an already installed VM with tacker? BR

6 15

Re: [release-announce] keystone_tempest_plugin 0.4.0 (ussuri)
by Thomas Goirand 24 Apr '20

24 Apr '20

On 4/23/20 9:32 PM, no-reply(a)openstack.org wrote: > We are amped to announce the release of: > > keystone_tempest_plugin 0.4.0: Tempest plugin keystone_tempest_plugin > > This release is part of the ussuri release series. > > The source is available from: > > https://opendev.org/openstack/keystone_tempest_plugin This one also has underscores instead of dashes... :/ Thomas

2 1

[user committee] Survey tool research
by Dincer Celik 24 Apr '20

24 Apr '20

Hi everyone! As Kolla project, we are looking for a survey tool to get feedback from our users. We are now on the comparison stage of some popular tools and would like to ask what user committee uses for the user surveys. The current tool seems hard coded to website but I would like to ask if it could be used for a custom survey. Best regards, Dincer

2 1

[octavia] Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 24 Apr '20

24 Apr '20

> Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/8831fb0606114aae904ba66386b0b0eb : FAILURE in 4m 26s > - publish-tox-docs-releases https://zuul.opendev.org/t/openstack/build/None : SKIPPED > This was a failure during the tag processing for the Octavia repo. There are a few steps that are done when a new branch is created for a repo. These are typically: 1. Update the .gitreview file on the new stable branch to include the setting pointing at the right branch. 2. Updating any upper-constraints links to point to the stable branch version of those constraints. 3. Add a new release notes landing page for the stable branch in the master release notes index. 4. Switch the python3 series jobs on master to the new series (ussuri > victoria). The first step completed successfully. The second step failed due to some repo specific files checks for constraints urls. The job has typically only updated constraints in tox.ini, but handling was added for other files used in this repo. Those files were updated, but the change missed the step of adding those files before committing and attempting to push up the review. Since git review does a rebase by default when submitting, git errored out due to the presence of unstaged files. That step has now bee manually submitted: https://review.opendev.org/#/c/722489/ And the fix for the job that caused the failure has been submitted with: https://review.opendev.org/#/c/722491/ The third step has been manually submitted with: https://review.opendev.org/#/c/722492/ And step four with: https://review.opendev.org/#/c/722493/ Everything should be set now. The skipped docs job will be caught up with the next merged release, so we should be good. If there are any issues that crop up from this, just let me know. Sean

2 1

Re: [release-announce] telemetry_tempest_plugin 1.0.0 (ussuri)
by Thomas Goirand 24 Apr '20

24 Apr '20

On 4/22/20 3:28 PM, no-reply(a)openstack.org wrote: > We are happy to announce the release of: > > telemetry_tempest_plugin 1.0.0: Tempest plugin for Telemetry Projects > > This release is part of the ussuri release series. > > The source is available from: > > https://opendev.org/openstack/telemetry_tempest_plugin Wrong link, it's with dashes, not underscores. I'm not sure where this gets fixed... Thomas Goirand (zigo)

3 2

[tc][tacker]Poll for Tacker PTL role
by Rico Lin 23 Apr '20

23 Apr '20

Hi all As Tacker team decided in meeting today [1] We will run an election inner Tacker team and provide one name for TCs to appoint as PTL The candidate list includes: * Hyunsik Yang ( http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014045.ht… ) * Yasufumi Ogawa ( http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014044.ht… ) The election will end at 2020/04/23 23:59 UTC. Please vote before that time. If you commit to Tacker project within a year, you should receive an email with civs link for voting. If you're a valid voter but didn't receive any email. Please contact me with links to your contribution and I'm more than happy to fix that for you. [1] http://eavesdrop.openstack.org/meetings/tacker/2020/tacker.2020-04-21-08.00…

2 2

[cinder] victoria virtual PTG time slots
by Brian Rosmaita 23 Apr '20

23 Apr '20

I've signed up Cinder for the following timeslots in the "Havana" room for the Victoria virtual PTG: Tuesday, June 2: 13:00-16:00 UTC Wednesday, June 3: 13:00-16:00 UTC Thursday, June 4: 13:00-16:00 UTC Friday, June 5: 13:00-16:00 UTC Not very creative (same 3 hour period each day), but I couldn't find a better solution. Details on the planning etherpad if you want to see if you can come up with something better: https://etherpad.opendev.org/p/cinder-victoria-ptg-planning cheers, brian

1 0

Re: [Release-job-failures] Pre-release of openstack/mistral-dashboard for ref refs/tags/10.0.0.0rc1 failed
by Thierry Carrez 23 Apr '20

23 Apr '20

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python https://zuul.opendev.org/t/openstack/build/dacb9f52eaa345b397a28e6dcdf54187 : SUCCESS in 3m 49s > - announce-release https://zuul.opendev.org/t/openstack/build/254ac00652174e60869fd1caa11ab261 : FAILURE in 6m 34s > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/1a94db3e1ad5473ab4814555ac9b2df4 : SUCCESS in 3m 27s Transient failure ("Temporary local problem") sending email: + send-mail -v /home/zuul/relnotes/mistral-dashboard-10.0.0.0rc1 send: 'ehlo [127.0.0.1]\r\n' reply: b'250-lists.openstack.org Hello [127.0.0.1] [108.44.198.35]\r\n' reply: b'250-SIZE 52428800\r\n' reply: b'250-8BITMIME\r\n' reply: b'250-PIPELINING\r\n' reply: b'250 HELP\r\n' reply: retcode (250); Msg: b'lists.openstack.org Hello [127.0.0.1] [108.44.198.35]\nSIZE 52428800\n8BITMIME\nPIPELINING\nHELP' send: 'mail FROM:<no-reply(a)openstack.org> size=1098\r\n' reply: b'250 OK\r\n' reply: retcode (250); Msg: b'OK' send: 'rcpt TO:<release-announce(a)lists.openstack.org>\r\n' reply: b'451 Temporary local problem - please try later\r\n' reply: retcode (451); Msg: b'Temporary local problem - please try later' This was for mistral-dashboard rc1, I think we can survive that announce not being sent. -- Thierry Carrez (ttx)

2 2