June 2020 - openstack-discuss - lists.openstack.org

[all][InteropWG] Tuesday June 9, UTC 17 - Meeting Reminder to review OpenStack Powered Logo Guidelines and your feedback
by prakash RAMCHANDRAN 08 Jun '20

08 Jun '20

InteropWG is inviting you to a scheduled Zoom meeting Tuesday June 9th,10-10.45 AM PDT / 13-13.45 EDT / 17-17.45 UTC,Join from a browser: https://Dell.zoom.us/wc/join/99829924353 , Password: 101045 , orJoin Zoom Meeting: https://Dell.zoom.us/j/99829924353?pwd=bU9NTkZQVkd3SmIrVGErZWFGVnlmUT09 , and in paralle on irc ,irc: #openstack-interopwg or #openstack , For background review - 1. https://www.slideshare.net/markvoelker/interopwg-intro-vertical-programs-ja… , 2. https://opendev.org/openstack/interop/src/branch/master/2020.06.json , 3. https://etherpad.opendev.org/p/victoria-ptg-interop-wg , Agenda: 1. Agenda Bashing2. Presentation for comments on Ussuri Interop Draft Guidelines (Need - Verbage and logo for adding OpenStack Powered DNS & Orchetsration - -https://www.openstack.org/brand/interop/) Review Project APIs for Interop Ussuri cycle a. keystone , b. glance , c. nova , d. neutron , e. cinder , f. swift , g. designate (OpenStack powered DNS logo?) , h. heat (OpenStack powered Orchestrator Logo?) . 3. Feed back by contributors and any other PTG or representatiive from community 4. Conclusion by Mark Voelker for Ussuri Draft - Vice Chair (Market Place, logo, irc, conference-bridge, issues in refstack-client, tempest features,...) 5. Approval verbal or irc vote in Interop WG for Draft to Board for Thursday June 11 schedule - https://wiki.openstack.org/wiki/Governance/Foundation/11June2020BoardMeeting Finally Any suggestions for Victoria cycle to explore 1. Ironic or Bare metal (Open Infrastructure Powered Logo?)2. NFV (tacker? NFVi &/or VNF/CNF APIs?) (OpenStack NFV Logo?)3. Ideas needed for Heterogeneus Cloud compliance (suggest use cases) (OpenStack Compatible Hybrid Cloud Logo?) ThanksPrakash : Chair InteropWGMark : Vice Chair : Interop WG

1 0

[tripleo] no irc meeting tomorrow
by Wesley Hayutin 08 Jun '20

08 Jun '20

Greetings, As discussed at the PTG, there will only be one TripleO irc meeting every three weeks. I'll update the docs and schedule to reflect that. Thanks

1 0

[oslo] Ping List for Victoria
by Ben Nemec 08 Jun '20

08 Jun '20

Hi, With the start of a new cycle, we refresh our courtesy ping list for the start of the meeting. We do this to avoid spamming people who may no longer be working on Oslo but haven't explicitly removed their name from the ping list. To that end, I've added a new ping list above the agenda template[0]. If you wish to continue receiving courtesy pings, please add your name there. In a couple of weeks we will switch to using this new list. Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

[keystone] No meeting June 9th
by Nikolla, Kristi 08 Jun '20

08 Jun '20

Hi all, Since we met during the PTG on Thu-Fri, I don't think it's necessary to have the weekly meeting this Tuesday on June 9th. Have 1 hour back :) Best, Kristi

1 0

OSF Community Meeting - June 25 & 26
by Allison Price 08 Jun '20

08 Jun '20

Hi everyone, On June 25 (1300 UTC) and June 26 (0200 UTC) , we will be holding the quarterly OSF community [1] that will cover project updates from all OSF-supported projects and events. The OpenStack community is encouraged to prepare a slide and present a 3-5 minute update on the project and community’s progress. The update should cover updates that have occurred since the last community meeting on April 2. If you would like to volunteer to present the OpenStack update for one meeting (or both!) please sign up here [1]. We are aiming to finalize the content by Friday, June 19. If you missed the Q1 community meeting, you can see how the upcoming meeting will be structured in this recording [2] and this slide deck [3]. If you have any questions, please let me know. Thanks! Allison [1] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…>

1 0

