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

[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

[Security SIG] Weekly Newsletter Aug 08 2019
by Gage Hugo 10 Aug '19

10 Aug '19

Of note, OSSA-2019-003 was released this week #Week of: 08 Aug 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-08-08-1… - Announced OSSA-2019-003 release on Tuesday August 06th 2019 - Image Encryption Spec - image encryption spec for nova unlikely to get a freeze exception - Will likely polish it up, target an early 'U' release # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2019-003 was released this week: https://security.openstack.org/ossa/OSSA-2019-003.html

1 0

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

10 Aug '19

# Keystone Team Update - Week of 5 August 2019 ## News ### CI instability update To follow up from this topic from last week, we came up with a solution[1][2] that at least reduces the size of the unit test log files to an acceptable, non-browser-crashing size. Unfortunately that didn't seem to be the root cause of the frequent timeouts, so it's unclear (to me, at least) whether the issue stems from a problem in our unit tests or if we're just getting unlucky with noisy neighbors. It could be as simple as needing to raise the timeout to account for all the additional protection tests we've added in the past few months. [1] https://review.opendev.org/673932 [2] https://review.opendev.org/673933 ### Call for help We need help completing the system-scope and default roles policy updates[3][4] before the end of the cycle, as operators cannot safely enable [oslo_policy]/enforce_scope until all of them are completed. For the most part, the task involves updating the scope_types option in the policy and adding a ton of unit tests. The already completed work[5][6] can serve as an example for what's needed. [3] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles [4] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope [5] https://bugs.launchpad.net/keystone/+bugs?field.status%3Alist=FIXRELEASED&f… [6] https://bugs.launchpad.net/keystone/+bugs?field.status%3Alist=FIXRELEASED&f… ### PTG attendance and Forum Planning Based on our poll[7] it's looking like there are not enough keystone-minded people planning to attend the Shanghai PTG to warrant requesting a room, so I will likely tell Kendall that we don't need a room unless something changes very soon. Even if you won't be attending, please use that etherpad to add topics you would like to see discussed at the Forum. We can use those discussions as a jumping off point for our pre- and post-PTG virtual gatherings. [7] https://etherpad.openstack.org/p/keystone-shanghai-ptg ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. We will skip next week's office hours since we don't have a topic planned. 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 Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 9 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 43 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories - https://review.opendev.org/#/q/topic:bug/1818734 (system scope and default roles) - https://review.opendev.org/#/q/topic:implement-default-roles+is:open (system scope and default roles) - https://review.opendev.org/#/q/topic:bp/whitelist-extension-for-app-creds+i… (application credential access rules) - https://review.opendev.org/672120 (caching guide) - https://review.opendev.org/#/q/project:openstack/oslo.limit+topic:rewrite+i… (oslo.limit) * Needs Discussion - https://review.opendev.org/618144 (Reparent Projects) - https://review.opendev.org/674940 (Make policy deprecation reasons less verbose) - https://review.opendev.org/675303 (Allows LDAP extra attributes to be exposed to the end user) ## Bugs This week we opened 4 new bugs and closed 4. Bugs opened (4) Bug #1839393 (keystone:Low) opened by Matthew Thode https://bugs.launchpad.net/keystone/+bug/1839393 Bug #1839133 (keystone:Undecided) opened by Radosław Piliszek https://bugs.launchpad.net/keystone/+bug/1839133 Bug #1839441 (keystone:Undecided) opened by Jose Castro Leon https://bugs.launchpad.net/keystone/+bug/1839441 Bug #1839577 (keystone:Undecided) opened by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1839577 Bugs fixed (4) Bug #1773967 (keystone:High) fixed by Jose Castro Leon https://bugs.launchpad.net/keystone/+bug/1773967 Bug #1838592 (keystone:High) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1838592 Bug #1709344 (keystone:Low) fixed by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1709344 Bug #1837741 (oslo.policy:High) fixed by no one https://bugs.launchpad.net/oslo.policy/+bug/1837741 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Feature proposal freeze is NEXT WEEK (August 12-August 16). Spec implementations that are not submitted or still in a WIP state by the end of the week will need to be postponed until next cycle unless we agree on an exception. Code implementing system scope and default roles policy work will be accepted until feature freeze week (September 9-September 13). If you are able, please help by picking up some of these tasks[7][8] or helping to review them (thanks Vishakha for jumping on the endpoint groups policies!). Final release of non-client libraries is the week of September 2 which allows us about three weeks to both implement and review library changes needed for this cycle. [7] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles [8] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[cyborg] [release] Process to discontinue os-acc
by Nadathur, Sundar 10 Aug '19

10 Aug '19

Hi, 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. It needs to be discontinued. What is the process for doing that? A part of that is presumably to update or delete the os-acc release yaml [2]. What else is needed? [1] https://opendev.org/openstack/os-acc/ [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/train… Regards, Sundar

2 1

[ironic][ops] Taking ironic nodes out of production
by Arne Wiebalck 09 Aug '19

09 Aug '19

Dear all, One of the discussions at the PTG in Denver raised the need for a mechanism to take ironic nodes out of production (a task for which the currently available 'maintenance' flag does not seem appropriate [1]). The use case there is an unhealthy physical node in state 'active', i.e. associated with an instance. The request is then to enable an admin to mark such a node as 'faulty' or 'in quarantine' with the aim of not returning the node to the pool of available nodes once the hosted instance is deleted. A very similar use case which came up independently is node retirement: it should be possible to mark nodes ('active' or not) as being 'up for retirement' to prepare the eventual removal from ironic. As in the example above, ('active') nodes marked this way should not become eligible for instance scheduling again, but automatic cleaning, for instance, should still be possible. In an effort to cover these use cases by a more general "quarantine/retirement" feature: - are there additional use cases which could profit from such a "take a node out of service" mechanism? - would these use cases put additional constraints on how the feature should look like (e.g.: "should not prevent cleaning") - are there other characteristics such a feature should have (e.g.: "finding these nodes should be supported by the cli") Let me know if you have any thoughts on this. Cheers, Arne [1] https://etherpad.openstack.org/p/DEN-train-ironic-ptg, l. 360

5 7

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

09 Aug '19

This is the goal-5 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 5 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. If your project has patches with successful tests please help get them merged. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) 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 == Today I reached out to all PTLs who have projects with failing patches, to ask for their help with getting tests to pass. == 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, Corey

