December 2019 - openstack-discuss

email alert settings are not applied (ask.openstack.org)
by Eugen Block 07 Dec '19

07 Dec '19

Hi all, I'm not really sure if this is the right place to ask but I'll try it anyway. I'm regularly checking ask.openstack.org for interesting questions and sometimes I comment and respond. In my profile I configured instant email notification if someone comments or responds to my questions/comments. But this has never worked properly, I think this worked just once two or three years ago, never again. The only setting that seems to work is the weekly notification about new questions. Can anyone comment on this? Should I try to change the email address and see if that works? Any insight is appreciated! Regards, Eugen

2 2

[horizon] Shanghai PTG recap
by Akihiro Motoki 07 Dec '19

07 Dec '19

Hi, I am summarizing the horizon PTG in Shanghai. One month passed from the PTG, but I believe the summary is still useful :-) Eight folks joined the session and we had productive discussions. Thanks all! - PTG etherpad https://etherpad.openstack.org/p/horizon-u-ptg - release priority etherpad https://etherpad.openstack.org/p/horizon-release-priorities [Priorities for Ussuri] After the PTG, we discussed the project priorities for Ussuri based on the PTG discussion and agreed the following as project priorities. We will cover them in the weekly team meetings. * High * Catch up the new policy mechanism * Bump and clean up Django versions * Error message refactoring * Medium * xstatic updates * ini-based-configuration * Chinese translation handling [PTG recap] * Train retrospective * To keep * We succeeded to restore integration tests in horizon and several plugins. They just cover basic GET scenarios. Most JS tests do not cover scenario testing so it would be a good step to avoid plugin breakage. * We can keep the project healthiness to some level regardless of the low number of contributors. * To improve * The bundle policy files in horizon is out of date from back-end services and there was no progress since Stein release. For example, the new policies (system scope, deprecated policies) from the keystone repo does not work with horizon. It should be priorities in Ussuri release. We will join the pop-up team for the policy enhancement. * Some community goal from queens has not completed. (Most of them have done.) * Supported versions of Django and Python * We discussed the plan to enable Django 2.2 (the current LTS) by default and drop Django 1.11 support. The current plan is to bump the default Django to 2.2 around milestone-1 and drop Django 1.11 support by milestone-2. The minimum goal is to support Django 2.2 as it will be the only LTS supported by Django community as of Ussuri release. * The version changes in Django may break horizon plugins so we need enough time to test them in real deployments. * Integration test coverage would help the transition of Django version and let's try integration tests more with our best. * X-Static updates * Many xstatic packages are not updated for long. They has has fixes including security fixes, so we need to update them. radomir volunteered for the effort. * JS loading * e0ne shared his experiences on his trial to implement a plugin using react. * The problem is that it is not easy to use newer JS libraries. An example of problmes with a current approach is https://review.opendev.org/#/c/652657/ * It comes from the gap between the xstatic way to use same versions for all JS applications and modern JS packaging like webpack. * There is no good conclusion in this topic, but a long-term goal would be to use modern packaging mechanism instead of xstatic. It could be an issue for distribution packagers. * Horizon plugins maintenance * This slot covered topics around horizon plugin ecosystem and their maintenance. * The main outcomes are: * we agreed to change the release model of horizon to cycle-with-intermediary. Horizon plugins use horizon as library and we need to release horizon promptly whenever we have changes which affect plugins. cycle-with-intermediary model would fit more for this purpose. * A concern on that multiple major version bump potentially happens was raised, but we agreed that the version number does not matter and the best practice to avoid this is to drop deprecated features at the beginning of the cycle. * horizon team asked individual project teams with horizon plugins to give +2 right to horizon cores to make plugin maintenance smooth. * Most team agreed and we had conversations with more team at the PTG. * One important note is that horizon team should shouldn’t merge anything to plugins without +2 from plugin team. * We will update our documentation to cover this change in the plugin maintenance and e0ne volunteered for it. * Some side-discussion happened. There was no decision but they might be worth considering in future. * An idea to split nova/cinder/neutron/keystone/.... support to plugins and make them mandatory dependencies. * Use of micro-frontend concept * Chinese translation handling * From horizon perspective we agreed that we would like to move to the new locale names (zh-hans/hant) both in horizon (+plugins). * The main questions are the transition plan and locales for documentations. Further discussion with the i18n team happened in Shanghai. The summary of the discussion will be coming soon, but the first step agreed is that the horizon team confirms the new locales work fine in horizon. * Feature Gaps * Brief discussions happened for features with volunteers. * We will visit the status of the gaps in the etherpad https://etherpad.openstack.org/p/horizon-feature-gap * Refactor Error Messages * We received a good number of bug reports which complain that horizon error messages are too general and hide error details. * We agree to show both error message summary (translated) and detail message from API. * An idea discussed is to have a collapsible box to show an error detail along with a summary message. This approach would bring us a good balance of translated message and error detail from back-end services. * It would be a nice improvement in Ussuri. * Deprecations and Removals * Short discussion covered potential feature deprecation and removals. * Cinder v2 support will be dropped soon. * ini-based-configuration * amotoki expressed that he continues the effort and hopefully completes it in Ussuri. * API versions of backend services * horizon uses the minimum microversions to communicate with back-end services unless new versions are required to support features. * The possibility to bump the minimum versions used (per cycle?) was discussed and we agreed to keep the current strategy considering dev resources and maintenance. * Adoption of openstacksdk was discussed. openstacksdk supports older APIs and it would help us keep the current strategy on API versions used. * To use openstacksdk, we need to explore how to instantiate keystonauth Auth object with a token (as horizon stores only token and does not store auth information). We can start the investigation on this and e0ne volunteered. That's all we discussed in Shanghai. I hope we will have good progress in Ussuri. Best Regards, Akihiro Motoki (irc: amotoki)

