August 2020 - openstack-discuss - lists.openstack.org

[tripleo] no recheck please
by Emilien Macchi 26 Aug '20

26 Aug '20

We're hitting the docker rate limits very badly right now and while our mitigation patch will land [1], please refrain from approving or recheck patches for now. I've cleared the gate and I'll take care of re-adding these patches into the gate when things will be stable again. [1] https://review.opendev.org/#/c/746993 Thanks for your understanding and your patience! -- Emilien Macchi

1 1

[tripleo] TripleO CI Summary: Unified Sprint 31
by Rafael Folco 26 Aug '20

26 Aug '20

Greetings, The TripleO CI team has just completed **Unified Sprint 31** (July 31 thru Aug 20). The following is a summary of completed work during this sprint cycle*: - Continued building internal component and integration pipelines for rhos-16.2. - Added more jobs to the component and integration pipelines. - Completed promoter code and test scenarios to run on CentOS8/Python3. - Continued merging changes to switch to the new configuration engine in promoter code. - Merged all patches for CentOS-7 -> CentOS-8 stable/train upstream migration. - Design improvements to Tempest scenario manager are under review. - Python3 support on diskimage-builder and buildimage role in tripleo-ci repo is under review. - Ruck/Rover recorded notes [1]. The planned work for the next sprint extends the work started in the previous sprint and focuses on the following: - Downstream OSP 16.2 pipeline. - Next-gen promoter changes (new configuration engine). - Dependency pipeline design to early detect breakages in the OS. - New container naming prefix on Victoria/Master onwards. The Ruck and Rover for this sprint are Arx Cruz (arxcruz) and Amol Kahat (akahat). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in hackmd [2]. Thanks, rfolco *TripleO-CI team is now using an internal JIRA instance to track sprint work [1] https://hackmd.io/QnprH9-yRTi6uWlEfaahoQ [2] https://hackmd.io/FUalpr55TJuy28QLp2tLng -- Folco

1 0

[OSSA-2020-006] Nova: Live migration fails to update persistent domain XML (CVE-2020-17376)
by Jeremy Stanley 25 Aug '20

25 Aug '20

=================================================================== OSSA-2020-006: Live migration fails to update persistent domain XML =================================================================== :Date: August 25, 2020 :CVE: CVE-2020-17376 Affects ~~~~~~~ - Nova: <19.3.1, >=20.0.0 <20.3.1, ==21.0.0 Description ~~~~~~~~~~~ Tadayoshi Hosoya (NEC) and Lee Yarwood (Red Hat) reported a vulnerability in Nova live migration. By performing a soft reboot of an instance which has previously undergone live migration, a user may gain access to destination host devices that share the same paths as host devices previously referenced by the virtual machine on the source. This can include block devices that map to different Cinder volumes on the destination than the source. The risk is increased significantly in non-default configurations allowing untrusted users to initiate live migrations, so administrators may consider temporarily disabling this in policy if they cannot upgrade immediately. This only impacts deployments where users are allowed to perform soft reboots of server instances; it is recommended to disable soft reboots in policy (only allowing hard reboots) until the fix can be applied. Patches ~~~~~~~ - https://review.opendev.org/747978 (Pike) - https://review.opendev.org/747976 (Queens) - https://review.opendev.org/747975 (Rocky) - https://review.opendev.org/747974 (Stein) - https://review.opendev.org/747973 (Train) - https://review.opendev.org/747972 (Ussuri) - https://review.opendev.org/747969 (Victoria) Credits ~~~~~~~ - Tadayoshi Hosoya from NEC (CVE-2020-17376) - Lee Yarwood from Red Hat (CVE-2020-17376) References ~~~~~~~~~~ - https://launchpad.net/bugs/1890501 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17376 Notes ~~~~~ - The stable/rocky, stable/queens, and stable/pike branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

Re: Openstack with Nginx Support (HARISH KUMAR Ivaturi)
by prakash RAMCHANDRAN 25 Aug '20

25 Aug '20

