- openstack-discuss - lists.openstack.org

[searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 11 Mar '19

11 Mar '19

Hi team, We will have a team meeting today at 13:30 UTC on #openstack-searchlight as usual. Please check out meeting agenda at [1]. Bests, [1] https://etherpad.openstack.org/p/search-team-meeting-agenda -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[dev][qa] New time options for QA Office Hour
by Ghanshyam Mann 11 Mar '19

11 Mar '19

Hello Everyone, As you all, I have been moved to CST TZ, which need to select the new time for QA office hour. Till now, we have scheduled two office hours ( Thursday every week at 09:00 UTC and 17:00 UTC) and 17 UTC was not so active. Let's covert two office hours into one and select the new time for the same. I have created the doodle vote for that, please cast your vote as per your availability and schedule. Or let me know if none of the options are good so that I can propose the new time. - https://doodle.com/poll/pugm7nx7eskwfczx -gmann

1 1

[placement] update 19-09
by Chris Dent 11 Mar '19

11 Mar '19

HTML: https://anticdent.org/placement-update-19-09.html Here's another placement update. It was feature freeze this week so people are probably a bit worn, I'll try to keep this light and quick. # Most Important We need to decide if we want to do what amounts to a feature freeze exception for Tetsuro's negative member-of handling linked below and work out how/when to fit Mel's allocation ratio work on osc-placement (also below) into the world so people can use it. If people have placement related forum sessions they would like to see happen the deadline is either today (March 8th) or Monday, depending on which and how you read various pieces of info. Matt has already set up an extraction-related session. It's also important to be thinking about how placement would like to engage (as a group) with the PTG. If you want to run for PTL (of placement or anything else) the deadline is 23:45 UTC, 12 March. # What's Changed * The refactoring of the objects/resource_provider.py file into smaller, more single-purpose files, continues to merge. In case anyone is feeling like this is a lot of churn for little purpose, it does have purpose: This is making the code more accessible to people who aren't familiar with it. It is also providing a good review (a variety of warts and bugs and have been found and fixed) of stale code. * pep8's whitespace handling has been turned back on in placement. We inherited the exceptions to the rules from nova, where fixing for those rules would have been messy. In placement it wasn't that much of a big deal. * A conf setting `[placement_database]/sync_on_startup` has been added. Defaults to `False`. If `True`, the web service process will attempt the equivalent of `placement-manage db sync` at startup. * Improved debug logging when requesting allocation candidates, so that operators can more accurately determine what requirement led to reduced or no available hosts. * [1.5.0 of osc-placement](https://pypi.org/p/osc-placement) was released. It now goes up to microversion 1.18 (filter resource providers by required traits). (Note to everyone: We should make the info that shows up on PyPI more useful, by changing the README). * VGPU reshaping for libvirt merged! # Specs/Blueprints/Features ## Near to Done * [Filter Allocation Candidates by Provider Tree](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/… has been mostly completed by Tetsuro, but there's a [pending update to the spec](https://review.openstack.org/639033). * [Support filtering by forbidden aggregate membership](http://specs.openstack.org/openstack/nova-specs/specs/stein/app… also mostly [completed by Tetsuro](https://review.openstack.org/#/q/topic:bp/negative-aggregate-membe…. ## Not yet Done These will get punted to Train. * [Support any traits in allocation_candidates query](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved… * [Support mixing required traits with any traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… ## Not yet Approved * [Resource provider - request group mapping in allocation candidate](https://review.openstack.org/#/c/597601/) has had a recent resurgence in attention. # Bugs There is a storyboard [project group](https://storyboard.openstack.org/#!/project_group/placement) for placement projects. Through to the end of Stein we'll be paying attention to both it and Launchpad. The sole story in storyboard right now is updating docs to indicate we are using storyboard. So meta! In launchpad: * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb):13. -2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 9. -8. That large drop on in progress is because I went through and caught up those bugs which had fixes committed but had not been automatically updated. # osc-placement osc-placement is currently behind by 13 microversions. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) # Main Themes ## Nested * VGPU reshaping for libvirt merged! * The bandwidth-resource-provider topic has merged a vast amount of code but there is [some left](https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider). Some of it may still merge in Stein, but the rest will be for Train. The microversion ([2.72](https://docs.openstack.org/nova/latest/reference/api-microversion-his… provides the API-level bits to allow booting a host with a minimum bandwidth requirement. At least some of the [remaining changes](https://review.openstack.org/#/c/637953) will be backported. There were no nibbles on last week's plea, so I'll say again: If anyone reading this is in a position to provide third party CI with fancy hardware for NUMA, NFV, FPGA, and GPU related integration testing with nova, there's a significant need for that. ## Refactoring The work that removed oslo.versionedobjects then moved on to removing the List classes (e.g. AllocationList) in favor of using native Python lists and breaking up the `resource_provider.py` file into smaller files. The first portion of that (`scrub-Lists`) merged. The next stage is on [cd/de-list-phase2](https://review.openstack.org/#/q/topic:cd/de-list-phase2). This will continue until each type has its own file. # Other Placement * <https://review.openstack.org/#/c/639628/> Docs: extract testing info to own sub-page * <https://review.openstack.org/#/q/topic:cd/gabbi-tempest-job> Gabbi-based integration tests of placement. These recently found a bug that none of the functional, grenade, nor tempest tests did. * <https://review.openstack.org/#/c/630216/> Add a vision-reflection (of the Technical Vision doc). * <https://review.openstack.org/#/q/topic:bp/negative-aggregate-membership> Negative member of aggregate filtering resource providers and allocation candidates. * <https://review.openstack.org/#/c/641422/> Docs: Group API versions by release * <https://review.openstack.org/#/c/640555/> Add explicit short-circuit in get_all_by_consumer_id # Other Service Users (If you stick "placement" somewhere in your commit message I'll probably eventually find your in-progress placement-related changes.) ## Nova * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Using placement (from nova) for counting (some of) quota. Some of this, mostly related to database migrations, managed to make it in before feature freeze, but not the part that actually uses placement to do some counting, that is still pending. * <https://review.openstack.org/621494> Add descriptions of numbered resource classes and traits ## Not Nova * <https://review.openstack.org/#/q/topic:tripleo-nova-placement-removal> * <https://review.openstack.org/#/q/topic:tripleo-placement-extraction> * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron side of minimum bandwidth. * <https://review.openstack.org/#/q/bp/no-affinity-instance-reservation> Blazar reservation handling, including some manipulation of inventory in placement. * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/#/c/626382/> Kolla: Copy placement database migration script * <https://review.openstack.org/#/c/629253/> Tempest: Minimum bandwidth allocation with placement # End Go forth and document and bug fix and raise a full and flavorful stein. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[magnum] Change `floating_ip_enabled` behavior
by Lingxian Kong 11 Mar '19

11 Mar '19

Hi, As an openstack based public cloud, we have deployed Magnum in our production recently, but we found there is something that our customer is unhappy with. One of them is when `floating_ip_enabled` and `master_lb_enabled` are both set for the Kubernetes cluster, Magnum allocates floating IPs for master load balancer VIP, etcd service load balancer VIP, each master node and even each worker node, which costs too much for the public cloud customers. So, I've proposed a patch[1] to improve that which needs feedback from the community: 1. If `floating_ip_enabled` is set, don't allocate floating IP for etcd service and worker nodes by default. The etcd service should be dedicated to the kubernetes cluster and only accessible within the cluster for security reasons. If the user has the requirement for worker node maintenance, she can manually associate floating IP with the worker node. 2. If `floating_ip_enabled` and `master_lb_enabled` are both set, don't allocate floating IP for each master node. In the multi-master scenario, all other services talk to kubernetes control plane via the master load balancer VIP, the master node itself doesn't need to be exposed to the public internet to avoid the attack surface against the cluster. If the changes above affect you, please reply this email or ping me (lxkong) in the #openstack-containers IRC channel, or leave your comments in the patch directly. Any feedback is appreciated. [1]: https://review.openstack.org/#/c/641547 Cheers, Lingxian Kong

1 0

[sdk] Request to release newer version of openstacksdk for Stein Cycle
by Tushar Patil 10 Mar '19

10 Mar '19

Hi SDK team, I have requested a release of openstacksdk which includes changes to the instance-ha service to get the recovery workflow details of the notification. Kindly consider our request on behalf of Masakari team to release a newer version of openstacksdk so that we can use this newer version in masakari-dashboard [1] to render the recovery workflow details on the notification screen. Thank you in advance for your cooperation. [1] : https://review.openstack.org/#/c/640755/ Regards, Tushar Patil

1 0

[ptl][requirements][election] Matthew Thode PTL candidacy
by Matthew Thode 09 Mar '19

09 Mar '19

I would like to announce my candidacy for PTL of the Requirements project for the Train cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like cmd2 and grpcio). 3. Publish constraints and requirements to streamline the freeze process. This is in progress, but did not make it for Stein. https://storyboard.openstack.org/#!/story/1719006 is the story tracking the publish job. 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, Matthew Thode IRC: prometheanfire

