December 2020 - openstack-discuss

[tc] weekly meeting
by Mohammed Naser 09 Dec '20

09 Dec '20

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 10th) at 1500 UTC in #openstack-tc, and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting # ACTIVE INITIATIVES * Follow up on past action items * W cycle goal selection start * Audit and clean-up tags (gmann) * X cycle release name vote recording (gmann) * CentOS 8 releases are discontinued / switch to CentOS 8 Stream (gmann/yoctozepto) * Open Reviews Thank you, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[kolla] Ussuri Horizon containers fail after Centos 8.3 release
by Braden, Albert 09 Dec '20

09 Dec '20

We are running Train on Centos 7, but I'm experimenting with Adjutant under Ussuri on Centos 8. Until yesterday my Ussuri Horizon containers were ok, but after the Centos 8.3 release they started failing with "{"log":"CommandError: An error occurred during rendering /var/lib/kolla/venv/lib/python3.6/site-packages/openstack_dashboard/templates/horizon/_scripts.html: Couldn't find any precompiler in COMPRESS_PRECOMPILERS setting for mimetype '\\'text/javascript\\''.\n","stream":"stderr","time":"2020-12-08T20:08:03.267208752Z"}" I dug through the Centos release notes and didn't find anything there. [1] I already have the "lowercasing" issue fixed [2]. I see the javascript reference in _scripts.html [3] but it's not obvious what is going wrong. How can I work around this? Is there a variable I can set to build the container on Centos 8.2? Or is there a better way? More logs at [4] [1] https://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.2011 [2] https://review.opendev.org/c/openstack/kolla/+/765854 [3] http://paste.openstack.org/show/800896/ [4] http://paste.openstack.org/show/800897/ 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 2

[tripleo] Deployment update (node addition) after changing aggregate groups/zones
by Ruslanas Gžibovskis 09 Dec '20

09 Dec '20

Hi all. After changing the host aggregate group and zone, I cannot run OpenStack deploy command successfully again, even after updating deployment environment files according to my setup. I receive error bigger one in [0]: 2020-12-02 10:16:18.532419 | 52540000-0001-cf95-492f-0000000003ca | FATAL | Nova: Manage aggregate and availability zone and add hosts to the zone | undercloud | error={"changed": false, "msg": "ConflictException: 409: Client Error for url: http://10.120.129.199:8774/v2.1/os-aggregates/1/action, Cannot add host to aggregate 1. Reason: One or more hosts already in availability zone(s) ['Alpha01']."} I was following this link [1] instructions for "Configuring Availability Zones (AZ)" steps to modify with OpenStack commands. And zone was created successfully, but when I needed to add additional nodes, executed deployment again with increased numbers it was complaining about an incorrect aggregate zone, and now it is complaining about not empty zone with error [0] mentioned above. I have added aggregate zones into deployment files even role file... any ideas? Also, I think, this should be mentioned, that added it after install, you lose the possibility to update using tripleo tool and you will need to modify environment files with. [0] http://paste.openstack.org/show/800622/ [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… -- Ruslanas Gžibovskis +370 6030 7030

2 8

review.opendev.org issue?
by Chris Morgan 09 Dec '20

09 Dec '20

Seems down for me? -- Chris Morgan <mihalis68(a)gmail.com>

4 5

[manila] Graduation of share migration APIs
by Carlos Silva 09 Dec '20

09 Dec '20

Hello, fellow Zorillas and stackers! During the Wallaby PTG, the Manila team discussed the need to remove the experimental flags from the share migration feature APIs. Then, we have realized that there aren't many third party drivers that have implemented "driver-assisted/optimized share migration", so we wanted to get some input from vendors community members on this. Do you want/have plans to implement the driver optimized migration? It'd also be helpful to know if you have tested this feature (even using host assisted migration) or intend to test host assisted migration and can give us some feedback/thoughts on this? In order to graduate the share migration APIs, we must make sure that they are stable. We haven't had bugs opened against it but gathering feedback from the wider community would be helpful to us. Cheers, Carlos

1 0

[neutron] Status on BGP support when using OVN in Neutron
by Tim Sæterøy 09 Dec '20

09 Dec '20

