- openstack-discuss - lists.openstack.org

[TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK?
by Marios Andreou 19 Jan '21

19 Jan '21

Hello TripleO I would like to propose that we move all tripleo stable/rocky repos [1] to "unmaintained", with a view to tagging as end-of-life in due course. This will allow us to focus our efforts on keeping the check and gate queues green and continue to deliver weekly promotions for the more recent and active stable/* branches train ussuri victoria and master. The stable/rocky repos have not had much action in the last few months - I collected some info at [2] about the most recent stable/rocky commits for each of the tripleo repos. For many of those there are no commits in the last 6 months and for some even longer. The tripleo stable/rocky repos were tagged as "extended maintenance" (rocky-em) [2] in April 2020 with [3]. We have already reduced our CI commitment for rocky - these [4] are the current check/gate jobs and these [5] are the jobs that run for promotion to current-tripleo. However maintaining this doesn’t make sense if we are not even using it e.g. merging things into tripleo-* stable/rocky. Please raise your objections or any other comments or thoughts about this. Unless there are any blockers raised here, the plan is to put this into motion early in January. One still unanswered question I have is that since there is no ‘unmaintained’ tag, in the same way as we have the <release>-em or <release-eol> for extended maintenance and end-of-life, do we simply _declare_ that the repos are unmaintained? Then after a period of “0 to 6 months” per [6] we can tag the tripleo repos with rocky-eol. If any one reading this knows please tell us! Thanks for reading! regards, marios [1] https://releases.openstack.org/teams/tripleo.html#rocky [2] http://paste.openstack.org/raw/800464/ [3] https://review.opendev.org/c/openstack/releases/+/709912 [4] http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-in… [5] http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullsc… [6] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena…

3 5

Ironic Midcycle - Three time windows next week
by Julia Kreger 19 Jan '21

19 Jan '21

Greetings everyone, Given we have a global community, I think the statement "Scheduling is hard" is definitely one of those things that we've all had to learn over the years. Luckily we have some time slots where many of the participants have indicated they will be able to attend. From that, it appears that the following times seem in terms of trying to cover time zones as well as including participants that have expressed interest. Monday January 25th @ 5PM - 6PM UTC / 9AM - 10AM US Pacific Tuesday January 26th @ 8 PM - 9PM UTC / 12:00 PM - 1 PM Pacific Wednesday January 27th @ 3PM - 4PM UTC / 7AM - 8AM US Pacific We will meet in MeetPad[0], and the etherpad is still open if more topics wish to be added, although we cannot guarantee we will get to them. I've also tried to spread them up across days in order to try and make efficient use of the time. Thanks everyone, and see you there. -Julia [0]: https://meetpad.opendev.org/ironic [1]: https://etherpad.opendev.org/p/ironic-wallaby-midcycle

1 0

Openstack integration with NSX-T
by ali ali 18 Jan '21

18 Jan '21

Hi. I use Openstack train version and I want to integrate openstack with nsx-t. I only found the following documentation. https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/nsxt-openstack-plug… and at the start of integration, I install, following packages apt install python-vmware-nsxlib openstack-vmware-nsx python-neutron-fwaas outputs: E: Unable to locate package openstack-vmware-nsx The following packages have unmet dependencies: python-neutron-fwaas : Depends: python-neutron (>= 2:12.0.0~) but it is not going to be installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). when I checked there are no python-neutron packages but there was a python3-neutron package. I don't know what to do with this problem. I think if I delete python3-neutron and install python-neutron, everything will crash and mess up. is it basicly possible to integrate openstack train or ussuri or victoryia with nsx-t?

3 2

[tc] weekly update
by Mohammed Naser 18 Jan '21

18 Jan '21

Hi everyone, Here’s an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Ke Chen as Watcher's PTL https://review.opendev.org/c/openstack/governance/+/770913 - Drop openSUSE from commonly tested distro list https://review.opendev.org/c/openstack/governance/+/770855 - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - WIP NO MERGE Move os-*-config to Heat project governance https://review.opendev.org/c/openstack/governance/+/770285 ## Project Updates - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 ## General Changes - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 # Other Reminders - Our next [TC] Weekly meeting is scheduled for January 21st at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 20th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[neutron] bug deputy report January 11th to 17th
by Miguel Lavalle 18 Jan '21

18 Jan '21

Hi, Here is this week's bugs deputy report: Critical ====== https://bugs.launchpad.net/neutron/+bug/1911128 Neutron with ovn driver failed to start on Fedora. Needs owner Medium ====== https://bugs.launchpad.net/neutron/+bug/1911153 [FT] DB migration "test_walk_versions" failing frequently. Owner ralonsoh https://bugs.launchpad.net/neutron/+bug/1911214 Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job. Needs owner https://bugs.launchpad.net/neutron/+bug/1910946 ovs is dead but ovs agent is up. Owner Norman Shen. Patch https://review.opendev.org/c/openstack/neutron/+/770058 https://bugs.launchpad.net/neutron/+bug/1911462 Optimize "PortForwarding" OVO loading. Owner Rodolofo Alonso. Patch: https://review.opendev.org/c/openstack/neutron/+/770654 https://bugs.launchpad.net/neutron/+bug/1911925 [FT] "test_read_queue_change_state" failing to initialize the keepalived-state-change monitor. Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770950 https://bugs.launchpad.net/neutron/+bug/1911927 [FT] "test_add_and_remove_multiple_ips" failing while decoding the JSON file returned by "ip_monitor". Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770983 https://bugs.launchpad.net/neutron/+bug/1911132 OVN mech driver - can't find Logical_Router errors. Needs owner RFE === https://bugs.launchpad.net/neutron/+bug/1911126 [RFE][L3] add ability to control router SNAT more granularly. Under discussion https://bugs.launchpad.net/neutron/+bug/1911864 [DHCP] AgentBinding for network will be created no matter the state

1 0

[$nova] [$horizon] openstack host show statistics
by Nagaraj Akkina 18 Jan '21

18 Jan '21

Hello, Openstack host show compute-host, shows more memory allocated to instances than actual physical memory, although the memory allocation ratio is 1.0 in nova.conf, the same is also shown in horizon dashboard hypervisor statistics. We can see this in many compute nodes in the cluster. Also these statistics does not match with free -g or cat /proc/meminfo. For Example : Memory_mb | compute-node23 | (total) | 257915 | | compute-node23 | (used_now) | 271360 | | compute-node23 | (used_max) | 267264 | How to avoid misleading statistics, also which statistics are actually correct? versions : openstack : Stein nova : 2:19.3.0-0ubuntu1~cloud0 Regards, Akkina

2 1

[nova] MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION bumps in Wallaby
by Lee Yarwood 16 Jan '21

16 Jan '21

Hello all, We are once again looking to increase the minimum and next minimum versions of libvirt and QEMU in the libvirt virt driver. These were previously increased late in the Victoria cycle: MIN_LIBVIRT_VERSION = (5, 0, 0) MIN_QEMU_VERSION = (4, 0, 0) NEXT_MIN_LIBVIRT_VERSION = (6, 0, 0) NEXT_MIN_QEMU_VERSION = (4, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/746981 I am now proposing the following updates to these versions in Wallaby: MIN_LIBVIRT_VERSION = (6, 0, 0) MIN_QEMU_VERSION = (4, 2, 0) NEXT_MIN_LIBVIRT_VERSION = (7, 0, 0) NEXT_MIN_QEMU_VERSION = (5, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/754700 libvirt v6.0.0 and QEMU 4.2.0 being supported by the three LTS releases supported by the Wallaby release of OpenStack [1][2]. libvirt v7.0.0 and QEMU 5.2.0 being slightly aspirational for the next minimum versions at this point but given current releases for both projects they seem appropriate for the time being. Please let me know ideally in the review if there are any issues with this increase. Regards, [1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

3 2

[all] https://github.com/OpenStackweb/openstack-org
by Kanevsky, Arkady 15 Jan '21

15 Jan '21

Looking at out current website code I wonder if we should 1. Reword to be OpenInfra not just OpenStack or even move to new repo for OpenInfraWeb? 2. Keep it to be dedicated to OpenStack and create a parent Web for OpenInfra. That parent page will point to all projects under OpenInftastructure umbrella? In related question, should we also create openinfra-discuss mail list? Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 1

[oslo][release] etcd3gw release model - series vs independent
by Herve Beraud 15 Jan '21

15 Jan '21

Greetings Osloers, etcd3gw was moved under the Oslo team's scope a few months ago [1][2]. This project hasn't yet been released by us and we should choose to release it either during Wallaby or to make it an independent [3] project. I didn't see significant changes merged since the project transition, so I think we could directly adopt the independent model for etcd3gw. However I want first to discuss this with all the core maintainers before and then I'll act accordingly. Notice that Wallaby Milestone 2 is next week, so it could be a good time for us to decide to continue with a coordinated series or to adopt the independent model directly. Let me know what you think about that. Thanks, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016457.h… [2] https://governance.openstack.org/tc/reference/projects/oslo.html#etcd3gw [3] https://releases.openstack.org/reference/release_models.html#independent -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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-----

3 2

[tripleo] next irc meeting Tuesday Jan 19 @ 1400 UTC in #tripleo
by Marios Andreou 15 Jan '21

15 Jan '21

Reminder that the next TripleO irc meeting is: ** Tuesday 19th January at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 05 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-05-14.… Hope you can make it on Tuesday, thanks, marios

1 0

[tripleo] TripleO CI Summary: Unified Sprint 37 and 38
by Bhagyashri Shewale 15 Jan '21

15 Jan '21

Greetings, The TripleO CI team has just completed **Unified Sprint 36 and 37** (Dec 04 to Jan 13). The following is a summary of completed work during this sprint cycle: - Component standalone-upgrade added to tripleo component: 1. https://review.rdoproject.org/zuul/builds?job_name=periodic-tripleo-ci-cent… - Docs https://review.opendev.org/c/openstack/tripleo-docs/+/767375 https://docs.openstack.org/tripleo-docs/latest/ci/stages-overview.html - Reduce content-providers in upgrade job layouts: https://review.opendev.org/q/topic:reduce-content-providers - Improve tripleo-upgrade repo job coverage: https://review.opendev.org/q/topic:tripleo-upgrade-provider-jobs-coverage - (content providers) remove registry_ip_address: https://bugs.launchpad.net/tripleo/+bug/1904565 https://review.opendev.org/c/openstack/tripleo-ci/+/764359 - Build report for container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Added a build report for the container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Promoter configuration fix: https://review.rdoproject.org/r/#/c/28014/ - rpm diff comparison script added to dependency jobs logs: https://github.com/rdo-infra/ci-config/commit/bf829ed2b7bda23d85d5128907147… - centos 8 stream: - rpm comparison skip list was updated with release delivery's help: https://github.com/rdo-infra/ci-config/commit/ca144362ee520dbd6e89f1e23dcb8… - branch jobs were added: victoria, ussuri, train - dependency lines now run with a controller job for rpm comparisons - working to get the stream jobs running on stream nodes https://bugs.launchpad.net/tripleo/+bug/1910791 https://review.rdoproject.org/zuul/builds?pipeline=openstack-dependencies-c… - Provisioning via metalsmith in 16.2 and created a new job for it in 16.2 component pipeline https://review.opendev.org/c/openstack/tripleo-ci/+/769469 - Stable version of scenario manager. Apart from that, https://review.opendev.org/c/openstack/tempest/+/766472 https://review.opendev.org/c/openstack/tempest/+/766015 - Writing unit test cases for the cockpit (telegraf container and moving scipts from py2 to py3 directory). https://review.rdoproject.org/r/#/c/30492/ - Done https://review.rdoproject.org/r/#/c/31442/ - Work in progress - Working on Promoter Stuff (Get familiar with the new promoter code). https://review.rdoproject.org/r/#/c/31318/ - Done - Released 1.2.1 version of Openstack Ansible collections: https://opendev.org/openstack/ansible-collections-openstack - Released 1.4.0 and 1.4.1 versions of Podman Ansible collections: https://github.com/containers/ansible-podman-collections - Created OSP 13 and OSP 16.2 jobs in CI that run Openstack Ansible collections tests to ensure collections work on these OSP versions. - Enable dracut list installed modules https://review.opendev.org/c/openstack/diskimage-builder/+/766232 - Collect dnf module related infos - https://review.opendev.org/c/openstack/ansible-role-collect-logs/+/768595 - still working on finishing copy-quay role: https://review.rdoproject.org/r/#/c/31395/ - Bugs related to os_tempest that is affecting upgrade jobs: https://bugs.launchpad.net/tripleo/+bug/1911020 - add test command on tempest-skip list and documentation https://review.opendev.org/c/openstack/openstack-tempest-skiplist/+/754994 Upstream promotions [1] NEXT SPRINT =========== - Bring the new promoter code online - Dependency pipeline - tripleo repos (As a design discussion for this sprint) - openstack Health for TripleO - Ruck and Rover - Akahat|rover - sshnaidm|ruck Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. [1]: http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?org… Sprint 37 and 38 ruck/rover notes: https://hackmd.io/R0kCgz_7SHSix_cNgoC9pg Thanks and Regards, Bhagyashri Shewale

1 0

Trying to resolve 2 deprecation warnings
by shubjero 15 Jan '21

15 Jan '21

Hi all, I am trying to resolve two deprecation warnings which I've not been able to locate exactly what package or file is causing them. We are running OpenStack Train on Ubuntu 18.04 The log entries are found in /etc/apache2/cinder_error.log : 2021-01-06 15:54:05.332604 /usr/lib/python3/dist-packages/oslo_context/context.py:108: DeprecationWarning: Policy enforcement is depending on the value of is_admin. This key is deprecated. Please update your policy file to use the standard policy values. 2021-01-06 15:54:20.147590 /usr/lib/python3/dist-packages/webob/acceptparse.py:1051: DeprecationWarning: The behavior of AcceptValidHeader.best_match is currently being maintained for backward compatibility, but it will be deprecated in the future, as it does not conform to the RFC. Any help on what needs to be changed/removed/updated/upgraded would be appreciated. Thanks! Jared Ontario Institute for Cancer Research

2 1

Openstack stein TLS configuration with combined method of interfaces
by roshan anvekar 15 Jan '21

15 Jan '21

Hello, Openstack version: stein Deployment method: kolla-ansible I am trying to set up TLS for Openstack endpoint. I have chosen combined method of vip address where I supply only kolla_internal_vip_address and network_interface details. I do not enable external kolla vip address. After this I set up kolla_enable_tls_external: 'yes' and pass the kolla_external_fqdn_cert certificates. The installation is successful but I see that http link opens but https:// endpoint does not open at all. Is as good as not available. Any reason for this? Regards, Roshan

2 1

[RDO][CentOS] RDO plans to move to CentOS Stream
by Alfredo Moralejo Alonso 15 Jan '21

15 Jan '21

Hi, As you know, CentOS announced recently that they will be focusing on CentOS Stream [1] and that CentOS Linux 8 will be EOL at the end of 2021 [2]. In order to align with this change, the RDO project is adapting the roadmap for the current and upcoming releases: - RDO Wallaby (ETA is end of April 2021 [3]) will be built, tested and released only for CentOS 8 Stream. - RDO CloudSIG repos for Victoria and Ussuri will be updated and tested for both CentOS Stream and CentOS Linux 8 until end of 2021 and then continue on CentOS Stream. - In the upcoming weeks, we will create new RDO CloudSIG repos for Victoria and Ussuri for CentOS Stream 8. - RDO Trunk repositories (aka DLRN repos) will be built and tested using CentOS 8 Stream for all releases currently using CentOS Linux 8 (starting with Train). If you are interested in the details about these plans and how we plan to implement it, we've created a blog post [4]. Don't hesitate to ask us in the ML or in the #rdo channel on freenode if you have questions or suggestions about this. We are also organizing a video AMA about RDO and CentOS Stream on Thursday Jan 21 1600 UTC in the RDO Meet room https://meet.google.com/uzo-tfkt-top On behalf of RDO, Alfredo [1] https://centos.org/distro-faq/ [2] https://blog.centos.org/2020/12/future-is-centos-stream/ [3] https://releases.openstack.org/ [4] https://blogs.rdoproject.org/2021/01/rdo-plans-to-move-to-centos-stream/

3 4

[rpm-packaging]release] Update our deliverables accordingly to the SIG governance model
by Herve Beraud 15 Jan '21

15 Jan '21

Dear rpm team fellows, I take off my release PTL cap to discuss with you as a teammate about some inconsistencies in our deliverables. Indeed, last week we noticed some inconsistencies between the rpm-packaging team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo. Since rpm-packaging became a SIG our deliverables [1][2][3] aren't managed by the release team anymore, so we should act accordingly to reflect that. Two choices are available to us: 1) mark these project as "release-model: abandoned" in the governance repo [4]; 2) remove the corresponding files from openstack/releases [1][2][3]. Each choice has pros and cons: - by choosing 1) it will reflect that our projects are abandoned, which is wrong, our projects are still active but not released by the coordinated releases anymore; - by choosing 2) it will reflect that we have always been a SIG, which is wrong too. I personally prefer 2) to allow us to avoid misleading someone by having an abandoned status, indeed, reflecting a SIG is less misleading than reflecting an abandoned project. Here is the list of our deliverables that should be addressed: - renderspec [1] - pymod2pkg [2] - rpm-packaging [3] Any opinion? For further details please take a look to our previous meeting discussion [5]. Thanks for reading, [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/_inde… [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_inde… [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/walla… [4] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-r… [5] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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 0

[release] Release countdown for week R-12 Jan 18 - Jan 22
by Herve Beraud 14 Jan '21

14 Jan '21

Greetings, Development Focus ----------------- The Wallaby-2 milestone is next week, on 21 January, 2021! Wallaby-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/wallaby/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 'Wallaby' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in Wallaby have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in Wallaby, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Wallaby-2 Milestone: 21 January, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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 0

Cannot login to Built trovestack image
by Ryan Price-King 14 Jan '21

14 Jan '21

Hi, I am having problems with the image being deployed correctly with nova, but the communication to the guestagent is timing out and i am stuck in build stage. ./trovestack build-image ubuntu bionic true ubuntu Also with that, I dont know which mysql version it is building. I am assuming it is 5.7.29. I cannot diagnose as i cannot login to the guest image instance. I assume the user is ubuntu, but i cannot login with any password that i have tried. Can you tell me what username/password to login to the instance by console in openstack please. Regards, Ryan

2 5

[nova] workarounds and operator experience around bug 1522307/1908133
by Rodrigo Barbieri 14 Jan '21

14 Jan '21

Hi Nova folks and OpenStack operators! I have had some trouble recently where while using the "images_type = rbd" libvirt option my ceph cluster got filled up without I noticing and froze all my nova services and instances. I started digging and investigating why and how I could prevent or workaround this issue, but I didn't find a very reliable clean way. I documented all my steps and investigation in bug 1908133 [0]. It has been marked as a duplicate of 1522307 [1] which has been around for quite some time, so I am wondering if any operators have been using nova + ceph in production with "images_type = rbd" config set and how you have been handling/working around the issue. Thanks in advance! [0] https://bugs.launchpad.net/nova/+bug/1908133 [1] https://bugs.launchpad.net/nova/+bug/1522307 -- Rodrigo Barbieri MSc Computer Scientist OpenStack Manila Core Contributor Federal University of São Carlos

3 6

[ironic] virtual midcycle
by Julia Kreger 14 Jan '21

14 Jan '21

Greetings awesome humans, We in the lands of baremetal and irony (err... Ironic, but you get the idea) have been discussing having a virtual midcycle in the next few weeks to help sort through some items and enable us to prioritize the remainder of the development cycle. I've created an etherpad[0], and a doodle poll[1]. Please keep in mind we have active contributors across the globe at this time, so if anyone feels like we need more time windows, please let me know. I'm hoping to schedule the midcycle by early next week. Additional topics are welcome on the etherpad. We will use that to identify how much time we should try and schedule. Thanks everyone! [0] https://etherpad.opendev.org/p/ironic-wallaby-midcycle [1] https://doodle.com/poll/y9afrz6hhq7s23km?utm_source=poll&utm_medium=link

1 0

Getting CPU Utilization null value
by ahsan ashraf 14 Jan '21

14 Jan '21

Hi Team, I have been using openstack apis and have following issue: - API used: /servers/{server_id}/diagnostics - API version: v2.1 Problem: Couldn't get utilization value of my server it is showing null even i have applied stress on the cpu API Result: { "state": "running", "driver": "libvirt", "hypervisor": "kvm", "hypervisor_os": "linux", "uptime": 10020419, "config_drive": false, "num_cpus": 2, "num_nics": 1, "num_disks": 2, "disk_details": [ { "read_bytes": 983884800, "read_requests": 26229, "write_bytes": 7373907456, "write_requests": 574537, "errors_count": -1 }, { "read_bytes": 3215872, "read_requests": 147, "write_bytes": 0, "write_requests": 0, "errors_count": -1 } ], "cpu_details": [ { "id": 0, "time": 12424380000000, "utilisation": null }, { "id": 1, "time": 12775460000000, "utilisation": null } ], "nic_details": [ { "mac_address": "fa:16:3e:0e:c7:f2", "rx_octets": 943004980, "rx_errors": 0, "rx_drop": 0, "rx_packets": 4464445, "rx_rate": null, "tx_octets": 785254710, "tx_errors": 0, "tx_drop": 0, "tx_packets": 4696786, "tx_rate": null } ], "memory_details": { "maximum": 2, "used": 2 } } Regards, Muhammad Ahsan

3 2

[ops][nova][designate] Does anyone rely on fully-qualified instance names?
by Stephen Finucane 14 Jan '21

14 Jan '21

When attaching a port to an instance, nova will check for DNS support in neutron and set a 'dns_name' attribute if found. To populate this attribute, nova uses a sanitised version of the instance name, stored in the instance.hostname attribute. This sanitisation simply strips out any unicode characters and replaces underscores and spaces with dashes, before truncating to 63 characters. It does not currently replace periods and this is the cause of bug 1581977 [1], where an instance name such as 'ubuntu20.04' will fail to schedule since neutron identifies '04' as an invalid TLD. The question now is what to do to resolve this. There are two obvious paths available to us. The first is to simply catch these invalid hostnames and replace them with an arbitrary hostname of format 'Server-{serverUUID}'. This is what we currently do for purely unicode instance names and is what I've proposed at [2]. The other option is to strip all periods, or rather replace them with hyphens, when sanitizing the instance name. This is more predictable but breaks the ability to use the instance name as a FQDN. Such usage is something I'm told we've never supported, but I'm concerned that there are users out there who are relying on this all the same and I'd like to get a feel for whether this is the case first. So, the question: does anyone currently rely on this inadvertent "feature"? Cheers, Stephen [1] https://launchpad.net/bugs/1581977 [2] https://review.opendev.org/c/openstack/nova/+/764482

9 23

Enabling KVM on Openstack Inbox
by open infra 14 Jan '21

14 Jan '21

Hi (This mail has been sent to the community mailing list already, and I was suggested to reach out to this mailing list.) I have enabled KVM after deploying openstack single node setup. Following entries has been added to /etc/nova/nova.conf and then restart libvirtd.service and openstack-nova-compute.servic. compute_driver = libvirt.LibvirtDriver [libvirt] virt_type=kvm #virt_type=qemu # lsmod | grep kvm kvm_intel 188740 0 kvm 637289 1 kvm_intel irqbypass 13503 1 kvm I have disabled qemu in nova config and restarted the entire box (including the base OS and the VM where I deployed Openstack. But still no luck. $ openstack hypervisor list +----+------------------------+-----------------+----------------+-------+ | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | +----+------------------------+-----------------+----------------+-------+ | 1 | openstack.centos.local | QEMU | 192.168.122.63 | up | +----+------------------------+-----------------+----------------+-------+ I still can see Hypervisor Type as QEMU, when I issue openstack hypervisor list command.

2 2

[release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3
by Herve Beraud 14 Jan '21

14 Jan '21

Dear release managers, We are currently experiencing an issue with the new pip resolver in our release job (publish-openstack-releasenotes-python3), so, please hold all the release's validations for now. Indeed, today we faced an issue [1][2] during the releasing tripleo-image-elements [3]. The problem here is that this repos haven't doc/requirements.txt file and by default in this case zuul will use the test-requirements.txt file to pull requirements [4] This requirements file contains extra requirements like flake8 that collided with those allowed in our job environment and so the new pip resolver fails to install these requirements and the job exits in error. All the repo who fit the same conditions (no doc/requirements.txt available) will fail too. We've almost identified all of these repos [5], I'll get the full list to you in a while. In parallel, fungi (Jeremy Stanley) will bring this topic on the zuul side too, to see if we can add something there to override this rule (test-requirements.txt as the default case). Thanks for reading [1] https://zuul.opendev.org/t/openstack/build/d82e8c8db7754394907459895f3f58fa [2} http://paste.openstack.org/show/801385/ [3] https://review.opendev.org/c/openstack/releases/+/768237 [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-sphinx/ta… [5] http://paste.openstack.org/show/801396/ -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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-----

5 9

[magnum][api] Error system library fopen too many open files with magnum-auto-healer
by Ionut Biru 14 Jan '21

14 Jan '21

Hi guys, I have an issue with magnum api returning an error after a while: Server-side error: "[('system library', 'fopen', 'Too many open files'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]" Log file: https://paste.xinu.at/6djE/ This started to appear after I enabled the template auto_healing_controller = magnum-auto-healer, magnum_auto_healer_tag = v1.19.0. Currently, I only have 4 clusters. After that the API is in error state and doesn't work unless I restart it. -- Ionut Biru - https://fleio.com

4 23

[neutron] Drivers meeting agenda for 15.01.2021
by Slawek Kaplonski 14 Jan '21

14 Jan '21

Hi, For tomorrow's drivers meeting we have one new RFE to discuss: * https://bugs.launchpad.net/neutron/+bug/1911126 Spec for that is proposed already: https://review.opendev.org/c/openstack/neutron-specs/+/770540 See You on the meeting tomorrow :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Only a few hours left: 2021 Board elections and Bylaws amendments
by Allison Price 13 Jan '21

13 Jan '21

Hi everyone, The 2021 Individual Director elections are currently open. All members who are eligible to vote should have received an email ballot earlier this week. You can review the candidates here: https://www.openstack.org/election/2021-individual-director-election/Candid… <https://www.openstack.org/election/2021-individual-director-election/Candid…>. If you are not currently a member of the Open Infrastructure Foundation, you can join here to vote in next year’s elections: https://openinfra.dev/join <https://openinfra.dev/join> This year, the election includes a set of amendments to the Foundation’s Bylaws. The amendments were approved unanimously by the Foundation Board in 2020. As a member class, the Individual Members must also approve these amendments. You can find more information in this mailing list post by Jonathan Bryce: http://lists.openstack.org/pipermail/foundation/2021-January/002939.html <http://lists.openstack.org/pipermail/foundation/2021-January/002939.html> The deadline to vote is this Friday, January 15 at 1800 UTC / 12pm CST. Please let me know if you have any questions. Allison Allison Price Open Infrastructure Foundation allison(a)openstack.org <mailto:allison@openstack.org>

1 0

[Watcher]stepping down as PTL
by licanwei 13 Jan '21

13 Jan '21

Hi all, For personal reason, I have no time to continue the work for Watcher PTL. My colleage, Chen Ke(irc:chenke) will temporarily replace me as PTL, thank you for your support. thanks, | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制

2 1

[nova] Nova evacuate issue
by Jean-Philippe Méthot 13 Jan '21

13 Jan '21

Hi, We’re running Openstack Rocky on a high-availability setup with neutron openvswitch. The setup has roughly 50 compute nodes and 2 controller nodes. We’ve run into an issue when we’re trying to evacuate a dead compute node where the first instance evacuate goes through, but the second one fails (we evacuate our instances one by one). The reason why the second one fails seems to be because Neutron is trying to plug the port back on the dead compute, as nova instructs it to do. Here’s an example of nova-api log output after compute22 died and we’ve been trying to evacuate an instance. f3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-unplugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 2021-01-06 13:31:31.750 2858 INFO nova.osapi_compute.wsgi.server [req-4f9b3e17-1a9d-48f0-961a-bbabdf922ad6 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] 10.30.1.224 "POST /v2.1/os-server-external-events HTTP/1.1" status: 200 len: 1091 time: 0.4987640 2021-01-06 13:31:40.145 2863 INFO nova.osapi_compute.wsgi.server [req-abaac9df-7338-4d10-9326-4006021ff54d 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1 HTTP/1.1" status: 302 len: 318 time: 0.0072701 2021-01-06 13:31:40.156 2863 INFO nova.osapi_compute.wsgi.server [req-c393e74b-a118-4a98-8a83-be6007913dc0 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/ HTTP/1.1" status: 200 len: 789 time: 0.0070350 2021-01-06 13:31:43.289 2865 INFO nova.osapi_compute.wsgi.server [req-b87268b7-a673-44c1-9162-f9564647ec33 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc HTTP/1.1" status: 200 len: 5654 time: 2.7543190 2021-01-06 13:31:43.413 2863 INFO nova.osapi_compute.wsgi.server [req-4cab23ba-c5cb-4dda-bf42-bc452d004783 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc/os-volume_attachments HTTP/1.1" status: 200 len: 770 time: 0.1135709 2021-01-06 13:31:43.883 2865 INFO nova.osapi_compute.wsgi.server [req-f5e5a586-65f3-4798-b03b-98e01326a00b 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/flavors/574a7152-f079-4337-b1eb-b7eca4370b73 HTTP/1.1" status: 200 len: 877 time: 0.5751688 2021-01-06 13:31:47.194 2864 INFO nova.api.openstack.compute.server_external_events [req-7e639b1f-8408-4e8e-9bb8-54588290edfe 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 As you can see, Nova "creates an event" as the virtual interface is unplugged but then immediately creates another event to plug the virtual interface in the same compute node that is dead. However, at the same time, the instance is being created on another compute node. Is this a known bug? I have not found anything about this in the bug database. Additionally, I am not able to reproduce in our staging environment which is smaller and running on Stein. Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada TEL : +1.514.802.1644 - Poste : 2644 FAX : +1.514.612.0678 CA/US : 1.855.774.4678 FR : 01 76 60 41 43 UK : 0808 189 0423

3 5

[all][dev] Beware how fun the new pip can be
by Radosław Piliszek 13 Jan '21

13 Jan '21

Hiya, Folks! Sharing what I have just learnt about the new pip's solver. pip install PROJECT no longer guarantees to install the latest version of PROJECT (or, well, giving you the ERROR that it cannot do it because something something :-) ). In fact, it will install the latest version *matching other constraints* and do it *silently*. Like it was recently only with Python version (i.e. py3-only would not get installed on py2 - that is cool) but now it moved into any-package territory. As an example, I can give you [1] where we are experimenting with getting some extracurricular package into our containers, notably fluent-logger. The only dep of fluent-logger is msgpack but the latest msgpack (as in upper constraints: 1.0.2, or any 1.x for that matter) is not compatible. However, the pin was introduced in fluent-logger in its 0.9.5 release (0.9.6 is the latest). Guess what pip does? Here is what it does: INFO:kolla.common.utils.openstack-base:Collecting fluent-logger INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/1a/f5/e6c30ec… (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d5/cb/19d8385… (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d1/d4/f9b3493… (12 kB) And that's it. Pip is happy, you got your "latest" version. In previous pip one would get the latest version AND a warning. Now just pip's view on what the "latest" version is. I am glad we have upper-constraints which save the day here (forcing the ERROR) but beware of this "in the wild". [1] https://review.opendev.org/c/openstack/kolla/+/759855 -yoctozepto

3 4

[largescale-sig] Next meeting: January 13, 15utc
by Thierry Carrez 13 Jan '21

13 Jan '21

Hi everyone, We'll have our first 2021 Large Scale SIG meeting this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210113T15 Our main topic will be to reboot the Large Scale SIG in the new year and get a few work items and contributions planned. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez

1 1

Ask for patch review
by 呂良 12 Jan '21

12 Jan '21

Hi, Mr.Ogawa & other members of tacker team: This is Liang Lu, may I invite you to review my patch ? https://review.opendev.org/c/openstack/tacker/+/764138 (now it is retesting but no new patch sets in future) This is a tiny patch fix calling parameter of kubernetes_driver.instantiate_vnf(), however it affects FT(will continuously fail if not merge), so I want to push it and merge it soon. best regards

2 1

ironic-python-agent erase block device failed
by Ankele zhang 12 Jan '21

12 Jan '21

Hi, I have an Rocky OpenStack platform. I used ironic-python-agent-builder to build a ipa.initramfs image. I called the clean API to erase my baremetal node disk. But it was failed. I traced the ipa source code, and got it used 'hdparm -I /dev/sdx' to check if the device is frozen [image: image.png] my device is frozen, then I switched to another SSD, and it's not frozen but it was also failed, [image: image.png] I don't know if I need to erase my bare metal nodes' block devices in product environment. If so, how to make it successful? Ankele

1 0

[heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance
by Marios Andreou 12 Jan '21

12 Jan '21

Hello Heat team o/ as discussed in the thread at [1] TripleO is no longer using os-collect-config, os-refresh-config and os-apply-config as part of the OpenStack deployment. As such we are considering moving these repos to the independent release model. However as pointed out in [1] it seems that Heat is still using these - documented at [2]. Is the Heat community interested in taking over the ownership of these? To be clear what the proposal here is, I posted [3] - i.e. move these projects under the Heat governance. Thanks for your time, thoughts and comments on this, either here or in [3]. If you are NOT interested in owning these then we will likely move them to independent, or possibly even unmaintained/eol (in due course). regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019751.… [2] https://docs.openstack.org/heat/latest/template_guide/software_deployment.h… [3] https://review.opendev.org/c/openstack/governance/+/770285

4 4

Re: [nova] unit testing on ppc64le
by aditi Dukle 12 Jan '21

12 Jan '21

2 1

[ironic] question regarding attributes required for a non-admin to boot from volume
by Tzu-Mainn Chen 12 Jan '21

12 Jan '21

Hi, I've been looking into what it would take to allow non-admins to boot from volume. It looks like they'd need to update a node's storage_interface; and if you'd like to boot from an iSCSI volume, then you also need to update a node's capabilities property. Are these fields that we want non-admins to be able to update? If not, is there an alternative that might be possible? Thanks, Tzu-Mainn Chen

2 1

[neutron] bug deputy report (week of Jan 4)
by Akihiro Motoki 12 Jan '21

12 Jan '21

Hi, This is a summary of neutron bugs last week. Sorry for late. It was generally a quiet week. Thanks, Akihiro # Undecided https://bugs.launchpad.net/neutron/+bug/1910474 some times rally test would fail at network scenario due to mysql data base error Undecided It was reported against the queens release and the detail log mentioned in the bug is not available. It looks related to a nested transaction in percona but we are waiting for more information from the reporter. # Unassigned gate failures https://bugs.launchpad.net/neutron/+bug/1910691 In "test_dvr_router_lifecycle_ha_with_snat_with_fips", the HA proxy PID file is not removed reported by ralonsoh. Hope someone interested in it can look into it. # Assigned or In Progress https://bugs.launchpad.net/neutron/+bug/1910213 Live migration doesn't work with OVN and DPDK assigned to jlibosva https://bugs.launchpad.net/neutron/+bug/1910717 "test_set_igmp_snooping_flood" fails because "ports_other_config" is None ralonsoh is working on the fix https://bugs.launchpad.net/bugs/1910334 [OVN]after create port forwarding, floating ip status is not running In Progress, a fix is under review

1 0

[octavia] problems configuring octavia
by Daniel Macdonald 12 Jan '21

12 Jan '21

Happy new year Openstack users and devs! I have been trying on and off for several months to get octavia working but I have yet to have it successfully create a loadbalancer. I have deployed OS bionic-train using the Charms telemetry bundle with the octavia overlay. Openstack is working for creating regular instances but I get various errors when trying to create a loadbalancer. The first issue I feel I should mention is that I am using bind running on our MAAS controller as a DNS server. juju doesn't work if I enable IPv6 under bind yet the octavia charm defaults to using IPv6 for its management network so I have tried creating a IPv4 management network but I'm still having problems. For more details on that please see the comments of this bug report: https://bugs.launchpad.net/charm-octavia/+bug/1897418 Bug #1897418 “feature request: have option to use ipv4 when sett...” : Bugs : OpenStack Octavia Charm<https://bugs.launchpad.net/charm-octavia/+bug/1897418> By default, Octavia charm uses ipv6 for its lb-mgmt-subnet.[1] It would be nice to have the option to choose an ipv4 network from the start instead of deleting the ipv6 network and recreating the ipv4 subnet. Implementation - possible configuration option parameter when deploying. [1] https://opendev.org/openstack/charm-octavia/src/branch/master/src/lib/charm… bugs.launchpad.net Another notable issue I have is that after installing the charms telemetry bundle I have 2 projects call services. How do I know which is the correct one to use for Octavia? Is this following document going to be the best guide for me to follow to complete the final steps required to get Octavia (under Train) working: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta… OpenStack Docs: Install and configure for Ubuntu<https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta…> Install and configure for Ubuntu¶. This section describes how to install and configure the Load-balancer service for Ubuntu 18.04 (LTS). docs.openstack.org I'm hoping someone has already written an easy to follow guide to using Octavia with an IPv4 management network using the Charms bundle to do most of the installation work? Thanks [University of Salford] DANIEL MACDONALD Specialist Technical Demonstrator School of Computing, Science & Engineering Room 145, Newton Building, University of Salford, Manchester M5 4WT T: +44(0) 0161 295 5242 D.R.MacDonald(a)salford.ac.uk<https://salfordexchangefarm.salford.ac.uk/owa/redir.aspx?C=xTvsJHwNEL3cOizC…> / www.salford.ac.uk<https://salfordexchangefarm.salford.ac.uk/owa/redir.aspx?C=VZufnsIyPXegmGvP…> [CSE]

2 2

[kolla] Victoria releases available
by Mark Goddard 12 Jan '21

12 Jan '21

Hi, I'm pleased to announce the availability of the first Victoria releases for all Kolla deliverables: * kolla 11.0.0 (https://docs.openstack.org/releasenotes/kolla/victoria.html#relnotes-11-0-0…) * kolla-ansible 11.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html#relnote…) * kayobe 9.0.0 (https://docs.openstack.org/releasenotes/kayobe/victoria.html#relnotes-9-0-0…) Thanks to everyone who contributed to these releases. And now onto Wallaby! Thanks, Mark

1 0

[tosca-parser][tacker] May I ask to push review process of patch 747516 : Support "Implementation" definition as Artifact Name
by 呂良 11 Jan '21

11 Jan '21

Hi Bob, This is Liang from tacker team, in our patch: Implement SOL001 features to MgmtDriver (Ib4ad3eb9) · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tacker/+/768091>, we tried to implement in order to allow user use their script by defining 'interface' in vnfd file: …/vnflcm_driver.py · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tacker/+/768091/12/tacker/vnflcm/vnf…> in the function above, changes in Support "Implementation" definition as Artifact Name (I192d3649) · Gerrit Code Review (opendev.org) <https://review.opendev.org/c/openstack/tosca-parser/+/747516> , is needed for our implementation, may I ask you to help us push review for an early merge of this patch, appreciate for that! Best regards Liang Lu

1 0

[oslo][TC] Dropping lower-constraints testing
by hberaud 11 Jan '21

11 Jan '21

Hello, As you already surely know, we (the openstack project) currently face some issues with our lower-constraints jobs due to pip's latest resolver feature. By discussing this topic with Thierry Carrez (ttx) from an oslo point of view, we reached the same conclusion that it is more appropriate to drop this kind of tests because the complexity and recurring pain needed to maintain them now exceeds the benefits provided by this mechanismes. Also we should notice that the number of active maintainers is declining, so we think that this is the shortest path to solve this problem on oslo for now and for the future too. In a first time I tried to fix our gates by fixing our lower-constraints project by project but with around ~36 projects to maintain this is a painful task, especially due to nested oslo layers inside oslo himself... I saw the face of the hell of dependencies. So, in a second time I submitted a series of patches to drop these tests [1]. But before moving further with that we would appreciate discussing this with the TC. For now the patches are ready and we just have to push the good button accordingly to our choices (+W or abandon). Normally all the oslo projects that need to be fixed are covered by [1]. Thoughts? Thanks for reading. [1] https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%20s… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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-----

9 13

[tc] weekly update
by Mohammed Naser 11 Jan '21

11 Jan '21

Hi there, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - Remove Karbor project team | https://review.opendev.org/c/openstack/governance/+/767056 ## Projects Updates - Deprecate neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/c/openstack/governance/+/735828 # Other Reminders - Our next [TC] Weekly meeting is scheduled on January 14th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 13th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[Glance] PTL on leaves
by Abhishek Kekane 11 Jan '21

11 Jan '21

Hi All, I'm going on leave from 13th January and will be back on 21st January to attend my sister's wedding. Please direct any issues to the rest of the core team. Thanks & Best Regards, Abhishek Kekane

1 0

[Diversity] Diversity &Inclusion WG Meeting reminder
by Amy Marrich 11 Jan '21

11 Jan '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting today, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[nova] unit testing on ppc64le
by Balazs Gibizer 11 Jan '21

11 Jan '21

Hi, We have a bugreport[1] showing that our unit tests are not passing on ppc. In the upstream CI we don't have test capability to run our tests on ppc. But we have the IBM Power KVM CI[2] that runs integration tests on ppc. I'm wondering if IBM could extend the CI to run nova unit and functional tests too. I've added Michael Turek (mjturek(a)us.ibm.com) to CC. Michael is listed as the contact person for the CI. Cheers, gibi [1]https://bugs.launchpad.net/nova/+bug/1909972 [2]https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI

2 2

[nova] [Ussuri] Unable to perform live block migrations on ephemeral VMs without shared storage
by Justin Goetz 08 Jan '21

08 Jan '21

Hello! Happy new year to everyone! I'm experiencing some trouble in my attempts to get live block migrations working on machines who's boot drives live on ephemeral (local) host storage. Offline (cold) migrations appear to work fine, however, I need live migrations to function with no downtime to the VMs. We're running on OpenStack Ussuri, with Ubuntu 18.04.5 LTS as our hypervisor OS, running libvirt 6.0.0. Below is the following command I'm utilizing to perform the live block migration: openstack server migrate <id> --debug --verbose --live-migration --block-migration The verbose logging of the above command shows no obvious issues, however digging deeper on the hypervisor side, we see some libvirtd errors, and the most telling is this segment here: Jan 08 16:53:02 h5 libvirtd[4118]: Unsafe migration: Migration without shared storage is unsafe Jan 08 16:53:02 h5 nova-compute[130270]: 2021-01-08 16:53:02.860 130270 ERROR nova.virt.libvirt.driver [-] [instance: 72bc9feb-b8f0-45f2-bad4-9cb61c3abff3] Live Migration failure: Unsafe migration: Migration without shared storage is unsafe: libvirt.libvirtError: Unsafe migration: Migration without shared storage is unsafe Full log output is available here: http://paste.openstack.org/show/801525/ Perhaps I'm severely mistaken, but native libvirt should have no problem whatsoever performing live migrations without shared storage on it's own. I've dug into the libvirt side for hours to try and troubleshoot what the system is seeing as "unsafe" (I confirmed disk caching is disabled, as well as no strange custom settings are present), but was unsuccessful. The full output of my VM's QEMU XML file can be viewed here: http://paste.openstack.org/show/801526/ As I couldn't figure out why libvirtd was not seeing the migration as "safe", I attempted to override the libvirt message by attempting to utilize the live_migration_flag and block_migration_flag options in nova.conf to invoke the --unsafe parameter when running the libvirt commands (with the flags VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE,VIR_MIGRATE_NON_SHARED_INC), however I later learned from a previous developers thread on the mailing list from 2016 that both of these options have been depreciated in the later versions of Nova and replaced by the "live_migration_tunnelled" setting in nova.conf. I've ensured my nova.conf files have the live_migration_tunnelled parameter set to "True". However, I have not found any method for passing along the "--unsafe" flag (or any other libvirt flag, in this case) to libvirt from nova.conf from this point on after the depreciation of the live_migration_flag parameters. Any help would be greatly appreciated, from reading around online this seems to be a fairly common setup, I'm baffled at how I've run into this issue across several separate OpenStack clusters at this point. Thank you for reading. -- Justin Goetz Systems Engineer, TeraSwitch Inc. jgoetz(a)teraswitch.com 412-945-7045 (NOC) | 412-459-7945 (Direct)

1 0

how to read ipa source code#ironic-python-agent
by Ankele zhang 08 Jan '21

08 Jan '21

Hi~ I have an OpenStack platform on Rocky, and I used Nova/Keystone/Cinder/Glance/Ceph/Ironic. Recently, I have build my own ironic-python-agent deployment ramdisk and kernel images by ironic-python-agent-builder, the following work is to add my customized raid configuration method to HardwareManager. Before this, I want to read the ipa's source code. But I don't know where is the 'main()' entry. Looking forward to your help. Ankele

3 2

Re: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed
by Herve Beraud 08 Jan '21

08 Jan '21

Hello, FYI it seems that kolla met docker's new limitation during its release jobs, especially with your publish jobs, I saw that you (the kolla team) already discussed this limitation [1] on the ML. ``` 2021-01-07 17:21:03.396355 | primary | ERROR:kolla.common.utils.base:Error'd with the following message 2021-01-07 17:21:03.396465 | primary | ERROR:kolla.common.utils.base:toomanyrequests: You have reached your pull rate limit. You may increase ``` Three jobs here failed for the same reason. I don't think that reenqueue the failing jobs without a specific action to manage this limitation will help us here. Let us know if we can help us in some manner. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019148… Le jeu. 7 janv. 2021 à 20:41, <zuul(a)openstack.org> a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/a64b4c4bc398481f9afffa2ad465a012 > : SUCCESS in 1m 03s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/2ed64dfcbcaf483abf003cfdf4f25837 > : SUCCESS in 3m 11s > - announce-release > https://zuul.opendev.org/t/openstack/build/84d803d496a2485c983f6233dafcfd71 > : SUCCESS in 4m 07s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/d0cac6a077054bc8ba9eb92e56c21799 > : SUCCESS in 4m 15s > - kolla-publish-centos-source > https://zuul.opendev.org/t/openstack/build/5e8f6aa2f56940a7be77a8dfe1c8ecc6 > : SUCCESS in 2h 20m 47s > - kolla-publish-centos-binary > https://zuul.opendev.org/t/openstack/build/8a8a021d9f9c4ca79755b06309710cc7 > : SUCCESS in 1h 56m 32s (non-voting) > - kolla-publish-centos8-source > https://zuul.opendev.org/t/openstack/build/fb6891d3f5e4493b880fce263a92e086 > : SUCCESS in 1h 50m 57s > - kolla-publish-centos8-binary > https://zuul.opendev.org/t/openstack/build/c312c05e5d084fdbb3f372755221f186 > : SUCCESS in 1h 13m 12s (non-voting) > - kolla-publish-debian-source > https://zuul.opendev.org/t/openstack/build/e24c12751b8c4aba881adb6c9ae8dc07 > : SUCCESS in 1h 27m 27s (non-voting) > - kolla-publish-debian-source-aarch64 > https://zuul.opendev.org/t/openstack/build/1ff3b02df53847d0aa54bf12ea7fa666 > : FAILURE in 1h 51m 49s (non-voting) > - kolla-publish-debian-binary > https://zuul.opendev.org/t/openstack/build/012c2de475fe45ea83f1cd8a7420aa6d > : SUCCESS in 1h 15m 15s (non-voting) > - kolla-publish-ubuntu-source > https://zuul.opendev.org/t/openstack/build/88ca21d972514cce954ecb586324fa29 > : FAILURE in 4m 14s > - kolla-publish-ubuntu-binary > https://zuul.opendev.org/t/openstack/build/f3d44e4d1b6c4e9799161b156290b238 > : FAILURE in 4m 19s (non-voting) > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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-----

3 3

[ironic] Resuming meetings next week
by Julia Kreger 08 Jan '21

08 Jan '21

Greetings everyone, Now that the Holidays are over, it is time for us to resume meeting on a regular basis. Ironic will resume it's weekly meeting next Monday at 1500 UTC in #openstack-ironic on irc.freenode.net. The agenda can be found on the OpenStack wiki[0]. See you all there! -Julia [0]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

1 0

[kolla] [train] Changing default quotas
by Braden, Albert 08 Jan '21

08 Jan '21

I'm trying to change default quotas on a Train kolla POC, and I can change compute, but when I try to change a network quota such as subnets I get an error: (openstack) [root@adjutant-poc openstack]# openstack quota set --class --subnets 2 default Network quotas are ignored since quota class is not supported. When I google around I find some old documents talking about setting neutron quotas in /etc/neutron/neutron.conf but I can't find anything recent, and I don't see any mention of quotas when I look at /etc/neutron/neutron.conf in our neutron_server containers. What is the best way to change neutron default quotas in kolla? I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 1

[cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline
by Herve Beraud 08 Jan '21

08 Jan '21

Hello teams with trailing projects, Next week is the Victoria cycle-trailing release deadline [1], and all projects following the cycle-trailing release model must release their Victoria deliverables by 14 January, 2021. The following trailing projects haven't been yet released for Victoria. Cinder: - cinderlib Tripleo: - os-collect-config - os-refresh-config - tripleo-ipsec This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----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-----

2 3