- openstack-discuss - lists.openstack.org

RE: High CPU utilization by systemd process || debian 8
by Md. Farhad Hasan Khan 07 Dec '19

07 Dec '19

Hi, Please help to solve this. Thanks/Rony From: Md. Farhad Hasan Khan [mailto:rony.khan@brilliant.com.bd] Sent: Saturday, December 7, 2019 11:55 AM To: 'OpenStack Discuss' Subject: High CPU utilization by systemd process || debian 8 Hi, We are observing high CPU utilization by systemd process. 100% CPU utilize by systemd process when no user is being logged in to the server but CPU utilization became 0% while any user logged in to the server. What cloud be possible reason behind this issue and solution? Log collected via login to the server via ssh or console: (0% CPU utilization) top -b -n 1 | grep systemd | grep 612 612 root 20 0 3386692 2.051g 4932 T 0.0 6.5 22029:26 systemd Log collected without login to the server : (100% CPU utilization) # ssh user(a)192.168.18.11 <mailto:user@192.168.18.11> top -b -n 1 | grep systemd | grep 612 user(a)192.168.18.11's <mailto:user@192.168.18.11's> password: 612 root 20 0 3386692 2.051g 4932 S 789.2 6.5 22031:31 systemd Please find the server information: lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release: 8.11 Codename: jessie uname -r 3.16.0-6-amd64 Thanks & B’Rgds, Rony

1 0

neutron-metadata-agent broken pipe
by Albert Braden 07 Dec '19

07 Dec '19

As our production cluster grows in size we are starting to have trouble with neutron-metadata-agent. After restarting it is happy for a minute and then it complains "2019-12-06 17:54:24.615 664587 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 11, greater than warning threshold: 10. There could be a leak. Increasing threshold to: 20" It increases the threshold a couple of times and then after increasing to 40 we start to see errors: 2019-12-06 17:55:10.119 664578 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe It looks like increasing the threshold to 40 fails because it keeps trying: 2019-12-06 17:55:17.452 664597 WARNING oslo_messaging._drivers.amqpdriver [-] Number of call queues is 21, greater than warning threshold: 20. There could be a leak. Increasing threshold to: 40 And the errors increase until the log is nothing but errors, and VMs fail to boot. root@us01odc-p02-ctrl1:~# tail -f /var/log/neutron/neutron-metadata-agent.log self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.664 664597 INFO eventlet.wsgi.server [-] 10.195.73.174,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 62.1517761 2019-12-06 17:59:23.756 664583 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 371, in _send_loop return send_method(data, *args) error: [Errno 32] Broken pipe 2019-12-06 17:59:23.757 664583 INFO eventlet.wsgi.server [-] 10.195.65.69,<local> "GET /latest/meta-data/instance-id HTTP/1.0" status: 200 len: 0 time: 63.0419171 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent [-] Unexpected error.: MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent Traceback (most recent call last): 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 89, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent instance_id, tenant_id = self._get_instance_and_tenant_id(req) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 162, in _get_instance_and_tenant_id 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ports = self._get_ports(remote_address, network_id, router_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 155, in _get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._get_ports_for_remote_address(remote_address, networks) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/cache_utils.py", line 116, in __call__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.func(target_self, *args, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 137, in _get_ports_for_remote_address 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent ip_address=remote_address) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 106, in _get_ports_from_server 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self.plugin_rpc.get_ports(self.context, filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/metadata/agent.py", line 72, in get_ports 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return cctxt.call(context, 'get_ports', filters=filters) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 173, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent time.sleep(wait) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent self.force_reraise() 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent six.reraise(self.type_, self.value, self.tb) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/neutron/common/rpc.py", line 150, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent return self._original_context.call(ctxt, method, **kwargs) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 179, in call 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=self.retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 133, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 584, in send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout, retry=retry) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 573, in _send 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent call_monitor_timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 459, in wait 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent message = self.waiters.get(msg_id, timeout=timeout) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in get 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 'to message ID %s' % msg_id) 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent MessagingTimeout: Timed out waiting for a reply to message ID 77551d4cf4394b7b9cdfad68c0be46e8 2019-12-06 17:59:23.776 664595 ERROR neutron.agent.metadata.agent 2019-12-06 17:59:23.778 664595 INFO eventlet.wsgi.server [-] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 521, in handle_one_response write(b''.join(towrite)) File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 462, in write wfile.flush() File "/usr/lib/python2.7/socket.py", line 307, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 390, in sendall tail = self.send(data, flags) File "/usr/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 384, in send return self._send_loop(self.fd.send, data, flags) What's causing this? Are we overloading RMQ?

1 0

[nova][ironic] Changing an owner of a provisioned node
by Matt Riedemann 07 Dec '19

07 Dec '19

The 1.50 microversion [1] in the ironic API added the "owner" field to the node and I'm trying to use that to add some scheduler filtering in nova [2]. It's my understanding that the owner field on a provisioned node (instance_uuid on the node is set) can be changed, but I'm surprised that is allowed. Was that an oversight in developing that feature? The use case for the scheduler filter is baremetal nodes are owned by different (non-admin) projects in a deployment. When a non-admin project creates a baremetal server via nova, nova will filter out nodes that are not owned by the project (based on the node.owner field). If a node isn't owned by any project, only admins can use it. Admins also have access to all nodes regardless of owner. Given that, let's say user 1 from project A creates a server on nova X that is owned by project A (node.owner=A). Then the node.owner is changed to project B. What should happen? Should nova detect that ownership change and stop the node or something? Note that with other resources that can transfer ownership, like volumes, that can only be done when they aren't in use. So why don't we have the same rules for nodes? Assuming we do want to enforce this in the API (a 409 response when trying to change the owner on a provisioned node), how would that be done given this is a problem since 1.50 which was added in Stein? Would a policy rule be added to ironic to determine if someone can change the owner on a provisioned node and if so, what would be the default rule? The same as "baremetal:node:update" (rule:is_admin)? [1] https://docs.openstack.org/ironic/latest/contributor/webapi-version-history… [2] https://blueprints.launchpad.net/nova/+spec/ironic-tenant-filter -- Thanks, Matt

3 3

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

06 Dec '19