Harish, Note Horizon dashboard is based on Django framework over Apache. Thus logically it should work if you deploy Django over Nginx and please refer to link getting Django and once you have that rest should work as the Model, View, Controller (MVC) take care of addressing the rest. I have not seen any Ngnix deployment of Open stack, but a single domain Open stack Controller should be possible to deploy with Nginx. You can also reach out to Ngnix or F5 team to help you out, as this is a good exercise for leveraging capability of Nginix for OpenSrack https://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html ThanksPrakash ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Aug 2020 14:30:27 +0200 From: HARISH KUMAR Ivaturi <harishkumarivaturi(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: Openstack with Nginx Support Message-ID: <CAGmfrByFq8++y6T6sBvKmCjb+T9MGhkua0WP6ZYOVb0gkCTXRA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi I am Harish Kumar, Master Student at BTH, Karlskrona, Sweden. I am working on my Master thesis at BTH and my thesis topic is Performance evaluation of OpenStack with HTTP/3. I have successfully built curl and nginx with HTTP/3 support and I am performing some commands using curl for generating tokens so i could access the services of OpenStack. OpenStack relies with the Apache web server and I could not get any results using Nginx HTTP/3 . I would like to ask if there is any official documentation on OpenStack relying with Nginx?, I have searched in the internet reg. this info but could not get any, I would like to use nginx instead of apache web server , so I could get some results by performing curl and commands and nginx web server (with http/3 support). Please let me know and if there is any content please share with me. I hope you have understood this. It would be helpful for my Master Thesis. BR Harish Kumar

1 0

[tc] weekly update
by Mohammed Naser 25 Aug '20

25 Aug '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. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Reviews - Add assert:supports-standalone https://review.opendev.org/722399 - Add etcd3gw to Oslo https://review.opendev.org/747188 - Update and simplify comparison of working groups https://review.opendev.org/746763 - Drop requirement of 1/3 positive TC votes to land https://review.opendev.org/746711 - Resolution to define distributed leadership for projects https://review.opendev.org/744995 - Move towards dual office hours in diff TZ https://review.opendev.org/746167 - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 - Drop all exceptions for legacy validation https://review.opendev.org/745403 - Move towards single office hour https://review.opendev.org/745200 ## General Changes - Fix names inside check-review-status https://review.opendev.org/745913 # Email Threads - Zuul Native Jobs Goal Update #2: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016561.h… - Masakari Project Aliveness: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016520.h… - vPTG October 2020 Signup: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016497.h… - OpenStack Client vs python-*clients: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016409.h… Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[monasca] Deprecate monasca-transform repository
by Witek Bedyk 25 Aug '20

25 Aug '20

Hello, this message is to announce the deprecation of openstack/monasca-transform repository. The project will not accept new development on master branch but accept fixes on stable branches. It will follow the process described in Project Team Guide [1]. Please reply to this message until Sept. 7 if you would like to take over the development and maintenance of this repository. Thanks Witek [1] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a…

1 0

Openstack with Nginx Support
by HARISH KUMAR Ivaturi 25 Aug '20

25 Aug '20

Hi I am Harish Kumar, Master Student at BTH, Karlskrona, Sweden. I am working on my Master thesis at BTH and my thesis topic is Performance evaluation of OpenStack with HTTP/3. I have successfully built curl and nginx with HTTP/3 support and I am performing some commands using curl for generating tokens so i could access the services of OpenStack. OpenStack relies with the Apache web server and I could not get any results using Nginx HTTP/3 . I would like to ask if there is any official documentation on OpenStack relying with Nginx?, I have searched in the internet reg. this info but could not get any, I would like to use nginx instead of apache web server , so I could get some results by performing curl and commands and nginx web server (with http/3 support). Please let me know and if there is any content please share with me. I hope you have understood this. It would be helpful for my Master Thesis. BR Harish Kumar

1 0

[ironic] RFC: deprecate the iSCSI deploy interface?
by Dmitry Tantsur 25 Aug '20

25 Aug '20

