May 2019 - openstack-discuss - lists.openstack.org

[kolla] Stepping down from core reviewer
by Martin André 24 May '19

24 May '19

Hi all, It became clear over the past few months I no longer have the time to contribute to Kolla in a meaningful way and would like to step down from core reviewer. It was an honor to be part of this great team, you fools who trusted me enough to give me +2 powers. Thanks, and long live Kolla! Martin

3 2

[heat][neutron] improving extraroute support
by Bence Romsics 24 May '19

24 May '19

Hi Heat and Neutron folks, I'm wondering how could I improve support for extra routes for one of our users. In this email I'd like to get your input (from both Heat and Neutron folks) in which direction should I start before I sit down to write the relevant blueprints and RFEs. This will be a bit long, please bear with me. As you know a neutron router can have extra static routing table entries as the 'routes' attribute like this (please see the api-ref in [1]): $ openstack router show router1 -f value -c routes destination='10.1.0.0/24', gateway='10.0.0.11' destination='10.2.0.0/24', gateway='10.0.0.12' ... To my best knowledge the whole set of extra routes must be updated at once which easily leads to lost updates if multiple clients modify this attribute concurrently (imagine client A and B working concurrently, for example both reads routes [r1], client A writes [r1, r2], client B writes [r1, r3]; depending on timing either r2 or r3 will be lost). Heat has an unsupported resource OS::Neutron::ExtraRoute [2] to front Neutron extra routes. For example: heat_template_version: '2015-04-30' resources: Extra_route_1: type: OS::Neutron::ExtraRoute properties: destination: '10.1.0.0/24' nexthop: '10.0.0.11' router_id: 'd544b5c5-d4d2-4b52-aaa8-ef4b9fa3e154' The Heat resource represents a single extra route out of the many in the router's routes attribute. If you have multiple OS::Neutron::ExtraRoute resources Heat by default handles them concurrently leading to the lost update problem. You can easily reproduce the problem just by having 10 extra routes in a template. The stack creation will succeed, but the router in fact will have only 6-7 (the exact number changes based on timing) extra routes. AFAIU this is exactly why this was marked unsupported. (Please let me know if you know other reasons.) As a workaround I suggested our user a hack to serialize the OS::Neutron::ExtraRoute resources by 'depends_on'. But which way should I go if I want to fix this properly? way #1 - changes in Heat only: Introduce a new Heat resource OS::Neutron::ExtraRoutes (please notice the plural) which can represent the whole routes attribute of a router (i.e. multiple extra routes in a single resource). This will not solve the design shortcomings of the neutron extraroute API, but it can at least express what can be done in the Neutron API as is. Lost updates of multiple stacks editing the same router's routes are still possible. way #2 - changes in Heat and Neutron: Introduce a new Neutron extension with a better API (either extraroutes as a top level resource, each object with a router_id or an action map a'la add/remove_router_interface to edit extra routes on the server side). This new API would work on the same DB tables and backends as the old. The old API would be kept for backwards compatibility. But if a new user exclusively uses the new API it can work concurrently. Then introduce a new Heat resource (or change the existing unsupported one) to use this new Neutron API. This is obviously more work than the first option. Which one do you prefer and why? Or let me know please if I missed a better alternative. In this thread I hope to get a cross-project agreement of this between Heat and Neutron so I can go ahead and open the relevant Heat and Neutron blueprints where we can focus only on each projects' internal questions. Thanks in advance, Bence Romsics irc: rubasov [1] https://developer.openstack.org/api-ref/network/v2/?expanded=update-router-… [2] https://docs.openstack.org/heat/latest/template_guide/unsupported.html#OS::…

4 11

Re: Fwd: Summit video website shenanigans
by Jimmy McArthur 24 May '19

24 May '19