Hi Sean, I didn't want to mess with prod configs but shelve/unshelve works. Thanks for your advice! -----Original Message----- From: Sean Mooney <smooney(a)redhat.com> Sent: Friday, December 6, 2019 3:53 AM To: Albert Braden <albertb(a)synopsys.com>; openstack-discuss(a)lists.openstack.org Subject: Re: Rebooted VM disappears when HV lacks memory On Fri, 2019-12-06 at 02:22 +0000, Albert Braden wrote: > Update: It looks like attempting to migrate any VM, alive or dead, from an oversubscribed hypervisor throws the same > error. Maybe I should have done the migrations before setting cpu_allocation_ratio and ram_allocation_ratio. > > Is there a way to recover from this besides deleting VMs from the oversubscribed hypervisors? you could tempoerally set the allocation ratio higher to allow the vm to boot then try migrating it again. you could also maybe try shelving the vm, waiting for ti to be shelve offloaded then unshelve it. > > -----Original Message----- > From: Albert Braden > Sent: Thursday, December 5, 2019 6:08 PM > To: openstack-discuss(a)lists.openstack.org > Subject: RE: Rebooted VM disappears when HV lacks memory > > We changed cpu_allocation_ratio and ram_allocation_ratio to 1 on the hypervisors. Now I'm trying to clean up the mess. > > I'm trying to cold-migrate dead VMs from an oversubscribed hypervisor, but they are failing to migrate: > > root@us01odc-p02-ctrl1:~# os hypervisor list --long|grep hv199 > > 218 | us01-p02-hv199.internal.synopsys.com | QEMU | 10.195.54.226 | up | 138 | 80 > > | 1122304 | 772691 | > > root@us01odc-p02-ctrl1:~# openstack server migrate fc250e76-4ca5-44b1-a6a0-8a7c7ad48c24 > No valid host was found. No valid host found for cold migrate (HTTP 400) (Request-ID: req-cc048221-abaf-4be0-bc90- > f28eecec3df5) > > But we have lots of hosts with space, and if I build a new VM with the same flavor it works. When I check the logs, it > appears that the migration fails because the hypervisor we are moving from is oversubscribed: > > /var/log/nova/nova-conductor.log:2019-12-05 17:30:17.163 48989 WARNING nova.scheduler.client.report [req-cc048221- > abaf-4be0-bc90-f28eecec3df5 5b288691527245bda715ab7744a193e9 deea2d8541f741eda6fb0d242d16bb23 - default > 824941b2ad6a43d7984fab9390290f18] Unable to post allocations for instance 87608240-1ad2-45fc-b4f0-c118e3bf0262 (409 > {"errors": [{"status": 409, "request_id": "req-e56d29f8-c97e-41ac-8481-0598f3c681b2", "detail": "There was a conflict > when trying to complete your request.\n\n Unable to allocate inventory: Unable to create allocation for 'MEMORY_MB' on > resource provider 'fde477cd-fd3d-4296-838c-f9c54b3e97ef'. The requested amount would exceed the capacity. ", "title": > "Conflict"}]}) > > 'fde477cd-fd3d-4296-838c-f9c54b3e97ef' is the UUID of hv199: > > root@us01odc-p02-ctrl1:~# curl -s -X GET -H "X-Auth-Token: $token" -H "Content-Type: application/json" " > http://us01odc-p02-lb.internal.synopsys.com:28778/resource_providers/fde477…";echo > {"generation": 40, "uuid": "fde477cd-fd3d-4296-838c-f9c54b3e97ef", "links": [{"href": "/resource_providers/fde477cd- > fd3d-4296-838c-f9c54b3e97ef", "rel": "self"}, {"href": "/resource_providers/fde477cd-fd3d-4296-838c- > f9c54b3e97ef/inventories", "rel": "inventories"}, {"href": "/resource_providers/fde477cd-fd3d-4296-838c- > f9c54b3e97ef/usages", "rel": "usages"}], "name": "us01-p02-hv199.internal.synopsys.com"} > > What am I doing wrong? Do I need to move the live VMs away from hv199 to make room for the dead ones? > > > > -----Original Message----- > From: Sean Mooney <smooney(a)redhat.com> > Sent: Wednesday, December 4, 2019 4:30 AM > To: Albert Braden <albertb(a)synopsys.com>; openstack-discuss(a)lists.openstack.org > Subject: Re: Rebooted VM disappears when HV lacks memory > > On Wed, 2019-12-04 at 00:51 +0000, Albert Braden wrote: > > We are running Rocky and we have the allocation bug because we set cpu_allocation_ratio and ram_allocation_ratio to > > 1 > > on the controllers but not on the hypervisors, so the hypervisors are oversubscribed. When we try to reboot a VM > > when > > the HV is short memory, the VM is deleted from the HV. It still exists in Openstack but not on the HV. Is it > > possible > > to recover a VM from this state? > > so the vm is likely not deleted the harddisk and the libvirt domain will still be defiend. my guess is starting the > vm cause the oom reaper to kill the qemu process when it was relaunched. > > if you are deploying with memory over subsription enabled you should configre enough swap space equal to total > memory* ram_allocation_ratio. > > if you do that you you should be able to start the vm. now the other option is while the vm is stopped you can > cold migrate it to another host and then start it there.

1 0

openstack volume snapshots and deleting
by Ratliff, John 06 Dec '19

06 Dec '19

If I create a volume, snapshot it, and create a new volume from that snapshot, I cannot seem to delete the snapshot until the volume is deleted. Is this intentional, or am I doing something wrong? Is the new volume based on the snapshot, and that's why I can't delete it? We're using CEPH as a storage backend if that makes a difference. openstack volume snapshot create -volume base-volume base-ss openstack volume create -snapshot base-ss new-volume openstack volume snapshot delete base-ss The last command is the one that fails. It gives no error message. It just doesn't actually delete the snapshot. But If I do this: openstack volume delete new-volume openstack volume snapshot delete base-ss Then it works. I also tried creating a snapshot, creating a volume from the snapshot, then creating a volume from that volume, but I still cannot delete the snapshot until both volumes are deleted. I do not want everlasting snapshots, so I hope I'm doing something wrong that someone can point out. Thanks. --John

3 6

openstack cli server stop command
by Ratliff, John 06 Dec '19

06 Dec '19

Does the openstack server stop command do an ACPI shutdown or does it do the equivalent of pulling the power plug? I want to know if it's safe to run this command rather than logging into the machine and running shutdown (for say a RHEL7 instance). If it does an ACPI shutdown, what happens if the machine doesn't respond? Is there a command to force the machine off? Thanks. --John

2 2

[nova][cinder][ops] question/confirmation of legacy vol attachment migration
by Matt Riedemann 06 Dec '19

06 Dec '19

