- openstack-discuss - lists.openstack.org

[keystone] Keystone Team Update - Week of 12 August 2019
by Colleen Murphy 16 Aug '19

16 Aug '19

# Keystone Team Update - Week of 12 August 2019 ## News ### Feature Proposal Freeze This week is our scheduled feature proposal freeze[1], see status summary post[2]. [1] https://releases.openstack.org/train/schedule.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008549.h… ### Trusts API While implementing system scope and default roles for the trusts API we discovered an inconsistency in the error handling for the GET trust details request: most of our APIs do RBAC enforcement first thing, and return a 403 if the resource is missing so as not to divulge whether there's a record in the database for the requested resource. The GET trust details request does the database lookup first and exposes a 404 to the user if the record is missing. We discussed in the bug report[3] whether this is desireable, intended, acceptable, or dangerous behavior, and so far have converged on not fixing the issue in the interest of not breaking the API contract. If you have feelings to the contrary, please speak up in the bug report. [3] https://bugs.launchpad.net/bugs/1840288 ## Action Items * knikolla to finish initial implementation proposal of renewable group membership next week * kmalloc to finish initial implementation proposal of resource options migration next week ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. The topic for next week's office hour will be: feature proposal review - we'll walk through code implementations (if available) and answer any questions, or discuss design details if code is not available yet The location for next week's office hour will be: https://meet.jit.si/keystone-office-hours Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Open Specs Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 15 changes this week, which included support for auth receipts in keystoneauth[4], the IPv6 community goal work[5], and some more changes to implement access rules in application credentials[6]. [4] https://review.opendev.org/675049 [5] https://review.opendev.org/671903 [6] https://review.opendev.org/#/q/status:merged+topic:bp/whitelist-extension-f… ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 47 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories - System scope/default roles (https://trello.com/c/ERo50T7r , https://trello.com/c/RlYyb4DU) + https://review.opendev.org/#/q/status:open+topic:implement-default-roles+la… + https://review.opendev.org/#/q/status:open+topic:trust-policies + https://review.opendev.org/#/q/topic:bug/1805409 - Federated attributes for users (https://trello.com/c/dEmSumDQ) + https://review.opendev.org/#/q/status:open+topic:bp/support-federated-attr - Application credential access rules (https://trello.com/c/dJsWMI4W) + https://review.opendev.org/#/q/status:open+topic:bp/whitelist-extension-for… * Closes bugs - Honor group_members_are_ids for user_enabled_emulation https://review.opendev.org/674782 - Cleanup session on delete https://review.opendev.org/674139 - token: consistently decode binary types https://review.opendev.org/665617 * Oldest - OpenID Connect improved support https://review.opendev.org/373983 ## Bugs This week we opened 6 new bugs and closed 3. Bugs opened (6) Bug #1840288 (keystone:High) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1840288 Bug #1840291 (keystone:Medium) opened by Rabi Mishra https://bugs.launchpad.net/keystone/+bug/1840291 Bug #1840090 (keystone:Undecided) opened by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1840090 Bug #1840403 (keystone:Undecided) opened by Ariya Jantaravises https://bugs.launchpad.net/keystone/+bug/1840403 Bug #1839748 (keystoneauth:High) opened by Adrian Turjak https://bugs.launchpad.net/keystoneauth/+bug/1839748 Bug #1840235 (keystoneauth:Undecided) opened by Rabi Mishra https://bugs.launchpad.net/keystoneauth/+bug/1840235 Bugs closed (1) Bug #1840288 (keystone:High) https://bugs.launchpad.net/keystone/+bug/1840288 Bugs fixed (2) Bug #1839577 (keystone:Medium) fixed by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1839577 Bug #1839748 (keystoneauth:High) fixed by Adrian Turjak https://bugs.launchpad.net/keystoneauth/+bug/1839748 ## Milestone Outlook https://releases.openstack.org/train/schedule.html This week is feature proposal freeze week for the keystone team, which as mentioned previously is being extended for some initiatives. Oslo feature freeze is in two weeks: anything we need to complete for oslo.policy needs to be merged before then. Oslo.limit is still pre-1.0 so feature freeze won't apply to it. The PTL nomination period is also in two weeks: while I intend to run again I'm also happy to answer questions about the role if anyone wants to also put their name in. Final release for non-client libraries (keystonemiddleware, keystoneauth) is in three weeks. Feature freeze and client library freeze is in four weeks. This is also the soft string freeze and the requirements freeze and the community goals deadline. ## Shout-outs Keystoneauth now supports multi-factor authentication and auth receipts[7]. Thanks to Adrian for tackling this ahead of the library freeze deadline! [7] https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#… ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[keystone] Feature proposal freeze status
by Colleen Murphy 16 Aug '19

16 Aug '19

This week is the keystone team's feature proposal freeze week. Here's a status update for our planned features for this cycle[1]: * Add Fine Grained Restrictions to Application Credentials[2]: implementation is proposed and ready for review[3], most work is merged, some patches remaining for review, client work not started * Expiring Group Memberships Through Mapping Rules[4]: implementation not yet proposed, 1-week extension granted[5] * Explicit Domain IDs[6]: Complete[7] * Immutable Resources[8]: Implementation proposed[9], partially WIP; depends on resource options work * Resource options for all resource types[10]: implementation not yet proposed, 1-week extension granted[11] * Extend user API to support federated attributes[12]: proposed and ready for review[13] We're only holding spec work accountable to the feature proposal freeze deadline. Other roadmap features[14], including system scope and default roles work, is open for code proposals until feature freeze week. [1] http://specs.openstack.org/openstack/keystone-specs/ [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ca… [3] https://review.opendev.org/#/q/topic:bp/whitelist-extension-for-app-creds [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008513.h… [6] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [7] https://review.opendev.org/605235 [8] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/im… [9] https://review.opendev.org/#/q/topic:immutable-resources [10] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/re… [11] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008546.h… [12] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/su… [13] https://review.opendev.org/#/q/topic:bp/support-federated-attr [14] https://trello.com/b/ClKW9C8x/keystone-train-roadmap

1 0

[keystone] Feature proposal freeze exception for resource options
by Colleen Murphy 16 Aug '19

16 Aug '19