Hi, I'm trying to explore BGP support when using OVN in Neutron, but haven't been able to find much info on the topic. According to [1] committed in march 2020, OVN seems to lack similar functionality as is seen in ML2/OVS, but there's no further references: > Currently ML2/OVS supports making a tenant subnet routable via BGP, > and can announce host routes for both floating and fixed IP > addresses. I've tried searching for 'bgp' on Neutrons launchpad for issues tagged with 'ovn', in the 'ovn-org/ovn' repo or on docs.ovn.org, but I'm getting blanks. Does anyone happen to know where OVN stands on this, and especially in the context of Neutron? Or perhaps able to point me in the right direction where I can find out more? Thanks. [1]: https://docs.openstack.org/neutron/victoria/ovn/gaps.html -- Tim

3 3

[Keystone]Question about access rules for identity API
by Rikimaru Honjo 09 Dec '20

09 Dec '20

Hi, Are the access rules not applied for identity API? I created an application credential with a access rule that allows only project list API. But the application credential allows all identity APIs. Is this correct? Are there any documents that explains about this? By the way, the application credential denied all other service's APIs. I think this behavior is correct. I use OpenStack Ubuntu. Best regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Rikimaru Honjo E-mail:honjo.rikimaru@ntt-tx.co.jp

1 1

[ironic] No Weekly Meeting - December 21st, 28th, and January 4th.
by Julia Kreger 08 Dec '20

08 Dec '20

Greetings fellow humans! As we have in years past, we are approaching the end of year holiday season where people begin to disappear to use time off, rest, and relax their brains. As such, we're cancelling[0] our December 21st, 28th, and January 4th weekly meetings. As in past years, contributors tend to remain connected to IRC, but expect people to be heads-down if they are working, so replies will be sporadic. This also means December 14th will be our last weekly meeting of 2020. In accordance with the prophecy of end of year time off, we'll be in auto-pilot of sorts during the weeks we do not meet. Contributors should feel free to update the review priorities section on the etherpad[1] and look to it for what is going on or what needs additional reviews/feedback. One bit of warning, CI breakages during this time of year are common. Single core approvals to fix CI issues are encouraged in this case. Have a wonderful remainder of the year everyone! -Julia [0]: http://eavesdrop.openstack.org/meetings/ironic/2020/ironic.2020-12-07-15.00… [1]: https://etherpad.opendev.org/p/IronicWhiteBoard

1 0

[tripleo][ci] update - CI jobs failures on RDO and Software Factory Project
by Wesley Hayutin 08 Dec '20

08 Dec '20

forwarded from rdo.... Hi, The CI jobs that are running on Vexxhost should be fine now. Regards, Dan

1 0

[all][qa][kolla][ops][tc] CentOS Project shifts focus to CentOS Stream
by Radosław Piliszek 08 Dec '20

08 Dec '20

TL;DR After 2021 there will be no CentOS 8 point releases. The focus is on CentOS 8 Stream. For more information, please read [1]. As the QA team, we have Stream testing proposed already [2]. We actually had Victoria from Manila ask us about it quite a while ago. Ghanshyam promised to coordinate this topic with the TC. As the Kolla team, we made switch to CentOS 8 Stream a priority of Wallaby and we will likely discuss this option for stable branches which will outlive the 2021 deadline. PS: Don't kill me. I'm just passing the information on. :-) [1] https://lists.centos.org/pipermail/centos-devel/2020-December/075451.html [2] https://review.opendev.org/c/openstack/devstack/+/759122 Kind regards, -yoctozepto

2 2

[tripleo][ci] CI jobs failures on RDO project
by Wesley Hayutin 08 Dec '20

08 Dec '20

FYI ---------- Forwarded message --------- From: Daniel Pawlik <dpawlik(a)redhat.com> Date: Mon, Dec 7, 2020 at 6:13 AM Subject: [rdo-users] CI jobs failures on RDO project To: <users(a)lists.rdoproject.org> Hello, We are facing an outage in our cloud providers. That's why from time to time you can have problems validating CI jobs in RDO project. We are doing our best to fix the issues as soon as possible. Kindly regards, Dan _______________________________________________ users mailing list users(a)lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/users To unsubscribe: users-unsubscribe(a)lists.rdoproject.org

2 1

[tc] weekly update
by Mohammed Naser 08 Dec '20

08 Dec '20