Hello Cinderinos, I've now got a working patch that migrates legacy volume attachments to new style v3 attachments [1]. The fun stuff showing it working is in this paste [2]. We want to do this data migration in nova because we still have a lot of compatibility code since Queens for pre-v3 style attachments and we can't remove that compatibility code (ever) if we don't first make sure we provide a data migration routine for operators to roll through. So for example if this lands in Ussuri we can can enforce a nova-status upgrade check in V and rip out code in X. Without digging into the patch, this is the flow: 1. On nova-compute restart, query the nova DB for instances on the compute host with legacy volume attachments. 2. For each of those, create a new style attachment with the host connector and update the BlockDeviceMapping information in the nova DB (attachment_id and connection_info). 3. Delete the existing legacy attachment so when the server is deleted the volume status goes back to 'available' due to proper attachment reference counting in the Cinder DB. My main question is on #3. Right now I'm calling the v3 attachment delete API rather than the v2 os-terminate_connection API. Is that sufficient to cleanup the legacy attachment on the storage backend even though the connection was created via os-initialize_connection originally? Looking at the cinder code, attachment_delete hits the connection terminate code under the covers [3]. So that looks OK. The only thing I can really think of is if a host connector is not provided or tracked with the legacy attachment, is that going to cause problems? Note that I think volume drivers are already required to deal with that today anyway because of the "local delete" scenario in the compute API where the compute host that the server is on is down and thus we don't have a host connector to provide to Cinder to terminate the connection. So Cinder people, are you OK with this flow? Hello Novaheads, Do you have any issues with the above? Note the migration routine is threaded out on compute start so it doesn't block, similar to the ironic flavor data migration introduced in Pike. One question I have is if we should add a config option for this so operators can enable/disable it as needed. Note that this requires nova to be configured with a service user that has the admin role to do this stuff in cinder since we don't have a user token, similar to nova doing things with neutron ports without a user token. Testing this with devstack requires [4]. By default [cinder]/auth_type is None and not required so by default this migration routine is not going to run so maybe that is sufficient? Hello Operatorites, Do you have any issues with what's proposed above? [1] https://review.opendev.org/#/c/549130/ [2] http://paste.openstack.org/show/781063/ [3] https://github.com/openstack/cinder/blob/410791580ef60ddb03104bf20766859ed9… [4] https://review.opendev.org/#/c/685488/ -- Thanks, Matt

5 10

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

06 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 06 Dec '19

06 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 05 Dec '19

05 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 05 Dec '19

05 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 05 Dec '19

05 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 05 Dec '19

05 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 05 Dec '19

05 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 05 Dec '19

05 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

What's the best recommendation of cache solution for Openstack services?
by 양유석 05 Dec '19

05 Dec '19

Hi, stackers. I wonder how other system deal with the problem we encountered. Any advice would be appreciated. He had a over 1000 hypervisors and hit some connection bottleneck in a DB. The DB instance handle all Openstack services (nova, neutron, cinder, glance ...) Also, we have some additional systems (kubernetes, consul...) which periodically request openstack API. Since most of request from additional systems is READ, I am trying to find cache approach for Openstack service. Although some services like keystone has their own caching layer, I could not find general solutions. Is there any project to solve this problem (reduce DB overhead in a lot of read overhead) I found oslo.cache only provide decorator for a function, so wonder there is any service level approach. Thanks

2 1

DHCP timeout when creating instances for specific tenants
by Grant Morley 05 Dec '19

05 Dec '19

Hi all, I wonder if anyone can help shed any light on an odd issue we are seeing with only a couple of specific tenants. Basically if they launch an instance they are taking about 5 minutes to launch rather than our usual 30 second or so launch. We are seeing the following on the instance logs: https://pastebin.com/hDstsd8G Weirdly it only seems to be happening for 1 or 2 new tenants. I have tested this on our personal account and a few other customers have tested and their instances launch really quickly as expected. Is there anything specific during the tenant creation that can cause this issue? Or are there any logs in nova / neutron I should be looking out for that might shed some light? I haven't seen anything that is obvious. Any help would be much appreciated as we are a little stumped at the moment. Many thanks, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

4 8

[neutron] Proposing Jakub Libosvar as Neutron core reviewer
by Slawek Kaplonski 05 Dec '19

05 Dec '19