Hey Matt, I responded to the cut-off video via speaker support. We had 8 videos that were truncated, but most were only by a few seconds. Yours was the unfortunate 15 minute chop and I'm afraid that one is irretrievable. Look over the option I sent in speaker support ticket and let me know if that's something you're interested in. Re: https://www.openstack.org/summit/denver-2019/summit-schedule/events/23234/o… This one appears to be blocked as a duplicate video by YouTube. I'm trying to sort this out as we speak. I'll update this thread as soon as I have an answer. If anyone else out there notices any other shenanigans, please don't hesitate to respond to this thread or directly via speakersupport(a)openstack.org where we have our devs and Foundation support staff all looking out. Cheers, Jimmy Allison Price wrote: > > > >> Begin forwarded message: >> >> *From: *Matt Riedemann <mriedemos(a)gmail.com <mailto:mriedemos@gmail.com>> >> *Subject: **Re: Summit video website shenanigans* >> *Date: *May 23, 2019 at 11:09:53 AM CDT >> *To: *"openstack-discuss(a)lists.openstack.org >> <mailto:openstack-discuss@lists.openstack.org>" >> <openstack-discuss(a)lists.openstack.org >> <mailto:openstack-discuss@lists.openstack.org>> >> >> On 5/14/2019 5:42 PM, Kendall Nelson wrote: >>> They are doing some more research to see if there are other videos >>> facing the same issues, but it should all be fine now? >> >> This one also appears to still be busted and/or lost. >> >> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23234/o… >> >> -- >> >> Thanks, >> >> Matt >> >

1 1

[placement] update 19-20
by Chris Dent 24 May '19

24 May '19

HTML: https://anticdent.org/placement-update-19-20.html Placement update 19-20. Lots of cleanups in progress, laying in the groundwork to do the nested magic work (see themes below). The poll to determine [what to do with the weekly meeting](https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_9599a2647c319fd4&… will close at the end of today. Thus far the leader is office hours. Whatever the outcome, the meeting that would happen this coming Monday is cancelled because many people will be having a holiday. # Most Important The [spec for nested magic](https://review.opendev.org/658510) is ready for more robust review. Since most of the work happening in placement this cycle is described by that spec, getting it reviewed well and quickly is important. Generally speaking: review things. This is, and always will be, the most important thing to do. # What's Changed * os-resource-classes 0.4.0 was released, promptly breaking the placement gate (tests are broken not os-resource-classes). [Fixes underway](https://review.opendev.org/661131). * [Null root provider protections](https://review.opendev.org/657716) have been removed and a blocker migration and status check added. This removes a few now redundant joins in the SQL queries which should help with our ongoing efforts to speed up and simplify getting allocation candidates. * I had suggested an additional core group for os-traits and os-resource-classes but after discussion with various people it was decided it's easier/better to be aware of the right subject matter experts and call them in to the reviews when required. # Specs/Features * <https://review.opendev.org/654799> Support Consumer Types. This is very close with a few details to work out on what we're willing and able to query on. It's a week later and it still only has reviews from me so far. * <https://review.opendev.org/658510> Spec for Nested Magic. Un-wipped. * <https://review.opendev.org/657582> Resource provider - request group mapping in allocation candidate. This spec was copied over from nova. It is a requirement of the overall nested magic theme. While it has a well-defined and refined design, there's currently no one on the hook implement it. These and other features being considered can be found on the [feature worklist](https://storyboard.openstack.org/#!/worklist/594). Some non-placement specs are listed in the Other section below. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 20 (-3) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 are [untagged](https://storyboard.openstack.org/#!/worklist/580). 2 (-2) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (-1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 2 are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. On launchpad: * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 16 (0). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 7 (+1). # osc-placement osc-placement is currently behind by 11 microversions. No change since the last report. Pending changes: * <https://review.openstack.org/#/c/640898/> Add 'resource provider inventory update' command (that helps with aggregate allocation ratios). * <https://review.openstack.org/#/c/651783/> Add support for 1.22 microversion * <https://review.openstack.org/586056> Provide a useful message in the case of 500-error # Main Themes ## Nested Magic At the PTG we decided that it was worth the effort, in both Nova and Placement, to make the push to make better use of nested providers — things like NUMA layouts, multiple devices, networks — while keeping the "simple" case working well. The general ideas for this are described in a [story](https://storyboard.openstack.org/#!/story/2005575) and an evolving [spec](https://review.opendev.org/658510). Some code has started, mostly to reveal issues: * <https://review.opendev.org/657419> Changing request group suffix to string * <https://review.opendev.org/657510> WIP: Allow RequestGroups without resources * <https://review.opendev.org/657463> Add NUMANetworkFixture for gabbits * <https://review.opendev.org/658192> Gabbi test cases for can_split ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. A [spec](https://review.opendev.org/654799) has started. There are some questions about request and response details that need to be resolved, but the overall concept is sound. ## Cleanup As we explore and extend nested functionality we'll need to do some work to make sure that the code is maintainable and has suitable performance. There's some work in progress for this that's important enough to call out as a theme: * <https://storyboard.openstack.org/#!/story/2005712> Some work from Tetsuro exploring ways to remove redundancies in the code. There's a [stack of good improvements](https://review.opendev.org/658778). * <https://review.opendev.org/643269> WIP: Optionally run a wsgi profiler when asked. This was used to find some of the above issues. Should we make it generally available or is it better as a thing to base off when exploring? * <https://review.opendev.org/660691> Avoid traversing summaries in _check_traits_for_alloc_request Ed Leafe has also been doing some intriguing work on using graph databases with placement. It's not yet clear if or how it could be integrated with mainline placement, but there are likely many things to be learned from the experiment. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are several [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Starting with the next pupdate I'll also be removing anything that has had no reviews and no activity from the author in 4 weeks. Otherwise these lists get too long and uselessly noisy. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/625284> Cyborg: Initial readme for nova pilot * <https://review.openstack.org/629142> Tempest: Add QoS policies and minimum bandwidth rule client * <https://review.openstack.org/648687> Nova-spec: Add PENDING vm state * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.openstack.org/651024> nova-spec: RMD Plugin: Energy Efficiency using CPU Core P-State control * <https://review.openstack.org/650963> nova-spec: Proposes NUMA affinity for vGPUs. This describes a legacy way of doing things because affinity in placement may be a ways off. But it also [may not be](https://review.openstack.org/650476). * <https://review.openstack.org/#/q/topic:heal_allocations_dry_run> Nova: heal allocations, --dry-run * <https://review.opendev.org/656448> Watcher spec: Add Placement helper * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/657884> Nova: Spec to pre-filter disabled computes with placement * <https://review.opendev.org/657801> rpm-packaging: placement service * <https://review.opendev.org/657016> Delete resource providers for all nodes when deleting compute service * <https://review.opendev.org/654066> nova fix for: Drop source node allocations if finish_resize fails * <https://review.opendev.org/660924> neutron: Add devstack plugin for placement service plugin * <https://review.opendev.org/661179> ansible: Add playbook to test placement * <https://review.opendev.org/656885> nova: WIP: Hey let's support routed networks y'all! # End As indicated above, I'm going to tune these pupdates to make sure they are reporting only active links. This doesn't mean stalled out stuff will be ignored, just that it won't come back on the lists until someone does some work related to it. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[OpenStack][Foreman][MAAS][Juju][Kubernetes][Docker] OpenStack deployment on Bare Metal
by Jay See 24 May '19