[all][PTG] Feedback Etherpad
by Kendall Nelson 08 Jun '20

08 Jun '20

Hello Everyone! Thanks to everyone who made the first ever virtual PTG a success! Instead of doing a live feedback session, we are asking you to share your experiences with us in a feedback etherpad! We started circulating it even before the PTG, but wanted to make sure you all saw it and had a chance to voice your feedback. We really appreciate it! -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/June2020-PTG-Feedback

1 0

[baremetal-sig][ironic] Baremetal whitepaper: the final chapter
by Arne Wiebalck 08 Jun '20

08 Jun '20

Dear all, The bare metal white paper [0] is almost finished, thanks to everyone who helped during the past weeks! We plan to have a (hopefully final) session to address the remaining open issues and to round things off during one of slots proposed in the doodle available at https://doodle.com/poll/afwgy9zs8fi55wqe Everyone is still welcome to give input or feedback. Like before, I will send out the call details once we have settled on the time slot. Cheers, Arne [0] https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsf… -- Arne Wiebalck CERN IT

1 1

[swift, interop] Swift API level changes to reflect in Interop
by Arkady.Kanevsky＠dell.com 08 Jun '20

08 Jun '20

As we create new guidelines for Interop, We need to see what changes needed for object storage guidelines. So a few specific questions for Swift team: 1. What new Tempest tests added for Ussuri release? a. APIs for query and accessing older versions? Is it for S3 APIs or for swift API also? b. Any new or modified Tempest test for Etags? c. Any SIGUSR1 test coverage? d. New tempest tests for swift-ring-builder? 2. What are tempest tests deprecated for Ussuri release? a. Any tempest tests removed for auto_create_account_prefix? Any other API test coverage tests missed above? Thanks, Arkady

3 6

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

08 Jun '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. # CHANGES PENDING - Select migrate-to-focal goal for Victoria cycle: https://review.opendev.org/#/c/731213/ - Propose Kendall Nelson for vice-chair: https://review.opendev.org/#/c/733141/ - Clarify the support for linux distro: https://review.opendev.org/#/c/727238/ - Add njohnston liaison preference: https://review.opendev.org/#/c/733269/ - Update joining-tc.rst to be general tc-guide.rst: https://review.opendev.org/#/c/732983/ - Remove tricircle project team: https://review.opendev.org/#/c/731566/ - Add diablo_rojo liaison preferences: https://review.opendev.org/#/c/733284/ - Rename ansible-role-lunasa-hsm deliverable: https://review.opendev.org/#/c/731313/ - Merging TC and UC into a single body: https://review.opendev.org/#/c/734074/ - Retire swift-specs: https://review.opendev.org/#/c/733901/ # RETIRED PROJECTS - Remove congress project team: https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Switch to newer openstackdocstheme version: https://review.opendev.org/#/c/733313/ Thanks! Regards, -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder][kayobe][kolla][OSA][tripleo] Ussuri cycle-trailing release deadline
by Sean McGinnis 08 Jun '20

08 Jun '20

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Ussuri trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until August 13: https://releases.openstack.org/victoria/schedule.html#v-cycle-trail If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla-cli kolla openstack-ansible os-refresh-config Thanks! Sean

1 0

[nova] Runway for Victoria
by Balázs Gibizer 08 Jun '20

08 Jun '20

Hi, Runway etherpad [1] with 3 slots and and empty queue is open for Victoria. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-runways-victoria

1 0

[doc] installation guide maintenance
by Akihiro Motoki 08 Jun '20

08 Jun '20

Hi, During the doc migration, the installation guide was moved to individual project repos. I see problems in installation guide maintenance after the migration. - The installation guide is not maintained well perhaps in many projects. AFAIK they are not verified well at least in horizon and neutron. - Even if we try to verify it, it is a tough thing because we need to prepare base distribution and setup other projects together (of course it depends on projects). This leads to a development bandwidth and priority issue. - We sometimes receive bug reports on the installation guide, but it is not easy for the upstream team confirm them and verify fixes. I guess the installation guides are not being maintained well from these reasons. Any thoughts on this situation? (This is my first question.) If a project team has no bandwidth to maintain it, what is a recommended way? I see several options: - Drop the installation guide (per OS or as a whole) -- If drop what should the criteria be? - Keep the installation guide with warnings like "the upstream team does not maintain it and just host it". - Keep it as-is (unmaintained) Finally, I am not sure we need to maintain step-by-step guides on installations and I wonder we need to drop them at some time. Most users deploy OpenStack using deployment projects (or their own deployment tools). Step-by-step guides might be useful from educational perspective but unmaintained guides are not useful. Thanks in advance, -- Akihiro Motoki (amotoki)