Work is underway to implement resource options for all resources[1] but the code has not been proposed yet. Since the implementation is close to ready to review, and because immutable resources[2] depends on it, we're proposing a 1-week extension to our feature proposal freeze deadline[3]. This will also push out the work for immutable resources, but the majority of this feature has been implemented[4] and will only require a rebase on top of the resource options work. If you have any concerns about this, please let me or the team know. Colleen [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/re… [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/im… [3] https://releases.openstack.org/train/schedule.html [4] https://review.opendev.org/#/q/topic:immutable-resources

1 0

[goal][python3] Train unit tests weekly update (goal-4)
by Corey Bryant 16 Aug '19

16 Aug '19

This is the goal-4 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 4 weeks remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) If your project has patches with successful tests please help get them merged. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3 -train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Ongoing Work == Thank you to all who have contributed their time and fixes to enable patches to land. We're down to 23 projects with failing tests. == Completed Work == All patches have been submitted to all applicable projects for this goal. Merged patches: https://review.openstack.org/#/q/topic:python3-train +is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/ python3-updates.html [2] Train release schedule: https://releases.openstack.org/train /schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… train.rst Thanks,

1 0

[ironic][ptl] Taking a break - i.e. disconnecting for a few weeks in September
by Julia Kreger 16 Aug '19

16 Aug '19

Greetings everyone, For my own mental health and with various things that have occurred in my life these past six months, I will be disconnecting for two weeks during the month of September, starting on the 6th. To put icing on the cake, I then have business related travel the two weeks following my return that will inhibit regular IRC access during peak contributor days/hours. In my absence, Dmitry Tantsur has agreed to take care of my PTL responsibilities. This will include the time through requirements freeze and quite possibly include the creation of the stable/train branch if necessary. That being said, fear not! I still intend to run for Ironic's PTL for the next cycle! -Julia

2 1

[neutron][OVN] Instance not getting metadata
by Zufar Dhiyaulhaq 16 Aug '19

16 Aug '19

Hi, I have set up OpenStack with OVN enabled (manual install) and I can create Instance, associate floating IP and test the ping. But my Instance not getting metadata from OpenStack. I check the reference architecture, https://docs.openstack.org/networking-ovn/queens/admin/refarch/refarch.html the compute nodes should have installed ovn-metadata-agent but I don't find any configuration document about ovn-metadata-agent. I have configured the configuration files like this: [DEFAULT] nova_metadata_ip = 10.100.100.10 [ovs] ovsdb_connection = unix:/var/run/openvswitch/db.sock [ovn] ovn_sb_connection = tcp:10.101.101.10:6642 But the agent always fails. Full logs: http://paste.openstack.org/show/757805/ Anyone know whats happen and how to fix this error? Best Regards, Zufar Dhiyaulhaq

2 3

[monasca][ptl] Out of office
by Witek Bedyk 16 Aug '19

16 Aug '19

Hello everyone, I will be out of office from August 19th until 30th. In Monasca related matters please contact: Martin Chacon Piza <martindavid.chaconpiza1(a)est.fujitsu.com> Thanks Witek

1 0

[placement] update 19-32
by Chris Dent 16 Aug '19

16 Aug '19

HTML: https://anticdent.org/placement-update-19-32.html Here's placement update 19-32. There will be no update 33; I'm going to take next week off. If there are Placement-related issues that need immediate attention please speak with any of Eric Fried (efried), Balazs Gibizer (gibi), or Tetsuro Nakamura (tetsuro). # Most Important Same as last week: The main things on the Placement radar are implementing Consumer Types and cleanups, performance analysis, and documentation related to nested resource providers. A thing we should place on the "important" list is bringing the osc placement plugin up to date. We also need to discuss what would we would like the plugin to be. Is it required that it have ways to perform all the functionality of the API, or is it about providing ways to do what humans need to do with the placement API? Is there a difference? We decided that consumer types is medium priority: The nova-side use of the functionality is not going to happen in Train, but it would be nice to have the placement-side ready when U opens. The primary person working on it, tssurya, is spread pretty thin so it might not happen unless someone else has the cycles to give it some attention. On the documentation front, we realized during some performance work [last](https://review.opendev.org/675606) [week](https://review.opendev.org/#/c/676204/4/placement/tests/functional/ga… that it easy to have an incorrect grasp of how `same_subtree` works when there are more than two groups involved. It is critical that we create good "how to use" documentation for this and other advanced placement features. Not only can it be easy to get wrong, it can be challenge to see that you've got it wrong (the failure mode is "more results, only some of which you actually wanted"). # What's Changed * Yet more [performance fixes](https://review.opendev.org/#/q/topic:optimize-_build_provider_summar… are in the process of merging. Most of these are related to getting `_merge_candidates` and `_build_provider_summaries` to have less impact. The fixes are generally associated with avoiding duplicate work by generating dicts of reusable objects earlier in the request. This is possible because of the relatively new `RequestWideSearchContext`. In a request that returns many provider summaries `_build_provider_summaries` continues to have a significant impact because it has to create many objects but overall everything is much less heavyweight. More on performance in Themes, below. * The combination of all these performance fixes, and because of microversions, makes it reasonable for anyone running placement in a resource constrained environment (or simply wanting things to be faster) to consider running Train placement with _any_ release of OpenStack. Obviously you should test it first, but it is worth investigating. More information on how to achieve this can be found in the [upgrade to stein docs](https://docs.openstack.org/placement/latest/upgrade/to-stein.html) # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 23 (1) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 4 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 4 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 18 (1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 4 (-1). # osc-placement osc-placement is currently behind by 12 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. * <https://review.opendev.org/640898> Adds a new '--amend' option which can update resource provider inventory without requiring the user to pass a full replacement for inventory. This has been broken up into three patches to help with review. # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> A WIP, as microversion 1.37, has started. As mentioned above, this is currently paused while other things take priority. If you have time that you could spend on this please respond here expressing that interest. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. As said above, there's lots of performance work in progress. We'll need to make a similar effort with regard to docs. For example, all of the coders involved in the creation and review of the `same_subtree` functionality struggle to explain, clearly and simply, how it will work in a variety of situations. We need to enumerate the situations and the outcomes, in documentation. One outcome of this work will be something like a _Deployment Considerations_ document to help people choose how to tweak their placement deployment to match their needs. The simple answer is use more web servers and more database servers, but that's often very wasteful. On the performance front, there is one major area of impact which has not received much attention yet. When requesting allocation candidates (or resource providers) that will return many results the cost of JSON serialization is just under one quarter of the processing time. This is to be expected when the response body is `2379k` big, and 154000 lines long (when pretty printed) for 7000 provider summaries and 2000 allocation requests. But there are ways to fix it. One is to ask more focused questions (so fewer results are expected). Another is to `limit=N` the results (but this can lead to issues with migrations). Another is to [use a different JSON serializer](https://review.opendev.org/674661). Should we do that? It make a _big_ difference with large result sets (which will be common in big and sparse clouds). # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are two [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/671312> blazar: Fix placement operations in multi-region deployments * <https://review.opendev.org/671793> Nova: libvirt: Start reporting PCPU inventory to placement A part of <https://review.opendev.org/#/q/topic:bp/cpu-resources * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/670696> tempest: Add placement API methods for testing routed provider nets * <https://review.opendev.org/672678> openstack-helm: Build placement in OSH-images * <https://review.opendev.org/674129> Correct global_request_id sent to Placement * <https://review.opendev.org/#/q/topic:bp/cross-cell-resize> Nova: cross cell resize * <https://review.opendev.org/674524> Nova: Scheduler translate properties to traits * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/674708> Zun: [WIP] Claim container allocation in placement # End Have a good next week. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