24 May '19

Hi, I am trying to deploy OpenStack cloud , before proceeding with deployment I wanted to take suggestion from people using some of these technologies. *Setup / plan:* I will be deploying OpenStack cloud using 3 nodes (servers), later on I will be adding more nodes. I want automatically install and provision the OS on the new nodes. I want scale up my cloud with new nodes in near future. If there are any issues in existing OpenStack, I would like to fix them or patch the fixes without much trouble. (I might be using wrong terminology - sorry for that) 1. Which tool is better for Bare Metal OS installation? I have looked around and found Foremen and MaaS. All the servers we are going to deploy will be running on Ubuntu (16.04 /18.04 LTS). If you have any other suggestions please let me know. 2. Do you suggest me to use Juju to deploy the OpenStack or do all the manual installation for the OpenStack as mentioned in OpenStack installation guide? 3. I am bit confused about choosing Kubernetes. If I am going with Juju, can I still use Kubernetes? If yes, if there any documentation please guide me in right direction. 4. I was thinking of going with OpenStack installation over Kubernetes. Is this a right decision? or Do I need to do some research between Kubernetes and Docker, find out which one is better? or Just install OpenStack without any containers. 5. I could not find installation of OpenStack with Kubernetes or Docker. If you know something, could you share the link? I don't have bigger picture at the moment. If some tools might help in near future. or If you can give any other suggestions, please let me know. Thanks and Best regards, Jayachander.

2 1

[networking-sfc] Unable to get Service Function Chain Mechanism working in Neutron
by Kalyani Rajkumar 24 May '19

24 May '19