5 7

[neutron] Neutron Bug Deputy Report Jun 1-8
by Lucas Alvares Gomes 08 Jun '20

08 Jun '20

Hi, This is the Neutron bug report of week 23 (1 Jun - 8 Jun). Untriaged: - "Inconsistent coding while upgrading" * https://bugs.launchpad.net/neutron/+bug/1881685 - "Centralized SNAT failover does not recover until "systemctl restart neutron-l3-agent" on transferred node" * https://bugs.launchpad.net/neutron/+bug/1881995 - "Quality of Service (QoS) in neutron" * https://bugs.launchpad.net/neutron/+bug/1882072 Critical: - "[OVN]IPv6 hot plug tempest tests are failing with OVN backend" * https://bugs.launchpad.net/neutron/+bug/1881558 - "Neutron-vpnaas scenario tests are very unstable" * https://bugs.launchpad.net/neutron/+bug/1882220 High: - "[OVN] Virtual port type set while port has no parents" * https://bugs.launchpad.net/neutron/+bug/1881759 * Fix released * Assigned to Maciej Jozefczyk * Patch proposed: https://review.opendev.org/732690 - "neutron-ipset-cleanup fails with Traceback: Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT]" * https://bugs.launchpad.net/neutron/+bug/1881771 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/732701 - "neutron-ovn-db-sync-util fails with KeyError: 'port_security_enabled' when port security not enabled" * https://bugs.launchpad.net/neutron/+bug/1882061 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733512 - "neutron-ovn-db-sync-util stops with Traceback due to L3 service plugin expecting ``ovn`` mech driver to be present while ``ovn-sync`` mech driver is loaded" * https://bugs.launchpad.net/neutron/+bug/1882202 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733775 Medium: - "neutron-ovn-db-sync-util fails with Traceback when notify_nova config is present" * https://bugs.launchpad.net/neutron/+bug/1882020 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733481 Invalid: - "Neutron CI doesn't run tests that require advanced image" * https://bugs.launchpad.net/neutron/+bug/1882060

1 0

Re：[cyborg][ptg] Cyborg PTG Summary for the Day — Come in series
by yumeng bao 07 Jun '20

07 Jun '20

Hi all, All topics for cyborg PTG are done! Notes and comments are on the etherpad. Thank you all for the great topics, participation, discussion etc! Topics that have come to an conclusion are marked with [AGREE] or [ACTION], while topics that need further discussion are not. listed below are important topics that need further discussion either in the format of future meeting or maillist or a spec: 1. 3rd party CI support for new drivers * define which tempest tests need to be used in 3rd party CI. * 2. cyborg/neutron/nova sriov intigration * a spec in nova will be proposed to continue discussion If you have any feedbacks please reply here or in IRC. Regards, Yumeng

1 0

[puppet] puppet-openstack meeting
by Thomas Goirand 07 Jun '20

07 Jun '20

Hi guys! Wouldn't it be nice to organize some meet-up online, for example using the jitsi instance that the infra team built? I at least would enjoy a lot seeing you face-to-face (ie: Tobias, Takashi, Zheng, as I know already Emilien and Alex). Moreover, it'd be nice to discuss the plans for Victoria. Your thoughts? Cheers, Thomas Goirand (zigo)

1 0

[all][InteropWG] Last call for interop capabilities from OpenStack partciapting projects
by prakash RAMCHANDRAN 06 Jun '20

06 Jun '20