kayobe 6.0.0.0rc1 (stein)
by no-reply＠openstack.org 16 Aug '19

16 Aug '19

Hello everyone, A new release candidate for kayobe for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kayobe/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://opendev.org/openstack/kayobe/log/?h=stable/stein Release notes for kayobe can be found at: https://docs.openstack.org/releasenotes/kayobe/

1 0

[ironic] [stable] Proposal to add Riccardo Pittau to ironic-stable-maint
by Dmitry Tantsur 16 Aug '19

16 Aug '19

Hi folks! I'd like to propose adding Riccardo to our stable team. He's been consistently checking stable patches [1], and we're clearly understaffed when it comes to stable reviews. Thoughts? Dmitry [1] https://review.opendev.org/#/q/reviewer:%22Riccardo+Pittau+%253Celfosardo%2…

6 6

Re: [lists.openstack.org]Re: [nova] The race for 2.76
by Brin Zhang(张百林) 16 Aug '19

16 Aug '19

> On 8/13/2019 7:25 AM, Matt Riedemann wrote: > > There are several compute API microversion changes that are > > conflicting and will be fighting for 2.76, but I think we're trying to > > prioritize this one [1] for the ironic power sync external event > > handling since (1) Surya is going to be on vacation soon, (2) there is > > an ironic change that depends on it which has had review [2] and (3) > > the nova change has had quite a bit of review already. > > > > As such I think others waiting to rebase from 2.75 to 2.76 should > > probably hold off until [1] is approved which should happen today or > > tomorrow. > > > > [1] https://review.opendev.org/#/c/645611/ > > [2] https://review.opendev.org/#/c/664842/ > These are both approved now so let the rebasing begin! "Specifying az when restore shelved server" have been updated, and now it's in the nova-runway, please review, thanks. Links: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… -- Thanks, Matt

1 0

[nova] NUMA live migration is ready for review and testing
by Artom Lifshitz 16 Aug '19

16 Aug '19

tl;dr If you care about NUMA live migration, check out [1] and test in in your env(s), or review it. Over the months that I've worked on NUMA LM, I've been pinged by various folks that were interested in helping out. At this point I've addressed all the issues that were found at the end of the Stein cycle, and the series is ready for review and testing, with the aim of getting it merged in Train (for real this time). So if you care about NUMA-aware live migration and have some spare time and hardware (if you're in the former category I don't think I need to explain what kind of hardware - though I'll try to answer questions as best I can), I would greatly appreciate it if you deployed the patches and tested them. I've done that myself, of course, but, as at the end of Stein, I'm sure there are edge cases that I didn't think of (though I'm selfishly hoping that there aren't). I believe the series is also ready for review, though I haven't put it in the runway queue just yet because the last functional test patch is still a WIP, as I need to fiddle with it to assert more things. Thanks in advance, cheers! [1] https://review.opendev.org/#/c/672595/8

4 3

[qa][openstackclient] Debugging devstack slowness
by Clark Boylan 15 Aug '19

15 Aug '19

Today I have been digging into devstack runtime costs to help Donny Davis understand why tempest jobs sometimes timeout on the FortNebula cloud. One thing I discovered was that the keystone user, group, project, role, and domain setup [0] can take many minutes [1][2] (in the examples here almost 5). I've rewritten create_keystone_accounts to be a python tool [3] and get the runtime for that subset of setup from ~100s to ~9s [4]. I imagine that if we applied this to the other create_X_accounts functions we would see similar results. I think this is so much faster because we avoid repeated costs in openstack client including: python process startup, pkg_resource disk scanning to find entrypoints, and needing to convert names to IDs via the API every time osc is run. Given my change shows this can be so much quicker is there any interest in modifying devstack to be faster here? And if so what do we think an appropriate approach would be? [0] https://opendev.org/openstack/devstack/src/commit/6aeaceb0c4ef078d028fb6605… [1] http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output… [2] http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output… [3] https://review.opendev.org/#/c/673108/ [4] http://logs.openstack.org/08/673108/6/check/devstack-xenial/a4107d0/job-out… Note the jobs compared above all ran on rax-dfw. Clark

11 23

[question][placement][rest api][403]
by 崔恒香 15 Aug '19

15 Aug '19

This is my problem with placement rest api.(Token and endpoint were OK) {"errors": [{"status": 403, "title": "Forbidden", "detail": "Access was denied to this resource.\n\n Policy does not allow placement:resource_providers:list to be performed. ", "request_id": "req-5b409f22-7741-4948-be6f-ea28c2896a3f" }]} Regards, Cuihx

2 1

[nova] The race for 2.76
by Matt Riedemann 15 Aug '19

15 Aug '19

There are several compute API microversion changes that are conflicting and will be fighting for 2.76, but I think we're trying to prioritize this one [1] for the ironic power sync external event handling since (1) Surya is going to be on vacation soon, (2) there is an ironic change that depends on it which has had review [2] and (3) the nova change has had quite a bit of review already. As such I think others waiting to rebase from 2.75 to 2.76 should probably hold off until [1] is approved which should happen today or tomorrow. [1] https://review.opendev.org/#/c/645611/ [2] https://review.opendev.org/#/c/664842/ -- Thanks, Matt

1 1

[glance] worker, thread, taskflow interplay
by Gregory Orange 15 Aug '19

15 Aug '19

