February 2020 - openstack-discuss

[tripleo]
by Wesley Hayutin 27 Feb '20

27 Feb '20

Greetings, Pending a zuul restart I suggest not rechecking or workflowing +2 patches atm. Probably should lay off submitting patches as well [1]. You can watch the dashboard [2] or follow twitter [3] for the restart notice if you want to. Thanks [1] http://zuul.openstack.org/builds?result=RETRY_LIMIT [2] http://dashboard-ci.tripleo.org/d/cockpit/cockpit?orgId=1&fullscreen&panelI… [3] https://twitter.com/openstackinfra

2 2

[cinder] ussuri virtual mid-cycle 16 march at 12:00 UTC
by Brian Rosmaita 27 Feb '20

27 Feb '20

The poll results are in. As with session one, there was only one time when everyone can meet (apologies to the "if need be" people, thank you for being flexible). Session Two of the Cinder Ussuri virtual mid-cycle will be held: DATE: Monday, 16 March 2020 TIME: 1200-1400 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the planning etherpad: https://etherpad.openstack.org/p/cinder-ussuri-mid-cycle-planning cheers, brian

1 0

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #3
by Kendall Nelson 27 Feb '20

27 Feb '20

Hello! There is some debate about where the content of the actual docs should live. This grew out of the discussion about how to setup the includes so that the correct info shows up where we want it. 'Correct' in that last sentence being where the debate is. There are two main schools of thought: 1. All the content of the docs should live in the top level CONTRIBUTING.rst and the sphinx glue should live in doc/source/contributor/contributing.rst. A patch has already been merged for this approach[1]. There is also a patch to update the goal to match[2]. This approach keeps all the info in one place so that if things change in the future, its easier to keep things straight. All the content is also more easily discoverable when looking at a repo in GitHub (or similar) or checking out the code because it is at the top most level of the repo and not hidden in the docs sub directory. 2. The new patch[3] says that the content should live in /doc/source/contributor/contributing.rst and a skeleton with only the most important version should live in the top level CONTRIBUTING.rst. This approach argues that people don't want to read a wall of text when viewing the code on GitHub (or similar) or checking it out and looking at the top level CONTRIBUTING.rst and as such only the important details should be kept in that file. These important details being that we don't accept patches in github and where to report bugs (both of which are included in the larger format of the content). So what do people think? Which approach do they prefer? I am anxious to get this settled ASAP so that projects have time to complete the goal in time. Previous updates if you missed them[4][5]. Please feel free to add other ideas or make corrections to my summaries of the approaches if I missed things :) -Kendall (diablo_rojo) [1] Merged Template Patch (school of thought 1): https://review.opendev.org/#/c/708511/ [2] Goal Update Patch: https://review.opendev.org/#/c/707736/ [3] Current Template Patch (school of thought 2): https://review.opendev.org/#/c/708672/ [4] Update #1: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012364… [5] Update #2: http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012570…

6 7

[oslo][cache] oslo.cache hardening
by Moises Guimaraes de Medeiros 27 Feb '20

27 Feb '20

Hi all, Whenever deploying a service inside a network, basic security concerns come to mind: Is the network trusted? Can we send data in plaintext? Is the service available only to those intended to use it? Can the service itself or others have access to the data? That is no exception for caching servers and a while ago, me and Lance Bragstad started a discussion about this topic. *Possible solutions* *Protecting data in transit using TLS* Requires a backend with TLS support. Since version 1.5.13, Memcached supports authentication and encryption via TLS. This feature requires: OpenSSL 1.1.0 or later; A Memcached client with TLS support; A Memcached server built using ./configure --enable-tls. Encrypting the traffic protects the data in transit from reading and tampering. The complexity impact is that each Memcached server will need a valid certificate. The performance impact is the TLS overhead itself. Performing client authentication protects the server from unauthorized read and write operations. The complexity impact is that each Memcached client will need a valid certificate. The performance impact is bigger due to the extra steps to authenticate both sides. This approach doesn't protect the data held in memory by Memcached in any other way. *Authentication using SASL* Requires a backend with SASL support. Since version 1.4.3, Memcached supports authentication via SASL. This feature requires: A Memcached client with SASL support; A Memcached server built using ./configure --enable-sasl. This approach protects the server from unauthorized read and write operations. The complexity and performance impact is according to SASL usage. This approach doesn't protect the data in transit or held in memory by Memcached in any other way. *Encrypting data before storing* Requires *NO* extra features in the backend. This approach consists of encrypting the data before sending it to the caching servers. The complexity impact is dealing with key sharing for the encryption/decryption process. The performance impact depends on the algorithms used for encryption. This approach protects the data both in transit and held in memory by caching servers, but the key sharing is more prone to setup errors than the TLS or the SASL approach. --- After considering the possible solutions, we decided to tackle the TLS path first. We did an initial analysis of oslo.cache backends that use Memcached together with Hervé Beraud here: https://etherpad.openstack.org/p/oslo-cache-tls-support-worksheet Since python-binary-memcached already has SASL support, we thought it to be a good first candidate to implement TLS support and last month I had it merged here: https://github.com/jaysonsantos/python-binary-memcached/pull/211 We are now looking for more people interested in the discussion and help to push changes forward. -- Moisés Guimarães Software Engineer Red Hat

