January 2019 - openstack-discuss - lists.openstack.org

[docs] Nominating Alex Settle for openstack-doc-core
by Petr Kovar 23 Jan '19

23 Jan '19

Hi all, Alex Settle recently re-joined the Documentation Project after a few-month break. It's great to have her back and I want to formally nominate her for membership in the openstack-doc-core team, to follow the formal process for cores. Please let the ML know should you have any objections. Thanks, pk

13 14

oslo.messaging, OpenSSL 1.1.1a, Eventlet and Python 3.7
by Thomas Goirand 23 Jan '19

23 Jan '19

Hi there! Just a quick return from my experience. While testing all what's in the subject in Debian Buster/Sid (testing a full deployment), I noticed that most (if not all) components wouldn't connect to RabbitMQ. The crash was like this: http://paste.openstack.org/show/743089/ This happened in: - cinder-scheduler - nova-conductor - neutron-api - neutron-rpc-server and probably many more. After some search-engine time, I found this patch: https://github.com/eventlet/eventlet/pull/531/commits This fixed the issue for me (on all OpenStack components). I've pushed it in the eventlet Debian package Git repository, and hopefully, I'll be able to push it to Buster before the release (currently waiting on approval from the current package maintainer). Hoping this helps the project and/or some deployment people, Cheers, Thomas Goirand (zigo) P.S: More soon about the latest update of OCI.

2 2

[all][oslo][coordination] remove method get_transport in transport.py
by Herve Beraud 23 Jan '19

23 Jan '19

Hello everybody! Since few months oslo plan to remove an deprecated method (oslo_messaging.get_transport). In a first this method was deprecated to facilitate removing rpc_backend support, get_transport aliases was deprecated to simplify the code and the tests. Aliases were first depreacted in oslo.messaging 5.20.0 during Pike and now we want to definitely remove this method. The support of this aliases was planed to be remove during milestone stein-1. So I propose to all projects who use this deprecated method to start to move to the right oslo.messaging supported transport methods (get_rpc_transport or get_notification_transport depends on your needs). This thread will try to coordinate projects during migrator. I already submit a patch[1] to oslo.messaging to start to remove this method. To move forward on this topic I personaly plan to propose patchs to projects that I know that use it. To ensure a better removing, to be sure that all projects remove usages of this method, and to merge in the right order, I propose to you to use the same topic in your gerrit reviews by using refer the bug https://bugs.launchpad.net/oslo.messaging/+bug/1714945 in your commit (Related-Bug: #1714945). Please ensure that all your projects stop to use this method. If you facing an issue please reply to this thread to centralize support during the migrator. You can track this topic by visiting this page: https://review.openstack.org/#/q/topic:bug/1714945+(status:open+OR+status:m… [1] https://review.openstack.org/632523 Cheers! Best! -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[TripleO][Kolla] Reduce base layer of containers for security and size of images (maintenance) sakes: UPDATE
by Bogdan Dobrelya 23 Jan '19

23 Jan '19