We are trying to figure out how these two settings interplay in: [DEFAULT]/workers [taskflow_executor]/max_workers [oslo_messaging_zmq]/rpc_thread_pool_size Just setting workers makes a bit of sense, and based on our testing: =0 creates one process =1 creates 1 plus 1 child =n creates 1 plus n children Are there green threads (i.e. coroutines, per https://eventlet.net/doc/basic_usage.html) within every process, regardless of the value of workers? Does max_workers affect that? We have read some Glance doco, hunted about various bug reports[1] and other discussions online to get some insight, but I think we're not clear on it. Can anyone explain this a bit better to me? This is all in Rocky. Thank you, Greg. [1] https://bugs.launchpad.net/glance/+bug/1748916

2 1

[keystone] Feature proposal freeze exception for refreshable group membership
by Colleen Murphy 15 Aug '19

15 Aug '19

Work is in progress to implement refreshable group membership in keystone[1]. In order to allow for some breathing room for thorough discussion on the implementation details, we're proposing a 1-week extension to our scheduled feature proposal freeze deadline (this week)[2]. Please let me or the team know if you have any concerns about this. Colleen [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [2] https://releases.openstack.org/train/schedule.html

2 1

[blazar] IRC meeting today
by Pierre Riteau 15 Aug '19

15 Aug '19

Hello, Today we have our biweekly Blazar IRC meeting at 16:00 UTC on #openstack-meeting-alt: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_15_Aug_2019_.28A… We can update on the status of upstream contributions from our user community. Everyone is welcome to join and bring up any other topic. Cheers, Pierre

1 0

[nova] API updates week 19-33
by Ghanshyam Mann 15 Aug '19

15 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… 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: This has been rebased as 2.75 microversion is already merged. This will need again rebase as 2.76 is reserved for 'Add 'power-update' external event' 2. Nova API cleanup - Topic: https://review.opendev.org/#/q/topic:bp/api-consistency-cleanup+(status:ope… - Weekly Progress: Nova patch is merged. python-novaclient patch is pending. 3. Show Server numa-topology - Topic: https://review.opendev.org/#/q/topic:bp/show-server-numa-topology+(status:o… - Weekly Progress: Alex is +1 on nova change, but this is with microversion number as 2.76. This might need to be hold on ? 4. Nova API policy improvement - Topic: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: First set of os-service and Admin Action API policy series is ready to review. I have sent the review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 5. Add 'power-update' external event: - Topic: https://review.opendev.org/#/q/topic:bp/nova-support-instance-power-update+… - Weekly Progress: This is reserved for 2.76 and we should merge this soon as many other microversion changes are waiting for grabbing 2.76. I do not have updates on the current state, maybe matt or surya can add more if needed. 6. 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.76. We can rebase the microverison number later and not blocking for review. I will review it next week. 7. Support delete_on_termination in volume attach api -Spec: https://review.opendev.org/#/q/topic:bp/support-delete-on-termination-in-se… - Weekly Progress: Spec is merged and code is up for review. This is another one from Brin. 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

[all] [tc] General questions on PDF community goal
by Akihiro Motoki 15 Aug '19

15 Aug '19

Hi, I have a couple of general questions on PDF community goal. What is the criteria of completing the PDF community goal? Is it okay if we publish a PDF deliverable anyway? During working on it, I hit the following questions. We already reached Train-2 milestone, so I think it is the time to clarify the detail criteria of completing the community goal. - Where should the generated PDF file to be located and What is the recommended PDF file name? <top directory>/<repository-name>.pdf? index.pdf? Any path and any file is okay? - Do we create a link to the PDF file from index.html (per-project top page)? If needed, perhaps this would be a thing covered by openstackdocstheme. Otherwise, how can normal consumers know PDF documents? - Which repositories need to provide PDF version of documents? My understanding (amotoki) is that repositories with 'publish-openstack-docs-pti' should publish PDF doc. right? - Do we need PDF version of release notes? - Do we need PDF version of API reference? I see no coordination efforts recently and am afraid that individual projects cannot decide whether patches to their repositories are okay to merge. Thanks, Akihiro Motoki (irc: amotoki)

3 2

[ansible][openstack-ansible][tripleo][kolla-ansible] Ansible SIG
by Mohammed Naser 15 Aug '19

15 Aug '19

Hi everyone, One of the things that came up recently was collaborating more with other deployment tools and this has brought up things like working together on our Ansible roles as more and more deployments tools start to use it. However, as we start to practice this, we realize that a project team ownership starts not making much sense (due to the fact that a project can only be under one team in governance). It starts being confusing when a role is built by OSA, and consumed by TripleO, so the PTL is from another team and it all starts getting weird and odd, so we discussed the creation of an Ansible SIG for those who are interested in maintaining code across our community together that would be consumed together. We already have some deliverables that can live underneath it which is pretty awesome too, so I'm emailing this to ask for interested parties to speak up if they're interested and to mention that we're more than happy to have other co-chairs that are intersted. I've submitted the initial patch here: https://review.opendev.org/676428 Thank you, Mohammed

2 2

neutron-server won't start in OpenStack OVN
by Zufar Dhiyaulhaq 15 Aug '19

15 Aug '19

Hi everyone, I try to install OpenStack with OVN enabled. But when trying to start neutron-server, the service is always inactive (exited) I try to check neutron-server logs and gets this message: 2019-08-14 05:40:32.649 4223 INFO networking_ovn.ml2.qos_driver [-] Starting OVNQosDriver 2019-08-14 05:40:32.651 4224 INFO networking_ovn.ovsdb.impl_idl_ovn [-] Getting OvsdbSbOvnIdl for MaintenanceWorker with retry 2019-08-14 05:40:32.654 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6641: connecting... 2019-08-14 05:40:32.655 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6641: connected 2019-08-14 05:40:32.657 4220 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.658 4220 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.660 4225 INFO networking_ovn.ovsdb.impl_idl_ovn [-] Getting OvsdbSbOvnIdl for AllServicesNeutronWorker with retry 2019-08-14 05:40:32.670 4220 INFO neutron.wsgi [-] (4220) wsgi starting up on http://0.0.0.0:9696 2019-08-14 05:40:32.692 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.692 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.693 4224 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.694 4224 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.697 4224 INFO networking_ovn.ml2.qos_driver [-] Starting OVNQosDriver 2019-08-14 05:40:32.844 4225 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.844 4224 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.844 4222 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.845 4223 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.845 4221 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting neutron-server full logs: https://paste.ubuntu.com/p/GHfS38KFCr/ ovsdb-server port is active: https://paste.ubuntu.com/p/MhgNs8SGdX/ neutron.conf and ml2_conf.ini: https://paste.ubuntu.com/p/4J7hTVf5qz/ Does anyone know why this error happens? Best Regards, Zufar Dhiyaulhaq

2 2

creating instances, haproxy eats CPU, glance eats RAM
by Gregory Orange 15 Aug '19

15 Aug '19

Hi everyone, We have a Queens/Rocky environment with haproxy in front of most services. Recently we've found a problem when creating multiple instances (2 VCPUs, 6GB RAM) from large images. The behaviour is the same whether we use Horizon or Terraform, so I've continued on with Terraform since it's easier to repeat attempts. WORKS: 340MB image, create 80x instances, 40 at a time FAILS: 20GB image, create 40x instances, 20 at a time ... Changed haproxy config, added "balance roundrobin" to glance, cinder, nova, neutron stanzas (there was no 'balance' config before, not sure what it would have been doing) ... WORKS sometimes[1]: 20GB image, create 40x instances, 20 at a time FAILS: 20GB image, create 80x instances, 40 at a time The failure condition: * The active haproxy server has a single core go to 100% usage (the rest are idle) * One glance server's RAM usage grows rapidly and continuously * Some instances that are building complete * Creating new instances fails (BUILD state forever) * Horizon becomes unresponsive * Ceph and Cinder don't appear to be overloaded (ceph -s, logs, system state) * These states do not recover until we take the following actions... To recover: * Kill any remaining (Terraform) attempts to launch instances * Stop haproxy on the active server * Wait a few seconds * Start haproxy again [1] When we create enough to not quite overload it, haproxy server goes to 100% on one core but recovers once the instances are (slooowly) created. The cause of the problem is not clear (e.g. from haproxy and glance logs, system state), and I'm looking for pointers on where to look or what to try next. Can you help? Thank you, Greg.

2 4

[Telemetry][Shanghai Summit] Looking for Project Update session volunteers
by Trinh Nguyen 15 Aug '19

15 Aug '19

Hi team, I cannot attend the next summit in Shanghai so I'm looking for one-two volunteers who want to represent the Telemetry team at the summit. Please reply to this email by this Sunday and we will work through the presentation together. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 1

[nova] Shanghai Project Update - Volunteer(s) needed
by Eric Fried 14 Aug '19

14 Aug '19

Hello Nova. Traditionally summit project updates are done by the PTL(s) of the foregoing and/or upcoming cycles. In this case, the former (that would be me) will not be attending the summit, and we don't yet know who the latter will be. So I am asking for a volunteer or two who is a) attending the summit [1], and b) willing [2] to deliver a Nova project update presentation. I (and others, I am sure) will be happy to help with slide content and other prep. Please respond ASAP so we can reserve a slot. Thanks, efried [1] it need not be definite at this point - obviously corporate, political, travel, and personal contingencies may interfere [2] blah blah, opportunity for exposure, yatta yatta, good experience, etc.

4 4

[release] Release countdown for week R-8, August 19-23
by Sean McGinnis 14 Aug '19

14 Aug '19

Your long awaited countdown email... Development Focus ----------------- It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Looking ahead to Train-3, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (September 05). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (September 12) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, September 12. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. * After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September 26) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (October 10) Finally, now is a good time to list contributors to your team who do not have a code contribution, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote in election. This is done by adding extra-atcs to: https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on August 29. Upcoming Deadlines & Dates -------------------------- Extra-ATC freeze: August 29 (R-7 week) Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone: September 12 (R-5 week) -- Sean McGinnis (smcginnis)