Hi all, We are happy to report that score of people turned up for Interop WG discussions on First call on Monday June1st.Friday 5th June we had a review call to consolidate and follow up on guidelines for the OpenStack Powered Trademark Program. https://etherpad.opendev.org/p/victoria-ptg-interop-wghttps://etherpad.open… Please note the terminology -https://github.com/openstack/interop/blob/master/doc/source/schema/2.0.rst#capabilities capabilities - required, advisory, deprecated, removed Stein Train /add Ussuri/delete Victoria KeystoneGlanceSwift Nova NA (Ironic BM) Neutron Cinder v2 Add-ons OpenStack Powered - Orchestration & DNSHeatDesignate Based on current review there are no net new APIs to be added to Ussuri cycle with respect to Stein that are eligible for Interop Programs.The above project teams can go through codeRefStack server guidelines page RefStack Client. Artem Goncharov (irc: gtema) - ANswers to Questions by Artem and follow up actions - refstack-client seems to be orphaned now and offered changes are not reviewed (gtema) - There is access failure and is being addressed by Mark, after that we will review this with help of gtema to file a ticket with bug details - link between guideline and required tempest is desired, since it requires currently effors to nail down failures by jumping between tempest versions (gtema) - This a feature add request, need a story or bug to aggressed in Tempest by gtema - network extensions api - does it make sense to include it? - Note any L2/L3 CRUD on network, subnet and ports and all their attributes are covered. The plug-ins and admin user requirements for extensions are out of scope and hence not considered. However you may verify with Neutron team as what is their proposal to this team? - resource tagging apis - does it make sense to include them? - Reosurce taggin again are optional attirbutes to reousrce ID and very speicifc to resource under trait libraray or ad-hoc to Vendor specific plugins and drivers and will not qualify for interoperability. You can still ask if any new resources that are used by any of core projects to propose and justify why tha'ts required for interop testing? Attached the current diff's for both 2020.06.json vs 2019.11.json and similar diff's for add-ons for Orchstration and DNS. Seeking volunteers to update web page write-up and logos to be proposed for "Openstack Powerd Orchestaion" & Openstack Powered DNS". Heat ans Designate teams can suggest what they would like to bring to table for draft and approval to board? ThanksPrakash

1 0

[nova][libvirt] Support for MIPS architecture?
by 赵晓琳 06 Jun '20

06 Jun '20

Hi I'm trying to run openstack on a host with MIPS architecture, but got some errors, and I have fixed them. Many people around me use hosts with MIPS architecture. We hope the official can add support for MIPS and we can maintain it. Thanks, xiaolin

4 5

[all][InteropWG] Please verify if Swift Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 05 Jun '20

05 Jun '20

Hi Swift team core members, We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this to your PTG meetings if needed to assign a volunteer to complete the verification and patch if updates are needed. Swift: We test 20 capability with 60 tests -do you need any changes to 2020.06.json swift api draft before seeking approvals?https://docs.openstack.org/api-ref/object-store/ https://opendev.org/openstack/interop/src/branch/master/2020.06.json#L179Ch… Line 179-214 and confim that tests is capability tests 1-20 will suffcie or submit patch to inerop. - identity-v3-tokens-create [1/1] - identity-v3-tokens-delete [1/1] - objectstore-account-list [12/12] - objectstore-account-quotas [2/2] - objectstore-container-acl [2/2] - objectstore-container-create [2/2] - objectstore-container-delete [1/1] - objectstore-container-list [11/11] - objectstore-container-metadata [5/5] - objectstore-container-quotas [3/3] - objectstore-dlo-support [2/2] - objectstore-info-request [1/1] - objectstore-object-copy [4/4] - objectstore-object-create [2/2] - objectstore-object-delete [1/1] - objectstore-object-get [3/3] - objectstore-object-versioned [1/1] - objectstore-slo-support [4/4] - objectstore-temp-url-get [1/1] - objectstore-temp-url-put [1/1] ThanksInterop WG chai Prakash& Vice chair Mark

2 1

[kolla-ansible] Proposing Doug Szumski as Kolla Ansible core
by Radosław Piliszek 05 Jun '20

05 Jun '20

