- openstack-discuss - lists.openstack.org

octavia : diskimage-create.sh ignores -s flag ?
by M. Ranganathan 14 Feb '19

14 Feb '19

Hello, I have been struggling to create a diskimage from an existing qcow2 image. I find that diskimage-builder does the following: 1. apparently ignores DIB_LOCAL_IMAGE environment setting and 2. ignores the -s flag. No matter what -s I supply, it creates a 2gb image. My flags are as follows: bash diskimage-create.sh -s 10 Not sure what I am doing wrong. Any help appreciated. Thanks -- M. Ranganathan

3 4

Zun : Error in "docker network create" with kuryr as driver, as required by Zun
by Nehal Bansal 14 Feb '19

14 Feb '19

Hi, I have installed OpenStack Queens release. I wish to run docker containers on it as first class residents like VMs therefore, I installed Zun. Zun requires Kuryr-libnetwork on the compute node. Everything got installed correctly but verifying the installation with docker network create --driver kuryr --ipam-driver kuryr --subnet 192.168.4.0/24 --gateway=192.168.4.1 test_net gives the following error: Error response from daemon: legacy plugin: Plugin.Activate: {"message":"page not found"} The /var/log/syslog file gives this error: Feb 13 09:25:01 compute dockerd[27830]: time="2019-02-13T09:25:01.006618155+05:30" level=error msg="Handler for POST /v1.39/networks/create returned error: legacy plugin: Plugin.Activate: {\"message\":\"page not found\"}\n". I have asked the question on ask.openstack.org too but have received no answers. I am new to both OpenStack and Docker. Please let me know if you need any more information. Thank you. Regards, Nehal Bansal

2 1

[tripleo] Plan around switching Podman to default
by Emilien Macchi 14 Feb '19

14 Feb '19