Hi neutrinos, We already started process of migrating networking-ovn driver to be one of in-tree neutron drivers. Blueprint for that is [1]. As part of this process I today proposed to include networking-ovn-core group into neutron-core group. Mail about it can be found at [2]. One of persons in networking-ovn-group is Jakub Libosvar who was Neutron core for very long time in the past. He knows very well not only ovn related code but also have great knowledge about all Neutron code base. So I would like to propose to Jakub as Neutron core reviewer again as he will be back working on neutron again now, after ovn will be in-tree driver. What do You think about it? I will wait for Your opinions for 1 week from now. Thx for all Your comments about it. [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011240… — Slawek Kaplonski Senior software engineer Red Hat

7 7

[heat][heat-translator] add Hiroyuki Jo to heat-translator core reviewer
by Rico Lin 05 Dec '19

05 Dec '19

Hi all Hiroyuki Jo has been active in the past few months. Also, he raises his willingness to help maintain patches in the last PTG [1]. It's my pleasure to add Hiroyuki Jo to heat-translator-core team with condition that me and other core members should help to review his patch (so no self-approval) and provide review guideline if needed. Free feel to suggest otherwise. [1] https://etherpad.openstack.org/p/PVG-heat -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

Swedish University Engagement Program
by Kendall Nelson 05 Dec '19

05 Dec '19

Hello Everyone! During the PTG, I talked to Kim Hindhart (along with Ildiko Vancsa, Sean McGinnis, and Victoria Martinez de la Cruz) about a program he was working on with several universities in Sweden (Blekinge Institute of Technology, Uppsala University, and KTH Royal Institute of Technology) to get students involved in open source, specifically involved in OpenStack. While this program is still getting off the ground, with its first round to start in this coming February with students working on Horizon (led by Kim), we are hoping to collect work for the second round that will be more student driven. The only disclaimer is that items suggested might not get picked up until the fall semester in September. I am collecting low-hanging-fruit here on this etherpad[1].Hopefully you have a lot of things tagged as such on Launchpad/StoryBoard already and can easily add those links to the etherpad. Can't wait to see what we can come up with! -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/swedish-university-program-work

1 0

[tripleo][ppc64le] Unexpected Return Code from TripleO Container Build Playbooks on ppc64le
by Adam Kimball 04 Dec '19

04 Dec '19

Hello all, Mike Turek and I have been working to get a ppc64le job to build tripleo containers for quite some time now. A few weeks back, we stumbled into a strange issue where the containers build job was issuing a return code 1, despite all containers successfully building. This has largely blocked our ability to push containers up to docker hub or report success through the delorean API. We've been pushing a number of patches to expand the logging of both our job, and the tripleo playbooks themselves, to get a better idea of what's going on. The most recent was a patch to show which containers have python futures that have been throwing exceptions, and why. [1] The end result of this seems to be that a number of jobs are reporting as incomplete. An example of this can be seen at timestamp 20:16:07 of an example build log. [2] However, upon checking the list of successfully built containers [3], or the RDO registry itself [4], one can see that the containers producing job not complete errors have actually built, and are being uploaded. The error log generated by the tripleo playbooks is also empty. [5] At this point, we're wondering what the path forward is. It seems like the issue stems from some unintended behavior in the tripleo playbooks themselves, not anything from our job. We're trying to figure out if this behavior is something that should be preventing us from reporting successful builds, and if so, how it can be fixed. Thanks, Adam Kimball [1] - https://review.opendev.org/#/c/695723/ [2] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master… [3] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master… [4] - https://console.registry.rdoproject.org/registry [5] - https://centos.logs.rdoproject.org/tripleo-upstream-containers-build-master…

2 1

[cinder] Ussuri Shanghai and Virtual PTG update
by Brian Rosmaita 04 Dec '19

04 Dec '19

The PTG summary document has been updated with a quick synopsis of what we discussed at the Virtual PTG last week: https://wiki.openstack.org/wiki/CinderUssuriPTGSummary All sessions (both Shanghai and Virtual) were recorded. The above page contains links to the recordings, which you can also find on the Cinder YouTube channel. Please look through the summary document to remind yourself about any actions you volunteered for. Additionally, there's an etherpad of unclaimed action items if you're looking for something to do: https://etherpad.openstack.org/p/cinder-ussuri-ptg-actions Thanks to everyone who participated in the PTG events. cheers, brian

1 0

[manila] Remote-only PTG poll
by Goutham Pacha Ravi 04 Dec '19

04 Dec '19

Hey Zorillas* and interested Stackers, (* manila contributors in the wild) A part of our community will be attending the Summit+Forum+PTG in Shanghai in a couple of weeks. However, we haven't figured out a way to enable remote participation during our PTG (Wednesday, 6th Nov 2019 between 9:00 AM and 4:30 PM) there. So, as discussed during our weekly meeting, I'd like to take a poll of when you would like to gather for a remote PTG that would supplement the gathering in Shanghai. Please take this poll and indicate your availability: https://xoyondo.com/dp/qQbsoHtNhi4DCki The prospective date for this meeting is between 2nd Dec and 13th Dec (Ussuri-1 Milestone is on 12th Dec). The meeting time will be 15:00 UTC to 22:00 UTC. This time may not work for our contributors in the Far East (APAC), but I'm hoping we'll address them primarily at the Shanghai get together, and relay their thoughts here. We will also be recording the entire meeting and will share notes on these lists. Thanks, Goutham

1 1

DHCP timeout when creating instances for specific tenants
by Grant Morley 04 Dec '19

04 Dec '19

Hi all, I wonder if anyone can help shed any light on an odd issue we are seeing with only a couple of specific tenants. Basically if they launch an instance they are taking about 5 minutes to launch rather than our usual 30 second or so launch. We are seeing the following on the instance logs: https://pastebin.com/hDstsd8G Weirdly it only seems to be happening for 1 or 2 new tenants. I have tested this on our personal account and a few other customers have tested and their instances launch really quickly as expected. Is there anything specific during the tenant creation that can cause this issue? Or are there any logs in nova / neutron I should be looking out for that might shed some light? I haven't seen anything that is obvious. Any help would be much appreciated as we are a little stumped at the moment. Many thanks, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

1 0

[neutron] api performance at scale
by Erik Olof Gunnar Andersson 04 Dec '19

04 Dec '19

Is there a SIG or similar discussion on neutron performance at scale? For us nova used to be the biggest concern, but a lot of work has been done and nova now performers great. Instead we are having issues to get Neutron to perform at scale. Obvious calls like security groups are performing really poorly, and nova-compute defaults for refreshing the network cache on computes causes massive issues with Neutron. Best Regards, Erik Olof Gunnar Andersson

3 5

[horizon] [plugins] Supported Django version for horizon in Ussuri
by vishal manchanda 04 Dec '19

04 Dec '19

Hello Everyone, As discussed at this weekly meeting[1] and Shanghai PTG[2], Horizon team is going to bump default version of Django to the next LTS release which is 2.2. Django 2.2 support is already added in Horizon and all its plugins [3]. Thanks to all for taking this at the priority and quick approvals on the patches. After Switching the default version of Django to 2.2(latest LTS), We will drop Django 1.11 in the next step(as its extended supports ending soon [4]). Also, Horizon usually supports LTS version of Django[5]. Please find below plan for coming weeks: Step 1: Switch the default version to Django 2.2 in upper-constraints till milestone-1. Additionally, Due to these changes, there might be a possibility of potential risks. Horizon and horizon plugins already support Django 2.2 as unit tests, but they are not tested in the real deployments with Django 2.2. So After switching the default version, if anything breaks we will keep working on fixing those issues. Step 2: Drop Django 1.11 during milestone-2. In case of any issue, please feel free to reach-out to Horizon channel #openstack-horizon. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstac… [2] https://etherpad.openstack.org/p/horizon-u-ptg#45 [3] https://review.opendev.org/#/q/topic:django22+(status:open+OR+status:merged) [4] https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ [5] https://docs.openstack.org/horizon/latest/contributor/policy.html#django-su… [6] https://docs.djangoproject.com/en/2.2/releases/2.2/ cheers, Vishal Manchanda

1 0

[glance] [glance_store] requirements-check job fails
by Naohiro Sameshima（鮫島直洋）(Group) 04 Dec '19

04 Dec '19

Hi, I'm Naohiro. I proposed a blueprint [0] (revive s3 driver) in Shanghai PTG and then create a patch [1]. So, I submit a patch in gerrit code review, but unfortunately one of zuul job (requirements-check) failed [2]. I think it seems that doc/requirements.txt is wrong. (Not included in my patch) Error log is below. ~~~~~~~~~~~~~~~~~~~~ Validating doc/requirements.txt WARNING: possible mismatch found for package "sphinx" Attribute "markers" does not match "" does not match "python_version>='3.4'" Requirement(package='sphinx', location='', specifiers='!=1.6.6,!=1.6.7,>=1.6.2', markers='', comment='# BSD', extras=frozenset()) Requirement(package='sphinx', location='', specifiers='!=1.6.6,!=1.6.7,!=2.1.0', markers="python_version>='3.4'", comment='# BSD', extras=frozenset()) WARNING: possible mismatch found for package "sphinx" Attribute "markers" does not match "" does not match "python_version=='2.7'" Requirement(package='sphinx', location='', specifiers='!=1.6.6,!=1.6.7,>=1.6.2', markers='', comment='# BSD', extras=frozenset()) Requirement(package='sphinx', location='', specifiers='!=1.6.6,!=1.6.7,<2.0.0', markers="python_version=='2.7'", comment='# BSD', extras=frozenset()) ERROR: Could not find a global requirements entry to match package sphinx. If the package is already included in the global list, the name or platform markers there may not match the local settings. ~~~~~~~~~~~~~~~~~~~~ Or is above job failing because of my patch? Thank you. Naohiro Sameshima [0]: https://review.opendev.org/#/c/687390/ [1]: https://review.opendev.org/#/c/695844/ [2]: https://zuul.opendev.org/t/openstack/build/4aef8abff3374613ab413aca0ab65381 This email and all contents are subject to the following disclaimer: https://hello.global.ntt/en-us/email-disclaimer

2 2

[tc] Meetings: Agenda for december 2019 and new date for January 2020
by Jean-Philippe Evrard 04 Dec '19

04 Dec '19

Hello everyone, Our next meeting is happening tomorrow 5 december, and the agenda is... still on the wiki. If you want it's also a little below [1]. I want to also highlight that the January 2020 meeting is happening on Thursday 16 instead of the first Thursday as usual. Regards, Jean-Philippe Evrard (evrardjp) [1]: Agenda for this meeting: Follow up on past action items: ricolin: (refresh) Follow up with SIG chairs about guidelines https://etherpad.openstack.org/p/SIGs-guideline ttx: (refresh) contact interested parties in a new 'large scale' sig (help with mnaser, jroll reaching out to verizon media) New initiatives and/or report on previous initiatives: gmann: report on the community goals for U and V, py2 drop, and goal select process schedule. anyone to help gmann? mnaser: sync up with swift team on python3 migration ricolin: report on multi-arch sig and other sigs ttx: Technical vision reflection update mnaser: Summary of the maintain issue with Telemetry mnaser: report oslo metrics project jungleboyj: update on the blog post about the analysis of the Foundation user survey mugsie: release naming progress mnaser: report on the infra liaison -- what's happening with the static hosting ttx: merge tc/uc update evrardjp: concepts repo addendums: gmann: define goal select process schedule -- is the current state clear? evrardjp: Patches pending mnaser: Summary of the stable branch policy discussion since the summit

1 0

[scientific-sig] IRC meeting today - unified limits for mixed baremetal/virt
by Stig Telfer 04 Dec '19

04 Dec '19

Hi All - We have a Scientific SIG IRC meeting at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_December_4th_2019 We’d like to discuss an update on unified limits, and how that will enable useful capabilities such as enforcing quotas across mixed environments - virtual, baremetal, GPUs, etc. Cheers, Stig (oneswig)

1 0

[Watcher] No IRC meeting today
by licanwei 04 Dec '19

04 Dec '19

1 0

Add functionality to Swift
by Anmar Salih 04 Dec '19

04 Dec '19

Hey, I have four containers in Openstack Swift. One of the containers called "Cont1", and I am using the web browser to upload and download objects to/from Cont1. I need to add a script that runs each time someone downloads an object from the container Cont1. Let's say I want Swift to execute a small script every time someone clicks on the Download button. Wondering if that possible? Where I should add the code. I cloned Swift Stein git on my local machine but not sure where to add my script. Take a look at the attached image, to the very right there is a download button for object1. So when someone clicks on that button, I want to execute a small script, then after executing the script, Swift will start to download object1. https://imgur.com/cCZIJqR Note: I need to add functionality to Swift, so when someone requests an object download, swift will take an action based on the container name. Best Regards. Anmar Salih

1 0

Thread on OpenDev Independence and Governance
by Clark Boylan 03 Dec '19

03 Dec '19

Hello, I wanted everyone to be aware of this thread [0] at openstack-infra(a)lists.openstack.org that I've started to formalize OpenDev's future independence and governance. Currently the infra team is formally an OpenStack project, but we think that we'll be better able to serve our non OpenStack users if the OpenDev aspects of this team become independent with its own governance. We are more than happy to hear feedback so please read this thread and respond if the topic interests you. Note, I'm using this pointer thread in an effort to avoid cross posting and losing feedback. It would be great if people can respond to the original on openstack-infra@lists. [0] http://lists.openstack.org/pipermail/openstack-infra/2019-December/006537.h… Thank you, Clark

1 0

[neutron][nova] Rootwrap daemon and privsep
by Arnaud Morin 03 Dec '19

03 Dec '19

Hey, If I believe both the nova and neutron documentation: https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.us… https://docs.openstack.org/neutron/latest/configuration/neutron.html#agent.… At scale, we are supposed to enable the rootwrap-daemon option. I have issues enabling that, but before going further on my issue, I'd like to understand the difference with privsep daemon. Is privsep a new daemon which is supposed to replace the rootwrap one? Is privsep being launch after rootwrap? IS privsep enabled by default, so I should not care about rootwrap at all? I'd like to understand more about that. Everything I try to find on popular search engine seems outdated, so if someone could give me a hand on finding the good page to understand that, I'l love it :p Cheers, -- Arnaud Morin

3 7

[Thirdparty CI] Thirdparty CI Site is down
by Rajini.Karthik＠Dell.com 03 Dec '19

03 Dec '19

The thirdparty CI site is down http://ciwatch.mmedvede.net/project?project=ironic&time=7+days, no results are displayed. Anyone has any insights? Thanks Rajini

2 1

[cinder] weekly meeting change reminder
by Brian Rosmaita 03 Dec '19

03 Dec '19

This is a quick reminder that this week's Cinder meeting will be held as usual on Wednesday, but: new time: 1400 UTC new channel: #openstack-meeting-4 See you there! brian

1 0

[kolla][cinder][glance][ceph] Corrupt image while downloading from Ceph
by Giuseppe Sannino 03 Dec '19

03 Dec '19

Hi community, need your help. *>>> Background <<<* I'm using kolla-ansible 8.0.0 to deploy a 1+3 "Stein" cluster. Ceph is used as backend. The configuration is a bit peculiar. The control runs on a VM hosted in a separate network compared to the one where the baremetal servers hosting the OS Compute services are. On the Compute Hosts, we have the following services: glance_api neutron_metadata_agent neutron_l3_agent neutron_dhcp_agent neutron_openvswitch_agent openvswitch_vswitchd openvswitch_db nova_compute nova_libvirt nova_ssh cinder_backup cinder_volume chrony cron kolla_toolbox fluentd Services APIs and Authentication run on the controller. In a standard "lab configuration" everything works fine. *>>> Fault Scenario <<<* We are trying to verify possible issues (and the way to work around them) in case latency between Controller and Compuite increases. And we have found one quite fast. Basically, if you try to create a volume from a RAW image (stored in Ceph) it will fail. >From glance-api.log on the controller: 2019-12-03 16:00:11.840 27 INFO eventlet.wsgi.server [req-225aae45-ad93-40f5-835d-027f93e3307d 615252134b844dbeb7acc34219e431e6 0049baebd0f742de915b11ec18509803 - default default] Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/wsgi.py", line 572, in handle_one_response write(b''.join(towrite)) File "/var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/wsgi.py", line 518, in write wfile.writelines(towrite) File "/usr/lib64/python2.7/socket.py", line 334, in writelines self.flush() File "/usr/lib64/python2.7/socket.py", line 303, in flush self._sock.sendall(view[write_offset:write_offset+buffer_size]) File "/var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/greenio/base.py", line 401, in sendall tail = self.send(data, flags) File "/var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/greenio/base.py", line 395, in send return self._send_loop(self.fd.send, data, flags) File "/var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/greenio/base.py", line 382, in _send_loop return send_method(data, *args) error: [Errno 104] Connection reset by peer >From the cinder-volume.log on the computes: : 019-12-03 16:00:15.932 34 ERROR oslo_messaging.rpc.server None, None) 2019-12-03 16:00:15.932 34 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/image/image_utils.py", line 410, in fetch 2019-12-03 16:00:15.932 34 ERROR oslo_messaging.rpc.server reason=reason) 2019-12-03 16:00:15.932 34 ERROR oslo_messaging.rpc.server ImageDownloadFailed: Failed to download image 6e7bb902-917e-4c9e-ba9f-3ee811a2502a, reason: IOError: 32 Corrupt image download. Hash was 88b062103e34c9824d7172afaa9a80befd00e1bef86d16a362572f01bd887a0551c188e98526eecdeedca262d3364175d384352c10d203bdb6a5b87b0593f231 expected adc29d5ce6129337e1e9bf00cc3f0798682c021c6f1a0aab46213438a6de8c6b027180389aa21196e7f708214815221a9a0c6029a96badafefca624bf58e4bff *>>> Troubleshooting <<<* At a first glance it seems a problem related to the size of the image. We have tried with: Cirros Raw (39MB) => It works Ubuntu18 QCOW2 (328MB) => It works Ubuntu18 Raw (2.2GB) => IT FAILS !!!! Any suggestion about where to address our effort? Many thanks in advance BR /Giuseppe

1 0

Re: [External] Re: [openstack-community] how do I revert a volume snapshot?
by Amy Marrich 03 Dec '19

03 Dec '19

John, Sorry I misread what you were trying to do. I thought you wanted to create a new instance with the snapshot not revert to it. I've included the link for how to revert volumes. https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backups.ht… I'm also forwarding this email to the OpenStack Discuss list which is the appropriate list for dev and ops issues. Thanks, Amy (spotz) On Tue, Dec 3, 2019 at 9:29 AM Ratliff, John <jdratlif(a)iu.edu> wrote: > Thanks, but that feels like a really complicated process to rollback. It > seems I would need to delete my old machine and volume, make a volume from > the snapshot, create a new one with the same port, a new volume and specify > the cloud-init script. > > > > Is that really the best way to revert to a snapshot? I don’t have a lot of > experience with openstack, and the documentation and scope is quite large, > but I’ve used vmware, libvirt with qemu, hyper-v, and virtualbox, and they > all had a fairly simple one-step process to revert a snapshot. I feel like > I’m missing something easy. > > > > Thanks. > > > > --John > > > > *From:* Amy Marrich <amy(a)demarco.com> > *Sent:* Monday, December 2, 2019 1:49 PM > *To:* Ratliff, John <jdratlif(a)iu.edu> > *Cc:* community(a)lists.openstack.org > *Subject:* [External] Re: [openstack-community] how do I revert a volume > snapshot? > > > > This message was sent from a non-IU address. Please exercise caution when > clicking links or opening attachments from external sources. > > > > You should be able to create a new instance using that snapshot as the > image. > > > > Amy (spotz) > > > > On Mon, Dec 2, 2019 at 11:27 AM Ratliff, John <jdratlif(a)iu.edu> wrote: > > I am trying to create an instance that I can revert to a snapshot. I > created the snapshot with openstack volume snapshot create, but I don’t see > a way to revert the instance to that image. > > > > What can I do to make use of the snapshot? > > > > Thanks. > > > > --John Ratliff > > > > > > > > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community > >

1 0

[ops] ops meetups team meeting 2019-12-3
by Chris Morgan 03 Dec '19

03 Dec '19

Minutes from todays meeting on #openstack-operators Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… London meetup links: https://go.bloomberg.com/attend/invite/openstack-operators-meetup-london202… https://etherpad.openstack.org/p/LON-2020-OPS-TOPICS South Korea meetup proposal: https://etherpad.openstack.org/p/ops-meetup-2nd-korea-2020 Event notification twitter account: https://twitter.com/osopsmeetup Chris Morgan - on behalf of the OpenStack Ops Meetups team -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[neutron] Bug Deputy report 2019-11-25 - 2019-12-02
by Nate Johnston 03 Dec '19

03 Dec '19

Here are my notes as Neutron bug deputy for last week. It was a pretty slow week. Critical: - "Old conjunction left after sg update" * URL: https://bugs.launchpad.net/neutron/+bug/1854131 * Status: Fix merged (yang-li) - "py36 unit test cases fails" * URL: https://bugs.launchpad.net/bugs/1854051 * Gate-Failure * Status: Unassigned, may be a typing issue, will bring it up in Neutron CI meeting. High: - "Neutron fails to create bandwidth providers if CONF.host is set" * URL: https://bugs.launchpad.net/neutron/+bug/1853840 * Status: In progress, assigned to rubasov - "[Functional tests] Timeout exception in list_namespace_pids" * URL: https://bugs.launchpad.net/bugs/1854462 * Gate-Failure * Status: Unassigned, will bring it up in Neutron CI meeting. Medium: - "The /v2.0/ports/{port_id}/bindings APIs are not documented" * URL: https://bugs.launchpad.net/bugs/1853873 * Status: Assigned to mlavalle Low: - "Avoid raising NetworkInterfaceNotFound exception in DHCP agent logs" * URL: https://bugs.launchpad.net/bugs/1854723 * Status: In progress, assigned to ralonsoh - "DhcpLocalProcess "_enable" method should not call 'restart' --> 'enable'" * URL: https://bugs.launchpad.net/neutron/+bug/1854940 * Status: Assigned to ralonsoh Invalid: - "minor versions 14.0.2 & 14.0.3 are not compatible in dvr-ha" * URL: https://bugs.launchpad.net/bugs/1854050 * Status: agent running higher version than neutron server not supported Thanks, Nate

1 0

Re: [openstack-community] Openstack FW rules
by Amy Marrich 03 Dec '19

03 Dec '19

Hi Lior, Forwarding this to the OpenStack discuss list where someone might be able to help you. Thanks, Amy (spotz) On Tue, Dec 3, 2019 at 7:41 AM Lior Fellus <felluslior(a)gmail.com> wrote: > Hi, > i am using OpenStack "Mitaka" and we have 3 controllers and 3 computes on > our environment and all managed by Fuel server. > recently i implemented a Veeam backup Server in our environment and in > order to backup the computes and the controllers i need to open ssh to them > directly because Veeam not support ssh tunnel via Fuel server. > can anyone explain me how ? > > Regards, > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community >

1 0

VMs auto start
by Alfredo De Luca 03 Dec '19

03 Dec '19

Hi all. Just a quick one. I can't find the settings for VMs auto start after a computer node reboots. Can you point me to the right docs? Which one is it? And you need to add it on nova scheduler right? Cheers -- *Alfredo*

2 2

[gnocchi][telemetry][ceilometer][cloudkitty] Gnocchi unmaintained
by Radosław Piliszek 03 Dec '19

03 Dec '19

Hello Folks, It looks like gnocchi is "officially" marked as unmaintained: https://github.com/gnocchixyz/gnocchi/issues/1049 Has there been any discussion regarding how it affects OpenStack projects? And/or are there any plans to amend this situation? -yoctozepto

15 28

[requirements][os-ken][neutron] update of tinyrpc from 1.0.3 to 1.0.4 breaks neutron-grenade
by Matthew Thode 03 Dec '19

03 Dec '19

2 2

Magnum: coe cluster can not be deleted (DELETE_FAILED)
by Pawel Konczalski 02 Dec '19

02 Dec '19

Hello, i try to delete a broken magnum (v7.1.1.dev21) cluster but neither the cluster or the stack entries can be deleted. Any idea how to force / fix this? BR Pawel openstack coe cluster list | grep DELETE_FAILED openstack coe cluster delete ae5c347c-3ba8-4d39-9125-0bdadef253b4 openstack coe cluster show ae5c347c-3ba8-4d39-9125-0bdadef253b4 | status | DELETE_FAILED ... |--- | status_reason | Resource DELETE failed: JSONDecodeError: resources.kube_masters.resources[1].resources.etcd_pool_member: Expecting value: line 1 column 1 (char 0) ... | faults | {'1': 'JSONDecodeError: resources[1].resources.etcd_pool_member: Expecting value: line 1 column 1 (char 0)', 'kube_masters': 'JSONDecodeError: resources.kube_masters.resources[1].resources.etcd_pool_member: Expecting value: line 1 column 1 (char 0)', '0': 'JSONDecodeError: resources[0].resources.api_pool_member: Expecting value: line 1 column 1 (char 0)', 'api_pool_member': 'JSONDecodeError: resources.api_pool_member: Expecting value: line 1 column 1 (char 0)', 'etcd_pool_member': 'JSONDecodeError: resources.etcd_pool_member: Expecting value: line 1 column 1 (char 0)'} | openstack stack list | grep DELETE_FAILED openstack stack delete 2a907fc4-7b40-43f6-9254-d4084bd056b8 t Payload DELETE: ResourceGroup "kube_masters" [85e1c6be-bdc8-41a3-ba0f-5ca65cdea8ec] Stack "slu-k8s-cluster2-6xiqrpfe7jd6" [2a907fc4-7b40-43f6-9254-d4084bd056b8] 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource Traceback (most recent call last): 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/resource.py", line 924, in _action_recorder 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource yield 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/resource.py", line 2034, in delete 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource *action_args) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/scheduler.py", line 346, in wrapper 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource step = next(subtask) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/resource.py", line 986, in action_handler_task 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource done = check(handler_data) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 596, in check_delete_complete 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource return self._check_status_complete(self.DELETE) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource File "/var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/resources/stack_resource.py", line 463, in _check_status_complete 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource action=action) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource ResourceFailure: JSONDecodeError: resources.kube_masters.resources[1].resources.etcd_pool_member: Expecting value: line 1 column 1 (char 0) 2019-12-02 12:43:08.887 22 ERROR heat.engine.resource # openstack stack list --nested | grep 7390a9b1d4be4d75b4bd08ab8107e4ff | 77848f9e-ff0c-4f7a-9fd7-8ed9e979b998 | test-k8s-cluster2-6xiqrpfe7jd6-kube_masters-mlvsrucewmsd-1-tpqatosey33u | 7390a9b1d4be4d75b4bd08ab8107e4ff | DELETE_FAILED | 2019-05-13T15:28:04Z | 2019-12-02T15:30:53Z | 85e1c6be-bdc8-41a3-ba0f-5ca65cdea8ec | | 85e1c6be-bdc8-41a3-ba0f-5ca65cdea8ec | test-k8s-cluster2-6xiqrpfe7jd6-kube_masters-mlvsrucewmsd | 7390a9b1d4be4d75b4bd08ab8107e4ff | DELETE_FAILED | 2019-05-13T15:28:03Z | 2019-12-02T15:30:53Z | 2a907fc4-7b40-43f6-9254-d4084bd056b8 | | 4c91c53b-42f4-41ca-a97c-49d9261069d6 | test-k8s-cluster2-6xiqrpfe7jd6-kube_masters-mlvsrucewmsd-0-hm2ucynq6hkc | 7390a9b1d4be4d75b4bd08ab8107e4ff | DELETE_FAILED | 2019-05-13T15:28:03Z | 2019-12-02T15:30:54Z | 85e1c6be-bdc8-41a3-ba0f-5ca65cdea8ec | | 2a907fc4-7b40-43f6-9254-d4084bd056b8 | test-k8s-cluster2-6xiqrpfe7jd6 | 7390a9b1d4be4d75b4bd08ab8107e4ff | DELETE_FAILED | 2019-05-13T15:24:45Z | 2019-12-02T15:30:53Z | None |