Hi Folks! This mail serves to propose Doug Szumski from StackHPC (dougsz @IRC, CC'ed) as Kolla Ansible core. Doug coauthored the Nova cells support and helps greatly with monitoring and logging facilities available in Kolla. Please give your feedback in this thread. If there are no objections, I will add Doug after a week from now (that is roughly when PTG is over). -yoctozepto

9 9

Networking-vpp 20.05 for VPP 20.05 is now available
by Naveen Joy (najoy) 05 Jun '20

05 Jun '20

Hello All, We'd like to invite you to try out Networking-vpp 20.05. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 20.05. In this release, we've made the below changes: - We've added a class that defines network type APIs and implements them. The network types supported are VLAN, Flat and GPE. Our intent is to add support for pluggable network types without the need to modify code. We'll be continuing our work to enhance this feature in the next release. - We've updated the code to be compatible with VPP 20.05 API changes. - We've added code to deal with poorly formed security group subnets. For instance, 1.2.3.4/0 is completely acceptable in a security group rule. Previously, VPP accepted this in its API calls but this is not currently the case. We've fixed this up at the high level to be acceptable to VPP. - We've fixed an issue with missing package data required for VPP API message validation. - We've dropped VPP 19.04 compatibility code. - We've fixed an issue with the security group mechdriver code in which a SG rule is added but not pushed out to VPP until the next rule is added or the security group is changed. - We've moved VPP specific constants to a dedicated vpp_constants.py file. - Due to a VPP issue, GPE support will be deferred to the 20.05.1 release. - We've been doing the usual round of bug fixes, clean-ups and updates - the code will work with VPP 20.05, the OpenStack Stein release & Python 3. The README [1] explains how you can try out VPP with Networking-vpp using devstack: the devstack plugin will deploy the mechanism driver with VPP 20.05 and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.05.1 release. We welcome anyone who would like to come help us. -- Jerome, Ian & Naveen [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

Hi there, Sorry for the previous email - it has been sent accidentally - it was just at the draft stage... I did some formating afterwards:) Here are some of the decisions we come up with during the PTG week: * CentOS 8 topic. ** Install systemd-extras to get systemd-networkd ** Launch without LXC build at first because of the complexity of the solution. To implement LXC we would need the following: *** Replace what `machinectl` does with Ansible tasks, as it's not working properly without btrfs *** See how much it costs to implement lxd - that would not only resolve Centos 8 issue, but also is pretty appreciated among comunity. However, installing in with snapd will auto-update. it's possible to delay up to 60 days the updates but still needs to fix/clean ** Make nspawn unmaintained, because it mostly relies on machinectl. *** Remove nspawn from docs. *** Remove code in cycle afterwards. ** Backport CentOS 8 to Ussuri, drop CentOS 7 for Victoria afterwards. *** On Ussuri CentOS 7 is going to live without distro support *** write reno, that explains that distro installed OSA upgrade path might be tricky/broken for CentOS because of absent Centos7 packages for U. * Logs topic ** finish transition to journald *** check heat for logging *** check for ceph logs - see [1] but this may be a result of the way cephadm containerises all the ceph daemons ** Rewrite log collection script on python with systemd python bindings and get deprecated messages from services' journal into separate file ** Check where we don't use uwsgi role and see if we can use it there now (like designate) ** Check through the logs what roles are we covered with tempest, and what not. We have buch of roles that run tempest, but test like only keystone (but not itself). ** We add libvirtd_exporter [2] to ansible-role-requirements and offer it's deployments on users own prometheus. Offer prometheus deployment as step2. Document usage * Promote ELK stack to 1st class thing ** Create a separate repo and remove from openstack-ansible-ops ** provide out-of-the-box deployment with OSA. Model would be similar to ceph-ansible where deployment can be integrated or standalone * Work on speeding up OSA runtime: ** Fight with skipped tasks (ie by moving them to separate files that would be included) - most valid for systemd service, systemd_networkd and python_venv_build roles ** Try to split up variables by group_vars ** Try to use include instead of imports again * speedup ci ** try to speedup zuul required projects clone process - work with infra team ** Set *_db_setup_host across all roles to utility and adjust [7] * Build mariadb deps for focal (like 10.4.12 release). We can use repo.vexxhost.net for hosting it until mariadb 10.4.14 release. * In case having issues with distro jobs/support we don't hestitate remove it or setting to non-voting state * Remove SUSE support early in Victoria. We already have [4] for this - needs rebasing * Add neutron ovn to integrated tests (with perspective to make it default for new deployments). * Drop resource creation tasks out of os_tempest - OSA and TripleO manage resource creation themselves and pass required vars to os_tempest for config generation * Add support for zookeeper deployment for services coordination (like telemetry, designate, etc) * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [3] * Try to add aarch64 jobs with separate pipeline once we have some python wheels built up * Migrate group names to remove underscores "The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10" * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [5] use it like this [6] * publish common roles (galera, haproxy, memcached, uwsgi, python_venv_build, etc...) to galaxy, rename them to ansible-role-* pattern. As a stage 2 consider publishing os roles. * add some check for repo server, to verify it's ok (lua linters check) instead of failing afterwards because of missing dev libraries for hosts [1] https://github.com/ceph/ceph/blob/be117b555fc1bba1048b87a624d542fd629d1ad1/… [2] https://github.com/jrosser/rd-ansible-libvirtd-exporter [3] http://paste.openstack.org/show/794258/ [4] https://review.opendev.org/#/c/725541/ [5] http://paste.openstack.org/show/794258/ [6] http://paste.openstack.org/show/794259/ [7] https://review.opendev.org/#/c/671454

1 1

[nova] running nova-scheduler in a container
by Jean-Philippe Méthot 05 Jun '20

05 Jun '20

Hi, I’ve been building my own docker images as a mean to both learn docker and to see if we can make our own images and run them in production. I’ve figured out how to make most services run fairly well. However, an issue remains with nova-scheduler and I can’t seem to figure out what’s going on. Essentially, when I try to create a VM it loops in a scheduling state and when I try to delete a VM, it loops forever in a deleting state. I’ve narrowed down the culprit to nova-scheduler. As far as I know, nothing appears in the debug logs of my containerized nova-scheduler whenever I do any kind of action, which forces me to believe that nova-scheduler is not receiving any command. From what I’ve always understood, nova-scheduler works through RPC and Rabbitmq. The fact that this nova-scheduler connects to rabbitmq without issue makes me believe that something else is missing from my container configuration. Does Nova-scheduler listen on network port? Does it listen on a socket? Is there any way that nova-scheduler could ignore requests sent to it? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

2 2

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

1 0

[nova][ptg] virtual PTG
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, I need to book slots for nova discussions on the official schedule[2] of the virtual PTG[1]. I need two things to do that: 1) What topics we have that needs real-time discussion. Please add those to the etherpad [3] 2) Who wants to join such real-time discussion and what time slots works for you. Please fill the doodle[4] Based on the current etherpad content we need 2-3 slots for nova discussion and a half slot for cross project (current neutron) discussion. Please try to provide your topics and options before the Thursday's nova meeting. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/nova-victoria-ptg [4] https://doodle.com/poll/ermn3vxy9v53aayy

