- openstack-discuss - lists.openstack.org

[keystone] Keystone Team Update - Week of 29 July 2019
by Colleen Murphy 03 Aug '19

03 Aug '19

# Keystone Team Update - Week of 29 July 2019 ## News ### CI instability The volume of policy deprecation warnings we generate in our unit tests has gotten to such a critical level that it appears to be causing serious instability in our unit test CI, possibly even affecting the CI infrastructure itself[1]. It's been suggested that we use the warnings module's filtering capabilities to suppress these warnings in the unit test output, but it seems that the sheer number of warnings that need to be suppressed makes the filtering so inefficient that the tests are even more likely to time out. We could do what the warnings actually suggest and override the deprecated policies in the tests, but it seems most of our unit tests aren't even ready to handle the new policies. Investigation is ongoing[2]. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infr… [2] https://review.opendev.org/673933 ### External auth In this week's meeting we discussed[3] how best to document external auth and agreed it's probably best to deprecate it entirely. We're seeking input from operators on how this may affect them[4]. [3] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-07-30-1… [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/008127.html ## Action Items None outstanding ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. We will skip next week's office hours since we don't have a topic planned. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 7 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 37 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories System scope/default roles (https://trello.com/c/ERo50T7r , https://trello.com/c/RlYyb4DU) - https://review.opendev.org/#/q/status:open+topic:implement-default-roles+la… Application credential access rules (https://trello.com/c/XyBGhKrE) - https://review.opendev.org/#/q/status:open+topic:bp/whitelist-extension-for… Caching Guide (https://trello.com/c/UCFt3mfF) - https://review.opendev.org/672120 (Update the caching guide) Predictable IDs (https://trello.com/c/MVuu6DbU) - https://review.opendev.org/651655 (Predictable IDs for Roles) Oslo.limit (https://trello.com/c/KGGkNijR) - https://review.opendev.org/667242 (Add usage example) - https://review.opendev.org/666444 (Flush out basic enforcer and model relationship) - https://review.opendev.org/666085 (Add ksa connection logic) YAML Catalog (https://trello.com/c/Qv14G0xp) - https://review.opendev.org/483514 (Add yaml-loaded filesystem catalog backend) * Needs Discussion - https://review.opendev.org/669959 (discourage using X.509 with external auth) - https://review.opendev.org/655166 (Allows to use application credentials through group membership) * Oldest - https://review.opendev.org/448755 (Add federated support for creating a user) * Closes bugs - https://review.opendev.org/674122 (Fix websso auth loop) - https://review.opendev.org/672350 (Fixing dn_to_id function for cases were id is not in the DN) - https://review.opendev.org/674139 (Cleanup session on delete) ## Bugs This week we opened 6 new bugs and closed 6. Bugs opened (6) Bug #1838592 (keystone:High) opened by Guang Yee https://bugs.launchpad.net/keystone/+bug/1838592 Bug #1838554 (keystone:Low) opened by Mihail Milev https://bugs.launchpad.net/keystone/+bug/1838554 Bug #1836618 (keystone:Undecided) opened by Ghanshyam Mann https://bugs.launchpad.net/keystone/+bug/1836618 Bug #1838231 (keystone:Undecided) opened by Raviteja Polina https://bugs.launchpad.net/keystone/+bug/1838231 Bug #1838704 (keystoneauth:Undecided) opened by Alex Schultz https://bugs.launchpad.net/keystoneauth/+bug/1838704 Bug #1836568 (oslo.policy:Undecided) opened by Colleen Murphy https://bugs.launchpad.net/oslo.policy/+bug/1836568 Bugs closed (4) Bug #1837061 (keystone:Wishlist) https://bugs.launchpad.net/keystone/+bug/1837061 Bug #1791111 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1791111 Bug #1836618 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1836618 Bug #1837010 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1837010 Bugs fixed (2) Bug #1724645 (keystone:Low) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1724645 Bug #1837407 (keystone:Low) fixed by Chason Chan https://bugs.launchpad.net/keystone/+bug/1837407 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Feature proposal freeze happens in two weeks. Feature freeze follows four weeks after that. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[nova][ops] Documenting nova tunables at scale
by Matt Riedemann 03 Aug '19

03 Aug '19

I wanted to send this to get other people's feedback if they have particular nova configurations once they hit a certain scale (hundreds or thousands of nodes). Every once in awhile in IRC I'll be chatting with someone about configuration changes they've made running at large scale to avoid, for example, hammering the control plane. I don't know how many times I've thought, "it would be nice if we had a doc highlighting some of these things so a new operator could come along and see, oh I've never tried changing that value before". I haven't started that doc, but I've started a bug report for people to dump some of their settings. The most common ones could go into a simple admin doc to start. I know there is more I've thought about in the past that I don't have in here but this is just a starting point so I don't make the mistake of not taking action on this again. https://bugs.launchpad.net/nova/+bug/1838819 -- Thanks, Matt

2 1

[goal][python3] Train unit tests weekly update (goal-6)
by Corey Bryant 02 Aug '19

02 Aug '19

