August 2019 - openstack-discuss - lists.openstack.org

[release] (a bit belated) Release countdown for week R-11, July 29 - August 2
by Kendall Nelson 02 Aug '19

02 Aug '19

Hello Everyone! Development Focus ----------------- We are now past the Train-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we will be proposing to change the release model for the following deliverables: blazar-dashboard cloudkitty-dashboard ec2-api freezer-web-ui freezer heat-agents heat-dashboard ironic-ui karbor-dashboard karbor kuryr-kubernetes magnum-ui manila-ui masakari-dashboard monasca-agent monasca-api monasca-ceilometer monasca-events-api monasca-kibana-plugin monasca-log-api monasca-notification monasca-persister monasca-thresh monasca-transform monasca-ui murano-agent networking-baremetal networking-generic-switch networking-hyperv neutron-fwaas-dashboard neutron-vpnaas-dashboard requirements sahara-extra senlin-dashboard solum-dashboard tacker-horizon tricircle vitrage-dashboard vitrage watcher-dashboard PTLs and release liaisons for each of those deliverables can either +1 the release model change when we get them pushed, or propose an intermediary release for that deliverable. In absence of answer by the start of R-10 week we'll consider that the switch to cycle-with-rc is preferable. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone: September 12 (R-5 week) -Kendall (diablo_rojo) + the Release Management Team

6 7

[placement] update 19-30
by Chris Dent 02 Aug '19

02 Aug '19

HTML: https://anticdent.org/placement-update-19-30.html Pupdate 19-30 is brought to you by the letter P for Performance. # Most Important The main things on the Placement radar are implementing Consumer Types and cleanups, performance analysis, and documentation related to nested resource providers. # What's Changed * [os-traits 0.16.0 was released](https://review.opendev.org/673294) was released, with a corresponding [canary update](https://review.opendev.org/673964). * The [ProviderIds namedtuple was removed](https://review.opendev.org/673788). This is the first in a series of performance optimizations discovered as part of the analysis described below in the Cleanup section. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 23 (2) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 3 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 17 (0). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 4 (0). # osc-placement osc-placement is currently behind by 12 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. * <https://review.opendev.org/640898> Adds a new '--amend' option which can update resource provider inventory without requiring the user to pass a full replacement for inventory # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> A WIP, as microversion 1.37, has started. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. I started some performance analysis this week. Initially I started working with [placement master in a container](https://anticdent.org/profiling-placement-in-docker.html) but as I started making changes I moved back to [container-less](https://anticdent.org/profiling-wsgi-apps.html). What I discovered was that there is quite a bit of redundancy in the code in the `objects` package that I was able to remove. For example we were creating at least twice as many ProviderSummary objects than required in a situation with multiple request groups. It's likely there would have been more duplicates with more request groups. That's improved in [this change](https://review.opendev.org/674254), which is at the end of a stack of several other like-minded improvements. The improvements in that stack will not be obvious until the [more complex nested topology](https://review.opendev.org/#/c/673513/) is generally available. My analysis was based on that topology. Not to put too fine a point on it, but this kind of incremental analysis and improvement is something I think we (the we that is the community of OpenStack) should be doing far more often. It is _incredibly_ revealing about how the system works and opportunities for making the code both work better and be easier to maintain. One outcome of this work will be something like a _Deployment Considerations_ document to help people choose how to tweak their placement deployment to match their needs. The simple answer is use more web servers and more database servers, but that's often very wasteful. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There is one [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And two [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/586960> zun: [WIP] Use placement for unified resource management * <https://review.opendev.org/671478> Kayobe: Build placement images by default * <https://review.opendev.org/671312> blazar: Fix placement operations in multi-region deployments * <https://review.opendev.org/671793> Nova: libvirt: Start reporting PCPU inventory to placement * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/664689> Nova: get_ksa_adapter: nix by-service-type confgrp hack * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/668252> Nova: Update HostState.\*\_allocation_ratio earlier * <https://review.opendev.org/670696> tempest: Add placement API methods for testing routed provider nets * <https://review.opendev.org/672678> openstack-helm: Build placement in OSH-images * <https://review.opendev.org/674129> Correct global_request_id sent to Placement # End I started working with around approximately 20,000 providers this week. Only 980,000 to go. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[Security SIG] Weekly Newsletter - Aug 01st 2019
by Gage Hugo 02 Aug '19

02 Aug '19

Apologies for the lack of a newsletter last week, back to regularly scheduled programming #Week of: 01 Aug 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-08-01-1… - Security Guide Docs Update - The first set of changes have been made - https://review.opendev.org/#/q/project:openstack/security-doc - Decided to link directly to the keystone federation setup page instead of maintaining an out-of-date copy - Currently looking to update the various checklists for each service - Nova/Cinder Policy - Currently checking out inconsistencies between the documentation of generating policy files for both nova and cinder - https://review.opendev.org/#/c/673349/ # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - IFLA_BR_AGEING_TIME of 0 causes flooding across bridges: https://bugs.launchpad.net/os-vif/+bug/1837252

1 0

[tc][forum] documenting "forum 101"
by Mohammed Naser 02 Aug '19

02 Aug '19

Hi everyone, We've discussed the idea of building a document which provides information on how to host a good forum session, tips and tricks, how to make the best out of them. It seems there's content all over the place but not aggregated in a single good spot that we can point attendees/hosts to. context: http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… Do we have any volunteers from the TC (or even community members) that are interested in this effort? Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[tc] monthly meeting
by Mohammed Naser 01 Aug '19

01 Aug '19