Hi everyone, 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 - Revive os_monasca https://review.opendev.org/c/openstack/governance/+/765800 - Deprecate openstack-ansible-galera_client role https://review.opendev.org/c/openstack/governance/+/765784 - Clarify impact on releases for SIGs https://review.opendev.org/c/openstack/governance/+/752699 - Remove Searchlight project team https://review.opendev.org/c/openstack/governance/+/764530 - Remove Qinling project team https://review.opendev.org/c/openstack/governance/+/764523 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 ## General Changes - Remove already done use-builtin-mock from goal https://review.opendev.org/c/openstack/governance/+/764262 - Propose Kendall Nelson for vice chair https://review.opendev.org/c/openstack/governance/+/762014 - Add election schedule exceptions in charter https://review.opendev.org/c/openstack/governance/+/751941 - Generate the TC liaisons assignments https://review.opendev.org/c/openstack/governance/+/763810 - Update example and oslo code usage in JSON->YAML goal https://review.opendev.org/c/openstack/governance/+/764261 - Clarify the requirements for supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/760562 - Remove assert_supports-zero-downtime-upgrade tag https://review.opendev.org/c/openstack/governance/+/761975 - Add assert:supports-standalone https://review.opendev.org/c/openstack/governance/+/722399 ## Project Updates - Add Magpie charm to OpenStack charms https://review.opendev.org/c/openstack/governance/+/762820 ## Other Reminders - [TC] Weekly meeting, December 10 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, December 09, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] reminder: virtual mid-cycle wednesday 1400 utc
by Brian Rosmaita 08 Dec '20

08 Dec '20

The Cinder Wallaby R-18 virtual mid-cycle will be held: DATE: WEDNESDAY 9 DECEMBER 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the mid-cycle etherpad: https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles cheers, brian

1 0

[development] Installation of Openstack for development using OVS
by Pavlos Basaras 08 Dec '20

08 Dec '20

Hello, I would like to install openstack for testing/development (not production) with OVS, with a controller node and multiple compute nodes, with the option to use ironic. I have followed the documentation https://docs.openstack.org/install-guide/ and i have a successful installation with linux bridges instead of OVS, with all the features working as mentioned in the tutorial. Any directions in how to have an openstack installation with OVS, e.g., a similar manual? Any advice welcome. all the best Pavlos.

1 0

[neutron] Team meeting - Tuesday 08.12.2020
by Slawek Kaplonski 08 Dec '20

08 Dec '20

Hi, It's just quick reminder that today at 1400 UTC on the #openstack-meeting-3 channel there will be neutron team meeting. Agenda is on [1]. If You have any topics which You would like to discuss, please add it to the "On demand section" in the agenda page. Just after that, at 1500 UTC in the same channel there will be also Neutron CI team meeting. [1] https://wiki.openstack.org/wiki/Network/Meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[ironic][masakari] Should masakari rely on Ironic to power fence failing hosts?
by Nicolas Parquet 08 Dec '20

08 Dec '20

Hello Ironic people! I am coming to you with a question from one of the points we discussed during Masakari's PTG [1]. When a host fails and Masakari gets notified, there are some cases in which we would like Masakari to power fence the host before evacuating its instances to other hosts. That way it is safe to start the instances from the failed host on another one. Given that Ironic has the responsability of managing hosts, we would be interested to know how Masakari should do that, in your view? We discussed implementing IPMI power on / off directly in masakari, but maybe an integration where Masakari calls some Ironic API would be better? Or maybe we should implement it relying on the pyghmi library, or any other library? A positive side of relying on Ironic would be that Masakari does not have to store IPMI information about hosts; however that would create a dependency between the 2 projects as some deployments might use masakari without managing their hosts through Ironic. Any insight is welcome! Regards, Nicolas [1] https://etherpad.opendev.org/p/masakari-wallaby-vptg -- Nicolas Parquet Gandi nicolas.parquet(a)gandi.net

2 1

[TripleO] how to make that inspection IP is given only to known hosts
by Ruslanas Gžibovskis 07 Dec '20

07 Dec '20

Hi all, I have a situation, when in my network, I have loads of equipment, which I do not control. and Inspection range gets occupied quite fast. and in TCP dump I get such messages: DHCP-Message Option 53, length 1: NACK Server-ID Option 54, length 4: DHCPD-IP MSG Option 56, length 21: "address not available" I have disabled: enabled_node_discovery = false Anything else? maybe additional environment options for undercloud I could provide? Than kyou in advance, have a good $day_time -- Ruslanas Gžibovskis +370 6030 7030

3 3

[OSSA-2020-008] horizon: Open redirect in workflow forms
by Gage Hugo 07 Dec '20