1 0

August 14 Early Bird Registration Deadline - Open Infrastructure Summit Shanghai
by Kendall Waters 14 Aug '19

14 Aug '19

Hi everyone, Friendly reminder that today, August 14, at 11:59pm PT (August 15 at 2:59pm China Standard Time) is the deadline to purchase passes for the Open Infrastructure Summit at the early bird price. Register now before the prices increase! There are 2 ways to register - in USD <https://app.eventxtra.link/registrations/6640a923-98d7-44c7-a623-1e2c9132b4…> or in RMB (with e-fapiao) <https://app.eventxtra.link/registrations/f564960c-74f6-452d-b0b2-484386d33e…>. In case you missed it, the agenda <https://www.openstack.org/summit/shanghai-2019/summit-schedule> went live last week and features sessions covering CI/CD, Edge Computing, 5G, hybrid cloud, and more. Other Summit News If you require a visa to travel to China, please apply here Hiring talent to build your open infrastructure strategy? Have a new product to share? Join the Summit as as sponsor If you have any questions, please email summit(a)openstack.org <mailto:summit@openstack.org>. Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall(a)openstack.org

1 0

[tripleo] TripleO CI Summary: Sprint 34
by Rafael Folco 14 Aug '19

14 Aug '19

Greetings, The TripleO CI team has just completed Sprint 34 / Unified Sprint 13 (Jul 18 thru Aug 07). The following is a summary of completed work during this sprint cycle: - Created RHEL8 jobs to build a periodic pipeline in the RDO Software Factory and provide early feedback for CentOS8 coverage. - Fixed RHEL8 container and image build jobs in the periodic pipeline. - Bootstrapped RHEL8 standalone job and made progress on RHEL8 OVB featureset 001 job. - Completed scenario007 and featureset039 job updates upstream. - Promotion status: red on all branches at half of the sprint due to rhel8 changes and infra related issues (transient failures). - Disabled Fedora jobs from periodic pipeline. - Merged code for automatic creation of featureset matrix on TripleO quickstart documentation [3]. The planned work for the next sprint [1] are: - Create scenario1-4 jobs for RHEL8 in the periodic pipeline. - Design and test multi-arch container support. - Resume the design work for a staging environment to test changes in the promoter server for the multi-arch builds. - Continue OVB featureset001 bootstrapping on RHEL8. - Disable Fedora jobs upstream. The Ruck and Rover for this sprint are Chandan Kumar (chkumar) and Ronelle Landy (rlandy). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-14 [2] https://etherpad.openstack.org/p/ruckroversprint14 [3] https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.…

1 0

[nova][stacktach]
by Blom, Merlin, NMU-OI 14 Aug '19

14 Aug '19

