- openstack-discuss - lists.openstack.org

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

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

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

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

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

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

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

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

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

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

15 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