- openstack-discuss - lists.openstack.org

[dev] [mistral] Deprecating keystone_authtoken/auth_uri
by Tobias Urdin 14 Feb '19

14 Feb '19

Hello all Mistral people, This patch [1] has been up for a long time about the removal (which probably should a deprecation?) (and support for www_authenticate_uri) but it's been still for a long time and since deployment tools have moved away from using auth_uri I would guess that the Puppet OpenStack project is not the only project that has specific code to keep compatible with Mistral. Is there anybody active in Mistral that could look at it or have more information? Best regards Tobias [1] https://review.openstack.org/#/c/594187/

3 2

[dev][keystone] Key loading performance during token validation
by Lance Bragstad 14 Feb '19

14 Feb '19

Both fernet tokens and JSON Web Tokens (still under review [0]) require keys to either encrypt or sign the token payload. These keys are kept on disk by default and are treated like configuration. During the validation process, they're loaded from disk, stored as a list, and iterated over until the correct key decrypts the ciphertext/validates the signature or the iterable is exhausted [1][2]. Last week XiYuan raised some concerns about loading all public keys from disk every time we validate a token [3]. To clarify, this would be applicable to both fernet keys and asymmetric key pairs used for JWT. I spent a couple days late last week trying to recreate the performance bottleneck. There were two obvious approaches. 1. Watch for writable changes to key repositories on disk I used a third-party library for this called watchdog [4], but the inherent downside is that it is specific to file-based key repositories. For example, this might not work with a proper key manager, which has been proposed in the past [5]. 2. Encode a hash of the key used to create the token inside the token payload This would give any keystone server validating the token the ability preemptively load the correct key for validation instead of iterating over a list of all possible keys. There was some hesitation around this approach because the hash would be visible to anyone with access to the token (it would be outside of ciphertext in the case of fernet). While hashes are one-way, it would allow someone to "collect" tokens they know were issued using the same symmetric private key or signed with the same asymmetric private key. Security concerns aside, I did attempt to write up the second approach [6]. I was able to get preemptive loading to work, but I didn't notice a significant performance impact. For clarification, I was using a single keystone server with one private key for signing and 100 public keys to simulate a deployment of 100 API servers that all need to validate tokens issued by each other. At a certain point, I wondered if the loading of keys was really the issue, or if it was because we were iterating over an entire set every time we validate a token. It's also important to note that I had to turn off caching to fully test this. Keystone enables caching by default, which short-circuits the entire key loading/token provider code path after the token is issued. My question is if anyone has additional feedback on how to recreate performance issues specifically for loading files from disk, since I wasn't particularly successful in noticing a difference between repetitive key loading or iterating all keys on token validation against what we already do. [0] https://review.openstack.org/#/c/614549/ [1] https://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/token… [2] https://github.com/pyca/cryptography/blob/master/src/cryptography/fernet.py… [3] https://review.openstack.org/#/c/614549/13/keystone/token/providers/jws/cor… [4] https://pythonhosted.org/watchdog/ [5] https://review.openstack.org/#/c/363065/ [6] https://review.openstack.org/#/c/636151/

2 1

[neutron] [upgrade] No meeting on Feb. 14th
by Lujin Luo 14 Feb '19

14 Feb '19

Hi team, I will not be able to chair the meeting tomorrow either. Let's skip it and resume next week on 21th! Sorry for any inconvenience caused. Best regards, Lujin

1 0

Fw: Re: [manila] [dev][tc][ptl] Continuing Evaluating projects in relation to OpenStack cloud vision
by Tom Barron 13 Feb '19

13 Feb '19

Resending with '[manila]' tag as well.

1 0

[Neutron] Split Network node from controller Node
by Zufar Dhiyaulhaq 13 Feb '19

13 Feb '19

Hi everyone, I Have existing OpenStack with 1 controller node (Network Node in controller node) and 2 compute node. I need to expand the architecture by splitting the network node from controller node (create 1 node for network). Do you have any recommended step or tutorial for doing this? Thanks Best Regards, Zufar Dhiyaulhaq

2 3

[loci] Loci builds functionally broken
by Chris Hoge 13 Feb '19

13 Feb '19

It appears the lastest release of virtualenv has broken Loci builds. I believe the root cause is an update in how symlinks are handled. Before the release, the python libraries installed in the: /var/lib/openstack/lib64/python2.7/lib-dynload directory (this is on CentOS, Ubuntu and Suse vary) were direct instances of the library. For example: -rwxr-xr-x. 1 root root 62096 Oct 30 23:46 itertoolsmodule.so Now, the build points to a long-destroyed symlink that is an artifact of the requirements build process. For example: lrwxrwxrwx. 1 root root 56 Feb 11 23:01 itertoolsmodule.so -> /tmp/venv/lib64/python2.7/lib-dynload/itertoolsmodule.so We will investigate how to make the build more robust, repair this, and will report back soon. Until then, you should expect any fresh builds to not be functional, despite the apparent success in building the container. Thanks, Chris [1] https://virtualenv.pypa.io/en/stable/changes/#release-history

