August 2019 - openstack-discuss - lists.openstack.org

[research][code-review][software-dev] Design Discussions During OpenStack Code Reviews
by farida el-zanaty 22 Aug '19

22 Aug '19

Hi! I am Farida El-Zanaty from McGill University. Under the supervision of Prof. Shane McIntosh, my research aims to study design discussions that occur between developers during code reviews. Last year, we published a study about the frequency and types of such discussions that occur in OpenStack Nova and Neutron (http://rebels.ece.mcgill.ca/papers/esem2018_elzanaty.pdf) We are reaching out to OpenStack developers to better understand their perspectives on design discussions during code reviews. Those who are interested can start by participating in our 10-minute survey about their experiences as both the code reviewer and author. Survey participants will be entered into a raffle for a $50 Amazon gift card. Survey: https://forms.gle/Hhn191f6cxF5hVgG8 Thanks for your time, Farida El-Zanaty

1 0

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting on August 23rd
by Miguel Lavalle 22 Aug '19

22 Aug '19

Dear Neutrinos, 3 out of 5 members of the drivers team are off on vacation this week, so we won't have quorum for the meeting. As a consequence, I am cancelling it this week. We will resume next week. Best regards Miguel

1 0

[tc] Naming releases after people
by Jeremy Freudberg 22 Aug '19

22 Aug '19

Hi, There is currently ongoing discussion about a new process for selecting release names. I would like to draw attention to one proposal in particular: "Name releases after ATCs" [0]. This is currently the only proposal which explicitly prefers names 'telling the story of OpenStack' like the current process based on the location of the summit does. For this reason I personally favor this proposal above all others currently proposed. There are some areas of the proposal to smooth out (and I mention these areas on the review), but I before I proceed, I would like to gather feedback from the community about the mere idea of naming releases after people. If such an idea strikes you one way or the other, please leave a comment on the review; I'd appreciate it greatly. Thanks, Jeremy [0] https://review.opendev.org/#/c/677827/

1 0

[TC] [UC] Shanghai Forum Selection Committee: Help Needed
by Jimmy McArthur 22 Aug '19

22 Aug '19

Hi everyone! The Forum in Shanghai is coming up. We require 2 volunteers from the TC and 2 from the UC for the Forum Selection Committee. For more information, please see:https://wiki.openstack.org/wiki/Forum Please reach out to myself orknelson(a)openstack.org if you're interested. Volunteers should respond on or before September 2, 2019. Note: volunteers are required to be currently serving on either the UC or the TC. Cheers, Jimmy

4 3

[nova] API updates week 19-34
by Ghanshyam Mann 22 Aug '19

22 Aug '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason 2. Add host and hypervisor_hostname flag to create server - https://blueprints.launchpad.net/nova/+spec/add-host-and-hypervisor-hostnam… 3. Nova API cleanup - https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup 4. Add 'power-update' external event: - https://blueprints.launchpad.net/nova/+spec/nova-support-instance-power-upd… Code Ready for Review: ------------------------------ 1. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Under Review and in runway also. 2. Show Server numa-topology - Topic: https://review.opendev.org/#/q/topic:bp/show-server-numa-topology+(status:o… - Weekly Progress: Alex is +2 on nova change, but this might conflict with above one on Microvision number(depends on which one gets first). 3. Nova API policy improvement - Topic: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: First set of os-service policy changs has Kenichi +2. Need more feedback and +A to start modifying the other policies. review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 4. Add User-id field in migrations table - Topic: https://review.opendev.org/#/q/topic:bp/add-user-id-field-to-the-migrations… - Weekly Progress: Changes are up for review but with microversion 2.77. We can rebase the microverison number later and not blocking for review. 5. Support delete_on_termination in volume attach api -Spec: https://review.opendev.org/#/q/topic:bp/support-delete-on-termination-in-se… - Weekly Progress: Ready for review and rebase on available microversion number can be done later. Specs are merged and code in-progress: ------------------------------ ------------------ 1. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress. Patches are in merge conflict. Spec Ready for Review: ----------------------------- 1. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: This has been added in backlog. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… - I remember I planned this to re-propose but could not get time. If anyone would like to help on this please repropose. otherwise I will start this in U cycle. 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… - This also need volutneer - http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007411.html Others: 1. Add API ref guideline for body text - 2 api-ref are left to fix. Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[storyboard] email notification on stories/tasks of subscribed projects
by Akihiro Motoki 22 Aug '19

22 Aug '19

Hi, Is there a way to get email notification on stories/tasks of subscribed projects in storyboard? In launchpad, I configure launchpad bug notifications of all bug changes in interested projects. After migration to storyboard (for example, openstackclient), I failed to find a similar way. Thanks, Akihiro Motoki (irc: amotoki)

5 8

[qa] QA Office Hour New Time: 0 UTC
by Ghanshyam Mann 21 Aug '19

21 Aug '19

Hello Everyone, Please note the QA office hour new time which is 0 UTC(which will include the Asia TZ members also) on every Thursday. I have updated the wiki page [1] also for that. I have cleaned up the PING LIST which was old, feel free to add yourself in the PING list on wiki if you want the IRC notification. [1] https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_next_Offi… -gmann

1 0

More upgrade issues with PCPUs - input wanted
by Stephen Finucane 21 Aug '19

21 Aug '19

tl;dr: Is breaking booting of pinned instances on Stein compute nodes in a Train deployment an acceptable thing to do, and if not, how do we best handle the VCPU->PCPU migration in Train? I've been working through the cpu-resources spec [1] and have run into a tricky issue I'd like some input on. In short, this spec means that pinned instances (i.e. 'hw:cpu_policy=dedicated') will now start consuming a new resources type, PCPU, instead of VCPU. Many things need to change to make this happen but the key changes are: 1. The scheduler needs to start modifying requests for pinned instances to request PCPU resources instead of VCPU resources 2. The libvirt driver needs to start reporting PCPU resources 3. The libvirt driver needs to do a reshape, moving all existing allocations of VCPUs to PCPUs, if the instance holding that allocation is pinned The first two of these steps presents an issue for which we have a solution, but the solutions we've chosen are now resulting in this new issue. * For (1), the translation of VCPU to PCPU in the scheduler means compute nodes must now report PCPU in order for a pinned instance to land on that host. Since controllers are upgraded before compute nodes and all compute nodes aren't necessarily upgraded in one go (particularly for edge or other large or multi-cell deployments), this can mean there will be a period of time where there are very few or no hosts available on which to schedule pinned instances. * For (2), we're hampered by the fact that there is no clear way to determine if a host is used for pinned instances or not. Because of this, we can't determine if a host should be reporting PCPU or VCPU inventory. The solution we have for the issues with (1) is to add a workaround option that would disable this translation, allowing operators time to upgrade all their compute nodes to report PCPU resources before anything starts using them. For (2), we've decided to temporarily (i.e. for one release or until configuration is updated) report both, in the expectation that everyone using pinned instances has followed the long- standing advice to separate hosts intended for pinned instances from those intended for unpinned instances using host aggregates (e.g. even if we started reporting PCPUs on a host, nothing would consume that due to 'pinned=False' aggregate metadata or similar). These actually benefit each other, since if instances are still consuming VCPUs then the hosts need to continue reporting VCPUs. However, both interfere with our ability to do the reshape. Normally, a reshape is a one time thing. The way we'd planned to determine if a reshape was necessary was to check if PCPU inventory was registered against the host and, if not, whether there were any pinned instances on the host. If PCPU inventory was not available and there were pinned instances, we would update the allocations for these instances so that they would be consuming PCPUs instead of VCPUs and then update the inventory. This is problematic though, because our solution for the issue with (1) means pinned instances can continue to request VCPU resources, which in turn means we could end up with some pinned instances on a host consuming PCPU and other consuming VCPU. That obviously can't happen, so we need to change tacks slightly. The two obvious solutions would be to either (a) remove the workaround option so the scheduler would immediately start requesting PCPUs and just advise operators to upgrade their hosts for pinned instances asap or (b) add a different option, defaulting to True, that would apply to both the scheduler and compute nodes and prevent not only translation of flavors in the scheduler but also the reporting PCPUs and reshaping of allocations until disabled. I'm currently leaning towards (a) because it's a *lot* simpler, far more robust (IMO) and lets us finish this effort in a single cycle, but I imagine this could make upgrades very painful for operators if they can't fast track their compute node upgrades. (b) is more complex and would have some constraints, chief among them being that the option would have to be disabled at some point post-release and would have to be disabled on the scheduler first (to prevent the mismash or VCPU and PCPU resource allocations) above. It also means this becomes a three cycle effort at minimum, since this new option will default to True in Train, before defaulting to False and being deprecated in U and finally being removed in V. As such, I'd like some input, particularly from operators using pinned instances in larger deployments. What are your thoughts, and are there any potential solutions that I'm missing here? Cheers, Stephen [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-r…

4 5

[election] Coordination + Prep
by Kendall Nelson 21 Aug '19

21 Aug '19

Hello Election Officials! (and anyone else curious about running elections :) ) Next week we are set to get this party started. Things that need to happen before then: 1. Election season email to the ML-- we have a template for this, but it and all the other emails this run will need to be tweaked (or we add new ones for this combined election type <-- I'm in favor of this approach in case we do this again in the future). 2. Patch to set up U nominations directories-- We don't have the next release name settled so I guess we just go for 'U' and we can update it later. 3. Patch to update officials list on site-- I will need to be removed because I won't be able to help with the actual election this round, but I am here to advise if you need anything. ...I could be missing things, but that's for sure what I know we need to accomplish before the start date and the actual nominations kickoff email. For reference, here is the general process that we run though[1]. That being said, things are a bit different this time since we are running the elections simultaneously. We should probably add a section for what happens when we have to run them in parallel (same vein as writing new email templates for the combined election). -Kendall (diablo_rojo) [1]https://opendev.org/openstack/election/src/branch/master/README.rst

2 1

[ALL][UC] Train EC Election - nomination results, and what is going on
by Ian Y. Choi 21 Aug '19

21 Aug '19

Hello all, As announced [1-2], the UC nomination period was from August 5 - August 16, 2019, and as the election officials, we would like to share the result, as well as the next steps. This was discussed by the User Committee yesterday [3]: - There was one UC candidacy [4]. The candicacy has been validated and election official announce that "Mohamed Elsakhawy" will serve on the UC. Congratulations! - There will be no election since there was only one candicate out of two positions for this election. - There were discussions during the UC meeting [3] yesterday, and the UC decided to have a second, special election for another seat within the timeframe spelled out in the charter. The same election officials will work, and the officials and UC members are discussing a feasible time frame for the election. As mentioned, the upcoming election is *special*, so please pay attention for more election information. The election officials will post an email soon with more details on upcoming special UC election. Thank you, - Ed & Ian [1] http://lists.openstack.org/pipermail/user-committee/2019-July/002862.html [2] http://lists.openstack.org/pipermail/user-committee/2019-August/002864.html [3] http://eavesdrop.openstack.org/meetings/uc/2019/uc.2019-08-19-15.04.log.htm… [4] http://lists.openstack.org/pipermail/user-committee/2019-August/002866.html

3 2