1 5

[nova][neutron][ptg] How to increase the minimum bandwidth guarantee of a running instance
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] As a next step in the minimum bandwidth QoS support I would like to solve the use case where a running instance has some ports with minimum bandwidth but then user wants to change (e.g. increase) the minimum bandwidth used by the instance. I see two generic ways to solve the use case: Option A - interface attach --------------------------- Attach a new port with minimum bandwidth to the instance to increase the instance's overall bandwidth guarantee. This only impacts Nova's interface attach code path: 1) The interface attach code path needs to read the port's resource request 2) Call Placement GET /allocation_candidates?in_tree=<compute RP of the instance> 3a) If placement returns candidates then select one and modify the current allocation of the instance accordingly and continue the existing interface attach code path. 3b) If placement returns no candidates then there is no free resource left on the instance's current host to resize the allocation locally. Option B - QoS rule update -------------------------- Allow changing the minimum bandwidth guarantee of a port that is already bound to the instance. Today Neutron rejects such QoS rule update. If we want to support such update then: * either Neutron should call placement allocation_candidates API and the update the instance's allocation. Similarly what Nova does in Option A. * or Neutron should tell Nova that the resource request of the port has been changed and then Nova needs to call Placement and update instance's allocation. The Option A and Option B are not mutually exclusive but still I would like to see what is the preference of the community. Which direction should we move forward? Both options have the limitation that if the instance's current host does not have enough free resources for the requested change then Nova will not do a full scheduling and move the instance to another host where resource is available. This seems a hard problem to me. Do you have any idea how can we remove / ease this limitation without boiling the ocean? For example: Does it make sense to implement a bandwidth weigher in the scheduler so instances can be spread by free bandwidth during creation? Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg

3 6