This is the goal-6 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 6 weeks remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… == Ongoing Work == All patches have been submitted for all applicable projects. Note: I need to resubmit most of the OpenStack Charms but the project is currently in release freeze so I'm holding off on consuming 3rd party gate resources. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals /train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[winstackers][release] compute-hyperv release in Train
by Thierry Carrez 02 Aug '19

02 Aug '19

Hi winstackers, We are now past the Train membership freeze[1] and compute-hyperv is not listed as a train deliverable yet. Unless you act very quickly (and add a deliverables/train/compute-hyperv.yaml file to the openstack/releases repository), we will not include a release of compute-hyperv in OpenStack Train. This may just be fine, for example if compute-hyperv needs more time before a release, or if it is released independently from OpenStack releases. [1] https://releases.openstack.org/train/schedule.html#t-mf -- Thierry Carrez (ttx)

2 1

[ops] [nova] Problems migrating an instance with libvirt if the image got deleted ?
by Massimo Sgaravatto 02 Aug '19

02 Aug '19

Hi I remember I had problems in the past trying to resize or migrate instances launched using an image that was then deleted (I use kvm as hypervisor). This is indeed confirmed e.g. here: https://storyboard.openstack.org/#!/story/2004892 https://docs.openstack.org/operations-guide/ops-user-facing-operations.html… Now I am not able to reproduce anymore the problem, i.e.: 1- I create an image 2- I launch an instance using this image 3- I delete the image 4- I migrate the instance (nova migrate <uuid)) and this works. Does the migration issue happen only in some particular scenarios ? My current setup: - OpenStack version: Rocky - CenOS 7.x - qemu-kvm-ev-2.12.0-18.el7_6.5.1.x86_64 - /var/lib/nova/instances not shared amomg compute nodes Thanks, Massimo

2 1

[tc][forum] Shanghai Forum selection committee
by Thierry Carrez 02 Aug '19

02 Aug '19

Hi, TC members! We need two TC members to serve on the Shanghai forum selection committee, and help select, refine and potentially merge the forum session proposals from the wider community. Beyond encouraging people to submit proposals, the bulk of the selection committee work happens after the submission deadline (planned for Sept 16th) and the Forum program final selection (planned for Oct 7th). Since we'll have TC renewal elections in progress, it's simpler to pick between members that are not standing for reelection in September. That would be: asettle mugsie jroll mnaser ricolin, ttx and zaneb. Anyone interested? -- Thierry Carrez (ttx)

2 2

[neutron][release] neutron-interconnection release in Train
by Thierry Carrez 02 Aug '19

02 Aug '19

Hi Neutron folks, We are now past the Train membership freeze[1] and neutron-interconnection is not listed as a train deliverable yet. Unless you act very quickly (and add a deliverables/train/neutron-interconnection.yaml file to the openstack/releases repository), we will not include a release of neutron-interconnection in OpenStack Train. This may just be fine, for example if neutron-interconnection needs more time before a release, or if it is released independently from OpenStack releases. [1] https://releases.openstack.org/train/schedule.html#t-mf -- Thierry Carrez (ttx)

2 1

