December 2020 - openstack-discuss

[tc][goals] community feedback on 'stabilization' goal
by Mohammed Naser 11 Dec '20

11 Dec '20

Hi there, Over the last TC meeting, we exchanged opinions about the new goal selection. It was discussed that due to the extraordinary situation this year, we could have a loose goal instead. Therefore, we would like to propose having a stabilization cycle this release. Some ideas discussed for this “stabilization” cycle (would be all of those): 1. Use this time to rest and relax, no need to do something. 2. Use this time to finish up this really cool thing you've been trying to find time to, and share with us to recognize. 3. Check out these existing goals/popup teams that might interest you if you want to invest time in something different/new. As a reminder that we don't have to do a community goal for every release, we are leaving this open and would like to know what the community thinks. Feel free to send over your thoughts, Regards, -- Mohammed Naser VEXXHOST, Inc.

4 3

[tc] weekly meeting summary
by Mohammed Naser 11 Dec '20

11 Dec '20

Hi everyone, Here's a summary of what happened in our TC weekly meeting last Thursday, Dec 10. # ATTENDEES (LINES SAID) - mnaser (115) - apevec (60) - gmann (57) - yoctozepto (26) - mugsie (26) - fungi (20) - jungleboyj (14) - noonedeadpunk (9) - diablo_rojo__ (6) - marios|rover (6) - ricolin (6) - zbr (4) - weshay|ruck (2) - jrosser (2) - akahat (1) - gouthamr (1) # MEETING SUMMARY 1. Rollcall 2. Follow up on past action items DONE: mnaser change all reference of meeting time to go towards eavesdrop for single source of truth DONE: mnaser remove openstacksdk discussions for future meetings DONE: mnaser remove project retirement from agenda 3. X cycle goal selection start It was discussed that due to the extraordinary situation this year, perhaps we could have a stabilization goal instead. As a reminder that we don't have to do a community goal for every release, we are leaving this open and will ask folks to update the proposed goal page with something they worked on. Some ideas discussed for this "stabilization" cycle: 1) Use this time to rest and relax, no need to do something. 2) Use this time to finish up this really cool thing you've been trying to find time to, and share with us to recognize. 3) Check out these existing goals/popup teams that might interest you if you want to invest time in something different/new We will keep this as an open discussion item to track the progress and will keep collecting new ideas for goals. 4. Audit and clean-up tags (gmann) For API interoperability tag, patch is merged; gmann will start the ML to encourage projects to start applying for that tag. We will keep this action to discuss the progress of getting projects in, and we will have each tag one by. 5. X cycle release name vote recording (gmann) Because the votes were not recorded, we are asking TC members to list what they voted for on the mailing list http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019337… 6. CentOS 8 releases are discontinued / switch to CentOS 8 Stream (gmann/yoctozepto) Community members from RH were present to help talk through the changes that are occurring with the introduction of CentOS Stream 8. mnaser work to find time for community deployment projects + centos/rdo team to meet to help teams get more information about the upcoming change # ACTION ITEMS 1. mnaser send email to ML to find volunteers to help drive goal selection 2. gmann complete retirement of searchlight & qinling 3. diablo_rojo complete retirement of karbor 4. mnaser work to find time for community deployment projects + centos/rdo team To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-12-10-15.01.log.html -- Mohammed Naser VEXXHOST, Inc.

1 0

[nova][gate] nova-multi-cell job failing test_*_with_qos_min_bw_allocation
by melanie witt 11 Dec '20

11 Dec '20

Howdy all, FYI we have gate failures of the recently added test_*_with_qos_min_bw_allocation tests [1] in the nova-multi-cell job on the master, stable/victoria, and stable/ussuri branches. The failures occur during cross cell migrations. I have opened a bug for the failure on the master branch: * https://bugs.launchpad.net/nova/+bug/1907522 The issue here is that we fail to create port bindings in neutron during a cross cell migration in the superconductor: nova.exception.PortBindingFailed: Binding failed for port <port uuid> and that corresponds to a failure in the neutron server log where it fails the port binding with: neutron_lib.exceptions.placement.UnknownResourceProvider: No such resource provider known by Neutron I don't yet know what is going on here ^. For the bug on stable/victoria and stable/ussuri I have opened this bug: * https://bugs.launchpad.net/nova/+bug/1907511 and have a WIP stable-only patch proposed that needs tests: https://review.opendev.org/c/openstack/nova/+/766364 I just wanted to see ASAP if the nova-multi-cell job will pass on it. The issue here ^ is that during a cross cell migration, we aren't targeting the cell database for the target host when we attempt to lookup the service record of the target host. For the stable branch failures I think the failure rate is 100% and it looks like it might also be 100% for the master branch failures. Cheers, -melanie [1] https://review.opendev.org/c/openstack/tempest/+/694539

2 3

