- openstack-discuss - lists.openstack.org

[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