1 0

[ptl] Train cycle-trailing release deadline
by Sean McGinnis 06 Dec '19

06 Dec '19

Hello all, For those teams with cycle-trailing deliverables, this is a reminder to make sure to get your Train series deliverables released. We like to have all of those out within three months of the coordinated release. For reference, here is a list of deliverables we have marked as Train cycle-trailing in the releases repo that do not appear to have a final release: cinderlib kayobe kolla-ansible kolla-cli kolla openstack-ansible tripleo-ui If these, or any others, need to be added or changed for Ussuri, please propose a placeholder deliverable file under deliverables/ussuri or update any existing ones with any needed changes. Thanks! Sean

3 3

Rebooted VM disappears when HV lacks memory
by Albert Braden 06 Dec '19

06 Dec '19

2 4

[magnum][stein] broken pipe
by Ignazio Cassano 06 Dec '19

06 Dec '19

Hello, I installed magnum stein on centos 7 but magnum-api reports the following error in /var/log/messages: Dec 5 21:14:49 tst2-osctrl01 magnum-api: Traceback (most recent call last): Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 568, in process_request Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.finish_request(request, client_address) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 334, in finish_request Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.RequestHandlerClass(request, client_address, self) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__ Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.finish() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.wfile.close() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/socket.py", line 279, in close Dec 5 21:14:49 tst2-osctrl01 magnum-api: self.flush() Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib64/python2.7/socket.py", line 303, in flush Dec 5 21:14:49 tst2-osctrl01 magnum-api: self._sock.sendall(view[write_offset:write_offset+buffer_size]) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 401, in sendall Dec 5 21:14:49 tst2-osctrl01 magnum-api: tail = self.send(data, flags) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 395, in send Dec 5 21:14:49 tst2-osctrl01 magnum-api: return self._send_loop(self.fd.send, data, flags) Dec 5 21:14:49 tst2-osctrl01 magnum-api: File "/usr/lib/python2.7/site-packages/eventlet/greenio/base.py", line 382, in _send_loop Dec 5 21:14:49 tst2-osctrl01 magnum-api: return send_method(data, *args) Dec 5 21:14:49 tst2-osctrl01 magnum-api: error: [Errno 32] Broken pipe Anyone could help me please ? Regards Ignazio

1 0

[goals][Drop Python 2.7 Support] Week R-23 Update
by Ghanshyam Mann 06 Dec '19