Hey, it anybody using stacktach with OpenStack Nova Stein? I can't stream messages to it via Nova: -> stacktach_worker_config.json {"deployments": [ { "name": "xxx.dev", "durable_queue": false, "rabbit_host": "10.x.x.x", "rabbit_port": 5672, "rabbit_userid": "nova", "rabbit_password": "xxx", "rabbit_virtual_host": "/nova", "exit_on_exception": true, "topics": { "nova": [ { "queue": "notification.info", "routing_key": "notification.info" }, { "queue": "monitor.error", "routing_key": "monitor.error" } . How do you configure it? Are there alternatives for reading RabbitMQ Messages for debug/billing purposes? Greetings, Merlin Blom

1 0

[os-acc] os-acc will be retired as a project
by Nadathur, Sundar 14 Aug '19

14 Aug '19

A project called os-acc [1] was created in Stein cycle based on an expectation that it will be used for Cyborg - Nova integration. It is not relevant anymore and we have no plans to support it in Train. We are discontinuing it with immediate effect. It was never used and had no developer base to speak of. So, we do not see any issues or impact for anybody. [1] https://opendev.org/openstack/os-acc/ Regards, Sundar

1 0

[cyborg] Poll for new weekly IRC meeting time
by Nadathur, Sundar 14 Aug '19

14 Aug '19

The current Cyborg weekly IRC meeting time [1] is a conflict for many. We are looking for a better time that works for more people, with the understanding that no time is perfect for all. Please fill out this poll: https://doodle.com/poll/6t279f9y6msztz7x Be sure to indicate which times do not work for you. You can propose a new timeslot beyond what I included in the poll. [1] https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Weekly_IRC_Cybor… Regards, Sundar

1 1

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 14 Aug '19

14 Aug '19

Hi team, Watcher team will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

1 0

Re: [lists.openstack.org代发]Re: [nova] Shanghai Project Update - Volunteer(s) needed
by Brin Zhang(张百林) 14 Aug '19

14 Aug '19

> I apply the second one. I can also provide some help if there is a need. Stephen Finucane <sfinucan(a)redhat.com<mailto:sfinucan@redhat.com>> 于2019年8月14日周三上午5:25写道： On Tue, 2019-08-13 at 15:20 -0500, Eric Fried wrote: > Hello Nova. > > Traditionally summit project updates are done by the PTL(s) of the > foregoing and/or upcoming cycles. In this case, the former (that would > be me) will not be attending the summit, and we don't yet know who the > latter will be. > > So I am asking for a volunteer or two who is a) attending the summit > [1], and b) willing [2] to deliver a Nova project update presentation. I > (and others, I am sure) will be happy to help with slide content and > other prep. Unless someone else wants to do it, I think I can probably do it. Stephen > Please respond ASAP so we can reserve a slot. > > Thanks, > efried > > [1] it need not be definite at this point - obviously corporate, > political, travel, and personal contingencies may interfere > [2] blah blah, opportunity for exposure, yatta yatta, good experience, etc. >

1 0

reply: [lists.openstack.org][nova] The race for 2.76
by Brin Zhang(张百林) 14 Aug '19

14 Aug '19

> There are several compute API microversion changes that are conflicting and will be fighting for 2.76, but I think we're trying to prioritize this one [1] for the ironic > power sync external event handling since (1) Surya is going to be on vacation soon, (2) there is an ironic change that depends on it which has had review [2] and (3) > the nova change has had quite a bit of review already. > As such I think others waiting to rebase from 2.75 to 2.76 should probably hold off until [1] is approved which should happen today or tomorrow. > > [1] https://review.opendev.org/#/c/645611/ > [2] https://review.opendev.org/#/c/664842/ > > -- > > Thanks, > > Matt Agree with Matt. It is recommended to speed up the review of the patches on nova-runway [1]. I found that it has accumulated a lot, and some of them are difficult to complete in one cycle. [1] https://etherpad.openstack.org/p/nova-runways-train

1 0

OpenStack 14 CentOS and Nvidia driver for vgpu?
by Piotr Baranowski 13 Aug '19

13 Aug '19