Pacemaker provided by CentOS7 doesn't work with Podman, and only works with Docker. Podman is already the default on the Undercloud, and this is fine, as we don't deploy Pacemaker on this node. However for the Overcloud, it causes problem as upstream is tested on CentOS7 and downstream is being tested on RHEL8. With that said, I propose that we: - Keep Docker as the default on the Overcloud until CentOS8 is out. - Switch downstream to use Podman on the Overcloud (since we run RHEL8 it's fine). - Switch all CI jobs except OVB to NOT deploy Pacemaker and switch to Podman. - Once CentOS8 is out, we revert the downstream only patch and land it upstream. Any feedback / concerns are welcome. -- Emilien Macchi

2 3

[nova][dev][ops] can we get rid of 'project_only' in the DB layer?
by melanie witt 14 Feb '19

14 Feb '19

Hey all, Recently, we had a customer try the following command as a non-admin with a policy role granted in policy.json to allow live migrate: "os_compute_api:os-migrate-server:migrate_live": "rule:admin_api or role:Operator" The scenario is that they have a server in project A and a user in project B with role:Operator and the user makes a call to live migrate the server. But when they call the API, they get the following error response: {"itemNotFound": {"message": "Instance <uuid server 1> could not be found.", "code": 404}} A superficial look through the code shows that the live migrate should work, because we have appropriate policy checks in the API, and the request makes it past those checks because the policy.json has been set correctly. A common pattern in our APIs is that we first compute_api.get() the instance object and then we call the server action (live migrate, stop, start, etc) with it after we retrieve it. In this scenario, the compute_api.get() fails with NotFound. And the reason it fails with NotFound is because, much lower level, at the DB layer, we have a keyword arg called 'project_only' which, when True, will scope a database query to the RequestContext.project_id only. We have hard-coded 'project_only=True' for the instance get query. So, when the user in project B with role:Operator tries to retrieve the instance record in project A, with appropriate policy rules set, it will fail because 'project_only=True' and the request context is project B, while the instance is in project A. My question is: can we get rid of the hard-coded 'project_only=True' at the database layer? This seems like something that should be enforced at the API layer and not at the database layer. It reminded me of an effort we had a few years ago where we removed other hard-coded policy enforcement from the database layer [1][2]. I've uploaded a WIP patch to demonstrate the proposed change [3]. Can anyone think of any potential problems with doing this? I'd like to be able to remove it so that operators are able use policy to allow non-admin users with appropriately configured roles to run server actions. Cheers, -melanie [1] https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part [2] https://review.openstack.org/#/q/topic:bp/nova-api-policy-final-part+(statu… [3] https://review.openstack.org/637010

3 2

[release] Release countdown for week R-7, February 18-22
by Sean McGinnis 14 Feb '19

14 Feb '19

Welcome to this weeks release countdown email. Development Focus ----------------- The non-client library freeze is getting, followed closely by the client lib freeze. Teams should be focusing on wrapping up work that will require library changes to complete. General Information ------------------- As we get closer to the end of the cycle, we have deadlines coming up for client and non-client libraries to ensure any dependency issues are worked out and we have time to make any critical fixes before the final release candidates. To this end, it is good practice to release libraries throughout the cycle once they have accumulated any significant functional changes. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Stein-3 milestone: March 7 RC1 deadline: March 21 -- Sean McGinnis (smcginnis)

1 0

[all][tc][foundation] looking for feedback on acceptance criteria for new open infrastructure projects
by Doug Hellmann 14 Feb '19

14 Feb '19

Claire posted this request to the foundation mailing list [1], but in case any contributors are not subscribed there it seemed like a good idea to mention it here on this list, too. The OpenStack Foundation Board and staff are looking for feedback from the community about the criteria used to approve new Open Infrastructure Projects (the name for new top level projects under the foundation's umbrella). Moving projects like Zuul, Airship, StarlingX, and Kata from the pilot phase to be fully recognized projects is a big milestone for our community, and it's important that everyone interested participate in the conversation about defining the process and criteria for accepting new projects. Please take a few minutes to read Claire's email and review the etherpad linked there in the next week or two, so that the Board will have your input before their next meeting. [1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html -- Doug

1 0

[requirements][mistral] Add yamlloader to global requirements
by Oleg Ovcharuk 14 Feb '19

14 Feb '19

Hi! Can you please add yamlloader library to global requirements? https://pypi.org/project/yamlloader/ It provides ability to preserve key order in dicts, it supports either python 2.7 and python 3.x, it provides better performance than built-in functions. Thank you.

2 1

Re: Diskimage-builder lvm
by bkannadassan 14 Feb '19

14 Feb '19

Not sure if you figured out. I hit the same for centos and I need to include dracut-regenerate in disk-image-create. Which did install lvm2 and other minimal packages.. -- Sent from: http://openstack.10931.n7.nabble.com/Operators-f4774.html

2 1

Re: [Release-job-failures] Release of openstack/puppet-aodh failed
by Thierry Carrez 14 Feb '19

14 Feb '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-puppet http://logs.openstack.org/61/617ffad84b633618490ca1023f8a31d9694b31a9/relea… : POST_FAILURE in 3m 42s > - announce-release announce-release : SKIPPED Error is: Forge API auth failed with code: 400 However it's a bit weird, since that release was made 4 weeks ago. Also we don't seem to upload things to the Puppet Forge... Was it some kind of a test ? It looks like I'm missing context. -- Thierry Carrez (ttx)

2 1

[nova][qa][cinder] CI job changes
by Matt Riedemann 14 Feb '19

14 Feb '19

I'd like to propose some changes primarily to the CI jobs that run on nova changes, but also impact cinder and tempest. 1. Drop the nova-multiattach job and move test coverage to other jobs This is actually an old thread [1] and I had started the work but got hung up on a bug that was teased out of one of the tests when running in the multi-node tempest-slow job [2]. For now I've added a conditional skip on that test if running in a multi-node job. The open changes are here [3]. 2. Only run compute.api and scenario tests in nova-next job and run under python3 only The nova-next job is a place to test new or advanced nova features like placement and cells v2 when those were still optional in Newton. It currently runs with a few changes from the normal tempest-full job: * configures service user tokens * configures nova console proxy to use TLS * disables the resource provider association refresh interval * it runs the post_test_hook which runs some commands like archive_delete_rows, purge, and looks for leaked resource allocations [4] Like tempest-full, it runs the non-slow tempest API tests concurrently and then the scenario tests serially. I'm proposing that we: a) change that job to only run tempest compute API tests and scenario tests to cut down on the number of tests to run; since the job is really only about testing nova features, we don't need to spend time running glance/keystone/cinder/neutron tests which don't touch nova. b) run it with python3 [5] which is the direction all jobs are moving anyway 3. Drop the integrated-gate (py2) template jobs (from nova) Nova currently runs with both the integrated-gate and integrated-gate-py3 templates, which adds a set of tempest-full and grenade jobs each to the check and gate pipelines. I don't think we need to be gating on both py2 and py3 at this point when it comes to tempest/grenade changes. Tempest changes are still gating on both so we have coverage there against breaking changes, but I think anything that's py2 specific would be caught in unit and functional tests (which we're running on both py27 and py3*). Who's with me? [1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135299.html [2] https://bugs.launchpad.net/tempest/+bug/1807723 [3] https://review.openstack.org/#/q/topic:drop-multiattach-job+(status:open+OR… [4] https://github.com/openstack/nova/blob/5283b464b/gate/post_test_hook.sh [5] https://review.openstack.org/#/c/634739/ -- Thanks, Matt

2 3

[dev][tc] Part 2: Evaluating projects in relation to OpenStack cloud vision
by Chris Dent 14 Feb '19

14 Feb '19

This a "part 2" or "other half" of evaluating OpenStack projects in relation to the technical vision. See the other threads [1][2] for more information. In the conversations that led up to the creation of the vision document [3] one of the things we hoped was that the process could help identify ways in which existing projects could evolve to be better at what they do. This was couched in two ideas: * Helping to make sure that OpenStack continuously improves, in the right direction. * Helping to make sure that developers were working on projects that leaned more towards interesting and educational than frustrating and embarrassing, where choices about what to do and how to do it were straightforward, easy to share with others, so well-founded in agreed good practice that argument would be rare, and so few that it was easy to decide. Of course, to have a "right direction" you first have to have a direction, and thus the vision document and the idea of evaluating how aligned a project is with that. The other half, then, is looking at the projects from a development standpoint and thinking about what aspects of the project are: * Things (techniques, tools) the project contributors would encourage others to try. Stuff that has worked out well. * Things—given a clean slate, unlimited time and resources, the benefit of hindsight and without the weight of legacy—the project contributors would encourage others to not repeat. And documenting those things so they can be carried forward in time some place other than people's heads, and new projects or refactorings of existing projects can start on a good foot. A couple of examples: * Whatever we might say about the implementation (in itself and how it is used), the concept of a unified configuration file format, via oslo_config, is probably considered a good choice, and we should keep on doing that. * On the other hand, given hindsight and improvements in commonly available tools, using a homegrown WSGI (non-)framework (unless you are Swift) plus eventlet may not have been the way to go, yet because it is what's still there in nova, it often gets copied. It's not clear at this point whether these sorts of things should be documented in projects, or somewhere more central. So perhaps we can just talk about it here in email and figure something out. I'll followup with some I have for placement, since that's the project I've given the most attention. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002524… [3] https://governance.openstack.org/tc/reference/technical-vision.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 11

[kolla] State of SELinux support
by Jason Anderson 14 Feb '19

14 Feb '19

Hey all, With CVE-2019-5736<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736> dropping today, I thought it would be a good opportunity to poke about the current state of SELinux support in Kolla. The docs<https://docs.openstack.org/kolla-ansible/rocky/user/security.html> have said it is a work in progress since the Mitaka release at least. I did find a spec<https://blueprints.launchpad.net/kolla/+spec/enable-selinux> that was marked as completed, but I am not aware that there is yet any support and I see that the baremetal role still forces SELinux to "permissive" by default. Is anybody currently working on this or is there an update spec/blueprint to track the development here? I am no SELinux expert by any means but this feels like an important thing to address, particularly if Docker has made it easier to label bind mounts<https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label>. Thanks! Jason Anderson Cloud Computing Software Developer Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory

2 1

[kolla][mariadb] Multinode deployment fails due to bootstrap_mariadb or mariadb errors
by Giuseppe Sannino 14 Feb '19

14 Feb '19

Hi all, need your help. I'm trying to deploy Openstack "Queens" via kolla on a multinode system (1 controller/kolla host + 1 compute). I tried with both binary and source packages and I'm using "ubuntu" as base_distro. The first attempt of deployment systematically fails here: TASK [mariadb : Running MariaDB bootstrap container] ******************************************************************************************************************************************************************************************************** fatal: [xx.yy.zz.136]: FAILED! => {"changed": true, "msg": "Container exited with non-zero return code 1"} Looking at the bootstrap_mariadb container logs I can see: ---------- Neither host 'xxyyzz' nor 'localhost' could be looked up with '/usr/sbin/resolveip' Please configure the 'hostname' command to return a correct hostname. ---------- Any idea ? Thanks a lot /Giuseppe

3 3

[blazar] Question about Interaction between Ironic and Blazar
by Tzu-Mainn Chen 14 Feb '19

14 Feb '19

Hi! I'm working with both Ironic and Blazar, and came across a strange interaction that I was wondering if the Blazar devs were aware of. I had four Ironic nodes registered, and only node A had an instance running on it. I tried adding node B - which was available - to the freepool and got this error: 2019-02-13 09:42:28.560 220255 ERROR oslo_messaging.rpc.server ERROR: Servers [[{u'uuid': u'298e83a4-7d5e-4aae-b89a-9dc74b4278af', u'name': u'instance-00000011'}]] found for host a00696d5-32ba-475e-9528-59bf11cffea6 This was strange, because the instance in question was running on node A, and not node B. After some investigation, the cause was identified as the following: https://bugs.launchpad.net/nova/+bug/1815793 But in the meantime, my question is: have other people using Blazar and Ironic run into this issue? It would seem to imply that Ironic nodes can only be added to the freepool if no instances are created, which poses a long-term maintenance issue. Is there a workaround? Thanks, Tzu-Mainn Chen

2 1

[tc][all][self-healing-sig] Service-side health checks community goal for Train cycle
by Jean-Philippe Evrard 14 Feb '19

14 Feb '19

Hello everyone, As you might have seen on the ML, two of the 3 top contenders for the Train cycle community got some traction. Let's here talk about the last one: The service-side health checks. While people were interested in this goal previously, nobody really came forward on the pre-work. Last week, I met a few of my colleagues to see what we can do together. Matt (irc: mattoliverau), Adam (irc: aspiers), and I discussed about the different ways to implement this new API, with the help of many in #openstack-sdk. Long story short, the current framework might be "good enough" for extension already, as we could have extra "backends" (basically "tests"), to increase the coverage of this healthcheck endpoint. While the immediate next step would be to work on the v2 prototype that Graham started (see link [1], anyone is welcome to help there!), the next step would be far easier if it was crowd sourced: We need to know which service is already using that oslo middleware, which service doesn't want to use it, and which service is already ready for healtchecks. When we'll have a lay of the land, we'll know where the energy will be spent in this community goal: Would that be bringing oslo.middleware to <insert amount here> services or bringing common "backends" that can be used by each service (like DB/MQ/cache checks). I would be very happy if you could have a look at this ethercal [2], and add/edit your project capabilities there. Thank you in advance. Jean-Philippe Evrard (evrardjp) [1]: https://review.openstack.org/#/c/617924/ [2]: https://ethercalc.openstack.org/di0mxkiepll8

4 5

[tripleo][ci] WARNING: All CI affected by a DPDK version bump
by Felix Enrique Llorente Pastora 14 Feb '19

14 Feb '19

Hi All, All the jobs from tripleo CI are currently failing at check, gate and promotions. There is a compatibility issue between OVS and DPDK versions we have a bypass to exclude problematic version. LP: https://bugs.launchpad.net/tripleo/+bug/1815863 Possible bypass: https://review.openstack.org/636860 BR -- Quique Llorente Openstack TripleO CI

1 0

[tc][uc] Becoming an Open Source Initiative affiliate org
by Thierry Carrez 14 Feb '19

14 Feb '19

I started a thread on the Foundation mailing-list about the OSF becoming an OSI affiliate org: http://lists.openstack.org/pipermail/foundation/2019-February/002680.html Please follow-up there is you have any concerns or questions. -- Thierry Carrez (ttx)

5 4

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

13 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 13 Feb '19

13 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 13 Feb '19

13 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

User Committee Elections - call for candidates
by Melvin Hillsman 13 Feb '19

13 Feb '19

The candidacy period for the upcoming UC election is open. Three seats will be filled. If you are an AUC and are interested in running for one of them, now is the time to announce it. Here are the important dates: February 04 - February 17, 05:59 UTC: Open candidacy for UC positions February 18 - February 24, 11:59 UTC: UC elections (voting) Special thanks to our election officials - Mohamed Elsakhawy and Jonathan Proulx! You can find all the info for the election here: https://governance.openstack.org/uc/reference/uc-election-feb2019.html You announce your candidacy by sending an email to user-committee(a)lists.openstack.org with the subject line UC Candidacy. Here are some great examples of previous candidate letters if you are having difficulty: http://lists.openstack.org/pipermail/user-committee/2018-August/002700.html http://lists.openstack.org/pipermail/user-committee/2018-August/002713.html http://lists.openstack.org/pipermail/user-committee/2018-February/002556.ht… http://lists.openstack.org/pipermail/user-committee/2018-February/002563.ht… -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

1 0

[kolla] Today meeting cancelled Feb-13-2019
by Eduardo Gonzalez 13 Feb '19

13 Feb '19

Hi team, Due to job responsabilities i won't be able to hold today's meeting. Meeting topics haven't changed since last week. If have something wanna discuss please add to next week meeting or raise in the main IRC channel. Regards

1 0

[nova][dev] Which response code should be returned when migrate is called but the src host is offline?
by Lee Yarwood 13 Feb '19

13 Feb '19

Hello all, I can't seem to settle on an answer for $subject as part this bugfix: compute: Reject migration requests when source is down https://review.openstack.org/#/c/623489/ 409 suggests that the user is able to address the issue while 503 suggests that n-api itself is at fault. I'd really appreciate peoples thoughts on this given I hardly ever touch n-api. Thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

4 5

How *-conductor (database accessor) assure concurrency?
by 양유석 13 Feb '19

13 Feb '19

Hi, guys. Today, I encountered strange behaviors and it raise me a simple question which I never concerned about. It's about 'how database accessors like *-conductor assure DB data consistency?' What I've seen is ModelsNotFound in Trove which meaning there is no sqlalchemy query result for the Trove DB model. I'm not sure what's happening before, but what I found is DB entry is actually existed but trove-conductor could not find it emitting exception continuously. At the same time, different trove-conductor would be working normally after restart. First, I thought that sqlalchemy ensures concurrency but after reading related document ( https://docs.sqlalchemy.org/en/latest/orm/session_basics.html#is-the-sessio…) it does not guarantee at all, and user should take all responsibility to manage session. After, I thought oslo.concurrency is promising to ensure consistency by making lock inter process in that the name tells me. But I could not find any related code for locking. So.. What happens internally for *-manage? Any hints would be appreciated. Thanks.

1 0

[cinder][dev] Bug for deferred deletion in RBD
by Jae Sang Lee 13 Feb '19

13 Feb '19

Hello, I recently ran a volume deletion test with deferred deletion enabled on the pike release. We experienced a cinder-volume hung when we were deleting a large amount of the volume in which the data was actually written(I make 15GB file in every volumes), and we thought deferred deletion would solve it. However, while deleting 200 volumes, after 50 volumes, the cinder-volume downed as before. In my opinion, the trash_move api does not seem to work properly when removing multiple volumes, just like remove api. If these test results are my fault, please let me know the correct test method.

3 14

[scientific-sig] IRC Meeting 1100UTC: ISC participation, Summit Forum, GPFS follow-up
by Stig Telfer 13 Feb '19

13 Feb '19

Hi All - We have a Scientific SIG IRC meeting at 1100 UTC (just over an hour away) in channel #openstack-meeting. Everyone is welcome. This week’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_13th_20… <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_13th_20…> We’d like to continue the discussions on SIG participation in up-and-coming conferences, and also follow up on user experiences of the GPFS/Manila driver. If anyone has other items to raise, please do add them to the agenda. Cheers, Stig

1 0

Re: [kolla][mariadb] Multinode deployment fails due to bootstrap_mariadb or mariadb errors (Giuseppe Sannino)
by Viktor Shulhin 13 Feb '19

13 Feb '19

Hi Giuseppe, Seems like deployments with Ubuntu base distros are broken. I didn't find any solution for that. I have deployed Rocky with Centos based distro on Ubuntu 16.04 host recently. Some parameters from /etc/kolla/globals.yml are: kolla_base_distro: "centos" kolla_install_type: "binary" openstack_release: "rocky" >Hi all, >need your help. >I'm trying to deploy Openstack "Queens" via kolla on a multinode system (1 >controller/kolla host + 1 compute). >I tried with both binary and source packages and I'm using "ubuntu" as >base_distro.

1 0

[manila][glusterfs] on queens error
by Ignazio Cassano 13 Feb '19

13 Feb '19

Hello All, I installed manila on my queens openstack based on centos 7. I configured two servers with glusterfs replocation and ganesha nfs. I configured my controllers octavia,conf but when I try to create a share the manila scheduler logs reports: Failed to schedule create_share: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter.: NoValidHost: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter. 2019-01-31 16:07:32.614 159380 INFO manila.message.api [req-241d66b3-8004-410b-b000-c6d2d3536e4a 89f76bc5de5545f381da2c10c7df7f15 59f1f232ce28409593d66d8f6495e434 - - -] Creating message record for request_id = req-241d66b3-8004-410b-b000-c6d2d3536e4a I did not understand if controllers node must be connected to the network where shares must be exported for virtual machines, so my glusterfs are connected on the management network where openstack controllers are conencted and to the network where virtual machine are connected. My manila.conf section for glusterfs section is the following [gluster-manila565] driver_handles_share_servers = False share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver glusterfs_target = root@10.102.184.229:/manila565 glusterfs_path_to_private_key = /etc/manila/id_rsa glusterfs_ganesha_server_username = root glusterfs_nfs_server_type = Ganesha glusterfs_ganesha_server_ip = 10.102.184.229 #glusterfs_servers = root(a)10.102.185.19 ganesha_config_dir = /etc/ganesha PS 10.102.184.0/24 is the network where controlelrs expose endpoint 10.102.189.0/24 is the shared network inside openstack where virtual machines are connected. The gluster servers are connected on both. Any help, please ? Ignazio

3 14

[keystone] x509 authentication
by Lance Bragstad 12 Feb '19

12 Feb '19

Hi all, We've been going over keystone gaps that need to be addressed for edge use cases every Tuesday. Since Berlin, Oath has open-sourced some of their custom authentication plugins for keystone that help them address these gaps. The basic idea is that users authenticate to some external identity provider (Athenz in Oath's case), and then present an Athenz token to keystone. The custom plugins decode the token from Athenz to determine the user, project, roles assignments, and other useful bits of information. After that, it creates any resources that don't exist in keystone already. Ultimately, a user can authenticate against a keystone node and have specific resources provisioned automatically. In Berlin, engineers from Oath were saying they'd like to move away from Athenz tokens altogether and use x509 certificates issued by Athenz instead. The auto-provisioning approach is very similar to a feature we have in keystone already. In Berlin, and shortly after, there was general agreement that if we could support x509 authentication with auto-provisioning via keystone federation, that would pretty much solve Oath's use case without having to maintain custom keystone plugins. Last week, Colleen started digging into keystone's existing x509 authentication support. I'll start with the good news, which is x509 authentication works, for the most part. It's been a feature in keystone for a long time, and it landed after we implemented federation support around the Kilo release. Chances are there won't be a need for a keystone specification like we were initially thinking in the edge meetings. Unfortunately, the implementation for x509 authentication has outdated documentation, is extremely fragile, hard to set up, and hasn't been updated with improvements we've made to the federation API since the original implementation (like shadow users or auto-provisioning, which work with other federated protocols like OpenID Connect and SAML). We've started tracking the gaps with bugs [0] so that we have things written down. I think the good thing is that once we get this cleaned up, we'll be able to re-use some of the newer federation features with x509 authentication/federation. These updates would make x509 a first-class federated protocol. The approach, pending the bug fixes, would remove the need for Oath's custom authentication plugins. It could be useful for edge deployments, or even deployments with many regions, by allowing users to be auto-provisioned in each region. Although, it doesn't necessarily solve the network partition issue. Now that we have an idea of where to start and some bug reports [0], I'm wondering if anyone is interested in helping with the update or refactor. Because this won't require a specification, we can get started on it sooner, instead of having to wait for Train development and a new specification. I'm also curious if anyone has comments or questions about the approach. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509

4 6

[openstack-ansible] bug squash day!
by Mohammed Naser 12 Feb '19

12 Feb '19

Hi team, As you may have noticed, bug triage during our meetings has been something that has kinda killed attendance (really, no one seems to enjoy it, believe it or not!) I wanted to propose for us to take a day to go through as much bugs as possible, triaging and fixing as much as we can. It'd be a fun day and we can also hop on a more higher bandwidth way to talk about this stuff while we grind through it all. Is this something that people are interested in, if so, is there any times/days that work better in the week to organize? Thanks! Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 9

[neutron] CI issue related to pyroute2 and latest oslo.privsep
by Slawomir Kaplonski 12 Feb '19

12 Feb '19

Hi, Recently we had one more issue related to oslo.privsep and pyroute2. This caused many failures in Neutron CI. See [1] for details. Now fix (more like a workaround) for this issue is merged [2]. So if You saw in Your patch failing tempest/scenario jobs and in failed tests there were issues with SSH to instance through floating IP, please now rebase Your patch. It should be better :) [1] https://bugs.launchpad.net/neutron/+bug/1811515 [2] https://review.openstack.org/#/c/631275/ — Slawek Kaplonski Senior software engineer Red Hat