07 Dec '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================== OSSA-2020-008: Open redirect in workflow forms ============================================== :Date: December 03, 2020 :CVE: CVE-2020-29565 Affects ~~~~~~~ - - Horizon: <15.3.2, >=16.0.0 <16.2.1, >=17.0.0 <18.3.3, >=18.4.0 <18.6.0 Description ~~~~~~~~~~~ Pritam Singh (Red Hat) reported a vulnerability in Horizon's workflow forms. Previously there was a lack of validation on the "next" parameter, which would allow someone to supply a malicious URL in Horizon that can cause an automatic redirect to the provided malicious URL. Patches ~~~~~~~ - - https://review.opendev.org/758843 (Stein) - - https://review.opendev.org/758841 (Train) Credits ~~~~~~~ - - Pritam Singh from Red Hat (CVE-2020-29565) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1865026 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29565 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAl/OrjwACgkQ56j9K3b+ vRG/Gg//Tyj5La8eFwIrwhpDbV/tKNFS+t3NzuhJzLS24WNS9cLf5yDronRdBPdT Ow2OegTZ7K5GyoRARpycTjtE66RIizX9I8Kx27FXPc83hLYYOs/MButYpqcp0swM 687RXZGFcZ5HZtPuRuTcclEcyhzvcUX7HXmznOCmVOHchr+RXzmp6cXC7tyCuNkV cGuuMtptDfkFmn2MpGmiTWEiMusMRbV5HqeyY39jg5dwph0kbMCcuzkX6c2WHubE T+rjVKbmqHr+v7og6mkZoK+pVk6Ulta/lGsYh/0NlszdQw3poN4FIt//TIwJZVwx WSlbMt6IwBW5XiPXvjpX9Awis6CT0jxlIV5XBq+klr3Jo+YnDsChElIPQs3CRKoM vqXVextHCk3LK1Evs3FkBns2Taro4tWOlkGYKR6INT4F1TJKNIzIUiF08673uF3B 8zXDfnVEb7tEMqwu6OdVnfQQ4SRu7uyrN1sHhtwIyfK10AAI7gfJL/wbItJy21Om SQahTfDnikEY5gYYU+NH0LBMXkE0I/T+uvPh4LgP7wUxCMR9uI8+iA0711Gp/aPD WUdm3pUfIJYE7Gq6sT7BJQftHyMPcxOBj+MIrmFDFOxyPV70Mub+f34zxdu3Qoda tZNpy/BGL19VqrlRa9R8H65tzzNy7k5GqkaUYEF5/LegfUgZOTo= =jr+k -----END PGP SIGNATURE-----

1 0

[ops] In a compute node, outbound traffic blocked when a VM running
by Hyunwoo KIM 07 Dec '20

07 Dec '20