[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

[dev][nova][glance][cinder] introducing 'compressed' image container_format
by Ma, Zheng 31 Jul '19

31 Jul '19

Hello Nova developers, Cinder is working on a feature that will allow it to compress volumes uploaded to Glance [0,1]. We are proposing a new container_format for Glance named 'compressed' [2]. The idea is that a consumer of a 'compressed' image would read the file to determine the kind of compression and take appropriate action (either successfully decompress to find a payload that matches the image's disk_format, or fail with 'unsupported container_format'). Our preliminary testing with a raw image with container_format == compressed, disk_format == raw is that Nova boots a VM from the image but the VM appears to be unusable. Nova seems taking it as a real RAW image as disk_format indicates. So we want to open a discussion about handling this. Thanks! [0] cinder spec patch https://review.opendev.org/#/c/652275/ [1] cinder code implementation https://review.opendev.org/#/c/668825 [2] glance spec patch https://review.opendev.org/#/c/670454/

2 1

[all] Pycharm Licences
by ʂʍɒρƞįł Ҟưȴķɒʁʉɨ 31 Jul '19

31 Jul '19

I have renewed the Pycharm licenses for community contributors until July 29, 2020. For everyone who is using it will be updated automatically. Please do not request again for renewal. Best Regards, Swapnil

2 1

[swift] Shanghai PTG attendance and etherpad
by tim＠swiftstack.com 31 Jul '19

31 Jul '19

你好! Most teams sent out emails two or three weeks ago with etherpads to start estimating headcount and coming up with discussion topics. I was a little slow, but here's Swift's: https://etherpad.openstack.org/p/swift-ptg-shanghai We're thinking of doing something a little different from our previous PTGs and hackathons and want to offer a kind of extended onboarding session. If you're new to Swift, this is a great opportunity to learn more about - how Swift works, - how to write applications against Swift, - how to deploy and operate your own Swift cluster, or - how to do upstream development for Swift. Interested? We'd love to hear from you and meet you! If there are any other aspects of Swift you'd like to learn about or dive deeper on, feel free to add them! I'll try to develop some materials based on people's level of interest so it won't all be off-the-cuff :-) Of course, there will also be more-traditional design discussions going on. (I don't think I could stop this if I tried -- it seems *any time* there are three or more Swift contributors around, there are going to be design discussions happening!) If you know you want to talk about some upcoming features or other work, please update the Development Topics at the bottom. 在上海见到您们! Tim

1 0

[openstack-ansible] office hours update
by Mohammed Naser 31 Jul '19

31 Jul '19

Hey everyone, Here is the update of what happened during the OpenStack Ansible office hours this week. We thought there was an issue with the logic that determines nova_cinder_rbd_inuse running on localhost and setting the fact only on localhost (and not the host that’s it’s running it on). So the variable ‘nova_cinder_rbd_inuse’ was always set to false on these hosts. The issue was a missing rbd configuration in nova.conf and that issue has been fixed. Thanks for tuning in and thanks for Tiffanie for taking care of the basic meeting logistics! 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

[tripleo][charms][helm][kolla][ansible][puppet][chef] Deployment tools capabilities v0.1.0
by Thierry Carrez 31 Jul '19

31 Jul '19

Hi, deployment tools teams, As mentioned here last month[1], we are working to improve the information present on the deployment tools pages on the OpenStack website, and we need your help! After the Forum session on this topic in Denver[2], a workgroup worked on producing a set of base capabilities that can be asserted by the various deployment tools we have. You can find version 0.1.0 of those capabilities here: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools_ca… As an example, I pushed a change that makes every deployment tool assert the capability to deploy keystone ("components:keystone" tag) at: https://review.opendev.org/#/c/669648/ Now it's your turn. Please have a look at the list of the capabilities above, and propose a change to add those that are relevant to your deployment tool in the following file: https://opendev.org/osf/openstack-map/src/branch/master/deployment_tools.ya… Capabilities are all of the form "category:tag" (components:keystone, starts-from:os-installed, technology:puppet...). Once all deployment projects have completed that task, we'll add the capabilities to the rendered page on the website and allow for basic searching for tools with matching capability. Now, capabilities go only so far in describing your deployment tool. I also encourage you to improve in the same file the "desc" field: that one is directly displayed on the site.Uuse it to describe in more details how your deployment tool actually works and what makes it unique, beyond basic capabilities tags. Please feel free to use this thread (or personal email) if you have questions on this. And thanks in advance for your help! [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006964.html [2] https://etherpad.openstack.org/p/DEN-deployment-tools-capabilities -- Thierry Carrez (ttx)

1 1

Re: [User-committee] [all][uc] Train UC Election Season
by Ian Y. Choi 31 Jul '19

31 Jul '19

+ openstack-discuss mailing list for broader announce of Train UC Election :) - Ed & Ian Ed Leafe wrote on 7/31/2019 11:20 PM: > Hello All! > > The User Committee (UC) election is coming! > > The OpenStack User Committee [1] is one of the governing bodies of the OpenStack project to serve the user community of OpenStack, representing them to the broader community. > > If you are not aware of UC election, please see the details first: > > Election details: > https://governance.openstack.org/uc/reference/uc-election-aug2019.html > > Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Note that the nomination period begins soon! (August 5). > > There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. > > If you have any questions which you feel affect others please reply to this email thread. > > If you have any questions that you which to discuss in private please email any of the election officials [2] so that we may address your concerns. > > Thank you, > > - Ed & Ian > > [1] https://governance.openstack.org/uc/reference/charter.html > [2] https://governance.openstack.org/uc/reference/uc-election-aug2019.html#offi… > > > _______________________________________________ > User-committee mailing list > User-committee(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

1 0

[dev][keystone][keystonemiddleware] Keystone CADF notifications for rabbitmq
by Ondřej Duchoň 31 Jul '19

31 Jul '19

Hello, I am trying to make to work CADF notifying for nova_api and other modules into rabbitmq. I tried to use keystonemiddleware ( https://docs.openstack.org/keystonemiddleware/queens/audit.html) but no notifications appeared. The only thing that is sending CADF notifications into rabbitmq is keystone. I assume that is because keystone has its own notifier. (keystone/notifications.py) Do you have some idea about this problem? Which approach is correct in this case? Thank you for your help, Ondrej

2 1

[kolla] cancelling meeting today
by Michał Nasiadka 31 Jul '19

31 Jul '19

Hello, Since there are no hot topics and the PTL/core team are unavailable for the meeting - it will be cancelled. See you next week on #openstack-kolla -- Michał Nasiadka mnasiadka(a)gmail.com

1 0

Magnum Kubernetes openstack-cloud-controller-manager unable not resolve master node by DNS
by Pawel Konczalski 31 Jul '19

31 Jul '19

Hi, i try to deploy a Kubernetes cluster with OpenStack Magnum but the openstack-cloud-controller-manager pod fails to resolve the master node hostname. Does magnum require further parameter to configure the DNS names of the master and minions? DNS resolution in the VMs works fine. Currently there is no Designate installed in the OpenStack setup. openstack coe cluster template create kubernetes-cluster-template1 \ --image Fedora-AtomicHost-29-20190429.0.x86_64 \ --external-network public \ --dns-nameserver 8.8.8.8 \ --master-flavor m1.kubernetes \ --flavor m1.kubernetes \ --coe kubernetes \ --volume-driver cinder \ --network-driver flannel \ --docker-volume-size 25 openstack coe cluster create kubernetes-cluster1 \ --cluster-template kubernetes-cluster-template1 \ --master-count 1 \ --node-count 2 \ --keypair mykey # kubectl get pods --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE kube-system coredns-78df4bf8ff-mjp2c 0/1 Pending 0 36m <none> <none> <none> kube-system heapster-74f98f6489-tgtzl 0/1 Pending 0 36m <none> <none> <none> kube-system kube-dns-autoscaler-986c49747-wrvz4 0/1 Pending 0 36m <none> <none> <none> kube-system kubernetes-dashboard-54cb7b5997-sk5pj 0/1 Pending 0 36m <none> <none> <none> kube-system openstack-cloud-controller-manager-dgk64 0/1 CrashLoopBackOff 11 36m <none> kubernetes-cluster1-vulg5fz6hg2n-master-0 <none> # kubectl -n kube-system logs openstack-cloud-controller-manager-dgk64 Error from server: Get https://kubernetes-cluster1-vulg5fz6hg2n-master-0:10250/containerLogs/kube-…: dial tcp: lookup kubernetes-cluster1-vulg5fz6hg2n-master-0 on 8.8.8.8:53: no such host BR Pawel

2 3

[loci][openstack-helm][tc] Proposal to fold Loci into OpenStack-Helm
by Chris Hoge 31 Jul '19

31 Jul '19

In the interest of consolidating workload, I'm proposing that we roll the Loci project under the governance of OpenStack Helm. Loci is a fairly low-bandwidth project, with the primary consumer of it being OpenStack Helm. By rolling Loci into OSH, we will be able focus shared efforts and increase review velocity for the Loci project. The architecture of OpenStack Helm allows it to be container build-system agnostic, and similarly the architecture of Loci allows it to be deployment tooling agnostic. Neither of these goals will change, as there are users of both projects that aren't using the other. However, as they are the largest consumers for each other's work, this is a natural pairing and both project stand to benefit from a tighter governance coupling. We already share a good proportion of the development team and frequently plan PTG sessions to allow for collaboration. If the community agrees with this approach, we would like to finalize the governance change before the next development cycle to allow for a graceful transition. Thanks, Chris Hoge Loci PTL

2 1

[scientific-sig][cloudkitty][monasca] SIG IRC meeting today - accounting using Monasca and CloudKitty
by Stig Telfer 31 Jul '19

31 Jul '19

Hi All - We have an IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_31st_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_July_31st_2019> Today we are looking to gather data on accounting, chargeback and billing, and we have a report on recent investigations using Monasca and CloudKitty together for this purpose. Cheers, Stig

1 0

[mistral] Office hour in ~30 min
by Renat Akhmerov 31 Jul '19

31 Jul '19

Hi, We’ll have an office hour at 8.00 UTC today (in ~30 min) so you’re welcome to join and chat with us. Thanks Renat Akhmerov @Nokia

1 0

[ops][keystone] Does anyone use external auth?
by Colleen Murphy 30 Jul '19

30 Jul '19

Currently, one of the default auth methods for keystone is 'external', meaning keystone offloads authentication to an HTTPD auth module like mod_ssl or mod_auth_kerb and gets the user's identity from the REMOTE_USER variable passed in by the web server: https://docs.openstack.org/keystone/latest/admin/external-authentication.ht… The 'external' auth method existed before federation. The biggest problem with external auth now is that it is effectively single-domain, there's no way to parse anything besides a user identifier from the REMOTE_USER variable, and keystone is barreling full steam ahead to a multidomain world. The 'external' auth method conflicts with the 'mapped' auth method as mentioned in the "Caution" notice in the above document for the same reason. Moreover, we should be able to achieve the same behavior with just federation, e.g. you can create a federated IdP representing your SSL CA, and continue to use mod_ssl with a mapping to properly parse all the attributes coming in from the auth module. We'd like to start discouraging, deprecating, and removing external auth in keystone. So our question to operators is: are you currently using external auth? If so, which HTTPD auth modules are you using? And is it a use case that we can't support with federated auth? Colleen (cmurphy)

2 2

[cinder] lvm_mirrors option seems to be broken
by Mark Lehrer 30 Jul '19

30 Jul '19

I have 4 fast nvme targets that I want to combine using RAID 10 and use with cinder-lvm. Unfortunately, lvm+mdadm is breaking all of my writes down to 4K -- without even increasing the queue depth to match. SSDs hate this workload. I tried bypassing mdadm by seting up LVM RAID10 by hand and got roughly a 10x increase in performance, so I definitely want to use this if possible. However, it looks like maybe the lvm_mirrors code hasn't been kept up to date. I ran into two main problems trying to use it: 1) The algorithm to calculate free space is broken and always returns 0. This means that the scheduler will never even try to use this pool 2) Thin provisioning is getting in the way... with lvm_mirrors enabled the code is apparently trying to create a new LV on top of the thin provisioned LV... and it is using an lvcreate option that appears to be deprecated (--mirrorlog mirrored) I expect I can fix #1, but what is the best way to handle #2? I was thinking that the easiest fix would be to use the mirror options when the thin LV is created, though I haven't tried it by hand yet to see if it works. The advantage here is that this is a one-time setting and the code path to create individual volumes wouldn't need to check lvm_mirrors at all. Thanks, Mark

2 4

[ops] NYC ops meetup sept 3,4 registration site live!
by Chris Morgan 30 Jul '19

30 Jul '19

Registration: https://go.bloomberg.com/attend/invite/open-stack-operators-quarterly-summi… planning etherpad : https://etherpad.openstack.org/p/NYC19-OPS-MEETUP Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

Retiring tc-as-a-service
by Andreas Jaeger 30 Jul '19

30 Jul '19

This repo was imported and never used, I'll start the retirement process for it now. Ofer, one of the initial developer on the project confirmed that the repo is dead, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

[release][infra] Supporting rget in our release process
by corvus＠inaugust.com 30 Jul '19

30 Jul '19

Hi, A colleague at Red Hat is working on an effort to record signatures of release artifacts. Essentially it's a way to help users verify release artifacts (or determine if they have been changed) independent of PGP signatures. You can read about it here: https://github.com/merklecounty/rget#rget It sounds like an interesting and useful effort, and I think we can support it at little cost. If we wanted to do so, I think we would need to do the following things: 1) Generate SHA256SUMS of our release artifacts. These could even include the GPG signature files. 2) Run "rget submit" on the resulting files after publication. That's it. Both of those would be changes to the release publication jobs, and wouldn't require any other changes to our processes. As mentioned in the README this is very early stages and the author, Brandon Philips, welcomes both further testing and feedback on the process in general. Thoughts? -Jim

5 4

Deprecate Aggregate[Core|Ram|Disk]Filters
by Sean Mooney 30 Jul '19

30 Jul '19

Hi all, back in january 2018 we annouced that the behavior of the Aggregate[Core|Ram|Disk]Filters http://lists.openstack.org/pipermail/openstack-dev/2018-January/126283.html form ocata on due to the use of placement you can no longer manage overcomit ratios using aggregate metadata as placement has no access to this data. as a result these filters if you use with placement then they only work if the aggregates enforce lower limits then placement default. if you also limit the responces from placemnet this also does not work as we may not recive any host that satisfy the lower limit in the aggregate metadata even if such host exist in the aggreate. we have a prominent warning https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#… advising operator of the impact of this change as well as this wont fix bug from last November https://bugs.launchpad.net/nova/+bug/1804125 11 months ago we deprecated the non aggreate [Core|Ram|Disk] Filters https://review.opendev.org/#/c/596502/ for several reasons noted in the commit and we furthermore removed the caching scheduler in stien. a few days ago we finally deleted the non aggreagate filters with https://github.com/openstack/nova/commit/78645e61c63bf042453d1f822ae8b3f1ee… but the Aggregate[Core|Ram|Disk]Filters are still present. we had intended to deprecate the Aggregate[Core|Ram|Disk]Filters in ocata when we sent the initial email about the behavior change however we never actully followed up and formally deprecated it in code. similarly when we formally deprecated the [Core|Ram|Disk] Filters we could have deprecated the Aggregate[Core|Ram|Disk]Filters too but we did not. As a result we cannot remove the Aggregate[Core|Ram|Disk]Filters in Train but i have proposed : https://review.opendev.org/673496 To formally deprecate them with the intent of removing them in the U cycle. In the 19.0.0 Stein release initial allocation ratios support was completed which allow managing of the allocation ratios via the placement api in addition to the existing capability to manage allocation ratios via the nova config. https://github.com/openstack/nova-specs/blob/master/specs/stein/implemented… As of the 18.0.0 rocky release nova automatically mirrors ``host-aggregates`` to placement aggregates. https://github.com/openstack/nova-specs/blob/master/specs/rocky/implemented… There is ongoing work in Train to enhance osc-placement to add a 'resource provider inventory update' command to make setting overcommit allocation ratios on a per-aggregate basis easier https://review.opendev.org/#/c/640898/ . These 3 features combined will allow operators to manage Aggreate Resource class allocation ratios in a placement native way. finally in the case the above was not sufficent motivation the AggregateCoreFilter it does not support handeling vCPU and pCPU resouce classes seperatly and will not work with the new cpu resouce tracking spec correctly. https://github.com/openstack/nova-specs/blob/master/specs/train/approved/cp… the AggregateRamFilter also does not understand the difference bewteen hugepage memory and standard memroy which means that even if we were to keep the filters they do not work correctly in all cases and will continue to becomre more broken over time, so i think the time has come to finally do this. regards sean

1 0

Error: python2-uritemplate conflicts with python2-uri-templates-0.6-5.el7.noarch
by Md. Farhad Hasan Khan 30 Jul '19

30 Jul '19

Hi, When I run # yum update and found below conflict: --> Processing Conflict: python2-uritemplate-3.0.0-1.el7.noarch conflicts python2-uri-templates --> Finished Dependency Resolution Error: python2-uritemplate conflicts with python2-uri-templates-0.6-5.el7.noarch You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles -nodigest If I remove python2-uri-templates-0.6-5.el7.noarch than below package ask to remove: Removing: python2-uri-templates noarch 0.6-5.el7 @centos-openstack-rocky 20 k Removing for dependencies: openstack-cinder noarch 1:13.0.5-1.el7 @centos-openstack-rocky 200 k python-cinder noarch 1:13.0.5-1.el7 @centos-openstack-rocky 19 M python2-google-api-client noarch 1.4.2-4.el7 @centos-openstack-rocky 305 k please let help me how can I update. Thanks/Rony

2 3

[qa]Proposing Attila Fazekas (afazekas) to Devstack Core list
by Ghanshyam Mann 30 Jul '19

30 Jul '19

Hello Everyone, I would like to propose to add Attila Fazekas (afazekas) in devstack core list. He has been contributing and reviewing code in devstack since a long time and has deep knowledge of code base. Please reply with your approval or objections. If no objection then till 5th Aug, I will add him in the list. -gmann

1 0

[I18n] project team status update regarding internationalization/translation as July 2019
by Ian Y. Choi 29 Jul '19

29 Jul '19

Hello all, I would like to share current project team status for better visibility into I18n team members, copying to openstack-discuss and user-committee thread: 1. Translation and team effort status There are still lots of translation contribution as you see through Stackalytics: https://www.stackalytics.com/?metric=translations&release=train . The number of translated words is not larger than the previous cycle, but I estimate that it will be similar or a little bit less than the previous cycle since I18n usually contributes translations a lot especially during Soft & Hard StringFreeze periods. Note that I18n team currently sets higher priority on OpenStack user survey translation and project document translations. Such priorities information can be found on Zanata dashboard: https://translate.openstack.org/ . Other progress such as migrating Zanata into other translation platform seems slow - me and Frank are planning to have a virtual sprint. 2. Shanghai Summit & PTG preparation : Frank submitted his presentation including me and Hoarce (China team). Let's wait for final approval on presentation submission. : There should be PTG at Shanghai - please add your name and detail thinking to Etherpad mentioned in http://lists.openstack.org/pipermail/openstack-i18n/2019-July/003436.html . I strongly think to more encourage participation since I expect more participation especially from Chinese translators & contributors. 3. Updating ATC & AUC : Frank previously submitted extra-ATC for Stein through https://review.opendev.org/#/c/633398/ , and this time I would like to submit the stat calculation from 2019-01-26 to 2019-07-25. : All contributors who had commits on openstack/i18n repository will be automatically regarded as Active Technical Contributors [1], and I18n team would like to nominate all translators who contributed translations on OpenStack official repositories (https://governance.openstack.org/tc/reference/projects/ ) >= 300 words as extra-ATCs assuming that their Zanata e-mail IDs are registered as Foundation members. : All translators who contributed >=300 word tranlations to the following projects will be nominated as Active User Contributors [2] assuming that their Zanata e-mail IDs are registered as Foundation members: "contributor-guide, edge-computing, leveraging-containers-openstack, openstack-user-survey, operations-guide". This is new nomination after the decision during Stein PTG with User Committee: Please see [3] and [4] if you would like to follow-up with more information. I will do this nomination for ATC & AUC as PTL just after July 25, although the due of extra ATC is Aug 26-30 [5] since I synced with Foundation that the price of Summit ticket will increase around Aug 7 : processing within the due will be fine, also I set period exactly for six months. 4. Team status : Although I regularly be online during I18n (+Docs) IRC team meetings, I couldn't find enough quorum, and I couldn't proceed more deep conversation with language teams (usually no reply from my e-mails unfortunately). : Current I18n team core members seem busy but when I communicate with them, all they are still very supportive to I18n team projects. I really appreciate their kind help. : Also, I find that some translators are very active comparing to some inactive language coordinators. In this case, would it be a good idea to nominate them as language coordinators? Please share your thoughts. : However, if such lack of team member conversations keep going, then I18n team might decide during upcoming PTG to make translation from an official team status into Special Interest Group [6]. This would mean that there will be no official PTL election and there will be no extra-ATC nomination, although I need to more figure out in details in future. With many thanks, /Ian [1] https://docs.openstack.org/i18n/latest/official_translator.html#atc-status-… [2]https://governance.openstack.org/uc/reference/charter.html#active-user-co… [3] http://lists.openstack.org/pipermail/openstack-i18n/2018-September/003316.h… [4] http://eavesdrop.openstack.org/meetings/uc/2018/uc.2018-10-01-18.02.html [5] https://releases.openstack.org/train/schedule.html [6] https://governance.openstack.org/sigs/

2 2

[TripleO] Transformation squad meeting time
by Kevin Carter 29 Jul '19

29 Jul '19

Hello, I'm writing to get feedback on what the best meeting time would be for all parties interested in participating in the TripleO Transformation Squad efforts. During this weeks meeting, it was raised that the current weekly time, Thursday 13:00 UTC, is less than ideal for a bunch of folks, and we should consider changing it [0]. To ensure we're getting everyone involved in the process, I've created a doodle that will run for one week [1]. In this Doodle, I'd like folks to vote on whatever time works best for them. During the next meeting, 25 Thursday 13:00 UTC, the results of the survey will be announced and the day and time with the highest number of votes will be used for all future meetings. Thank you, and please go vote! [0] http://eavesdrop.openstack.org/meetings/tripleo/2019/tripleo.2019-07-18-13.… [1] https://doodle.com/poll/nkkqnkarhbgp8cxr -- Kevin Carter IRC: kecarter

1 1

[openstack-dev] [neutron] [rally] [osprofiler]
by Miguel Lavalle 29 Jul '19

29 Jul '19

Hi, The Neutron team has been playing lately with Rally scenarios and osprofiler. One example is http://logs.openstack.org/80/671780/1/check/neutron-rally-task/6cc66e4/resu…. As can be seen in this example, we get a lot of trace points from SQLAlchemy with the corresponding SQL statement that was sent the DB. Is there a way we can add information to these trace points to help us relate them to the Neutron code that issued the statement? Cheers Miguel

1 0

[forum][sdk][nova] Closing compute API feature gaps in the openstack CLI - recap
by Matt Riedemann 29 Jul '19

29 Jul '19

I wanted to give a quick recap of this Forum session for those that couldn't attend and also find owners. Please reply to this thread if you'd like to sign up for any specific item. The etherpad [1] has the details. To restate the goal: "Identify the major issues and functional gaps (up through Mitaka 2.25) and prioritize which to work on and what the commands should do." We spent the majority of the time talking about existing issues with compute API functionality in openstack CLI, primarily boot-from-volume, live migration and lack of evacuate support (evacuate as in rebuild on a new target host because the source host is dead, not drain a host with live migrations [2]). We then talked through some of the microversion gaps and picked a few to focus on. Based on that, the agreements and priorities are: **High Priority** 1. Make the boot-from-volume experience better by: a) Support type=image for the --block-device-mapping option. b) Add a --boot-from-volume option which will translate to a root --block-device-mapping using the provided --image value (nova will create the root volume under the covers). Owner: TBD (on either) 2. Fix the "openstack server migrate" command We're going to deprecate the --live option and add a new --live-migration option and a --host option. The --host option can be used for requesting a target host for cold migration (omit the --live/--live-migration option for that). Then in a major release we'll drop the --live option and intentionally not add a --force option (since we don't want to support forcing a target host and bypassing the scheduler). Owner: TBD (I would split the 2.56 cold migration --host support from the new --live-migration option review-wise) **Medium Priority** Start modeling migration resources in the openstack CLI, specifically for microversions 2.22-2.24, but note that the GET /os-migrations API is available since 2.1 (so that's probably easiest to add first). The idea is to have a new command resource like: openstack compute migration (list|delete|set) [--server <server_id>] Owner: TBD (again this is a series of changes) **Low Priority** Closing other feature gaps can be done on an as-needed basis as we've been doing today. Sean Mooney is working on adding evacuate support, and there are patches in flight (see [3]) for other microversion-specific features. I would like to figure out how to highlight these to the OSC core team on a more regular basis, but we didn't really talk about that. I've been trying to be a type of liaison for these patches and go over them before the core team tries to review them to make sure they match the API properly and are well documented. Does the OSC core team have any suggestions on how I can better socialize what I think is ready for core team review? [1] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps [2] http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-co… [3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc -- Thanks, Matt