1 0

[neutron] Shared tenant network allow duplicate IP's?
by Adam Peacock 27 Feb '20

27 Feb '20

Hey folks, So I caught wind from a friend/colleague that allowing duplicate IP's in each tenant was now only achievable by creating a separate tenant network+subnet and assigning them separately to each individual tenant. This doesn't seem right to me and it doesn't scale. *Looking for this:* - tenant-network-id = abc (shared) - tenant1 - vm1: 10.0.0.10 - tenant2 - vm1: 10.0.0.10 Am I missing something and this setup is no longer supported? I hope I'm wrong but I can't find documentation that speaks to this specifically so would appreciate a link if anyone has it handy. Thanks! //adam *Adam Peacock* Principal Architect Office: +1-916-794-5706

4 4

[ptl][release][stable][EM] Extended Maintenance - Rocky
by Elõd Illés 27 Feb '20

27 Feb '20

Hi, In less than one month Rocky is planned to enter into Extended Maintenance phase [1] (estimated date: 2020-02-24). I have generated the list of *open* and *unreleased* changes in *stable/rocky* for the follows-policy tagged repositories [2]. These lists could help the teams, who are planning to do a final release on Rocky before moving stable/rocky branches to Extended Maintenance. Feel free to edit them! * At the transition date the Release Team will tag the latest (Rocky) releases of repositories with *rocky-em* tag. * After the transition stable/rocky will be still open for bugfixes, but there won't be any official releases. NOTE: teams, please focus on wrapping up your libraries first if there is any concern about changes, in order to avoid any broken releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/rocky-final-release-before-em

4 5

[ops] nova wsgi config
by Arnaud Morin 27 Feb '20

27 Feb '20

Hey all, I am trying to configure apache as a WSGI. Is there any other documentation than this: https://docs.openstack.org/nova/stein/user/wsgi.html Is there any recommendations? Thanks in advance! -- Arnaud Morin

4 7

Cinder / Nova - Select cinder backend based on nova availability zone?
by Tony Pearce 27 Feb '20

27 Feb '20

Apologies in advance if this seems trivial but I am looking for some direction on this and I may have found a bug while testing also. Some background - I have 2 physical hosts which I am testing with (host1, host2) and I have 2 separate cinder backends (backend1, backend2). Backend1 can only be utilised by host1. Same for backend2 - it can only be utilised by host2. So they are paired together like: host1:backend1 host2:backend2 So I wanted to select a Cinder storage back-end based on nova availability zone and to do this when creating an instance through horizon (not creating a volume directly). Also I wanted to avoid the use of metadata input on each instance create or by using metadata from images (such as cinder_img_volume_type) [2] . Because I can foresee a necessity to then have a number of images which reference each AZ or backend individually. - Is it possible to select a backend based on nova AZ? If so, could anyone share any resources to me that could help me understand how to achieve it? Because I failed at achieving the above, I then decided to use one way which had worked for me in the past, which was to use the image metadata "cinder_img_volume_type". However I find that this is not working. The “default” volume type is selected (if cinder.conf has it) or if no default, then `__DEFAULT__` is being selected. The link at [2] states that first, a volume type is used based on the volume type selected and if not chosen/set then the 2nd method is "cinder_img_volume_type" from the image metadata and then the 3rd and final is the default from cinder.conf. I have tested with fresh deployment using Kayobe as well as RDO’s packstack. Openstack version is *Train* Steps to reproduce: 1. Install packstack 2. Update cinder.conf with enabled_backends and the [backend] 3. Add the volume type to reference the backend (for reference, I call this volume type `number-1`) 4. Upload an image and add metadata `cinder_img_volume_type` and the name as mentioned in step 3: number-1 5. Try and create an instance using horizon. Source = image and create new volume 6. Result = volume type / backend as chosen in the image metadata is not used and instance goes into error status. After fresh-deploying the RDO Packstack, I enabled debug logs and tested again. In the cinder-api.log I see “"volume_type": null,” and then the next debug log immediately after logged as “Create volume request body:” has “volume_type': None”. I was searching for a list of the supported image metadata, in case it had changed but the pages seem empty one rocky/stein/train [3] or not yet updated. Selecting backend based on nova AZ:: I was searching how to achieve this and I came across this video on the subject of AZs [1]. Although it seems only in the context of creating volumes (not with creating instances with volume from an image, for example). I have tried creating a host aggregate in nova, with AZ name `host1az`. I've also created a backend in Cinder (cinder.conf) with `backend_availability_zone = host1az`. But this does not appear to achieve the desired result, either and the cinder api logs are showing “"availability_zone": null” during the volume create part of the launch instance from Horizon. I also tried setting RESKEY [3] in the volume type, but again similar situation seen; although I dont think this option is the correct context for what I am attempting. Could anyone please nudge me in the right direction on this? Any pointers appreciated at this point. Thanks in advance. References: [1] https://www.youtube.com/watch?v=a5332_Ew9JA [2] https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html [3] https://docs.openstack.org/cinder/train/contributor/api/cinder.api.schemas.… [4] https://docs.openstack.org/cinder/rocky/admin/blockstorage-availability-zon… Regards, Tony Pearce