Hi, I have been trying to enable the networking SFC mechanism in OpenStack. I have successfully created port pairs, port pair groups, port chain and a flow classifier. However, I am unable to get the service chain working. The architecture of the set up I have deployed is attached. I have used the queens version of OpenStack. The steps that I followed are as below. * Create port neutron port-create --name <p1-p6> sfc-Network * Create VMs and attach the interfaces with them accordingly VM1 - P1 & P2; VM2 - P3 & P4; VM3 - P5 & P6 * Create port pairs neutron port-pair-create pp1 -- ingress p1 -- egress p2 neutron port-pair-create pp2 -- ingress p3 -- egress p4 neutron port-pair-create pp3 -- ingress p5 -- egress p6 * Create port pair groups neutron port-pair-group-create -- port-pair pp1 ppg1 neutron port-pair-group-create -- port-pair pp2 ppg2 neutron port-pair-group-create -- port-pair pp3 ppg3 * Create flow classifier neutron flow-classifier-create --source-ip-prefix <ip of p1> --destination-ip-prefix <ip of p6> --logical-source-port p1 fc1 * Create port chain neutron port-chain-create --port-pair-group ppg1 --port-pair-group ppg2 --port-pair-group ppg3 --flow-classifier fc1 pc1 I am testing this architecture by sending a ping request from VM1 to VM3. Therefore, the destination port is P6. If SFC is working correctly, I should be able to see the packets go through the VM2 to VM3 when I do a tcpdump in VM2. As I am new to OpenStack and SFC, I am not certain if this is logically correct. I would like to pose two questions. 1) All the VMs are on the same network, is it logically correct to expect the ping packets to be routed from VM1 > VM2 > VM3 in the SFC scenario? Because all the ports are on the same network, I get a ping response but it is not via VM2 even though the port chain is created through VM2. 2) If not, how do I make sure that the packets are routed through VM2 which is the second port pair in the port pair chain. Could it be something to do with the OpenVSwitch configuration? Any help would be highly appreciated. Regards, Kalyani Rajkumar High Performance Networks Group, University of Bristol

1 1

[nova] stable-maint is especially unhealthily RH-centric
by Matthew Booth 24 May '19

24 May '19

During the trifecta discussions at PTG I was only considering nova-core. I didn't appreciate at the time how bad the situation is for nova-stable-maint. nova-stable-maint currently consists of: https://review.opendev.org/#/admin/groups/540,members https://review.opendev.org/#/admin/groups/530,members Not Red Hat: Claudiu Belu -> Inactive? Matt Riedemann John Garbutt Matthew Treinish Red Hat: Dan Smith Lee Yarwood Sylvain Bauza Tony Breeds Melanie Witt Alan Pevec Chuck Short Flavio Percoco Tony Breeds This leaves Nova entirely dependent on Matt Riedemann, John Garbutt, and Matthew Treinish to land patches in stable, which isn't a great situation. With Matt R temporarily out of action that's especially bad. Looking for constructive suggestions. I'm obviously in favour of relaxing the trifecta rules, but adding some non-RH stable cores also seems like it would be a generally healthy thing for the project to do. Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK)

7 8

Re: [tripleo][Release-job-failures] Tag of openstack/tripleo-upgrade failed
by Tony Breeds 24 May '19

24 May '19

On Thu, May 23, 2019 at 11:58:20PM +0000, zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/e3/e350fb6648441ce0b33f7960cee7ba81083b1adb/tag/p… : FAILURE in 5m 42s This failed because the releasenotes don't build[1]: Could not import extension openstackdocstheme (exception: No module named 'openstackdocstheme' The publish of the sdist and wheels worked. https://review.opendev.org/661203, should fix the failure but we probably also want to add releasenotes to the check (and gate) pipelines Yours Tony. [1] http://logs.openstack.org/e3/e350fb6648441ce0b33f7960cee7ba81083b1adb/tag/p…

1 0

[all][requirements][stable] requests version bump on stable brances {pike|queens} for CVE-2018-18074
by Matthew Thode 24 May '19

24 May '19

Hi all, This is a warning and call to test the requests updates linked below. The best way to test is to make a dummy review in your project that depends on the linked review (either Pike or Queens). Upstream has no intrest or (easy) ability to backport the patch. Please let us know either in the the #openstack-requirements channel or in this email thread if you have issues. Pike - 2.18.2 -> 2.20.1 - https://review.opendev.org/640727 Queens - 2.18.4 -> 2.20.1 - https://review.opendev.org/640710 -- Matthew Thode

7 27

[autohealing] Demo of Application Autohealing in OpenStack (Heat + Octavia + Aodh)
by Lingxian Kong 24 May '19

24 May '19

Please see the demo here: https://youtu.be/dXsGnbr7DfM --- Best regards, Lingxian Kong Catalyst Cloud

4 4