2 2

[ops][glance][nova] scheduling problem because of ImagePropertiesFilter
by Massimo Sgaravatto 29 Jul '19

29 Jul '19

We have just finished the update of our cloud to Rocky but we are seeing a strange issue with images with property: hypervisor_type='QEMU' The scheduling of instances created with such images fails because of the ImagePropertiesFilter [*] Removing that property from the image, the scheduling works. We also tried changing hypervisor_type='QEMU' --> hypervisor_type='qemu', but this didn't help. Any suggestions? Thanks, Massimo [*] 2019-07-17 13:52:58.148 13312 INFO nova.filters [req-1863bef0-0326-46d1-a836-436227e91eef 6e3b136d578f4292a5c03b16f443ab3d d27fe2becea94a3e980fb9f66e2f291a - default default] Filtering removed all hosts f\ or the request with instance ID '63810b60-76e4-4e76-a1c3-e4d3932c002e'. Filter results: ['AggregateMultiTenancyIsolation: (start: 49, end: 37)', 'AggregateInstanceExtraSpecsFilter: (start: 37, end: 34)', \ 'RetryFilter: (start: 34, end: 34)', 'AvailabilityZoneFilter: (start: 34, end: 34)', 'ComputeFilter: (start: 34, end: 32)', 'ComputeCapabilitiesFilter: (start: 32, end: 32)', 'ImagePropertiesFilter: (star\ t: 32, end: 0)']

