- openstack-discuss - lists.openstack.org

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update
by Ghanshyam Mann 20 Jan '21

20 Jan '21

Hello Everyone, Please find the week's R-16 updates on 'Migrate RBAC Policy Format from JSON to YAML' community-wide goals. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress: ======= * Projects completed: 5 * Projects left to merge the patches: 25 * Projects left to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 17 Updates: ======= * I have pushed the patches for all the required service projects. ** Because of many services gate is already broken for lower constraints job, these patches might not be green in the test results. I request projects to fix the gate so that we can merge this goal work before m-2. ** There are many project tests where CONF object was not fully initialized before the policy is init. This was working till now as policy init did not use the CONF object but oslo_policy 3.6.0 onwards it needs fully initialized CONF object during init only. ** Aodh work for this goal is blocked because it needs oslo_policy 3.6.0 but gnocchi is capped for oslo_policy 3.4.0 [1] - https://review.opendev.org/c/openstack/aodh/+/768499 * Horizon and Openstackansible work is pending to use/deploy the YAML formatted policy file. I will start exploring this next week or so. [1] https://github.com/gnocchixyz/gnocchi/blob/e19fda590c7f7f07f1df0ba93177df07… Merry Christmas and Happy Holidays! -gmann

6 11

[cinder] wallaby new driver status
by Brian Rosmaita 20 Jan '21

20 Jan '21

At today's Cinder meeting [0] we discussed the unmerged proposed drivers (3 volume drivers, 1 backup driver) in light of tomorrow's new driver merge deadline. Here's a summary of what we decided: 1. s3 cinder backup driver https://review.opendev.org/c/openstack/cinder/+/746561 The code looks basically OK but the driver hasn't been independently tested. There's a proposed CI job but it currently isn't passing. ==> plan: aim for two +2s on the patch before the merge deadline, but hold off on merging until we have confirmation that the driver works, hopefully but the CI working by next week (Thursday 28 January). 2. TOYOU ACS5000 driver https://review.opendev.org/c/openstack/cinder/+/767290/ Code is looking good and they've been good about quickly revising patches. The CI is running and driver is passing tempest and cinder-tempest-plugin tests, though it's not reporting reliably on patches. They've agreed to get their CI responding properly by milestone-3. ==> plan: the requested revisions haven't been major, so this is looking good for tomorrow's deadline. We anticipate that the CI situation will be corrected by M-3. 3. Ceph iSCSI driver https://review.opendev.org/c/openstack/cinder/+/662829 Code is looking good but the CI isn't passing yet. ==> plan: this is an important community driver so we're extending the deadline two weeks to 5 February. 4. Kioxia Kumoscale driver (and brick changes) https://review.opendev.org/c/openstack/cinder/+/768574 https://review.opendev.org/c/openstack/os-brick/+/768575 https://review.opendev.org/c/openstack/os-brick/+/768576 Kioxia reports that their CI is up though it's not reporting yet. This is a large change and the cinder team review bandwidth has been low this cycle, but with the other drivers (mostly) done at this point, we should be able to get faster reviews on these. ==> plan: new driver merge extension to 8 Feb, that is, code merged and CI running and reporting by that date to be included in wallaby. cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-01-20-14.00…

1 0

Requesting help with OpenStack configuration files
by Bessghaier, Narjes 20 Jan '21

20 Jan '21

Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1(a)ens.etsmtl.ca<mailto:yasmine.makroum.1@ens.etsmtl.ca>

3 4

[masakari] Masakari Team Meeting - the schedule
by Radosław Piliszek 20 Jan '21

20 Jan '21