Summary of the problem This problem is in a compute node, not in a VM. Once a VM is running in a compute node, all outbound connections in a compute node (not VM) are blocked. For example: # telnet www.google.com 80 Trying 172.217.5.4... Technical Details: We only use provider network. These 4 services are running in each compute node: - neutron-linuxbridge-agent.service - neutron-dhcp-agent.service - neutron-metadata-agent.service - openstack-nova-compute.service Detailed description of the problem: In a compute node, the following is the result of iptables -L when no VM is running: <begin> Chain INPUT (policy ACCEPT) target prot opt source destination neutron-linuxbri-INPUT all -- anywhere anywhere And our usual rules Chain FORWARD (policy ACCEPT) target prot opt source destination neutron-filter-top all -- anywhere anywhere neutron-linuxbri-FORWARD all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination neutron-filter-top all -- anywhere anywhere neutron-linuxbri-OUTPUT all -- anywhere anywhere Chain neutron-filter-top (2 references) target prot opt source destination neutron-linuxbri-local all -- anywhere anywhere Chain neutron-linuxbri-FORWARD (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out tapb --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in tapb --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out tap9 --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in tap9 --physdev-is-bridged Chain neutron-linuxbri-INPUT (1 references) target prot opt source destination Chain neutron-linuxbri-OUTPUT (1 references) target prot opt source destination Chain neutron-linuxbri-local (1 references) target prot opt source destination Chain neutron-linuxbri-sg-chain (0 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain neutron-linuxbri-sg-fallback (0 references) target prot opt source destination DROP all -- anywhere anywhere </end> In the same compute node, when a VM is running, the following is the result of iptables -L: <begin> Chain INPUT (policy ACCEPT) target prot opt source destination neutron-linuxbri-INPUT all -- anywhere anywhere And our usual rules Chain FORWARD (policy ACCEPT) target prot opt source destination neutron-filter-top all -- anywhere anywhere neutron-linuxbri-FORWARD all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination neutron-filter-top all -- anywhere anywhere neutron-linuxbri-OUTPUT all -- anywhere anywhere Chain neutron-filter-top (2 references) target prot opt source destination neutron-linuxbri-local all -- anywhere anywhere Chain neutron-linuxbri-FORWARD (1 references) target prot opt source destination neutron-linuxbri-sg-chain all -- anywhere anywhere PHYSDEV match --physdev-out tap8 --physdev-is-bridged neutron-linuxbri-sg-chain all -- anywhere anywhere PHYSDEV match --physdev-in tap8 --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out tapb --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in tapb --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-out tap9 --physdev-is-bridged ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in tap9 --physdev-is-bridged Chain neutron-linuxbri-INPUT (1 references) target prot opt source destination neutron-linuxbri-o8 all -- anywhere anywhere PHYSDEV match --physdev-in tap8 --physdev-is-bridged Chain neutron-linuxbri-OUTPUT (1 references) target prot opt source destination Chain neutron-linuxbri-i8 (1 references) target prot opt source destination RETURN all -- anywhere anywhere state RELATED,ESTABLISHED RETURN udp -- anywhere fermicloud248.fnal.gov udp spt:bootps dpt:bootpc RETURN udp -- anywhere 255.255.255.255 udp spt:bootps dpt:bootpc RETURN icmp -- anywhere anywhere RETURN tcp -- fermilab-net.fnal.gov/16 anywhere tcp dpt:ssh RETURN all -- anywhere anywhere match-set NIPv41d69ba3c-68e3-414f-8f1b- src DROP all -- anywhere anywhere state INVALID neutron-linuxbri-sg-fallback all -- anywhere anywhere Chain neutron-linuxbri-local (1 references) target prot opt source destination Chain neutron-linuxbri-o8 (2 references) target prot opt source destination RETURN udp -- default 255.255.255.255 udp spt:bootpc dpt:bootps neutron-linuxbri-s8 all -- anywhere anywhere RETURN udp -- anywhere anywhere udp spt:bootpc dpt:bootps DROP udp -- anywhere anywhere udp spt:bootps dpt:bootpc RETURN all -- anywhere anywhere state RELATED,ESTABLISHED RETURN tcp -- anywhere anywhere tcp dpt:https RETURN all -- anywhere anywhere RETURN tcp -- anywhere anywhere tcp dpt:http DROP all -- anywhere anywhere state INVALID neutron-linuxbri-sg-fallback all -- anywhere anywhere Chain neutron-linuxbri-s8 (1 references) target prot opt source destination RETURN all -- fermicloud248.fnal.gov anywhere MAC FA:16: DROP all -- anywhere anywhere Chain neutron-linuxbri-sg-chain (2 references) target prot opt source destination neutron-linuxbri-i8 all -- anywhere anywhere PHYSDEV match --physdev-out tap8 --physdev-is-bridged neutron-linuxbri-o8 all -- anywhere anywhere PHYSDEV match --physdev-in tap8 --physdev-is-bridged ACCEPT all -- anywhere anywhere Chain neutron-linuxbri-sg-fallback (2 references) target prot opt source destination DROP all -- anywhere anywhere </end> Let me summarize the differences from when no VM running: Chain INPUT : no change Chain FORWARD: no change Chain OUTPUT : no change Chain neutron-filter-top: no change Chain neutron-linuxbri-FORWARD: Two new rules are added neutron-linuxbri-sg-chain neutron-linuxbri-sg-chain Chain neutron-linuxbri-INPUT: One new rule is added neutron-linuxbri-o8ae816b0-f Chain neutron-linuxbri-sg-chain: Two new rules are added neutron-linuxbri-i8 neutron-linuxbri-o8 Chain neutron-linuxbri-OUTPUT: no change Chain neutron-linuxbri-local: no change Chain neutron-linuxbri-sg-fallback: no change Chain neutron-linuxbri-i8: A new chain with multiple rules Chain neutron-linuxbri-o8: A new chain with multiple rules Chain neutron-linuxbri-s8: A new chain with multiple rules But now a problem arises here: All outbound connections are blocked (remember this is in a compute node, not VM): For example: # telnet www.google.com 80 Trying 172.217.5.4... When there isn't any VM running, We don't see this problem. I was wondering if I needed to create a new security group rule for the port 80 (for example) but that didn't solve the issue. Any technical advice will be appreciated, Thanks, Hyunwoo

2 2

openstack read only user
by dhanesh1212121212 07 Dec '20

07 Dec '20

Hi Team, Please let me know the steps to create a read only user in openstack. (My version is Rocky) Regards, Dhanesh M.

4 3