06 Dec '19

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-23 week. We are in phase-1 which targets all the OpenStack services to drop the py2 support. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… NOTE: Phase-2 is for Library (including client library), QA tooling. Phase-3 is mainly for openstack/requirement and audit to all repo. (we can always adjust the schedule to make it smooth migration. For example, dropping a few testing jobs from phase-2/3 candidates if any cross-testing jobs are failing due to phase-1 candidates dropping the support[1].) Summary: ======= Patches to all services repo have been up for review[2]. The OpenStack services have not merged the py2 drop patches: * Adjutant * Barbican * Designate * ec2-api * Glance * Neutron * Freezer * Kolla * Monasca * Karbor * Congress * Telemetry * Storlets * Sahara * Blazar * Masakari * Placement * Heat (heat-dashboard patch is note merged ) * Tacker * Trove * Zaqar * Quinling * Manila * Tricircle * openstack-helm * python-openstackclient The OpenStack services dropped the py2 support: * Cinder * Nova * Ironic * Keystone * Octavia * Watcher * Vitrage * Zun * Winstackers * Mistral * Cyborg * Kuryr * Cloudkitty * Murano * Solum * Magnum * Senlin * Searchlight * openstack-ansible - I do not think we need any update in openstack-ansible? release notes jobs etc are already on py3. Rest all projects are targetted for phase-2 (after m-1). How you can help: ============== - Review the patches. Push the patches if I missed any repo targetted for phase-1. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011392… [2] https://review.opendev.org/#/q/topic:drop-py27-support -gmann

1 0

[release] Release countdown for week R-22
by Sean McGinnis 06 Dec '19

06 Dec '19

Development Focus ----------------- The Ussuri-1 milestone is next week, on December 12! Project team plans for the Ussuri cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Train release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Ussuri-1 milestone: December 12 (R-22 week)

1 0

[all][requirements][drop-py27-support] Requirements is dropping cross tests with projects that will be dropping support for python2.7 this cycle
by Matthew Thode 06 Dec '19

06 Dec '19

Hi all, The requirements project is dropping python2.7 cross tests we do for those projects that are also dropping python2.7 support this cycle. We are doing this as wel do not know when projects will drop support (neutron seems to have done so, cinder is soon as well). This was originally scheduled for later but need to be pushed up as we missed the dependency requirements has on those projects for cross jobs. Here's the review if you are curious :D https://review.opendev.org/697377 -- Matthew Thode

3 2

How Bank or Financial sector benefited from OpenStack ?
by Mobarak Hossain 06 Dec '19

06 Dec '19

Hi, I want to approach to Bank for Open Infrastructure . They are asking how a Bank get benefited from Open Infrastructure .Except open Source . Is there any special features for Bank . I saw a video that Amex is using . Is there suggestion for me please let me know . Thanks -- Mobarak Hossain

2 1

[OSSN-0085] Cinder configuration option can leak secret key from Ceph backend
by Brian Rosmaita 06 Dec '19

06 Dec '19

Cinder configuration option can leak secret key from Ceph backend --- ### Summary ### This vulnerability is present only when Cinder has a Ceph backend *and* the ``rbd_keyring_conf`` option in the Cinder configuration file is set. (The option is unset by default.) Under these circumstances, the keyring content may be leaked to a regular user. ### Affected Services / Software ### Cinder, Pike, Queens, Rocky, Stein, Train ### Discussion ### When the ``rbd_keyring_conf`` option is set, a user who creates a volume and then does a local attach of that volume using the Cinder REST API, may discover the keyring content for the Ceph cluster. (This does not apply to the normal Nova attach process. The user must contact the Cinder REST API directly for this exploit.) If this user then gains access to the Ceph cluster independently of Cinder, these credentials may be used to access any volume in the cluster. This issue was reported by Raphael Glon of OVH. NOTE: This issue is different from OSSA-2019-003, through which Ceph credentials could be leaked from the Nova REST API during error conditions, but we suggest you take this opportunity to review that security advisory and make sure your system has been updated or patched to address it: https://security.openstack.org/ossa/OSSA-2019-003.html ### Recommended Actions ### Any installation currently using the ``rbd_keyring_conf`` option should immediately stop using that option. In order for Cinder backups to continue working, the Ceph keyring secrets should be deployed directly on cinder-backup hosts in their standard location: /etc/ceph/<cluster_name>.client.<user_name>.keyring The ``rbd_keyring_conf`` is deprecated in the Ussuri release and will be removed early in the 'V' development cycle. There is no replacement planned for this functionality. ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0085 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1849624 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg

1 0