Hello list, I'm struggling deploying Rocky with vGPU using nvidia drivers. Has anyone experienced the issues loading nvidia modules? I'm talking about hypervisor part of the setup. There are two modules provided by nvidia. One loads correctly it's the nvidia.ko one. The other however does not. The module is called nvidia-vgpu-vfio.ko I'm trying to load it and it seems that 7.6 kernel is no longer compatible with it modprobe nvidia-vgpu-vfio modprobe: ERROR: could not insert 'nvidia_vgpu_vfio': Invalid argument dmesg shows this: nvidia_vgpu_vfio: disagrees about version of symbol vfio_pin_pages nvidia_vgpu_vfio: Unknown symbol vfio_pin_pages (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_unpin_pages nvidia_vgpu_vfio: Unknown symbol vfio_unpin_pages (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_register_notifier nvidia_vgpu_vfio: Unknown symbol vfio_register_notifier (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_unregister_notifier nvidia_vgpu_vfio: Unknown symbol vfio_unregister_notifier (err -22) modinfo nvidia-vgpu-vfio filename: /lib/modules/3.10.0-957.27.2.el7.x86_64/weak-updates/nvidia-vgpu-vfio.ko version: 430.27 supported: external license: MIT rhelversion: 7.6 srcversion: 0A179A61A02AD500D05FB1A alias: pci:v000010DEd00000E00sv*sd*bc04sc80i00* alias: pci:v000010DEd*sv*sd*bc03sc02i00* alias: pci:v000010DEd*sv*sd*bc03sc00i00* depends: nvidia,mdev,vfio vermagic: 3.10.0-940.el7.x86_64 SMP mod_unload modversions My guess is that somewhere along the rhel/centos 7.6 lifecycle vfio module changed the vfio module and broke the compatibility. Nvidia provides those modules built against the BETA 7.6 release and assume weak-modules to make it work. Somehow it does not. Anybody got any suggestions how to handle this? I'm working on it with nvidia enterprise support but maybe one of you got there first? best regards -- Piotr Baranowski

1 0

[tc] meeting summary for aug. 8 2019
by Mohammed Naser 13 Aug '19

13 Aug '19

Hi everyone, The TC held it’s monthly meeting on the 8th of August 2019 and this email provides a summary of that meeting Jeremy Stanley (fungi) was added as TC Liaison for the Image Encryption pop-up team and their proposed resolution on proper retirement procedures was approved and merged. Swift is now working in Python 3 and inside DevStack so this puts us in a really good place to continue with Python 3 efforts in Swift. Graham Hayes (mugsie) is currently working on the code for the proposal bot so that when we cut a branch, it automatically pushes up a patch to add the ‘python3 jobs’ for that series. Thierry Carrez (ttx) organized the milestone 2 forum meeting with TC members. We have Jim Rollenhagen (jroll) and maybe Graham Hayes (mugsie) volunteering for the programming committee. The proposal for making goal selection a two-step process has been needing reviews for a while so I encourage the community to have a look at it as well as other TC members. We also talked about who’s attending the Shanghai Summit (here’s the Etherpad with the list of who’s going: https://etherpad.openstack.org/p/PVG-TC-PTG) and who will be attending the leadership meeting. We think that everybody already on the TC going to PTG will be there but we’ll only be able to know the exact number at the end of the election, so towards the end of September. We’re also thinking about starting a “Large Scale” SIG so people could collaborate in tackling more of the scaling issues together. Thierry Carrez (ttx) and I will be looking into that by mentioning the idea to LINE and YahooJapan (as some perspective at-scale operators)to see what they think and also make a list of organizations that could be interested. Rico Lin (ricolin) will also update the SIG guidelines documents to make the whole process easier and Jim Rollenhagen (jroll) will try and bring this up at Verizon Media. Finally, we talked about an issue regarding CI Maintainers associated with Cinder not maintaining their systems by not migrating them to Python 3.7. Half of those drivers will be deprecated since they still run on Python 2.7, which won’t be supported by the next ‘U’ release. Jay Bryant tried contacting them all individually but most didn’t answer (a lot of contact info isn’t up to date). If you know someone who maintains a Cinder driver in-tree, please have them double-check on this. I hope that I covered most of what we discussed, for the full meeting logs, you can find them here: http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-08-08-14.00.log.html 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

4 4

[ptl][release] Stepping down as Release Management PTL
by Tony Breeds 13 Aug '19

13 Aug '19

Hello all, I'm sorry to say that I have insufficient time and resources to dedicate to being the kind of PTL the community deserves. With that in mind I've asked if Sean has the time to see out the role for the remainder of the Train cycle and he's agreed. I have proposed https://review.opendev.org/675246 up update the governance repo. I'm not going any where but instead trying to take on less and do *that* better. Yours Tony.

6 9

[neutron] bug deputy report (the week of Aug 5)
by Akihiro Motoki 13 Aug '19

13 Aug '19

Hi neutrinos, I was a bug deputy for last week (Aug 5 to Aug 11). We got a few new bug last week. Two bugs are in the undecided state. https://bugs.launchpad.net/neutron/+bug/1834045 Live-migration double binding doesn't work with OVN New, Undecided, No assignee (in neutron) NOTE: 'neutron' was added to the affected projects last week. This is related to the double binding feature on non-agent based drivers like networking-ovn. networking-ovn already has a workaround for this. Is any further work needed in neutron side? More input would be appreciated. https://bugs.launchpad.net/neutron/+bug/1839658 "subnet" register in the DB can have network_id=NULL New, Undecided, Assigned to ralonsoh NOTE: I could not reproduce it yet. It looks like a corner case and more code investigation might be needed. The following new bugs have been fixed. - https://bugs.launchpad.net/bugs/1839595 Thanks, Akihiro

3 2

[glance] glance-cache-management hardcodes URL with port
by Bernd Bausch 13 Aug '19

13 Aug '19

Stein re-introduces Glance cache management, but I have not been able to use the glance-cache-manage command. I always get errno 111, connection refused. It turns out that the command tries to access http://localhost:9292. It has options for non-default IP address and port, but unfortunately on my (devstack) cloud, the Glance endpoint is http://192.168.1.200/image. No port. Is there a way to tell glance-cache-manage to use this endpoint? Bernd.

2 2

[neutron] QoS meeting cancelled today
by Slawek Kaplonski 13 Aug '19

13 Aug '19

Hi, As there is no agenda for today and Rodolfo is not available, today’s QoS meeting will be cancelled. Sorry for very late announcement of that :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[zaqar][requirements][tc][triple-o][tripleo] jsonschema 3.x and python-zaqarclient
by Dirk Müller 13 Aug '19

13 Aug '19

Hi, For a while the requirements team is trying to go through the process of removing the upper cap on jsonschema to allow the update to jsonschema 3.x. The update for that is becoming more urgent as more and more other (non-OpenStack) projects are going with requiring jsonschema >= 3, so we need to move forward as well to keep co-installability and be able to consume updates of packages to versions that depend on jsonschema >= 3. The current blocker seems to be tripleo-common / os-collect-config depending on python-zaqarclient, which has a broken gate since the merge of: http://specs.openstack.org/openstack/zaqar-specs/specs/stein/remove-pool-gr… on the server side, which was done here: https://review.opendev.org/#/c/628723/ The python-zaqarclient functional tests have not been correspondingly adjusted, and are failing for more than 5 months meanwhile, in consequence many patches for zaqarclient, including the one uncapping jsonschema are piling up. It looks like no real merge activity happened since https://review.opendev.org/#/c/607553/ which is a bit more than 6 months ago. How should we move forward? doing a release of zaqarclient using some implementation of an API that got removed server side doesn't seem to be a terribly great idea, plus that we still need to merge either one of my patches (one that makes functional testing non-voting or the brutal "lets drop all tests that fail" patch). On the other side, I don't know how feasible it is for Triple-O to drop the dependency on os-collect-config or os-collect-config to drop the dependency on zaqar. Any suggestion on how to move forward? TIA, Dirk

3 4

[tc] weekly update
by Mohammed Naser 13 Aug '19

13 Aug '19

Hi everyone, Here’s the weekly update for what happened in the Openstack TC. You can get more information by checking for changes in openstack/governance repository. # General changes - Changed the dates for the ‘U’ naming poll: https://review.opendev.org/#/c/674465/ - Rico Lin volunteered to be the naming poll coordinator instead of Tony Breeds: https://review.opendev.org/#/c/674494/ - Added a wiki link to the rpm-packaging project: https://review.opendev.org/#/c/673837/ - Updated policy regarding project retirements: https://review.opendev.org/#/c/670741/ 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

1 0

[charms] OpenStack Charms 19.07 release is now available
by Peter Matulis 12 Aug '19

12 Aug '19

The OpenStack Charms team is delighted to announce the 19.07 charms release. This release brings several new features and improvements, including some for existing releases (Queens, Rocky, Stein) and many stable combinations of Ubuntu and OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/1907.html == Highlights == * Percona Cluster Cold Start The percona-cluster charm now contains logic and actions to assist with operational tasks surrounding a database shutdown scenario. * DVR SNAT The neutron-openvswitch charm now supports deployment of DVR based routers with combined SNAT functionality, removing the need to use the neutron-gateway charm in some types of deployment. * Octavia Image Lifecycle Management A new octavia-diskimage-retrofit charm provides a tool for retrofitting cloud images for use as Octavia Amphora. * Nova Live Migration: Streamline SSH Host Key Handling The nova-cloud-controller charm has improved the host key discovery and distribution algorithm. This will make the addition of a nova-compute unit faster and the nova-cloud-controller upgrade-charm hook will be significantly improved for large deployments. == OpenStack Charms team == The OpenStack Charms development team can be contacted on the #openstack-charms IRC channel on Freenode. The team will also be represented at the Open Infrastructure Summit and PTG events in Shanghai (November, 2019). == Thank you == Huge thanks to the below 46 charm contributors who worked together to squash 48 bugs, to enable an entirely new charmed version of OpenStack, and to move the line forward on several key features! Frode Nordahl Chris MacNaughton David Ames Liam Young Alex Kavanagh James Page Corey Bryant Ryan Beisner Tytus Kurek Edward Hope-Morley Sahid Orentino Ferdjaoui Dmitrii Shcherbakov Rodrigo Barbieri Peter Matulis Ghanshyam Mann Jorge Niedbalski Nicolas Pochet Andrea Ieri Andreas Jaeger Zachary Zehring Trent Lloyd Tiago Pasqualini David Coronel Hua Zhang Ian Wienand Dan Ackerson Ramon Grullon George Kraft Alvaro Uria Michael Skalka Nikolay Vinogradov melissaml Nobuto Murata Andrew McLeod Frank Kloeker Tim Burke Cory Johns Marian Gasparovic sunnyve Felipe Reyes Pete Vander Giessen Ryan Farrell Mark Maglana Levente Tamas Alexander Litvinov Marcelo Subtil Marcal -- OpenStack Charms Team

1 0

[ironic] [sushy] Stepping down from Sushy core
by Debayan Ray 12 Aug '19

12 Aug '19

Hey all, it's not easy to send this email. With a heavy heart, I announce that I'll be stepping down from the Sushy core team effective today. Almost six months back, I left HPE and joined Oracle. Although earlier I thought of keeping out some time to dedicate to being an effective Sushy core reviewer, gradually I found those "spare" time very much elusive and near impossible to find. Now after all these years of working together, I really can't completely disassociate myself altogether. So you can expect me reviewing stuff from time to time and I will continue to follow Ironic and its projects and other interesting ones in OpenStack. Thanks, everyone for everything. It has been great, to say the least, to work with you all these years. Cheers! Debayan (deray)

2 1

[masakari] pacemaker-remote Setup Overview
by Teckelmann, Ralf, NMU-OIP 12 Aug '19

12 Aug '19

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

1 0

[ironic] Resuming having weekly meetings
by Julia Kreger 12 Aug '19

12 Aug '19

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

1 0

[swauth][swift] Retiring swauth
by Ondrej Novy 12 Aug '19

12 Aug '19

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ý

1 0

[tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA
by Chandan kumar 12 Aug '19

12 Aug '19

Hello, With os_tempest project, TripleO and Openstack Ansible projects started collaborating together to reuse the tools developed by each other to avoid duplicates and enable more collaboration. During Denver Train 2019 PTG, we decided to unifying the CI logs for both the projects by providing a unified experience to the developers while browsing the CI logs making sure we have a similar logs structure for both the projects, so that one can easily navigate through the logs without scratching the heads and also the logs tree structure should say what logs are present where. In TripleO, we have ansible-role-collect-logs[1.] role for the same and in OSA we have logs_collect.sh[2.] script for the same. But once the logs gets collected at each other projects, It is very hard to navigate and find out where is the respective files. A little about ansible-role-collect-logs roles: * A role for aggregating logs from different nodes * Provide a list for files to collect at one places in playbook [3] * Hyperlink the logs with description about log files * Once logs collection is done, it pushes to a particular log server For example, tempest.html or stestr_results.html is the common file for viewing tempest results. In TripleO, we keep it under logs folder but in OSA logs/openstack/aio1-utility/stestr_results.html. If a new user contributes to another project, he tries to follow the same pattern for find logs as he seen in current project. By Keeping the same structure at all places It would be easier. So moving ahead what we are going to do: * Refactor collect-logs role to pass defaults list of files at one place * Pass the list of different logs files based on deployment tools * Put system/containers related commands at one place * Replace the collect_logs.sh script with playbook in OSA and replace it. Thanks for reading, We are looking for the comments on the above suggestion. Links: [1.] https://opendev.org/openstack/ansible-role-collect-logs/ [2.] https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/l… [3.] https://opendev.org/openstack/tripleo-ci/src/branch/master/toci-quickstart/… Thanks, Chandan Kumar

4 4

[openstack-dev] [neutron] Propose Rodolfo Alonso for Neutron core
by Miguel Lavalle 11 Aug '19

11 Aug '19

Dear Neutrinos, I want to nominate Rodolfo Alonso (irc:ralonsoh) as a member of the Neutron core team. Rodolfo has been an active contributor to Neutron since the Mitaka cycle. He has been a driving force over these years in the implementation an evolution of Neutron's QoS feature, currently leading the sub-team dedicated to it. Recently he has been working on improving the interaction with Nova during the port binding process, driven the adoption of Pyroute2 and has become very active in fixing all kinds of bugs. The quality and number of his code reviews during the Train cycle are comparable with the leading members of the core team: https://www.stackalytics.com/?release=train&module=neutron-group. In my opinion, Rodolfo will be a great addition to the core team. I will keep this nomination open for a week as customary. Best regards Miguel

8 8

[nova-lxd] no one uses nova-lxd?
by Adrian Andreias 10 Aug '19

10 Aug '19

Hey, We were planing to migrate some thousand containers from OpenVZ 6 to Nova-LXD this fall and I know at least one company with the same plans. I read the message about current team retiring from the project. Unfortunately we don't have the manpower to invest heavily in the project development. We would however be able to allocate a few hours per month, at least for bug fixing. So I'm curios if there are organizations using or planning to use Nova-LXD in production and they have the know-how and time to contribute. It would be a pity if the the project dies. Cheers! - Adrian Andreias https://fleio.com

5 5