Hello, Folks! I have realised the Masakari Team Meeting is to run on even weeks [1]. However, anyone who created the meeting record in their calendar (including me) has likely gotten the meeting schedule in odd weeks this year (because last year finished with an odd week and obviously numbering also starts on odd: the 1). So I have run the first meeting this year the previous week but someone came for the meeting this week. :-) According to the "new wrong" schedule, the next meeting would be on Jan 19, but according to the "proper" one it would be on Jan 26. I am available both weeks the same so can run either term (or both as well, why not). The question is whether we don't want to simply move to the weekly meeting schedule. We usually don't have much to discuss but it might be less confusing and a better way to form a habit if we met every week. Please let me know your thoughts. [1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting -yoctozepto

2 2

[nova] Selecting PCI devices by their addresses
by Mauricio Tavares 20 Jan '21

20 Jan '21

Stupid question of the day: if I am not mistaken, I can ask nova[1] which pci/pcie devices it knows and where they are. And it will reply with the PCI address for each device it knows of. But, when I want to create flavours so I can create (libvirt-based) instances using them, I cannot tie an alias to a specific pci address; all I can do is say "this pci_alias is for all the pci devices with this vendor_id and product_id that I whitelisted already"[2]. Since libvirt allows me to feed a vm guest the exact pci device I want, could anyone point out which obvious step I am missing here? [1] https://wiki.openstack.org/wiki/Pci-api-support [2] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure…

2 1

[tc] weekly meeting summary (Jan 14)
by Mohammed Naser 20 Jan '21

20 Jan '21

Hi everyone, Here’s a summary of what happened in our TC weekly meeting last Thursday, Jan 14th. # ATTENDEES (LINES SAID) 1. mnaser (123) 2. gmann (56) 3. fungi (31) 4. rosmaita (19) 5. ricolin (11) 6. dansmith (9) 7. jungleboyj (8) 8. knikolla (6) 9. clarkb (3) 10. apevec (2) 11. slaweq (2) 12. belmoreira (1) # MEETING SUMMARY 1. Rollcall 2. Follow up on past action items - DONE: mnaser submit a patch to officially list no community goals for X cycle - DONE: diablo_rojo update resolution for tc stance on osc - IN PROGRESS: diablo_rojo complete retirement of karbor - ALMOST DONE - TBD: diablo_rojo reach out to SIGs/ML and start auditing states of SIGs - TBD: gmann continue to audit tags + outreach to community to apply for them 3. Write a proposed goal for X about stabilization/cooldown This topic mostly continues to live inside gerrit, so ti will be removed from the agenda. 4. Audit SIG list and chairs (diablo_rojo) No progress update, we'll keep an action item to keep up with it. 5. Annual report suggestions (diablo_rojo) Topic to be removed from the agenda as this is getting drafted already. 6. Add Resolution of TC stance on the OpenStackClient (diablo_rojo) dansmith will update osc change to include ci/docs commentary. 7. Audit and clean-up tags (gmann) gmann bumped the email with PTL tag for API interoperability tag, we’ll see how many projects start applying it. 8. infra-core additions (was Farewell Andreas) (diablo_rojo) The reposition is quiet for the moment and there is no backlog yet. We are bringing this up at the OpenDev infrastructure meeting on Tuesday the 19th, mnaser will add openstack/infra-core as a discussion topic in the OpenDev meeting. 9. Dropping lower-constraints testing from all projects (gmann) This is something projects asked TC for consensus and direction for all projects. l-c testing is not part of PTI but there should exist some direction for consistency testing and providing a lower bound to package maintainers. A few projects already started dropping l-c job, and it seems that our current l-c were not exactly testing in a valid way. Also, most testing (except for the l-c job) is being done with versions close to the upper-constraints. We will keep this an open topic for next week. 10. Decide on OpenSUSE in testing runtime (gmann) OpenSUSE distro job is broken for a month and DevStack team is approaching removing it as there is no investment from the company or the community. It was discussed to make the governance change and if that goes through the DevStack one, it will be merged. We’ll have an ML before and after moving testing/governance change, gmann will update supported distros to drop OpenSUSE. # ACTION ITEMS 1. diablo_rojo complete retirement of karbor 2. mnaser to remove proposed goal topic from agenda 3. diablo_rojo reach out to SIGs/ML and start auditing states of SIGs 4. mnaser remove annual report suggestions from agenda 5. dansmith update osc change to include ci/docs commentary 6. mnaser add openstack/infra-core as discussion topic in opendev meeting 7. gmann follow-up with zigo if debian uses l-c 8. gmann update supported distros to drop opensuse To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-01-14-15.00.log.html -- Mohammed Naser VEXXHOST, Inc.

1 0

[$nova] [$horizon] [$nova-scheduler] [$heat]
by Nagaraj Akkina 20 Jan '21

20 Jan '21

I think we have a big problem, scheduler is able to allocate more memory than actual physical memory in the compute node, the same statistics are also there in database. For example : if we have a physical memory of 125GB in a node, the total memory allocated to all the instances(virsh dommemstat of all vms) in that host is more than physical memory say around 147GB, being ram_allocation_ratio defined as 1 and reserve_host_memory_mb defined as required. How can nova allocates more memory than actual? Statistics from database +-----------+----------------+-------------+----------------------+ | memory_mb | memory_mb_used | free_ram_mb | ram_allocation_ratio | +-----------+----------------+-------------+----------------------+ | 128897 | 154624 | -25727 | 1 | +-----------+----------------+-------------+----------------------+ we are using openstack stein Regards, Akkina

2 1

[qa][release] Abandoning openstack-tempest-skiplist?
by Herve Beraud 20 Jan '21

20 Jan '21

Dear QA team, The release team noticed an inconsistency between the QA team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] 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-----

3 6

docs about ironic-inspector
by Ankele zhang 20 Jan '21

20 Jan '21

Hi, I have an rocky OpenStack platform, and I need openstack-ironic-inspector to inspect my baremetal node, but the documentation on the websit https://docs.openstack.org/ironic/rocky/admin/inspection.html is too concise, without a detailed configuration process. I need a link to documentation for detailed ironic-inspector configuration and usage. Looking forward to your help. Ankele

2 1

[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 19 Jan '21

19 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 15 Jan '21

15 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 呂良 13 Jan '21

13 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