2 4

Networking-vpp 20.01 for VPP 20.01 is now available
by Naveen Joy (najoy) 26 Feb '20

26 Feb '20

Hello All, We'd like to invite you to try out Networking-vpp 20.01. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 20.01. In this release, we've made the below changes: - We've dropped support for Python 2.7 and updated the code to work with Python 3.6 or later. - We've updated the code to be compatible with VPP 20.01 API changes. - We've added VPP API versioning support using 2 data files. They are API whitelist file and API CRC manifest file. At startup, the vpp-agent will check to see if the API signature is compatible with the installed VPP. Also, at runtime, only the whitelisted API calls will be allowed. - We've fixed an issue with the eventlet that caused problems when binding tap interfaces into Linux bridge - We've been doing the usual round of bug fixes, clean-ups and updates. The code will work with VPP 20.01 and the OpenStack Stein release. The README [1] explains how you can try out VPP with Networking-vpp using devstack: the devstack plugin will deploy the mechanism driver and VPP and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.05 release. We welcome anyone who would like to come help us. -- Jerome, Ian & Naveen [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[nova][neutron] nova scheduling support for routed networks
by Balázs Gibizer 26 Feb '20

26 Feb '20

Hi, There are multiple efforts to add scheduler support to the neutron routed network feature. Matt's effort to have it as a scheduler pre-filter [1] Adam's (rm_work) effort to have this as a a new scheduler hint and a new scheduler filter [2] We had a good discussion on #openstack-nova [3] about the possible way forward with Sean and Adam. Here is a summary and my proposed way forward. Currently booting a server in a routed network setup works iff the neutron port is pre-created with ip_allocation=deferred before the server create. Nova then schedule the server without consider anything about the possible multiple network segments of the port. Neutron will do the segment assignment when the port is bond to the compute host. The problem is that once a port bound to a segment it cannot be bound to another segment as that would change the IP of the port. So if a server is migrated nova should select a destination host where the _same segment_ is available. Therefore we need a way to influence the scheduling based on the assigned segment id of the port. Both [1] and [2] does that based on the fact that neutron creates nova host aggregates for each network segment and those aggregates are mirrored to placement as placement aggregates. For me the pre-filter approach[1] seems better as * it avoids introducing a new scheduler hint * it is not affected by the allocation candidate limit configuration that effect scheduler filters * it allows us to iterate towards an approach where neutron provides the required aggregates of each port via the ports' resource_request attribute The downside of the pre-filter approach is that right now it needs to query the segments for each network / port the server has before the each scheduling. I think we limit such performance impact by making this pre-filter turned off by default via configuration. So a deployment without routed networks does not need to pay this cost. Later this cost can be nullified by extending neutron to specify the needed aggregates in the port's resource_request. I'm now planning to take [1] over from Matt and finish it up by adding functional test and documentation to it. I would also like to raise attention to the tempest patch that adds basic CI coverage for the currently working server create scenario [4]. Cheers, gibi [1] https://review.opendev.org/#/c/656885 [2] https://review.opendev.org/#/c/709280 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [4] https://review.opendev.org/#/c/665155

2 1