2 2

[tc] smcginnis non-nomination for TC
by Sean McGinnis 12 Feb '19

12 Feb '19

As Chris said, it is probably good for incumbents to make it known if they are not running. This is my second term on the TC. It's been great being part of this group and trying to contribute whatever I can. But I do feel it is important to make room for new folks to regularly join and help shape things. So with that in mind, along with the need to focus on some other areas for a bit, I do not plan to run in the upcoming TC election. I would highly encourage anyone interested to run for the TC. If you have any questions about it, feel free to ping me for any thoughts/advice/feedback. Thanks for the last two years. I think I've learned a lot since joining the TC, and hopefully I have been able to contribute some positive things over the years. I will still be around, so hopefully I will see folks in Denver. Sean

6 5

[tc] cdent non-nomination for TC
by Chris Dent 12 Feb '19

12 Feb '19

Next week sees the start of election season for the TC [1]. People often worry that incumbents always get re-elected so it is considered good form to announce if you are an incumbent and do not intend to run. I do not intend to run. I've done two years and that's enough. When I was first elected I had no intention of doing any more than one year but at the end of the first term I had not accomplished much of what I hoped, so stayed on. Now, at the end of the second term I still haven't accomplished much of what I hoped, so I think it is time to focus my energy in the places where I've been able to get some traction and give someone else—someone with a different approach—a chance. If you're interested in being on the TC, I encourage you to run. If you have questions about it, please feel free to ask me, but also ask others so you get plenty of opinions. And do your due diligence: Make sure you're clear with yourself about what the TC has been, is now, what you would like it to be, and what it can be. Elections are fairly far in advance of the end of term this time around. I'll continue in my TC responsibilities until the end of term, which is some time in April. I'm not leaving the community or anything like that, I'm simply narrowing my focus. Over the past several months I've been stripping things back so I can be sure that I'm not ineffectively over-committing myself to OpenStack but am instead focusing where I can be most useful and make the most progress. Stepping away from the TC is just one more part of that. Thanks very much for the experiences and for the past votes. [1] https://governance.openstack.org/election/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