5 21

[tc][all] seeking candidates to run in the next TC election
by Doug Hellmann 29 Jul '19

29 Jul '19

Nominations for the next Technical Committee term open on 27 August, just over 4 weeks from now. In the past, we have had people wait until the last minute to consider running, and then in some cases they had issues getting approval from their managers to serve in the role. This time, since I know there will be at least one open seat when I step down, I thought it would be a good idea to start that recruiting process a little earlier. Our community places a high value on democratically electing representative leadership — selecting members of the community to help steer the project. That system only works if we have people willing and able to serve in the elected roles like the Technical Committee. There is no fall-back option. We need community members to step up and run. So, if you are interested in serving on the TC, now is the time ask the necessary questions within your company. If you need advice about how to approach your manager, any current TC member, including me, would be happy to help you. Doug

1 0

[requirements] changes in requests library maintainership
by Doug Hellmann 29 Jul '19

29 Jul '19

It looks like the Kenneth Reitz, the primary maintainer of the requests library, is stepping down [1]. There are several offers to take over right now, so it's not really clear to me what's going to happen. I think we'll want to keep an eye on both requests and requests3 until the new maintainer is designated. And of course if anyone is interested in helping out, I encourage you to get involved in the discussion on github. [1] https://github.com/not-kennethreitz/team/issues/21 -- Doug