1 2

[neutron] Switch port configuration with Neutron and Networking-Ansible
by Ian Ballou 13 Feb '19

13 Feb '19

Hi Dan, I'm working with a group of people on a project to create an Ironic-based bare-metal leasing system. As part of this system, we would like to allow users and administrators to connect their hardware to different VLAN networks that may span multiple switch ports. We're hoping to use Neutron and the appropriate plugins to accomplish this. I've been testing out the Networking-Ansible ML2 Neutron driver to see if it fits our needs. The Python APIs available in the newest version (such as configuring switch ports and VLANs) work well. However, we would like to use this ML2 driver directly for OpenStack CLI support. In testing I've been able to create VLANs on a Nexus switch, but I have not yet found a way through Neutron (via the Openstack CLI) to change VLAN settings on switch ports (access or trunk). I was able to do this with the Python APIs, however. I did see that the Networking-Ansible mechanism driver calls bind_port() to change switch port configuration, but it's not clear if the port information comes from static configuration or if Neutron does have a way of reading it from the CLI. Is this kind of switch configuration by users and admins outside the scope of Neutron or this Neutron driver? I've included openstack-discuss in case anyone else has any comments. Thanks! - Ian -- Ian Ballou SOFTWARE ENGINEERING Intern Red Hat Boston, MA iballou(a)redhat.com

1 0

Placement governance switch
by Ed Leafe 13 Feb '19

13 Feb '19

With PTL election season coming up soon, this seems like a good time to revisit the plans for the Placement effort to become a separate project with its own governance. We last discussed this back at the Denver PTG in September 2018, and settled on making Placement governance dependent on a number of items. [0] Most of the items in that list have been either completed, are very close to completion, or, in the case of the upgrade, is no longer expected. But in the time since that last discussion, much has changed. Placement is now a separate git repo, and is deployed and run independently of Nova. The integrated gate in CI is using the extracted Placement repo, and not Nova’s version. In a hangout last week [1], we agreed to several things: * Placement code would remain in the Nova repo for the Stein release to allow for an easier transition for deployments tools that were not prepared for this change * The Placement code in the Nova tree will remain frozen; all new Placement work will be in the Placement repo. * The Placement API is now unfrozen. Nova, however, will not develop code in Stein that will rely on any newer Placement microversion than the current 1.30. * The Placement code in the Nova repo will be deleted in the Train release. Given the change of context, now may be a good time to change to a separate governance. The concerns on the Nova side have been largely addressed, and switching governance now would allow us to participate in the next PTL election cycle. We’d like to get input from anyone else in the OpenStack community who feels that a governance change would impact them, so please reply in this thread if you have concerns. [0] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.ht… [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002451… -- Ed Leafe

3 7

[infra] StoryBoard Maintenance 2019-02-15 at 20:00 UTC
by Jeremy Stanley 13 Feb '19

13 Feb '19

We're planning to perform a quick server upgrade/replacement and database move for the StoryBoard service at https://storyboard.openstack.org/ this Friday, 2019-02-15 starting at 20:00 UTC and hopefully only lasting 5-10 minutes. Please find us in the #openstack-infra channel on the Freenode IRC network or follow up to this message if you have any questions or concerns. -- Jeremy Stanley

1 0

[ops][nova] Heads-up: Upcoming version bump for libvirt and QEMU in 'Stein'
by Kashyap Chamarthy 13 Feb '19

13 Feb '19

Heya folks, This is a gentle reminder to note that we are about to[1] bump the minimum required versions for libvirt and QEMU in "Stein" to: libvirt : 3.0.0 QEMU : 2.8.0 We've picked[1][2] these "next" minimum versions for "Stein" in April 2018. And the last time we did a minimum libvirt / QEMU version bump was during the "Pike" release. So we hope the intervening one year's time since the last version change is sufficient enough to prepare for this upcoming version bump. If there aren't any valid objections to this in a week, we intend to go ahead and bump the versions, as we planned[1][2]. * * * PS: Ccing the zKVM CI maintainers to check if they're okay with this, as the zKVM CI isn't running anymore. [1] https://review.openstack.org/#/c/632507/ — libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Stein" [2] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129048.html — RFC: Next minimum libvirt / QEMU versions for "Stein" release [3] http://git.openstack.org/cgit/openstack/nova/commit/?id=28d337b — Pick next minimum libvirt / QEMU versions for "Stein" -- /kashyap

1 0