March 2019 - openstack-discuss - lists.openstack.org

[ptl][election][mistral] PTL candidacy
by Renat Akhmerov 10 Mar '19

10 Mar '19

Hi, After a year break I'd like to announce my PTL candidacy for Mistral in Train cycle ([1] is the official patch to openstack/election). I’d like to thank Dougal Matthews who was the PTL from Feb 2018 up to the middle of Dec 2018 and performed really well in this period. In Dec Dougal decided to step down due to the changes in his work priorities and I agreed to take over. In the last two years we've been mainly focused on improving Mistral performance and the reason for this was that some big users began to adopt it for their production needs. The amount of work done in this area was huge and the result is orders of magnitude boost for a number of use cases. Although much was done and the core of the technology is pretty mature now, there's still a lot ahead: 1. Continue to improve performance (e.g. "join" tasks) 2. Make the technology more product-like. That is, eliminating obvious gaps in the documentation (inconsistent structure, lack of tutorials, etc.), installation and configuration tools, tools for developing custom actions and functions easier and plugging them in easier. The ultimate goal here is to make sure that a new user can start using the technology within minutes, and the experience should be as positive as possible. Another thing that I'd like to do is to attract more talented and qualified contributors, i.e. to make the project community stronger. So if one has interest in working on Mistral we're always open and ready to help witn getting up to speed. Most likely, not all of the things mentioned above will be done in Train but I want to make sure we finally started addressing #2 in a more serious way than before. The best way to get in touch with us is IRC channel #openstack-mistral or the openstack-discuss mailing list (with [mistral] tag in email subject). [1] https://review.openstack.org/#/c/642336 Thanks Renat Akhmerov @Nokia

1 0

[sdk] Request to release newer version of openstacksdk for Stein Cycle
by Patil, Tushar 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 Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

4 5

[neutron] Cancelling the Neutron Performance sub-team meeting
by Miguel Lavalle 10 Mar '19

10 Mar '19

Ho Team, I will be travelling March 11th on a business trip. As a consequence, we will cancel the performance sub-team meeting. We will resume normally on the 25th. Best regards Miguel

1 0

[cloudkitty] PTL candidacy
by Luka Peschke 10 Mar '19

10 Mar '19

Hello everybody, I would like to submit my candidacy as CloudKitty's PTL for the Train cycle. I've been contributing to the project since the Newton release and I've been the PTL for the Stein cycle. As a PTL, I'd like to keep working on the points we addressed during the last cycle: * Help CloudKitty's community to grow. Some work has been done during the stein cycle (IRC meetings have been reintroduced, the developer documentation has been improved...), but we need to keep putting effort into this. * Improve the documentation. Here again, this has been worked on in Stein (there have been a lot of documentation patches), but we are far from done. * Add missing features: I'd like to mentor developers willing to add endpoints to the v2 API, which has been added during the stein cycle. We have also been talking a lot about a new rating engine recently. It would be great to have a spec draft for this, on which we could work together. Thank you for your attention, Luka Peschke (peschk_l) Envoyé avec AquaMail pour Android https://www.mobisystems.com/aqua-mail

1 0

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

10 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 10 Mar '19

10 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 10 Mar '19

10 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 10 Mar '19

10 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 09 Mar '19

09 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