[interop][refstack] Revival/Maintenance proposal
by Goutham Pacha Ravi 07 Dec '20

07 Dec '20

Hi, As many of you are aware, the interop working group defines test advisories for evaluating implementations of OpenStack for interoperability. The implementers themselves - whether they are OpenStack cloud operators, distributions or vendors of specific products aligning with OpenStack use refstack-client [1] to submit their results. Refstack client is a bunch of helpful scripts to stand up tempest, run the tests and compile results. The results compiled from refstack-client are posted to https://refstack.openstack.org - code for which exists in the "refstack" repository [2] For a few releases now, gmann has pointed out to the Interop WG that refstack needs maintainers. In our last meeting, Martin Kopec (mkopec) volunteered to maintain refstack-client, and help coordinate changes to adopt the latest advisories published by the interop working group. Martin's been running interop testing for Red Hat OpenStack, and he has contributed ansible automation for installing, running tests and submitting results [3]. So he'll bring valuable interop perspective to this project and maintain it effectively. The interop WG also suggested that Martin's ansible scripts [3] be moved under the "osf/" organization on opendev.org, and he's currently pursuing that [4]. I see a number of names on the refstack-core group on Gerrit [5]. Is it possible there's anyone in the team that's still involved in the maintenance of this project, and can add Martin? Thanks, Goutham [1] https://opendev.org/osf/refstack-client [2] https://opendev.org/osf/refstack [3] https://opendev.org/x/ansible-role-refstack-client [4] https://review.opendev.org/c/openstack/project-config/+/765787 [5] https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf…

2 1

[tc][all][searchlight ] Retiring the Searchlight project
by Ghanshyam Mann 07 Dec '20

07 Dec '20

Hello Everyone, As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Searchlight contributors and PTLs for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&met… [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re… -gmann

5 8

[tc][all][qinling] Retiring the Qinling project
by Ghanshyam Mann 07 Dec '20

07 Dec '20

Hello Everyone, As you know, Qinling is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Qinling repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Qinling, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Qinling will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Qinling contributors and PTLs (especially lxkong ) for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=qinling-group&metric=… [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-reposito… [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re… -gmann

4 6

[Neutron] How to enable the SCTP protal support in security-groups for Openstack-Rocky release
by Velugubantla Praveen 07 Dec '20

07 Dec '20

Hi Team, In OPENSTACK security groups how to add the SMTP protocol rules, can some-one please point me to the right documentation of how to add those required configurations to enable SMTP and other protocols to my openstack-rocky release neutron setup. Can we add some additional protocol's above the default provided security rules? Any help or suggestion is highly appreciated. Thanks in advance. Regards, ________________________________________________________ Velugubantla Praveen Engineer - Non-Media Solutions Communications & Media L&T TECHNOLOGY SERVICES LIMITED L3 Building, Manyata Embassy Business Park, Nagawara Hobli, Bengaluru-560045 ________________________________________________________ Mobile: +91 9154111420 www.LTTS.com<http://www.ltts.com/> [cid:e997ce03-4d35-4f33-ad56-ad4facc1f804] L&T Technology Services Ltd www.LTTS.com L&T Technology Services Limited (LTTS) is committed to safeguard your data privacy. For more information to view our commitment towards data privacy under GDPR, please visit the privacy policy on our website www.Ltts.com. This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

2 1

[ptl] Victoria Release Community Meeting Videos
by helena＠openstack.org 07 Dec '20

07 Dec '20

Hi Everyone, Thank you to all the PTLs who presented and all the community members who attended the Victoria Release Community Meeting last November! As mentioned before we uploaded the presentations from the community meeting to the project navigator for each project that was presented on ([ Glance ]( https://www.openstack.org/software/releases/victoria/components/glance ), [ Cinder ]( https://www.openstack.org/software/releases/victoria/components/cinder ), [ Manila ]( https://www.openstack.org/software/releases/victoria/components/manila ), [ Nova ]( https://www.openstack.org/software/releases/victoria/components/nova ), [ Masakri ]( https://www.openstack.org/software/releases/victoria/components/masakari ), [ Neutron ]( https://www.openstack.org/software/releases/victoria/components/neutron )). You can also find the full community meeting and all the individual videos on the “[ Community Meetings ]( https://www.youtube.com/playlist?list=PLKqaoAnDyfgpYADSiOfIVwgKb5zbL0GJE )” playlist on YouTube. If you are a PTL interested in still creating a video to add to YouTube and the Project Navigator, you may do so and email it to me. Cheers, Helena

2 2