[Openstack][FOSDEM][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 11 Dec '20

11 Dec '20

Friendly reminder that submission deadline for Virtualization & IaaS dev room at Fosdem is on 20th of December.

1 0

[TC][all] X Release name polling
by Sean McGinnis 11 Dec '20

11 Dec '20

Hey everyone, We recently collected naming suggestions for the X release name. A lot of great suggestions by the community! Much more than I had expected for this letter. As a reminder, starting with the W release we had changed the process for selecting the name [1]. We collected suggestions from the community, then the members of the TC voted in a poll [2] to select which name(s) out of the suggestions to go with. The vetting of the top choices from that process is happening now, and we should have a official result soon. This is a bit of a mea culpa from me about an issue with how this was conducted though. The naming process specifically states: "the poll should be run in a manner that allows members of the community to see what each TC member voted for." When I set up the CIVS poll, I failed to check the box that would allow seeing the detailed results of the poll. So while we do have the winning names, we are not able to see which TC members voted and how. I apologize for missing this step (and I've noted that we really should add some detailed process for future coordinators to follow!). I believe the intent with that part of the process was to allow the community to see how your elected TC members voted as one factor to consider when reelecting anyone. Also transparency to show that no one is pushing through their own choices, circumventing any process. The two options I see at this point would be to either redo the entire naming poll, or just try to capture what TC members voted for somewhere so we have a record of that. It's been long enough now since taking the poll that I don't expect TC members to remember exactly how they ranked things. But we've also started the vetting process through the Foundation (lawyers engaged, etc) so I'd really rather not start over if we can avoid it. If TC members could respond here with what they remember voting for, I hope that is enough to satisfy the spirit of the defined process. If there are any members of the community that have a strong objection to this, please say so. I leave it up to the TC then to decide how to proceed. Again, apologies for missing this step. Otherwise, I think the process has worked well, and I hope we can declare an official X name shortly. Thanks! Sean [1] https://governance.openstack.org/tc/reference/release-naming.html#release-n… [2] https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_7e6e96070af39fe7

8 9

[nova] weekly meeting is canceled during the holidays
by Balázs Gibizer 11 Dec '20

11 Dec '20

Hi, As we agreed on the weekly meeting the nova meeting schedule will look like the following during the next weeks: Dec 17 2020 16:00 UTC, #openstack-meeting-3 Dec 24 2020 16:00 UTC, Cancelled Dec 31 2020 16:00 UTC, Cancelled Jan 7 2021 16:00 UTC, #openstack-meeting-3 Cheers, gibi

1 0

About fuel
by sunkai 11 Dec '20

11 Dec '20

Hello, I have a question to ask you。How do I modify the disk configuration of fuel for the node? I need to add some configuration items。How can I fulfill this requirement？Looking forward to your reply，Thankyou very much!!!

1 0

[all][policy] Canceling policy-popup's 24th Dec meeting
by Ghanshyam Mann 11 Dec '20

11 Dec '20

Hello Everyone, Due to new year vacations, we decided to cancel the policy popup 24th Dec meeting and will resume meeting from 7th Jan onwards. -gmann

1 0

[all][tc][policy] Progress report of consistent and secure default policies pop-up team
by Ghanshyam Mann 11 Dec '20

11 Dec '20

Hello Everyone, Please find this month's progress on 'Consistent and Secure Default Policies Popup Team'. Meeting notes: ============ * We discussed progress on policy format migration from JSON->YAML and updates required in oslo.upgradecheck is merged now. * As you saw in another email thread by Lance[1], he has started the work on many projects. We will be adding the test coverage also in those, I will be able to help lance on some of them in next month. * We will define the common personas in oslo.policy for reusing it on the service side[2] * Below are the 'Action items, by person': ** gmann to check with abhishekk on glance point in meeting agenda ** gmann to push common persona on oslo policy and release 3.6.1 and lbragstad to review that ** lbragstad/gmann to push common persona on Oslo policy and release 3.6.1 and lbragstad to review that ** lbragstad to finish placement as first ** raildo to update https://review.opendev.org/#/c/743318/ Progress so far: ============ * Popup team meet twice in a month and discuss and work on progress and pre-work to do. - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… * Pre-work to provide a smooth migration path to the new policy <here we will add any pre-work we need to do before more project start moving towards new policy> ** Migrate Default Policy Format from JSON to YAML - This is now a community-wide goal, refer my separate ML thread for progress - https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… ** Improving documentation about target resources (oslo.policy) - https://bugs.launchpad.net/oslo.policy/+bug/1886857 - raildo pushed the patch which is under review: https://review.opendev.org/#/c/743318/ * Team Progress: (list of a team interested or have volunteer to work) ** Keystone (COMPLETED; use as a reference) ** Nova (COMPLETED; use as a reference) ** Cyborg (COMPLETED) ** Work started in other projects *** https://review.opendev.org/q/topic:%22secure-rbac%22+(status:open%20OR%20st… [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019313… [2] https://review.opendev.org/c/openstack/oslo.policy/+/766536 -gmann

1 0

Multiple VM ports on provider networks / dhcp fails
by Eric K. Miller 11 Dec '20

11 Dec '20

Hi, We ran into an issue recently that I haven't been able to figure out (this environment is on Stein which uses DVR). It involves an environment with many provider networks that connect to a legacy environment as well as many tenant networks. We create a server on a tenant network and add ports to this afterwards with each port attached to its respective provider network. The provider networks have "None" for the "gateway" property, so we don't have multiple default routes added to the routing table. We have a single subnet which has DHCP enabled and a proper allocation pool on its subnet. Note that this is a CentOS 8 server we are testing with, which has "no" ifcfg files for the additional ports, and so we rely on CentOS using DHCP by default. After adding the first port, the DHCP client does its job and requests an IP, which succeeds - so the DHCP server in the respective network namespace is responding fine. However, after adding the second port, it appears the DHCP client is sending requests out the network (we can see this traffic when tcpdump'ing the respective tap interface on the host), but the DHCP server is not replying. After looking at OpenVSwitch flows, it appears that DHCP broadcast traffic is being dropped for the second network. This does NOT happen with tenant networks. I can add multiple ports, each connected to its respective tenant network, and an IP is assigned to each interface that appears in CentOS immediately after the port has been added. Is there something special that is blocking the creation of the DHCP flow for subsequent provider network ports? NOTE that non-DHCP traffic flows fine if we create an ifcfg file with a static IP set to the address that DHCP should have set the interface to - it just appears that DHCP traffic is not flowing to the DHCP namespace for second and subsequent ports/networks. Thanks! Eric

1 0