1 0

[sdk] Proposing Eric Fried for openstacksdk-core
by Monty Taylor 09 Aug '19

09 Aug '19

Hey all, I'd like to propose Eric Fried be made core on SDK. This is slightly different than a normal core proposal, so I'd like to say a few more words about it than normal- largely because I think it's a pattern we might want to explore in SDK land. Eric is obviously super smart and capable - he's PTL of Nova after all. He's one of the few people in OpenStack that has a handle on version discovery, having helped write the keystoneauth support for it. And he's core on os-service-types, which is another piece of client-side arcana. However, he's a busy human, what with being Nova core, and his interaction with SDK has been limited to the intersection of it needed for Nova integration. I don't expect that to change. Basically, as it stands now, Eric only votes on SDK patches that have impact on the use of SDK in Nova - but when he does they are thorough reviews and they indicate "this makes things better for Nova". So I'd like to start recognizing such a vote. As our overall numbers diminish, I think we need to be more efficient with the use of our human time - and along with that we need to find new ways to trust each other to act on behalf of the project. I'd like to give a stab at doing that here. Thoughts? Monty

9 9

[kolla][nova][cinder] Got Gateway-Timeout error on VM evacuation if it has volume attached.
by Eddie Yen 09 Aug '19

09 Aug '19

Hi everyone, I met an issue when try to evacuate host. The platform is stable/rocky and using kolla-ansible to deploy. And all storage backends are connected to Ceph. Before I try to evacuate host, the source host had about 24 VMs running. When I shutdown the node and execute evacuation, there're few VMs failed. The error code is 504. Strange is those VMs are all attach its own volume. Then I check nova-compute log, a detailed error has pasted at below link; https://pastebin.com/uaE7YrP1 Does anyone have any experience with this? I googled but no enough information about this. Thanks!

5 14