Here is an update. The %{systemd_ordering} macro is proposed for lightening containers images and removing the systemd dependency for containers. Please see & try patches in the topic [0] for RDO, and [1][2][3][4][5] for generic Fedora 29 rpms. I'd very appreciate if anyone building Kolla containers for f29/(rhel8 yet?) could try these out as well. PS (somewhat internal facing but who cares): I wonder if we could see those changes catched up automagically for rhel8 repos as well? > I'm tracking systemd changes here [0],[1],[2], btw (if accepted, > it should be working as of fedora28(or 29) I hope) > > [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1668688 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1668687 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1668678 -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[scientific-sig] IRC meeting Wednesday 1100 UTC: 2FA with FreeIPA, OpenInfra Days London, ISC 2019
by Stig Telfer 23 Jan '19

23 Jan '19

Hi All - We have a Scientific SIG IRC meeting coming up on Wednesday 16th at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Full agenda and details are here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_16th_2019> We’ve got quite a bit to cover this week. Our headline item is a presentation on experiences configuring 2FA for OpenStack using FreeIPA. We also have some exciting events coming up, and discussion on a possible Scientific OpenStack BoF at the International Supercomputer Conference in Frankfurt in June. Cheers, Stig

2 3

Subject: Re: [Trove] State of the Trove service tenant deployment model
by Darek Król 23 Jan '19

23 Jan '19

On Tue, Jan 22, 2019 at 07:29:25PM +1300, Zane Bitter wrote: > Last time I heard (which was probably mid-2017), the Trove team had > implemented encryption for messages on the RabbitMQ bus. IIUC each DB being > managed had its own encryption keys, so that would theoretically prevent > both snooping and spoofing of messages. That's the good news. > > The bad news is that AFAIK it's still using a shared RabbitMQ bus, so > attacks like denial of service are still possible if you can extract the > shared credentials from the VM. Not sure about replay attacks; I haven't > actually investigated the implementation. > > cheers, > Zane. > Excellent - many thanks for the confirmation. > > Cheers, > Michael Hello Michael and Zane, sorry for the late reply. I believe Zane is referring to a video from 2017 [0]. Yes, messages from trove instances are encrypted and the keys are kept in Trove DB. It is still a shared message bus, but it can be a message bus dedicated for Trove only and separated from message bus shared by other Openstack services. DDOS attacks are also mentioned in the video as a potential threat but there is very little details and possible solutions. Recently we had some internal discussion about this threat within Trove team. Maybe we could user Rabbitmq mechanisms for flow control mentioned in [1,2,3] ? Another point, I'm wondering if this is a problem only in Trove or is it something other services would be interesting in also ? Best, Darek [0] https://youtu.be/dzvcKlt3Lx8 [1] https://www.rabbitmq.com/flow-control.html [2] http://www.rabbitmq.com/blog/2012/04/17/rabbitmq-performance-measurements-p… [3] https://tech.labs.oliverwyman.com/blog/2013/08/31/controlling-fast-producer…

6 9

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 23 Jan '19

23 Jan '19

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[nova] Do we need to copy pci_devices to target cell DB during cross-cell resize?
by Matt Riedemann 23 Jan '19

23 Jan '19

While working on the code to create instance-related data in the target cell database during a cross-cell resize I noticed I wasn't copying over pci_devices [1] but when looking at the PciDevice object create/save methods, those aren't really what I'm looking for here. And looking at the data model, there is a compute_node_id field which is the compute_nodes.id primary key which won't match the target cell DB. I am not very familiar with the PCI device manager code and data model (it's my weakest area in nova lo these many years) but looking closer at this, am I correct in understanding that the PciDevice object and data model is really more about the actual inventory and allocations of PCI devices on a given compute node and therefore it doesn't really make sense to need to copy that data over to the target cell database. During a cross-cell resize, the scheduler is going to pick a target host in another cell and claim standard resources (VCPU, MEMORY_MB and DISK_GB) in placement, but things like NUMA/PCI claims won't happen until we do a ResourceTracker.resize_claim on the target host in the target cell. In that case, it seems the things I only need to care about mirroring is instance.pci_requests and instance.numa_topology, correct? Since those are the user-requested (via flavor/image/port) resources which will then result in PciDevice and NUMA allocations on the target host. I'm just looking for confirmation from others that better understand the data model in this area. [1] https://review.openstack.org/#/c/627892/5/nova/conductor/tasks/cross_cell_m… -- Thanks, Matt

2 2

[neutron] Neutron Bug Deputy report for week of Jan 14
by Nate Johnston 23 Jan '19

23 Jan '19

Neutron friends, Below is a summary of the neutron bugs that came in last week (Jan 14th). Any bugs with a preceding "(*)" are not yet in "in progress" state. Looks like lajoskatona is this week's bug deputy. Ports/IPAM - https://bugs.launchpad.net/bugs/1811905 Deferred IP allocation, port update with binding_host_id + set new mac address fails - https://bugs.launchpad.net/bugs/1812788 Port with no active binding mark as dead Gate Failures - (*) https://bugs.launchpad.net/bugs/1812364 Error "OSError: [Errno 22] failed to open netns" in l3-agent logs - https://bugs.launchpad.net/bugs/1812404 test_concurrent_create_port_forwarding_update_port failed with InvalidIpForSubnet - (*) https://bugs.launchpad.net/bugs/1812872 Trunk functional tests can interact with each other - https://bugs.launchpad.net/bugs/1812552 tempest-slow tests fails often L3 / DHCP - https://bugs.launchpad.net/bugs/1811873 get_l3_agent_with_min_routers fails with postgresql backend - (*) https://bugs.launchpad.net/bugs/1812118 Neutron doesn't allow to update router external subnets DNS - (*) https://bugs.launchpad.net/bugs/1812168 Neutron doesn't delete Designate entry when port is deleted QoS - https://bugs.launchpad.net/bugs/1812576 L2 agent do not clear old QoS rules after restart Oslo - https://bugs.launchpad.net/bugs/1812922 neutron functional tests break with oslo.utils 3.39.1 and above Docs - (*) https://bugs.launchpad.net/bugs/1812225 Firewall-as-a-Service (FWaaS) in neutron docs for Rocky still refer to plans for Ocata - (*) https://bugs.launchpad.net/bugs/1809578 Documentation might be wrong - https://bugs.launchpad.net/bugs/1812497 create vm failed, RequiredOptError: value required for option lock_path in group

1 0

[scientific-sig] IRC meeting at 2100 UTC: Jitter on SR-IOV IB, Terraform and Kubespray
by Stig Telfer 22 Jan '19

22 Jan '19

Hi All - We have a Scientific SIG IRC meeting in about 30 minutes in channel #openstack-meeting. Everyone is welcome. Today’s agenda is at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_January_22nd_2019 We have Jacob Anders from CSIRO talking about some recent research on latency and jitter for SR-IOV InfiniBand. We also have Martial Michel from DataMachines on Terraform and Kubespray. Cheers, Stig

1 0