7 6

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

12 Feb '19

On Wed, Jan 23, 2019 at 9:27 AM Fox, Kevin M <Kevin.Fox(a)pnnl.gov<mailto:Kevin.Fox@pnnl.gov>> wrote: > > I'd recommend at this point to maybe just run kubernetes across the vms and push the guest agents/workload to them. > This sounds like an overkill to me. Currently, different projects in openstack are solving this issue > in different ways, e.g. Octavia is using two-way SSL authentication API between the controller service and amphora(which is the vm running HTTP server inside), Magnum is using heat-container-agent that is communicating with Heat via API, etc. However, Trove chooses another option which has brought a lot of discussions over a long time. > In the current situation, I don't think it's doable for each project heading to one common solution, but Trove can learn from other projects to solve its own problem. > Cheers, > Lingxian Kong The Octavia way of communication was discussed by Trove several times in the context of secuirty. However, the security threat has been eliminated by encryption. I'm wondering if the Octavia way prevents DDOS attacks also ? Implementation of two-way SSL authentication API could be included in the Trove priority list IMHO if it solves all issues with security/DDOS attacks. This could also creates some share code between both projects and help other services as well. Best, Darek

4 5

Denver PTG Attending Teams
by Kendall Nelson 12 Feb '19

12 Feb '19