2 1

[nova][sfe] Nova part of Image Encryption
by Josephine Seifert 29 Jul '19

29 Jul '19

Hi, we would like to have a spec freeze exception for the spec for the Nova Part of Image Encryption [1] as this is part of a cross-project contribution with specs also in cinder (already merged) and glance. We will attend the next meeting on August 1st. Greetings Josephine (Luzi) [1] https://review.opendev.org/#/c/608696

1 0

[searchlight] Meeting today cancelled
by Trinh Nguyen 29 Jul '19

29 Jul '19

Hi team, I cannot hold the meeting today so please email or ping me on #openstack-searchlight channel. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[ironic][edge] L3/DHCP-Less deployments
by Julia Kreger 29 Jul '19

29 Jul '19

Greetings everyone! Over the last few weeks, I've had numerous discussions with contributors who have expressed interest in the DHCP-less deployment method specification document[0]. It seems many parties are interested! I think the path forward at this time is to get everyone talking about where and how they can help push this feature forward. If those interested could propose time windows when they are available, I'll try to find a mutual time window where we can try to get everyone on IRC or on a call and try to map out the next steps together. Sound good? -Julia [0]: https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3…

2 2

[tc] weekly update
by Mohammed Naser 29 Jul '19

29 Jul '19

Hi everyone, This is the weekly update for what happened inside the Openstack TC last week. You can check for more information in the openstack/governance repository. We had one change only which was the retirement of puppet-crane (from TripleO). Thanks, 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