2 1

[all] Shanghai PTG Feedback
by Kendall Nelson 02 Dec '19

02 Dec '19

Hello Everyone! Now that we've had a few weeks to catch up after the summit and marinate on everything we accomplished together there, we wanted to take a sec to see if anyone had feedback. Normally we would have held a lunchtime feedback session, but due to venue restrictions, we didn't have a good place to do things like normal so we created the etherpad[1] and are distributing it this way :) Hope to hear everyone's feedback! Thanks! -the Kendalls (diablo_rojo & wendallkaters) [1]https://etherpad.openstack.org/p/PVG-PTG-feedback

1 0

[stein][manila-ui] error
by Ignazio Cassano 02 Dec '19

02 Dec '19

Hello, I just installed openstack stein on centos. Manila works fine my command line but when I click "share" in the dashboard the following error appears: Environment: Request Method: GET Request URL: http://10.102.184.190/dashboard/project/shares/ Django Version: 1.11.20 Python Version: 2.7.5 Installed Applications: ['openstack_dashboard.dashboards.project', 'neutron_lbaas_dashboard', 'heat_dashboard', 'openstack_dashboard.dashboards.admin', 'openstack_dashboard.dashboards.identity', 'openstack_dashboard.dashboards.settings', 'dashboards', 'openstack_dashboard', 'django.contrib.contenttypes', 'django.contrib.auth', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'django.contrib.humanize', 'django_pyscss', 'debreach', 'openstack_dashboard.django_pyscss_fix', 'compressor', 'horizon', 'openstack_auth'] Installed Middleware: ('openstack_auth.middleware.OpenstackAuthMonkeyPatchMiddleware', 'debreach.middleware.RandomCommentMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'horizon.middleware.OperationLogMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'horizon.middleware.HorizonMiddleware', 'horizon.themes.ThemeMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'openstack_dashboard.contrib.developer.profiler.middleware.ProfilerClientMiddleware', 'openstack_dashboard.contrib.developer.profiler.middleware.ProfilerMiddleware') Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/exception.py" in inner 41. response = get_response(request) File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response 187. response = self.process_exception_by_middleware(e, request) File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in _get_response 185. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 36. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 52. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 36. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 113. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 84. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in view 68. return self.dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in dispatch 88. return handler(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in get 223. handled = self.construct_tables() File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in construct_tables 214. handled = self.handle_table(table) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in handle_table 123. data = self._get_data_dict() File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in _get_data_dict 43. data.extend(func()) File "/usr/lib/python2.7/site-packages/horizon/utils/memoized.py" in wrapped 109. value = cache[key] = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/manila_ui/dashboards/project/shares/views.py" in get_shares_data 57. share_nets = manila.share_network_list(self.request) File "/usr/lib/python2.7/site-packages/manila_ui/api/manila.py" in share_network_list 280. return manilaclient(request).share_networks.list(detailed=detailed, Exception Type: AttributeError at /project/shares/ Exception Value: 'NoneType' object has no attribute 'share_networks' Anyone can help, please ?

