July 2021 - openstack-discuss - lists.openstack.org

[nova][neutron][deployment-projects] Re secbug #1734320
by Radosław Piliszek 04 Aug '21

04 Aug '21

Hello Folks! I am writing this because a recent patch proposed to DevStack [1] mentioned "when using ml2/ovs vif isolation should always be used to prevent cross tenant traffic during a live migration" which is related to secbug #1734320 "Eavesdropping private traffic" [2]. However, I've found that none of the publicly-available deployment projects seem to be using ``isolate_vif``. [3] [4] Should this be corrected? PS: I used the deployment-projects tag as a collective tag to avoid mentioning all the projects (as it is too long to write :-) ). I hope that relevant people see this if need be or someone passes the information to them. For now, I am curious whether this should actually be enforced by default with ML2/OVS. [1] https://review.opendev.org/c/openstack/devstack/+/796826 [2] https://bugs.launchpad.net/neutron/+bug/1734320 [3] https://codesearch.opendev.org/?q=%5Cbisolate_vif%5Cb&i=nope&files=&exclude… [4] https://github.com/search?p=1&q=isolate_vif&type=Code -yoctozepto

3 2

stackalytics.com/api/1.0/activity
by Csatari, Gergely (Nokia - FI/Espoo) 03 Aug '21

03 Aug '21