[Watcher] No IRC meeting this week
by li.canwei2＠zte.com.cn 29 Jul '19

29 Jul '19

Hi team, I'll be on vacation until to August 5, so I can't host meeting this week. Thanks, licanwei

1 0

[neutron] Bug Deputy July 22 - July 29
by Boden Russell 29 Jul '19

29 Jul '19

Below is a list of neutron bugs that came in last week. To the best of my knowledge, the only bug still under discussion is #2 below (and the RFE in #3). Thanks to everyone on the team for their bug diligence. It looks like Brian H. is on deck for bug duty this week. 1) https://bugs.launchpad.net/neutron/+bug/1838068 "QoSTest:test_qos_basic_and_update" failing in DVR node scenario 2) https://bugs.launchpad.net/neutron/+bug/1837916 Trunk subports sometimes not becoming ACTIVE and trunk:subport 3) https://bugs.launchpad.net/neutron/+bug/1837847 [RFE] neutron-vpnaas OpenVPN driver 4) https://bugs.launchpad.net/neutron/+bug/1837635 HA router state change from "standby" to "master" should be delayed 5) https://bugs.launchpad.net/neutron/+bug/1837553 Neutron api-ref should mention that list of e.g. IDs is supported in GET requests 6) https://bugs.launchpad.net/neutron/+bug/1837552 neutron-tempest-with-uwsgi job finish with timeout very often 7) https://bugs.launchpad.net/neutron/+bug/1837529 Cannot use push-notification with custom objects

1 0

[nova][sfe] Use PCPU and VCPU in One Instance
by David Wang 29 Jul '19

29 Jul '19

Hi, We are proposing a Nova spec for the feature of creating an instance of mixed dedicated CPUs and shared CPUs and experience communities review. The spec link is https://review.opendev.org/#/c/668656/ and spec name is "Use PCPU and VCPU in One Instance". I recognized that Nova Sepc for Train release is frozen, I'd like to request a spec freeze exception process and let the spec to be merged in train release. I may have trouble in attending next week's team meeting, on Aug 1, so, please discuss in the email thread. Thanks Huaqiang

1 0