- openstack-discuss - lists.openstack.org

Nova causes MySQL timeouts
by Albert Braden 23 Aug '19

23 Aug '19

It looks like nova is keeping mysql connections open until they time out. Is there a way to stop these error messages? Aborted connection 10726 to db: 'nova' user: 'nova' host: 'asdf' (Got timeout reading communication packets)

1 0

[nova][ops] What should the compute service delete behavior be wrt resource providers with allocations?
by Matt Riedemann 23 Aug '19

23 Aug '19

Before [1] when deleting a compute service in the API we did not check to see if the compute service was hosting any instances and just blindly deleted the service and related compute_node(s) records which orphaned the resource provider(s) for those nodes. With [2] we built on that and would cleanup the (first [3]) compute node resource provider by first deleting any allocations for instances still on that host - which because of the check in [1] should be none - and then deleted the resource provider itself. [2] forgot about ironic where a single compute service can be managing multiple (hundreds or even thousands) of baremetal compute nodes so I wrote [3] to delete *all* resource providers for compute nodes tied to the service - again barring there being any instances running on the service because of the check added in [1]. What we've failed to realize until recently is that there are cases where deleting the resource provider can still fail because there are allocations we haven't cleaned up, namely: 1. Residual allocations for evacuated instances from a source host. 2. Allocations held by a migration record for an unconfirmed (or not yet complete) migration. Because the delete_resource_provider method isn't checking for those, we can get ResourceProviderInUse errors which are then ignored [4]. Since that error is ignored, we continue on to delete the compute service record [5], effectively orphaning the providers (which is what [2] was meant to fix). I have recreated the evacuate scenario in a functional test here [6]. The question is what should we do about the fix? I'm getting lost thinking about this in a vacuum so trying to get some others to help think about it. Clearly with [1] we said you shouldn't be able to delete a compute service that has instances on it because that corrupts our resource tracking system. If we extend that to any allocations held against providers for that compute service, then the fix might be as simple as not ignoring the ResourceProviderInUse error and fail if we can't delete the provider(s). The question I'm struggling with is what does an operator do for the two cases mentioned above, not-yet-complete migrations and evacuated instances? For migrations, that seems pretty simple - wait for the migration to complete and confirm it (reverting a cold migration or resize would put the instance back on the compute service host you're trying to delete). The nastier thing is the allocations tied to an evacuated instance since those don't get cleaned up until the compute service is restarted [7]. If the operator never intends on restarting that compute service and just wants to clear the data, then they have to manually delete the allocations for the resource providers associated with that host before they can delete the compute service, which kind of sucks. What are our options? 1. Don't delete the compute service if we can't cleanup all resource providers - make sure to not orphan any providers. Manual cleanup may be necessary by the operator. 2. Change delete_resource_provider cascade=True logic to remove all allocations for the provider before deleting it, i.e. for not-yet-complete migrations and evacuated instances. For the evacuated instance allocations this is likely OK since restarting the source compute service is going to do that cleanup anyway. Also, if you delete the source compute service during a migration, confirming or reverting the resize later will likely fail since we'd be casting to something that is gone (and we'd orphan those allocations). Maybe we need a functional recreate test for the unconfirmed migration scenario before deciding on this? 3. Other things I'm not thinking of? Should we add a force parameter to the API to allow the operator to forcefully delete (#2 above) if #1 fails? Force parameters are hacky and usually seem to cause more problems than they solve, but it does put the control in the operators hands. If we did remove allocations for an instance when deleting it's compute service host, the operator should be able to get them back by running the "nova-manage placement heal_allocations" CLI - assuming they restart the compute service on that host. This would have to be tested of course. Help me Obi-Wan Kenobi. You're my only hope. [1] https://review.opendev.org/#/q/I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a [2] https://review.opendev.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 [3] https://review.opendev.org/#/c/657016/ [4] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [5] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [6] https://review.opendev.org/#/c/663737/ [7] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… -- Thanks, Matt

6 16

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

23 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 23 Aug '19

23 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 22 Aug '19

22 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 22 Aug '19

22 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 22 Aug '19

22 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

[sahara] Cancelling Sahara meeting August 22
by Jeremy Freudberg 21 Aug '19

21 Aug '19

Hi all, There will be no Sahara meeting 2019-08-22, the reason being that Luigi is not around and I myself will most likely not be around either. Holler if you need anything. Thanks, Jeremy

1 0

[cinder] Not Weekly Meeting Today ...
by Jay Bryant 21 Aug '19

21 Aug '19

Team, Just a reminder that we will not have our weekly meeting this week due to our mid-cycle meeting going on. If you are able to join the mid-cycle please check the #openstack-cinder channel for details. Thanks! Jay (irc: jungleboyj)

1 0

[cinder] [3rd party ci] Deadline Has Past for Python3 Migration
by Jay Bryant 21 Aug '19

21 Aug '19

All, This e-mail has multiple purposes. First, I have expanded the mail audience to go beyond just openstack-discuss to a mailing list I have created for all 3rd Party CI Maintainers associated with Cinder. I apologize to those of you who are getting this as a duplicate e-mail. For all 3rd Party CI maintainers who have already migrated your systems to using Python3.7...Thank you! We appreciate you keeping up-to-date with Cinder's requirements and maintaining your CI systems. If this is the first time you are hearing of the Python3.7 requirement please continue reading. It has been decided by the OpenStack TC that support for Py2.7 would be deprecated [1]. The Train development cycle is the last cycle that will support Py2.7 and therefore all vendor drivers need to demonstrate support for Py3.7. It was discussed at the Train PTG that we would require all 3rd Party CIs to be running using Python3 by the Train milestone 2: [2] We have been communicating the importance of getting 3rd Party CI running with py3 in meetings and e-mail for quite some time now, but it still appears that nearly half of all vendors are not yet running with Python 3. [3] If you are a vendor who has not yet moved to using Python 3 please take some time to review this document [4] as it has guidance on how to get your CI system updated. It also includes some additional details as to why this requirement has been set and the associated background. Also, please update the py3-ci-review etherpad with notes indicating that you are working on adding py3 support. I would also ask all vendors to review the etherpad I have created as it indicates a number of other drivers that have been marked unsupported due to CI systems not running properly. If you are not planning to continue to support a driver adding such a note in the etherpad would be appreciated. Thanks! Jay [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008255.h… [2] https://wiki.openstack.org/wiki/CinderTrainSummitandPTGSummary#3rd_Party_CI [3] https://etherpad.openstack.org/p/cinder-py3-ci-review [4] https://wiki.openstack.org/wiki/Cinder/3rdParty-drivers-py3-update

3 4

[all][tc] U release naming poll result
by Rico Lin 21 Aug '19

21 Aug '19

Dear all OpenStackers, First, we got 298 voters to participate in the poll, so thank you for your vote. And here is the poll result: 1. Ussuri [乌苏里江 https://en.wikipedia.org/wiki/Ussuri_River] (Condorcet winner: wins contests with all other choices) 2. Uma [http://www.fallingrain.com/world/CH/20/Uma.html] 3. Ula [Miocene Baogeda Ula] 4. Urad [乌拉特中旗 https://en.wikipedia.org/wiki/Urad_Middle_Banner] 5. Ulansu [乌兰苏海组 Ulansu sea] 6. Ulanhot [乌兰浩特市 https://en.wikipedia.org/wiki/Ulanhot] 7. Ulanqab [乌兰察布市 https://en.wikipedia.org/wiki/Ulanqab] 8. Ujimqin [东/西乌珠穆沁旗 https://en.wikipedia.org/wiki/Ujimqin] Here is result in detail: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_19e5119b14f86294&rkey=3…

2 1

[goals][IPv6-Only Deployments and Testing] Week R-9 Update
by Ghanshyam Mann 21 Aug '19

21 Aug '19

Hello Everyone, Below is the progress on Ipv6 goal during R9 week. At the first step, I am preparing the ipv6 jobs for the projects having zuulv3 jobs. The projects having zuulv2 jobs will be my second take. Summary: * Number of Ipv6 jobs proposed Projects: 25 * Number of pass projects: 11 ** Number of project merged: 6 * Number of failing projects: 14 Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 Current status: ============ 1. Cinder is error when configuring the conder's my_ip as IPv6. iscsi is not able to _connect_single_volume [1]. 2. Configuring the tempest test regex to run only smoke tests which can be extended to include future IPv6 tests also. Running all test is not actually required as such in IPv6 job but if any project wants to run all then also fine. Example: [1] 3. Fixing the Murano's MURANO_DEFAULT_DNS to set as IPv6 for IPv6 env[2]. 4. Solum job need Zun to configure the host_ip properly for IPv6. I will make the dependent patch. 5. For Monasca, kafka was not working for IPv6 but witek is upgrading the Kafka version in Monasca. I will rebase IPv6 job patch on top of that and check the result. 6. This week new projects ipv6 jobs patch and status: - Tacker: link: https://review.opendev.org/#/c/671908/ status: job is failing, I need to properly configure the job. - Senlin: links: https://review.opendev.org/#/c/676910/ status: jobs are failing. In same patch I have fixed the devstack plugin to deploy the Selin service on IPv6 which was hardcoded to HOST_IP(ipv4). But it seems Senlin endpoint is not created in keystone. Need to debug more for the root cause. - Solum: links: https://review.opendev.org/#/c/676912/ Status: job is failing. Fixed the devstack plugin for 'host' for IPv6 env. It also need fix on Zun side to configure the host_ip properly for IPv6. - Trove: link: https://review.opendev.org/#/c/677015/ status: job is passing and it is good to merge. - Watcher: link: https://review.opendev.org/#/c/677017/ status: job is passing and it is good to merge. In same patch, I have fixed the devstack plugin for 'host' for IPv6 env. - Sahara link: https://review.opendev.org/#/c/676903/ status: Job is failing to start the sahara service. I could not find the logs for sahara service(it shows empty log under apache). Need help from sahara team. IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific varification then it can be added in project side job as post-run playbooks as described in wiki page[3]. [1] https://zuul.opendev.org/t/openstack/build/5b7b823d6faa4f5393b4c46d36e15d80… [2] https://review.opendev.org/#/c/676857/ [3] https://review.opendev.org/#/c/676900/ [4] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing -gmann

2 3

[public-cloud-sig] Debian Cloud Sprint
by Jeremy Stanley 21 Aug '19

21 Aug '19

Just a heads-up, there was a suggestion[*] on the debian-cloud mailing list that it would be nice if some representatives from public OpenStack service providers are able to attend/participate in the upcoming Debian Cloud Sprint[**], October 14-16 on MIT campus in Cambridge, Massachusetts, USA. I too think it would be awesome for OpenStack to have a seat at the table alongside representatives of the usual closed-source clouds when it comes time to talk about (among other things) what Debian's official "cloud" image builds should be doing to better support our collective users. If you're interested in going, I recommend reaching out via the debian-cloud mailing list[***]. [*] https://lists.debian.org/debian-cloud/2019/08/msg00065.html [**] https://wiki.debian.org/Sprints/2019/DebianCloud2019 [***] https://lists.debian.org/debian-cloud/ -- Jeremy Stanley

3 2

RE: [masakari] pacemaker-remote Setup Overview
by Devharakar, Shilpa 21 Aug '19

21 Aug '19

Hi Ralf Teckelmann, Sorry for the attachment, instead please refer [1] Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [2]. You can refer 'devstack/plugin.sh' [1]: http://paste.openstack.org/show/760301/ [2]: https://review.opendev.org/#/c/671200/ > Hi Ralf Teckelmann, > > Sorry resending by correcting subject with appropriate subject. Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 19, 2019 10:19 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 94 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [tc] weekly update (Mohammed Naser) 2. RE: [masakari] pacemaker-remote Setup Overview (Devharakar, Shilpa) 3. Re: [tc] weekly update (Andreas Jaeger) 4. Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org (Doug Hellmann) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Aug 2019 12:26:48 -0400 From: Mohammed Naser <mnaser(a)vexxhost.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [tc] weekly update Message-ID: <CAEs876hqf-R4r9+LZcVbPPLJMEHTs=tPBztJtGqO8-oZvEXLcg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Retired projects - Networking-generic-switch-tempest (from networking-generic-switch): https://review.opendev.org/#/c/674430/ # General changes - Michał Dulko as Kuryr PTL: https://review.opendev.org/#/c/674624/ - Added a mission to Swift taken from its wiki: https://review.opendev.org/#/c/675307/ - Sean McGinnis as release PTL: https://review.opendev.org/#/c/675246/ Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com ------------------------------ Message: 2 Date: Mon, 19 Aug 2019 16:34:26 +0000 From: "Devharakar, Shilpa" <Shilpa.Devharakar(a)nttdata.com> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: RE: [masakari] pacemaker-remote Setup Overview Message-ID: <CH2PR12MB4072764F39DDD35C4A8ED158FFA80(a)CH2PR12MB4072.namprd12.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Ralf Teckelmann, Sorry resending by correcting subject with appropriate subject. > Hello, > > Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. > For the hostmonitor a pacemaker cluster is missing. > > Can anyone give me an overview how the pacemaker cluster setup would look like? > Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? > > Best regards, > > Ralf Teckelmann Sorry for the late answer... Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [1]. You can refer 'devstack/plugin.sh', please note it has IPMI Hardware support dependency. Also PFA 'detailed_steps_on_ubuntu_for_pacemaker_verification.txt' for verification of same carried out on Ubuntu distribution (installed openstack using devstack with Masakari enabled). [1]: https://review.opendev.org/#/c/671200/ Add devstack support to install host-monitor Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 12, 2019 6:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 59 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA (Arx Cruz) 2. [swauth][swift] Retiring swauth (Ondrej Novy) 3. [ironic] Resuming having weekly meetings (Julia Kreger) 4. [masakari] pacemaker-remote Setup Overview (Teckelmann, Ralf, NMU-OIP) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Aug 2019 12:32:34 +0200 From: Arx Cruz <arxcruz(a)redhat.com> To: Jean-Philippe Evrard <jean-philippe(a)evrard.me> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA Message-ID: <CAB27Hy1tB0TjEwsvrgeBUF1NFCzDadE58-VR68Qt_=3RKY+fVw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I've started to split the logs collection tasks in small tasks [1] in order to allow other users to choose what exactly they want to collect. For example, if you don't need the openstack information, or if you don't care about networking, etc. Please take a look. I'll also add it on the OSA agenda for tomorrow's meeting. Kind regards, 1 - https://review.opendev.org/#/c/675858/ On Mon, Jul 22, 2019 at 8:44 AM Jean-Philippe Evrard < jean-philippe(a)evrard.me> wrote: > Sorry for the late answer... > > On Wed, 2019-07-10 at 12:12 -0600, Wesley Hayutin wrote: > > > > These are of course just passed in as extra-config. I think each > > project would want to define their own list of files and maintain it > > in their own project. WDYT? > > Looks good. We can either clean up the defaults, or OSA can just > override the defaults, and it would be good enough. I would say that > this can still be improved later, after OSA has started using the role > too. > > > It simple enough. But I am happy to see a different approach. > > Simple is good! > > > Any thoughts on additional work that I am not seeing? > > None :) > > > > > Thanks for responding! I know our team is very excited about the > > continued collaboration with other upstream projects, so thanks!! > > > > Likewise. Let's reduce tech debt/maintain more code together! > > Regards, > Jean-Philippe Evrard (evrardjp) > > > > > -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 2 Date: Mon, 12 Aug 2019 12:56:15 +0200 From: Ondrej Novy <novy(a)ondrej.org> To: openstack-discuss(a)lists.openstack.org Subject: [swauth][swift] Retiring swauth Message-ID: <CAOO6c=wgDZDRpQboo=_0qZ=fHrfu0rO0w=PaUat9bJduwFiVXw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, because swauth is not compatible with current Swift, doesn't support Python 3, I don't have time to maintain it and my employer is not interested in swauth, I'm going to retire swauth project. If nobody take over it, I will start removing swauth from opendev on 08/24. Thanks. -- Best regards Ondřej Nový -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 3 Date: Mon, 12 Aug 2019 07:55:07 -0400 From: Julia Kreger <juliaashleykreger(a)gmail.com> To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: [ironic] Resuming having weekly meetings Message-ID: <CAF7gwdhSWcUbYu0S2QfvjO44Q_5vJr6KTUQE3TRu3UYirqFGmQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" All, I meant to send this specific email last week, but got distracted and $life. I believe we need to go back to having weekly meetings. The couple times I floated this in the past two weeks, there hasn't seemed to be any objections, but I also did not perceive any real thoughts on the subject. While the concept and use of office hours has seemingly helped bring some more activity to our IRC channel, we don't have a check-point/sync-up mechanism without an explicit meeting. With that being said, I'm going to start the meeting today and if we have quorum, try to proceed with it today. -Julia ------------------------------ Message: 4 Date: Mon, 12 Aug 2019 12:59:20 +0000 From: "Teckelmann, Ralf, NMU-OIP" <ralf.teckelmann(a)bertelsmann.de> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: [masakari] pacemaker-remote Setup Overview Message-ID: <AM6PR04MB47112DF6617442709662B43389D30(a)AM6PR04MB4711.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hello, Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. For the hostmonitor a pacemaker cluster is missing. Can anyone give me an overview how the pacemaker cluster setup would look like? Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? Best regards, Ralf Teckelmann -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 59 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. ------------------------------ Message: 3 Date: Mon, 19 Aug 2019 18:36:01 +0200 From: Andreas Jaeger <aj(a)suse.com> To: Mohammed Naser <mnaser(a)vexxhost.com>, OpenStack Discuss <openstack-discuss(a)lists.openstack.org>, juliaashleykreger(a)gmail.com Subject: Re: [tc] weekly update Message-ID: <803b9cce-9887-95a5-b257-21f164f5569a(a)suse.com> Content-Type: text/plain; charset=utf-8 On 19/08/2019 18.26, Mohammed Naser wrote: > Hi everyone, > > Here’s the update for what happened in the OpenStack TC this week. You > can get more information by checking for changes in > openstack/governance repository. > > # Retired projects > - Networking-generic-switch-tempest (from networking-generic-switch): > https://review.opendev.org/#/c/674430/ The process for retiring is documented here: https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Could you follow those steps to get the system out of Zuul properly, please? Andreas > # General changes > - Michał Dulko as Kuryr PTL: https://review.opendev.org/#/c/674624/ > - Added a mission to Swift taken from its wiki: > https://review.opendev.org/#/c/675307/ > - Sean McGinnis as release PTL: https://review.opendev.org/#/c/675246/ > > Thanks for tuning in! > > Regards, > Mohammed > -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg GF: Nils Brauckmann, Felix Imendörffer, Enrica Angelone, HRB 247165 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 ------------------------------ Message: 4 Date: Mon, 19 Aug 2019 12:48:40 -0400 From: Doug Hellmann <doug(a)doughellmann.com> To: Jeremy Stanley <fungi(a)yuggoth.org> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org Message-ID: <740FFC7B-F7F0-427C-95F8-C6D6E8A0FA7E(a)doughellmann.com> Content-Type: text/plain;charset=utf-8 > On Aug 19, 2019, at 10:59 AM, Jeremy Stanley <fungi(a)yuggoth.org> wrote: > > On 2019-08-19 13:17:35 +0000 (+0000), Alexandra Settle wrote: > [...] >> Doug has rightfully pointed out that whilst the documentation team >> as it stands today is no longer "integral", the docs.openstack.org >> web site is. An owner is required. >> >> The suggestion is for the Release Management team is the "least >> worst" (thanks, tonyb) place for the website manaagement to land. >> As Tony points out, this requires learning new tools and processes >> but the individuals working on the docs team currently have no >> intention to leave, and are around to help manage this from the >> SIG. >> >> Open to discussion and suggestions, but to summarise the proposal >> here: >> >> docs.openstack.org ownership is to transition to be the >> responsibility of the Release Management team officially provided >> there are no strong objections. > [...] > > The prose above is rather vague on what "the docs.openstack.org web > site" entails. Inferring from Doug's comments on 657142, I think you > and he are referring specifically to the content in the > https://opendev.org/openstack/openstack-manuals/src/branch/master/www > subtree. Is that pretty much it? The Apache virtual host > configuration and filesystem hosting the site itself are managed by > the Infra/OpenDev team, and there aren't any plans to change that as > far as I'm aware. > -- > Jeremy Stanley Yes, that’s correct. Doug ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 94 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 1

[ptl][keystone] PTL Out of Office August 24 - September 4
by Colleen Murphy 20 Aug '19

20 Aug '19

As mentioned in today's keystone meeting, I will be on vacation between August 24 and September 4 with no laptop and little to no cell service. Morgan Fainberg (kmalloc) has graciously agreed to step up as acting PTL while I am gone (thank you!). We agreed in today's meeting that the team will plan to hold next week's meeting as usual and possibly skip the following one. Office hours will be cancelled unless someone decides they really want to cover something with the team. The priority efforts for the next couple of weeks are: * finish remaining system-scope/default roles migrations (deadline is feature freeze, Sept 9-13) * reviews for spec implementations and system-scope/default roles migrations (deadline is feature freeze, Sept 9-13) * reviews for keystonemiddleware and keystoneauth (final release Sept 2-6) * reviews for python-keystoneclient (final release Sept 9-13) * helping the requirements team with any requirements issues[1] before requirements freeze (Sept 9-13) * completing community goals (follow the PDF generation news[2]) In the event there's feedback on one of my own outstanding patches that needs to be addressed in a timely manner, I grant any keystone core permission to go ahead and update it (that goes generally even when I'm not completely AFK). Colleen [1] https://bugs.launchpad.net/keystone/+bug/1839393 [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008506.h…

1 0

Re: [all][infra] Zuul logs are in swift
by Eric Fried 20 Aug '19

20 Aug '19

Hi infra. I wanted to blast out a handful of issues I've had since the cutover to swift. I'm using Chrome Version 76.0.3809.100 (Official Build) (64-bit) on bionic (18.04.3). - Hot tip: if you want the dynamic logs (with timestamp links and sev filters), use the twisties. Clicking through gets you to the raw files. The former was not obvious to me. - Some in-app logs aren't working. E.g. when I try to look at controller=>logs=>screen-n-cpu.txt.gz from [1], it redirects me to [2]. The hover [3] has a double slash in it, not sure if that's related, but when I try squashing to one slash, I get an error... sometimes [4]. - When the in-app logs do render, they don't wrap. There's a horizontal scroll bar, but it's at the bottom of an inner frame, so it's off the screen most of the time and therefore not useful. (I don't have horizontal mouse scroll capabilities; maybe I should look into that.) - The timestamp links in app anchor the line at the "top" - which (for me, anyway) is "underneath" the header menu (Status Projects Jobs Labels Nodes Builds Buildsets), so I have to scroll up to get the anchored line and a few of its successors. Thanks as always for all your hard work. efried [1] https://zuul.opendev.org/t/openstack/build/402a73a9238643c2b893d53b37a6ce27… [2] https://zuul.opendev.org/tenants [3] https://zuul.opendev.org/t/openstack/build/402a73a9238643c2b893d53b37a6ce27… [4] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infr…

4 9

[all][tc]Naming the U release of OpenStack -- Poll open
by Rico Lin 20 Aug '19

20 Aug '19

Hi, all OpenStackers, It's time to vote for the naming of the U release!! U 版本正式命名票选开始!! First, big thanks for all people who take their own time to propose names on [2] or help to push/improve to the naming process. Thank you. We'll use a public polling option over per-user private URLs for voting. This means everybody should proceed to use the following URL to cast their vote: *https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_19e5119b14f86294&akey=0cde542cb3de1b12 <https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_19e5119b14f86294&akey=0cde…>* We've selected a public poll to ensure that the whole community, not just Gerrit change owners get a vote. Also, the size of our community has grown such that we can overwhelm CIVS if using private URLs. A public can mean that users behind NAT, proxy servers or firewalls may receive a message saying that your vote has already been lodged if this happens please try another IP. Because this is a public poll, results will currently be only viewable by me until the poll closes. Once closed, I'll post the URL making the results viewable to everybody. This was done to avoid everybody seeing the results while the public poll is running. The poll will officially end on 2019-08-20 23:59:00+00:00 (UTC time)[1], and results will be posted shortly after. [1] https://governance.openstack.org/tc/reference/release-naming.html [2] https://wiki.openstack.org/wiki/Release_Naming/U_Proposals -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 3

[uc] Less than 4 days left to nominate for the UC!
by Ed Leafe 20 Aug '19

20 Aug '19

A week has gone by since nominations opened, and we have yet to receive a single nomination! Now I’m sure everyone’s waiting until the last minute in order to make a dramatic moment, but don’t put it off for *too* long! If you missed the initial announcement [0], here’s the information you need: Any individual member of the Foundation who is an Active User Contributor (AUC) can propose their candidacy (except the three sitting UC members elected in the previous election). Self-nomination is common, no third party nomination is required. They do so by sending an email to the user-committee(a)lists.openstack.orgmailing-list, with the subject: “UC candidacy” by August 16, 05:59 UTC. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate. -- Ed Leafe [0] http://lists.openstack.org/pipermail/user-committee/2019-August/002864.html

3 4

Update / change user_id from server / VM
by Pawel Konczalski 20 Aug '19

20 Aug '19

Hi all, is it possible to update / change the user_id of a OpenStack server (VM) if the user no more exists? # openstack server show 8cf8164a-6f55-4435-9f4e-621617d7951f -c user_id +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | user_id | ebfd5b2bf26a4f4381a290948cb3ce8b | +---------+----------------------------------+ # openstack user show ebfd5b2bf26a4f4381a290948cb3ce8b No user with a name or ID of 'ebfd5b2bf26a4f4381a290948cb3ce8b' exists. BR Pawel

1 0

ops meetup team meeting 2019-8-20
by Chris Morgan 20 Aug '19

20 Aug '19

Minutes for the openstack ops meetups team meeting today are linked below. Here are some notes: - Attendance at the upcoming NYC meetup (hosted at Bloomberg) is up to 40 and still growing - Hoping to arrange a social event on the evening of day 1, a sponsor for that is still being sought - easiest way to get updates is to follow https://twitter.com/osopsmeetup - one of the sessions will propose bringing more ceph content to these meetups or starting a new similar dedicated ceph operators meetup series <https://twitter.com/osopsmeetup> Meeting ended Tue Aug 20 14:37:20 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:37 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:37 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:37 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Cheers, Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0