Hi, We plan to use the API of stackalytics.com and we realized that the data it provides ([1<https://www.stackalytics.com/api/1.0/activity?page_size=100>]) is never more recent than March 2021. Does anyone know what is the reason for this? Thanks, Gergely 1: https://www.stackalytics.com/api/1.0/activity?page_size=100

5 5

[swift] EC data left in old location after rebalance
by Reid Guyett 03 Aug '21

03 Aug '21

Hello, We started using EC policies in a new cluster a few months ago and added more capacity. During the rebalance (started June 30), it seems that all the data was copied to the new locations but it didn't clean up the old locations. This was identified through our handoff monitoring. OS: Ubuntu 18.04 Swift: 2.17.1 Example: List of devices for partition ~$ swift-get-nodes /etc/swift/object-4.ring.gz -p 14242 ... removed ... Server:Port Device x.x.x.31:6031 d31 Server:Port Device x.x.x.66:6030 d30 Server:Port Device x.x.x.25:6029 d29 Server:Port Device x.x.x.33:6027 d27 Server:Port Device x.x.x.36:6020 d20 Server:Port Device x.x.x.29:6018 d18 Server:Port Device x.x.x.21:6033 d33 Server:Port Device x.x.x.27:6025 d25 Server:Port Device x.x.x.35:6022 d22 Server:Port Device x.x.x.39:6031 d31 Server:Port Device x.x.x.28:6032 d32 Server:Port Device x.x.x.23:6021 d21 Server:Port Device x.x.x.26:6022 d22 Server:Port Device x.x.x.34:6023 d23 Server:Port Device x.x.x.37:6019 d19 Server:Port Device x.x.x.30:6017 d17 Server:Port Device x.x.x.22:6027 d27 Server:Port Device x.x.x.24:6031 d31 Server:Port Device x.x.x.32:6032 d32 Partitions look to have the correct data on them: ~$ ssh root(a)x.x.x.31 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.66 "ls -lah ${DEVICE:-/srv/node*}/d30/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.25 "ls -lah ${DEVICE:-/srv/node*}/d29/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.33 "ls -lah ${DEVICE:-/srv/node*}/d27/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.36 "ls -lah ${DEVICE:-/srv/node*}/d20/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.29 "ls -lah ${DEVICE:-/srv/node*}/d18/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.21 "ls -lah ${DEVICE:-/srv/node*}/d33/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.27 "ls -lah ${DEVICE:-/srv/node*}/d25/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.35 "ls -lah ${DEVICE:-/srv/node*}/d22/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.39 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.28 "ls -lah ${DEVICE:-/srv/node*}/d32/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.23 "ls -lah ${DEVICE:-/srv/node*}/d21/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.26 "ls -lah ${DEVICE:-/srv/node*}/d22/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.34 "ls -lah ${DEVICE:-/srv/node*}/d23/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.37 "ls -lah ${DEVICE:-/srv/node*}/d19/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.30 "ls -lah ${DEVICE:-/srv/node*}/d17/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.22 "ls -lah ${DEVICE:-/srv/node*}/d27/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.24 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" 664 ~$ ssh root(a)x.x.x.32 "ls -lah ${DEVICE:-/srv/node*}/d32/objects-4/14242 | wc -l" 664 >From one of the nodes that does not belong to the list above. This partition should not exist on this node after the rebalance. x.x.x.20:~# ls /srv/node/d28/objects-4/14242 | wc -l 627 The reconstructor is throwing a lot of these unexpected response errors in the logs. Manually running it from the node that should not have the partition, I can reproduce the error. x.x.y.0/24 is the replication network. x.x.x.20:~# swift-object-reconstructor /etc/swift/object-server.conf -d d28 -p 14242 -o -v object-reconstructor: x.x.y.42:6200/d30/14242 Unexpected response: ":ERROR: 500 'ERROR: With :UPDATES: 36 failures to 0 successes'" There looked to have been some partition locations cleaned up around July 11. Our expectation is that the old partition locations should be cleaned gradually since June 30 but we're not seeing that. I Was hoping for some ideas on what may be the problem (if any) and how we can make sure that the old partitions are cleaned up. Thanks, Reid

2 4

[ironic] Xena Mid-cycle
by Iury Gregory 03 Aug '21

03 Aug '21

Hello Ironicers! In our upstream meeting we decided we should do a virtual mid-cycle! If you are interested please fill out the doodle[1] and add topics in the etherpad[2]. Keep in mind we have contributors in many time zones, if you think we should add more time windows, please let me know. Maybe we can have multiple sessions each day so we can accommodate APAC TZ. I will close the doodle before our upstream meeting next week. [1] https://doodle.com/poll/mhh959u4s4rturxi [2] https://etherpad.opendev.org/p/ironic-xena-midcycle -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 1

[nova][gate] nova-tox-functional-* jobs failing on master branch
by melanie witt 02 Aug '21

02 Aug '21

Hey all, The nova-tox-functional-* jobs on the openstack/nova master branch are currently failing 100% of the time: https://zuul.openstack.org/builds?job_name=nova-tox-functional-py38&branch=… This is due to another issue with time overrides (a lack thereof) in the test_archive_task_logs functional tests. The same bug has happened in the past and the fix is now known to have been unsuccessful: https://bugs.launchpad.net/nova/+bug/1934519 Another fix has been proposed here: https://review.opendev.org/c/openstack/nova/+/803106 Please hold your rechecks until the fix merges and apologies for the trouble. -melwitt

2 2

[TripleO] centos7 gate blocker (stable/train) please hold rechecks
by Marios Andreou 02 Aug '21

02 Aug '21

Hello tripleo o/ new gate blocker for centos7 hitting stable/train tripleo repos https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-7-co… bug is at https://bugs.launchpad.net/tripleo/+bug/1938079 - hitting stable/train (we only run c7 jobs there). investigation/resolution ongoing please hold rechecks for centos7 jobs. thank you

2 3

[cinder-backup][ceph] replicate volume between sites
by Tony Liu 01 Aug '21

01 Aug '21

Hi, I have two sites with OpenStack Victoria deployed by Kolla and Ceph Octopus deployed by cephadm. As what I know, either Swift (implemented by RADOSGW) or RBD is supported to be the backend of cinder-backup. My intention is to use one of those option to replicate Cinder volume from one site to another, based on RADOSGW multi-site support or RBD mirroring. I wonder if anyone has done this and could share some opinions, like pros, cons, which way is better for which case? One specific thing I am not clear is that, how to import RBD volume into Cinder when it gets to another site. There used to be a way, but it's replicated. Any comments is appreciated. Thanks! Tony

1 1

[neutron] dnsmasq refusing to provide ipv6 address over dhcpv6 after a server rebuild
by Thomas Goirand 01 Aug '21

01 Aug '21

Hi, I've filled this bug in Debian concerning our official image: https://bugs.debian.org/991613 tl;dr: When doing "openstack server rebuild", dnsmasq refuses to provide an ipv6 when the instance does a dhcpv6 request, because after a rebuild, the instance generates a different DUID. So I wonder if there's a way to fix this by configuring dnsmasq in some ways, maybe by telling it to not use the DUID at all. So far, I haven't found a way yet. Does anyone have a good answer to this problem? Ideally, I'd like to find a way to fix on both side (ie: OpenStack *AND* the official Debian image), so I can make sure to never encounter the issue ever again. Cheers, Thomas Goirand (zigo)

1 0

Routed provider networks
by Gk Gk 31 Jul '21

31 Jul '21

Hi, I learnt that routed provider networks from the below links: https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html https://www.youtube.com/watch?v=HwQFmzXdqZM This concept, according to them solves two issues: 1. Large broadcast L2 domains with failure domains 2. If there are multiple L2 provider networks, users are confused, unable to choose a particular network. My question is, how does routed provider networks solve the second problem mentioned above ? If one user wants to use external network for internet, how can he choose from this one single routed provider network ? Or, if another user wants another provider network, how can he choose that particular network ? Also the same can also be achieved by creating nova aggregates or availability zones and mapping computes with particular provider network connections and ask users to use that particular nova AZ, without creating routed provider networks at all ? Can someone clarify this for me ? Thanks Kumar

2 2

[all][tc] What's happening in Technical Committee: summary 30th July, 21: Reading: 5 min
by Ghanshyam Mann 31 Jul '21

31 Jul '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Retired tripleo-common-tempest-plugin[1] 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-07-29-15.00.log.html * We will have next week's meeting on Aug 5th, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Three open reviews for ongoing activities[4]. Migration from Freenode to OFTC ----------------------------------------- * Only few repo patches are left to merge. requesting core team of those repos to merge them. ** https://review.opendev.org/q/topic:%2522oftc%2522+status:open * openstack blog site is updated for freenode->oftc, Thanks Jimmy for taking care of it. * All the required work for this migration is tracked in this etherpad[5] Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[6], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. Project updates: ------------------- * Retiring js-openstack-lib [7] * Adding tap-as-a-service back to neutron stadium[8] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [9]. * Current status: One goal "Secure RBAC" is proposed. Other Changes ------------------ * Defining Yoga release testing runtime[10] PTG planning ---------------- * TC booked three slots: ** 1. Monday 15-17 UTC for TC + Community Leaders ** 2. Thursday 13-17 UTC ** 3. Friday 13-17UTC * We are collecting the PTG topics in etherpad[11], feel free to add any topic you want to discuss. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [14] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/800432 [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [7] https://review.opendev.org/c/openstack/governance/+/798540 [8] https://review.opendev.org/c/openstack/governance/+/802833 [9] https://etherpad.opendev.org/p/y-series-goals [10] https://review.opendev.org/c/openstack/governance/+/799927 [11] https://etherpad.opendev.org/p/tc-yoga-ptg [12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [14] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0