1 0

[networking-ovs-dpdk
by Elanchezian Settu 09 Mar '19

09 Mar '19

Hi All, Trying to install devstack along with OVS-DPDK. But it fails at the below step during installation of OVS DPDK process. Herewith attached the logs and local.conf file used for installing. Kindly help me to resolve this issue. depbase=`echo lib/heap.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I ./include -I ./include -I ./lib -I ./lib -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -fno-strict-aliasing -Wswitch-bool -Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare -mssse3 -I/opt/stack/DPDK-v17.11/x86_ Thanks & Regards, Elan This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails ("spam").

1 0

[Interop-wg] [dev] [cinder] [qa] Strict Validation for Volume API using JSON Schema
by Ghanshyam Mann 09 Mar '19

09 Mar '19

Hello everyone, Tempest is planning to add the strict API validation using JSON schema for Volume test [1]. We do the same for all the compute test. With *Strict* JSON schema validation, all the API response will be validated with predefined schema with additionalProperties=False. additionalProperties=False will not allow any additional attribute in API response than what upstream APIs has in their current version. For example: If any vendor has modified the API response and returning additional attributes then Tempest tests going to fail. This will help: - To improve the OpenStack interoperability. Strict validation of API response is always helpful to maintain the interoperability. - To improve the volume API testing to avoid the backward compatible changes. Sometime we accidentally change the API in backward incompatible way and strict validation with JSON schema help to block those. We want to hear from cinder and interop team about any impact of this change to them. [1] https://blueprints.launchpad.net/tempest/+spec/volume-response-schema-valid… -gmann

4 6

[nova] nova-live-migration gate failure - hold rechecks
by Eric Fried 09 Mar '19

09 Mar '19

Please hold off rechecking in nova until [1] merges. The failure is in nova-live-migration with an error that looks like [2]. Thanks, Eric [1] https://review.openstack.org/641986 [2] http://logs.openstack.org/79/640879/7/check/nova-live-migration/f6c3653/job…

1 0

[interop] Restarting Interop WG Meeting this Wed. 10:00 AM CST/ 16:00 UTC
by Egle Sigler 09 Mar '19

09 Mar '19

Hello Everyone, We will be restarting Interop WG meetings this Wednesday, at 1600 UTC in #openstack-meeting-3, everyone welcome. Last year we discussed moving to once a year interop guidelines, and we need community’s input on the frequency. Etherpad for Wednesday’s meeting: https://etherpad.openstack.org/p/InteropWhistler.22 Please add items to the agenda. Meetings will be held every other week. Web IRC link if you are not using IRC client: http://webchat.freenode.net/?channels=openstack-meeting-3 Meetbot quick reference guide: http://meetbot.debian.net/Manual.html#user-reference If you have general interop questions, please ask in #openstack-interop IRC channel. Thank you, Egle

2 2