Hi all, Side note for those lacking context: this proposal concerns deprecating one of the ironic deploy interfaces detailed in https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html. It does not affect the boot-from-iSCSI feature. I would like to propose deprecating and removing the 'iscsi' deploy interface over the course of the next 2 cycles. The reasons are: 1) The iSCSI deploy is a source of occasional cryptic bugs when a target cannot be discovered or mounted properly. 2) Its security is questionable: I don't think we even use authentication. 3) Operators confusion: right now we default to the iSCSI deploy but pretty much direct everyone who cares about scalability or security to the 'direct' deploy. 4) Cost of maintenance: our feature set is growing, our team - not so much. iscsi_deploy.py is 800 lines of code that can be removed, and some dependencies that can be dropped as well. As far as I can remember, we've kept the iSCSI deploy for two reasons: 1) The direct deploy used to require Glance with Swift backend. The recently added [agent]image_download_source option allows caching and serving images via the ironic's HTTP server, eliminating this problem. I guess we'll have to switch to 'http' by default for this option to keep the out-of-box experience. 2) Memory footprint of the direct deploy. With the raw images streaming we no longer have to cache the downloaded images in the agent memory, removing this problem as well (I'm not even sure how much of a problem it is in 2020, even my phone has 4GiB of RAM). If this proposal is accepted, I suggest to execute it as follows: Victoria release: 1) Put an early deprecation warning in the release notes. 2) Announce the future change of the default value for [agent]image_download_source. W release: 3) Change [agent]image_download_source to 'http' by default. 4) Remove iscsi from the default enabled_deploy_interfaces and move it to the back of the supported list (effectively making direct deploy the default). X release: 5) Remove the iscsi deploy code from both ironic and IPA. Thoughts, opinions, suggestions? Dmitry

6 11

[cliff] [dev] Cliff auto completion not working inside interactive mode
by sandeep 25 Aug '20

25 Aug '20

Hi Team, In my system, I am trying auto completion for my CLI application. CLIFF version - cliff==3.4.0 Auto complete works fine on bash prompt. But inside the interactive shell, auto complete does not work. Below is the output for the help command inside the interactive shell. (appcli) help Miscellaneous help topics: ========================== help Application commands (type help <topic>): ========================================= complete snapshot list reports service restart service-object-type app2 service restart service-object-type app3 service restart service-object-type app4 service show state service-object-type app1 service show state service-object-type app2 service show state service-object-type app3 service show state service-object-type app4 swm rollback node swm cancel sw-update swm downgrade node swm list sw-info swm show sw-info swm start sw-update file swm start sw-downgrade help Now, if I type swm and press tab, it lists all the sub commands under it. (appcli) swm cancel sw-update list sw-info start sw-update file downgrade node rollback node show sw-info start sw-downgrade But if i type, (appcli) swm s<tab> gives below output, (appcli) swm "s It stops at this point and further pressing tab does not autocomplete. Could you please let me know what could be the problem? Is this a known issue? or Am i missing something? Thanks, Sandeep

1 0

Scaling control nodes
by Benjamin Zapiec 25 Aug '20

25 Aug '20

Hello everyone, while trying openstack i referred to the red hat installation documentation which is okay but lead to one question. It looks like there is no problem in scaling compute nodes if you run out of resources. But scaling the controller nodes is not supported by red hat. Since I'm using the official tripleo openstack version and not the red hat version i was wondering if this is not supported by the openstack project. Having in mind that red hat doesn't support this i was looking for something that tells me that it is supported (or not) by the tripleo openstack project. But i didn't found anything explicit. So may you tell me if it is possible to scale up Controller Nodes? And if not which component is not scalable by tripleo? Is it possible to create an controller profile that is scalable? Best regards -- Benjamin Zapiec <benjamin.zapiec(a)gonicus.de> (System Engineer) * GONICUS GmbH * Moehnestrasse 55 (Kaiserhaus) * D-59755 Arnsberg * Tel.: +49 2932 916-0 * Fax: +49 2932 916-245 * http://www.GONICUS.de * Sitz der Gesellschaft: Moehnestrasse 55 * D-59755 Arnsberg * Geschaeftsfuehrer: Rainer Luelsdorf, Alfred Schroeder * Vorsitzender des Beirats: Juergen Michels * Amtsgericht Arnsberg * HRB 1968 Wir erfüllen unsere Informationspflichten zum Datenschutz gem. der Artikel 13 und 14 DS-GVO durch Veröffentlichung auf unserer Internetseite unter: https://www.gonicus.de/datenschutz oder durch Zusendung auf Ihre formlose Anfrage.

1 0