Hi everyone, I’ve prepared the planning for the next TC meeting which will happen on Thursday, August 8th at 1400 UTC. If you’d like to add a topic of discussion, please feel free to do so. We will be cutting off the agenda on Wednesday the 7th so any subject added afterwards won’t appear in the plan. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[horizon] Stein, multi-domain, admin, can't list users, projects (maybe networks) (bug#1830782)
by Alex Kavanagh 01 Aug '19

01 Aug '19

Hi I'm trying to resolve/solve the issue that is described in bug 183072 [1], and I'm looking for help in how it might be resolved. To recap the bug quickly: 1. horizon, multi-domain enabled. 2. 'admin' user is in 'admin_domain' and 'admin' project 3. Log in as that 'admin' user in 'admin_domain'. 4. Create test domain. 5. Set domain context to 'test' domain 6. Create a user in the 'test' domain. 7. Can't see that user in the user list. 8. Do same for project; can't see the project. In the bug comments at [2] (comment 38) I've recorded the results after adding some debug code to keystone and horizon and came to the following tentative conclusion: 1. Horizon uses a domain scoped token for listing users when the domain context is set. In this case that token is domain-scoped to 'admin_domain' 2. Keystone at the stein release, due to a change introduced in [3] for the users (detail in [4]) filters users that are not in the domain of the domain scoped token. 3. Thus, the domains for the 'test' domain are filtered out and are not seen in the horizon dashboard. 4. I believe this is the same for projects. In order to solve this, I suspect one or more of the following would need to be done. However, I'm not familiar enough with the horizon codebase to know where to start. 1. In horizon, if the user is an admin user, then don't use a domain-scoped token for listing users, projects, or anything else. 2. Alternatively, obtain a domain scoped token for the domain context that is set. (I'm not familiar enough with keystone to know whether it's possible for the admin user to get 'any' domain scoped token for any domain???) Incidentally, the openstack CLI doesn't use domain scoped tokens for list users in a domain; I don't know whether this is an appropriate approach to take in horizon. Thanks very much in advance. Happy to chat on IRC if that's useful (I'm UTC TZ). Best regards Alex. [1] https://bugs.launchpad.net/openstack-bundles/+bug/1830782 [2] https://bugs.launchpad.net/openstack-bundles/+bug/1830782/comments/38 [3] https://review.opendev.org/#/c/647587/ [4] https://review.opendev.org/#/c/647587/3/keystone/api/users.py -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd

1 0

[ironic] Shanghai Planning
by Julia Kreger 01 Aug '19

01 Aug '19

Greetings everyone, I just wanted to remind my fellow ironic contributors that the planning and coordination etherpad for Shanghai[0] is available. Please add any topics and indicate your attendance as soon as possible. Thanks, -Julia [0]: https://etherpad.openstack.org/p/PVG-Ironic-Planning

1 0

[masakari] how to install masakari on centos 7
by Vu Tan 01 Aug '19

01 Aug '19

Vu Tan <vungoctan252(a)gmail.com> 10:30 AM (35 minutes ago) to openstack-discuss Sorry, I resend this email because I realized that I lacked of prefix on this email's subject Hi, I would like to use Masakari and I'm having trouble finding a step by step or other documentation to get started with. Which part should be installed on controller, which is should be on compute, and what is the prerequisite to install masakari, I have installed corosync and pacemaker on compute and controller nodes, , what else do I need to do ? step I have done so far: - installed corosync/pacemaker - install masakari on compute node on this github repo: https://github.com/openstack/masakari - add masakari in to mariadb here is my configuration file of masakari.conf, do you mind to take a look at it, if I have misconfigured anything? [DEFAULT] enabled_apis = masakari_api # Enable to specify listening IP other than default masakari_api_listen = controller # Enable to specify port other than default masakari_api_listen_port = 15868 debug = False auth_strategy=keystone [wsgi] # The paste configuration file path api_paste_config = /etc/masakari/api-paste.ini [keystone_authtoken] www_authenticate_uri = http://controller:5000 auth_url = http://controller:5000 auth_type = password project_domain_id = default user_domain_id = default project_name = service username = masakari password = P@ssword [database] connection = mysql+pymysql://masakari:P@ssword@controller/masakari

4 15

[rdo] [packstack] failing to setup Stein with Openvswitch/VXLAN networking
by Bernd Bausch 01 Aug '19

01 Aug '19

Trying to set up a Stein cloud with Packstack. I want the Openvswitch mech driver and VXLAN type driver. A few weeks ago, the following invocation was successful: |sudo packstack --debug --allinone --default-password pw \ --os-neutron-ovs-bridge-interfaces=br-ex:eth0 \ --os-neutron-ml2-tenant-network-types=vxlan \ --os-neutron-ml2-mechanism-drivers=openvswitch \ --os-neutron-ml2-type-drivers=vxlan,flat \ --os-neutron-l2-agent=openvswitch \ --provision-demo-floatrange=10.1.1.0/24\ --provision-demo-allocation-pools '["start=10.1.1.10,end=10.1.1.50"]'\ --os-heat-install=y --os-heat-cfn-install=y||| Now, it fails during network setup. My network connection to the Packstack server is severed, and it turns out that its only network interface /eth0 /has no IP address and is down. No bridge exists. In the /network.pp.finished /file, I find various /ovs-vsctl /commands including /add-br/, and a command /ifdown eth0 /which fails with exit code 1 (no error message from the /ifdown /command is logged). *Can somebody recommend the options required to successfully deploy a Stein cloud based on the Openvswitch and VXLAN drivers?* Thanks much, Bernd || ||

2 3