Hello! The results are in! Here are the list of teams that are planning to attend the upcoming PTG in Denver, following the summit. Hopefully we are getting it to you soon enough to plan travel. If you haven't already registered yet, you can do that here[1]. If you haven't booked your hotel yet, please please please use our hotel block here[2]. ----------------------------------------- Pilot Projects: - Airship - Kata Containers - StarlingX OpenStack Components: - - Barbican - Charms - Cinder - Cyborg - Docs/I18n - Glance - Heat - Horizon - Infrastructure - Ironic - Keystone - LOCI - Manila - Monasca - Neutron - Nova - Octavia - OpenStack Ansible - OpenStack QA - OpenStackClient - Oslo - Placement - Release Management - Requirements - Swift - Tacker - TripleO - Vitrage - OpenStack-Helm SIGs: - API-SIG - AutoScaling SIG - Edge Computing Group - Extended Maintenance SIG - First Contact SIG - Interop WG/RefStack - K8s SIG - Scientific SIG - Security SIG - Self-healing SIG ------------------------------------------ If your team is missing from this list, its because I didn't get a 'yes' response from your PTL/Chair/Contact Person. Have them contact me and we can try to work something out. Now that we have this list, we will start putting together a draft schedule. See you all in Denver! -Kendall (diablo_rojo) [1] https://www.eventbrite.com/e/open-infrastructure-summit-project-teams-gathe… [2] https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE

1 0

[ironic] should console be renamed to seriale_console ?
by elfosardo 12 Feb '19

12 Feb '19

Greetings Openstackers! Currently ironic supports only one type of console: serial The current implementation also gives as assumed the support for just one type of console, but not that long ago a spec to also support a graphical console type [1] has been accepted and we're now close to see a first patch with basic support merged [2]. With the introduction of the support for the graphical console, the need to define a new parameter called "console_type" has been recognized. In practice, at the moment that would mean having "console" and "graphical" as console types, which could result in a confusing and in the end not correct implementation. With this message I'd like to start a discussion on the potential impact of the possible future renaming of everything that currently involves the serial console from "console" to "serial_console" or equivalent. Thanks, Riccardo [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/vn… [2] https://review.openstack.org/#/c/547356/

1 0

[PTLs] Got unfinished business from Berlin?
by Matt Van Winkle 12 Feb '19

12 Feb '19

Greetings, PTLs, cores or anyone on point for a key feature, In an effort to make the feedback loop even stronger between the dev and ops community, the UC is actively looking for any unfinished etherpads or topics from the Berlin summit that need more Ops input. We'd like to get them proposed as potential topics at the upcoming Ops Meetup (strangely enough back in Berlin) [1] If you have something your dev team needs input on, please propose it here: [2] so it can get voted on by the attendees and organizers. There is a section titled "Session Ideas" that you can list the topic in. Feel free to link an etherpad if one exists. The UC will continue to push to tie discussions at forums/PTGs to those at the Ops meetups and OpenStack Days - and vice versa. Thanks in advance! VW [1] https://www.eventbrite.com/e/openstack-ops-meetup-berlin-tickets-55034908894 [2] https://etherpad.openstack.org/p/BER-ops-meetup -- Matt Van Winkle Senior Manager, Software Engineering | Salesforce

1 0

[ops] last weeks ops meetups team minutes
by Chris Morgan 12 Feb '19

12 Feb '19

Meeting ended Tue Feb 5 15:31:14 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:31 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:31 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:31 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Next meeting is in 25 minutes on #openstack-operators Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[nova] Can we drop the cells v1 docs now?
by Matt Riedemann 12 Feb '19

12 Feb '19

I have kind of lost where we are on dropping cells v1 code at this point, but it's probably too late in Stein. And technically nova-network won't start unless cells v1 is configured, and we've left the nova-network code in place while CERN is migrating their deployment to neutron*. CERN is running cells v2 since Queens and I think they have just removed this [1] to still run nova-network without cells v1. There has been no work in Stein to remove nova-network [2] even though we still have a few API related things we can work on removing [3] but that is very low priority. To be clear, CERN only cares about the nova-network service, not the APIs which is why we started removing those in Rocky. As for cells v1, if we're not going to drop it in Stein, can we at least make incremental progress and drop the cells v1 related docs to further signal the eventual demise and to avoid confusion in the docs about what cells is (v1 vs v2) for newcomers? People can still get the cells v1 in-tree docs on the stable branches (which are being published [4]). [1] https://github.com/openstack/nova/blob/bff3fd1cd/nova/cmd/network.py#L43 [2] https://blueprints.launchpad.net/nova/+spec/remove-nova-network-stein [3] https://etherpad.openstack.org/p/nova-network-removal-rocky [4] https://docs.openstack.org/nova/queens/user/cells.html#cells-v1 *I think they said there are parts of their deployment that will probably never move off of nova-network, and they will just maintain a fork for that part of the deployment. -- Thanks, Matt

3 2

[tripleo][openstack-ansible] collaboration on os_tempest role update X - Feb 12, 2019
by Chandan kumar 12 Feb '19

12 Feb '19

Hello, Here is the 10th update (Feb 06 to Feb 12, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: This week we basically worked on clearing up/merging the existing patches like: * For debugging networking issue for os_tempest, we have router ping * Added telemetry tempest plugin support * The os_tempest overview page got rewrite: https://docs.openstack.org/openstack-ansible-os_tempest/latest/overview.html * Added use of user/password for secure image download And from myside, not to much work as busy with ruck/rover on TripleO Side. Things got merged OS_TEMPEST: * Update all plugin urls to use https rather than git - https://review.openstack.org/633752 * venv: use inventory_hostname instead of ansible_hostname - https://review.openstack.org/635187 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Add user and password for secure image download (optional) - https://review.openstack.org/625266 * Ping router once it is created - https://review.openstack.org/633883 * Improve overview subpage - https://review.openstack.org/633934 python-venv_build: * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/634377 In Progress work: OS_TEMPEST * Use the correct heat tests - https://review.openstack.org/#/c/630695/ * Add option to disable router ping - https://review.openstack.org/636211 * Add tempest_service_available_mistral with distro packages - https://review.openstack.org/635180 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 TripleO: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Goal of this week: * Unblock os_heat gate due to mpi4py dependency and other issue * Complete skip list reuse on tripleo side Thanks to jrosser, mnaser, odyssey4me, guilhermesp on router_ping, os_heat help, arxcruz on reuse skip list & mkopec for improving doc. Here is the 9th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002382… Thanks, Chandan Kumar

1 0

[Neutron] Multi segment networks
by Ricardo Noriega De Soto 12 Feb '19

12 Feb '19

Hello guys, Quick question about multi-segment provider networks. Let's say I create a network and a subnet this way: neutron net-create multinet --segments type=dict list=true provider:physical_network='',provider:segmentation_id=1500,provider:network_type=vxlan provider:physical_network=physnet_sriov,provider:segmentation_id=2201,provider:network_typ e=vlan neutron subnet-create multinet --allocation-pool start=10.100.5.2,end=10.100.5.254 --name mn-subnet --dns-nameserver 8.8.8.8 10.100.5.0/24 Does it mean, that placing two VMs (with regular virtio interfaces), one in the vxlan segment and one on the vlan segment, would be able to ping each other without the need of a router? Or would it require an external router that belongs to the owner of the infrastructure? Thanks in advance! -- Ricardo Noriega Senior Software Engineer - NFV Partner Engineer | Office of Technology | Red Hat irc: rnoriega @freenode

2 1

[dev] [neutron] bug deputy report of the week of Feb 4
by Akihiro Motoki 11 Feb '19

11 Feb '19

Hi neutrinos, I was a bug deputy last week. The last week was relatively quiet. The following * Needs investigation * https://bugs.launchpad.net/neutron/+bug/1815463 (New) [dev] Agent RPC version does not auto upgrade if neutron-server restart first * ovsdbapp.exceptions.TimeoutException in functional tests (gate failure) https://bugs.launchpad.net/bugs/1815142 * In Progress * https://bugs.launchpad.net/bugs/1815345 (Medium, In Progress) neutron doesnt delete port binding level when deleting an inactive port binding * Incomplete * https://bugs.launchpad.net/bugs/1815424 (Incomplete) Port gets port security disabled if using --no-security-groups I cannot reproduce it. Requesting the author more information. * FYI * https://bugs.launchpad.net/bugs/1815433 Code crash with invalid connection limit of listener neutron-lbaas bug needs to be filed to storyboard. I requested it to the bug author and he/she filed it. [1] https://storyboard.openstack.org/#!/project/openstack/neutron-lbaas Best Regards, Akihiro Motoki (irc: amotoki)

1 1

[cinder] Help with Fedora 29 devstack volume/iscsi issues
by Ian Wienand 11 Feb '19

11 Feb '19

Hello, I'm trying to diagnose what has gone wrong with Fedora 29 in our gate devstack test; it seems there is a problem with the iscsi setup and consequently the volume based tempest tests all fail. AFAICS we end up with nova hitting parsing errors inside os_brick's iscsi querying routines; so it seems whatever error path we've hit is outside the usual as it's made it pretty far down the stack. I have a rather haphazard bug report going on at https://bugs.launchpad.net/os-brick/+bug/1814849 as I've tried to trace it down. At this point, it's exceeding the abilities of my cinder/nova/lvm/iscsi/how-this-all-hangs-together knowledge. The final comment there has a link the devstack logs and a few bits and pieces of gleaned off the host (which I have on hold and can examine) which is hopefully useful to someone skilled in the art. I'm hoping ultimately it's a rather simple case of a missing package or config option; I would greatly appreciate any input so we can get this test stable. Thanks, -i

2 2