3 7

[cinder] Anastasiya accepted for Outreachy
by Sofia Enriquez 02 Dec '19

02 Dec '19

Hi Cinder team, I'd like to announce that Anastasiya will be working with us improving the Tempest coverage this round. The internship schedule starts on Dec. 3, 2019, to March 3, 2020. Feel free to reach her on IRC *as anastzhyr* if something comes up. On the other hand, If you have any suggestions for tempest test scenarios or possible ideas, please let me know. Regards, Sofi -- L. Sofía Enriquez she/her Associate Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

6 7

"Transible" - convert your current cloud state to Ansible playbooks
by Sagi Shnaidman 02 Dec '19

02 Dec '19

Hi, all I'd like to present you a new tool I wrote recently, although it's under heavy development, but it can be already used and can be helpful in some of your DevOps/CloudOps tasks. I'd appreciate any feedback on it and any contributions of course :) Transible [1] (TRansformANSIBLE) - converts existing cloud state to ansible playbooks. It's a tool that takes your current cloud resources and represents them as Ansible playbooks. Running these playbooks you *ideally* will get no "changed" tasks and the same cloud configuration. Currently, it works with Openstack servers, security rules, security groups, images, volumes, servers, routers, networks, subnets, users, domains and projects which your cloud includes and defines their config as tasks in Ansible playbooks that are ready for deployment. By running these playbooks you actually can deploy or redeploy your current cloud. What are the possible use cases? 1. Freezing cloud config for further IaaC management If you have a ton of deployed resources and lost your tracking, better to start to manage them according to Infrastructure as Code principles. Creating a configuration of everything you have now allows you to change, delete, add things now via code. 2. Keeping current cloud configuration Sometimes it's required to have a "snapshot" of mandatory resources on the cloud and keep them the same no matter what happens in the cloud, like heavy testing for example. Running these playbooks will ensure you have all you need in the cloud in the required configuration. 3. Moving current infrastructure to another tenant, cloud, provider, whatever If you move to another provider but want to keep all you need and as it's configured right now, you can create playbooks with Transible and use them in the new cloud or provider. 4. In the future, I plan to add translation from one cloud configuration to another and it may help with releasing from vendor lock. Of course, because of various clouds' differences, it'll be limited. Can you come up with more? More details about the tool and how it can be configured for various use cases you can read in my longer articles on Medium [2] or Dev.to [3]. I'd appreciate your feedback here or in issues of Transible project. [4] Thanks [1] https://github.com/sshnaidm/transible [2] https://medium.com/@einarum/https-medium-com-einarum-transible-represents-c… [3] https://dev.to/sshnaidm/transible-represents-cloud-configuration-as-ansible… [4] https://github.com/sshnaidm/transible/issues -- Best regards Sagi Shnaidman

1 0