May 2020 - openstack-discuss - lists.openstack.org

[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

[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

[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

[nova][neutron][ptg] Future of the routed network support
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] There is only basic scheduling support in nova for the neutron routed networks feature (server create with port.ip_allocation=deferred seems to work). There was multiple attempts in the past to complete the support (e.g.server create with port.ip_allocation=immediate or server move operations). The latest attempt started by Matt couple of cycles ago, and in the last cycle I tried to push that forward[1]. When I added this topic to the PTG etherpad I thought I will have time in the Victoria cycle to continue [1] but internal priorities has changed. So finishing this feature needs some developers. If there are volunteers for Victoria then please let me know and then we can keep this as a topic for the PTG but otherwise I will remove it from the schedule. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/q/topic:routed-networks-scheduling

2 2

[nova][ptg] Can we close old bugs?
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] We have more than 800 open bugs in nova [1] and the oldest is 8 years old. Can we close old bugs? If yes, what would be the closing criteria? Age and status? Personally I would close every bug that is not updated in the last 3 years and not in INPROGRESS state. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance…

5 7

[nova][ptg] bumping compute RPC to 6.0
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] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log…

3 4

[nova][ptg] Runway process in Victoria
by Balázs Gibizer 04 Jun '20

04 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] In the last 4 cycles we used a process called runway to focus and timebox of the team's feature review effort. However compared to the previous cycles in ussuri we did not really keep the process running. Just compare the length of the Log section of each etherpad [1][2][3][4] to see the difference. So I have two questions: 1) Do we want to keep the process in Victoria? 2) If yes, how we can make the process running? 2.1) How can we keep the runway etherpad up-to-date? 2.2) How to make sure that the team is focusing on the reviews that are in the runway slots? Personally I don't want to advertise this process for contributors if the core team is not agreed and committed to keep the process running as it would lead to unnecessary disappointment. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/nova-runways-rocky [2] https://etherpad.opendev.org/p/nova-runways-stein [3] https://etherpad.opendev.org/p/nova-runways-train [4] https://etherpad.opendev.org/p/nova-runways-ussuri

3 4

[nova][ptg] Feature Liaison
by Balázs Gibizer 04 Jun '20

04 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] Last cycle we introduced the Feature Liaison process [1]. I think this is time to reflect on it. Did it helped? Do we need to tweak it? Personally for me it did not help much but I think this is a fairly low cost process so I'm OK to keep it as is. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/c/685857/

5 6

[keystone] Keystone PTG Schedule
by Nikolla, Kristi 03 Jun '20

03 Jun '20

Hi all, The Keystone team will be meeting Thursday and Friday 1300-1700 UTC. The schedule[0] can be found below and provides information on how to register and attend. In addition, I'm hoping to organize a team meetup Wednesday, Thursday or Friday on 1700UTC. Please fill in the doodle at [1]. More general PTG information can be found at [2]. [0]. https://etherpad.opendev.org/p/victoria-ptg-keystone [1]. https://doodle.com/poll/z7diwe6qyq4mbghe [2]. http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 1