February 2019 - openstack-discuss

[tripleo][openstack-ansible] collaboration on os_tempest role update XI - Feb 19, 2019
by Chandan kumar 19 Feb '19

19 Feb '19

Hello, Here is the 11th update (Feb 13 to Feb 19, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Summary: This week was still a calm week. we unblocked the os_heat CI, thanks to mnaser, odyssey4me and guilhermesp. In os_tempest we can also disable the router ping and run mistral tempest tests. Default zero disk flavor to RULE_ADMIN_API in Stein [https://review.openstack.org/#/c/603910/] patch in nova broke python-tempestconf, but os_tempest was working fine as it has already using DISK=1. Now everything is fixed Things got merged: os_tempest * Add tempest_service_available_mistral with distro packages - https://review.openstack.org/635180 * Add option to disable router ping - https://review.openstack.org/636211 python-tempestconf * Update image flavor to have some disk - https://review.openstack.org/637679 os_heat * Fixed the egg name of heat to openstack_heat - https://review.openstack.org/635518 Things in progress: os_tempest * Ensure stackviz wheel build is isolated - https://review.openstack.org/637503 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Use the correct heat tests - https://review.openstack.org/630695 * Added dependency of os_tempest role - https://review.openstack.org/632726 * Revert "Only init a workspace if doesn't exists" - https://review.openstack.org/637801 TripleO: * Reuse the validate-tempest skip list in os_tempest - https://review.openstack.org/634380 Note: os_tempest tripleo CI got broken, we are working on fixing this bug https://bugs.launchpad.net/tripleo/+bug/1816552 Upcoming week: * Complete heat support in os_tempest Here is the 10th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002608… Thanks, Chandan Kumar

1 0

[Openstack][Heat] service times out 504
by Florian Engelmann 19 Feb '19

19 Feb '19

Hi all, - Version: heat-base-archive-stable-rocky - Commit: Ica99cec6765d22d7ee2262e2d402b2e98cb5bd5e I have a fresh openstack deployment (kolla-Ansible). Everything but Heat is working fine. When I do a webrequest (either horizon or curl) on the openstack heat endpoint (internal or public), I just get nothing and after a while, it times out with a 500 http error. root@xxxx-kolla-xxxx:~# curl -vvv http://10.10.10.10:8004/v1/e7f405fb2b7b4b029dfc48e06920eb92 * Trying 10.x.y.z * Connected to heat.xxxxxxxx (10.x.x.x.) port 8004 (#0) > GET /v1/e7f405fb2b7b4b029dfc48e06920eb92 HTTP/1.1 > Host: heat.xxxxxxxxx:8004 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Content-Type: application/json < Content-Length: 4338 < X-Openstack-Request-Id: req-46afc474-682b-4938-8777-b3b4b6fcb973 < Date: Fri, 15 Feb 2019 13:08:04 GMT < {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, In the heat_api log I see the request coming through, but it seems that there is just no reply. 2019-02-15 14:16:40.047 25 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET / Accept: <no header in request> process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2019-02-15 14:16:40.048 25 INFO eventlet.wsgi.server [-] 10.x.y.z - - [15/Feb/2019 14:16:40] "GET / HTTP/1.0" 300 327 0.001106 Should the api give some output when I do a http request? Any hints? Thanks a lot, its quite urgent.. Built 11.0.0 and current rocky-stable (11.0.0.1dev), same on both versions. ## with a horizon request (just click on Project -> Compute -> Orchestration -> Stacks 2019-02-15 14:22:22.250 22 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET /v1/beb568af3781471d94c3623805946ca3/stacks Accept: application/json process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2019-02-15 14:22:22.250 22 DEBUG heat.api.middleware.version_negotiation [-] Matched versioned URI. Version: 1.0 process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 2019-02-15 14:22:23.003 22 DEBUG eventlet.wsgi.server [req-663d17e3-7e41-4c9e-a30a-a43ef18cf056 - - - - -] (22) accepted ('10.xxx.xxx.xxx', 51084) server /var/lib/kolla/venv/lib/python2.7/site-packages/eventlet/wsgi.py:883 2019-02-15 14:22:23.004 22 DEBUG heat.api.middleware.version_negotiation [-] Processing request: GET / Accept: <no header in request> process_request /var/lib/kolla/venv/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 Best regards, Flo

2 1

[cinder] questions about release cycles
by Kulazhenkov, Yury 19 Feb '19

19 Feb '19

Hi all, I'm currently maintain VxFlex OS(ScaleIO) cinder driver. Driver require some changes to support future VxFlex OS release. We want to add this changes to Stein release and if it possible backport them to old supported releases. I have couple questions: 1. Is it still possible to submit patches which extend driver functionality in Stein release cycle? If such changes are still possible, then I have another question: I already submitted patch that renames ScaleIO driver to VxFlex OS (https://review.openstack.org/#/c/634397/) Is it possible that this patch will be merged during Stein release cycle? In other words, I'm interesting, should I prepare "new feature" patch based on this "renaming" patch (as patch chain) or it will be better to prepare separate patch based on master branch state? 2. Is it possible to add new driver features (changes for compatibility, to be more accurate) for currently supported Openstack releases? Any rules, policy or special workflow for that? Thanks, Yury

2 1

Re: [openstack-community] Help on OpenStack-Kolla
by Eduardo Gonzalez 19 Feb '19

19 Feb '19

Openstack-dicuss is the ML, what area need help? Regards El mar., 19 feb. 2019 a las 8:24, Vlad Blando (<vblando(a)morphlabs.com>) escribió: > Hi, > > Is there a mailing list that tackles issues specific to openstack-kolla? > > Regards, > > /Vlad > ᐧ > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community >

1 0

[dev][keystone] Keystone Team Update - Week of 11 February 2019
by Colleen Murphy 19 Feb '19

19 Feb '19

# Keystone Team Update - Week of 11 February 2019 ## News ### Blueprints Overhaul After someone inquired about a very old Launchpad blueprint that was not aligned with reality, we started a campaign to clean up all of the keystone blueprints. Lance described the proposed plan[1] which is to stop using Launchpad blueprints for tracking feature work and to consolidate everything into specs and RFE bug reports. The plan is also in discussion in our spec template[2]. Once we have our backlog cleaned up, it will hopefully be a little more straightforward to port all of our tracked work into Storyboard when the time comes. There are also quite a few open blueprints that we need to discuss as a team to reaffirm whether they are moving in the right direction and still worthwhile[3]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002672… [2] https://review.openstack.org/625282 [3] https://etherpad.openstack.org/p/keystone-blueprint-cleanup ### OpenStack User Survey Since the Foundation is working on this year's user survey, we talked about what we want included on it[4]. We've found the current keystone question is not really detailed enough to give us concrete feedback, but unfortunately we're limited to two questions. We decided to add one additional question[5] and the Foundation has also offered to help collect more fine-grained feedback via a Surveymonkey survey. [4] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-02-12-1… [5] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 16 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 68 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 6 new bugs and closed 3. Bugs opened (6) Bug #1815539 (keystone:High) opened by Guang Yee https://bugs.launchpad.net/keystone/+bug/181553 Bug #1815771 (keystone:Medium) opened by Jose Castro Leon https://bugs.launchpad.net/keystone/+bug/1815771 Bug #1815810 (keystone:Low) opened by Drew Freiberger https://bugs.launchpad.net/keystone/+bug/1815810 Bug #1815966 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815966 Bug #1815971 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815971 Bug #1815972 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1815972 Bugs fixed (3) Bug #1804446 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1804446 Bug #1805372 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805372 Bug #1813739 (keystonemiddleware:Undecided) fixed by Yang Youseok https://bugs.launchpad.net/keystonemiddleware/+bug/1813739 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Feature freeze as well as final client release are both in 3 weeks. Non-client release deadline is in two weeks, which means changes needed for keystonemiddleware, keystoneauth, and the oslo libraries need to be proposed and reviewed ASAP. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

3 5

[neutron] Bug deputy report week of February 11th
by Brian Haley 18 Feb '19

18 Feb '19

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1815585 - Floating IP status failed to transition to DOWN in neutron-tempest-plugin-scenario-linuxbridge - intermittent gate failure * https://bugs.launchpad.net/neutron/+bug/1815618 - cannot update qos rule - Bence took ownership, triaging * https://bugs.launchpad.net/neutron/+bug/1815629 - api and rpc worker defaults are problematic - Fix proposed - https://review.openstack.org/636363 * https://bugs.launchpad.net/neutron/+bug/1815758 - Error in ip_lib.get_devices_info() retrieving veth interface info - Fix proposed - https://review.openstack.org/#/c/636652/ * https://bugs.launchpad.net/neutron/+bug/1815797 - rpc_response_max_timeout" configuration variable not present in fullstack tests - Fix proposed - https://review.openstack.org/#/c/636719/ - Duplicate - https://bugs.launchpad.net/neutron/+bug/1816443 * https://bugs.launchpad.net/neutron/+bug/1815912 - [OVS] exception message when retrieving bridge-id is not present - Fix proposed - https://review.openstack.org/#/c/636963/ * https://bugs.launchpad.net/neutron/+bug/1815913 - DVR can not work with multiple routers on single network. - Fix proposed - https://review.openstack.org/#/c/636953/ * https://bugs.launchpad.net/bugs/1816239 - Functional test test_router_processing_pool_size failing - Fix proposed - https://review.openstack.org/#/c/637544/ Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1815609 - [fwaas] devstack plugin fails if ML2/OVS is not use - Fix proposed - https://review.openstack.org/#/c/636340/ * https://bugs.launchpad.net/neutron/+bug/1815871 - neutron-server api don't shutdown gracefully - Fix proposed - https://review.openstack.org/#/c/636855/ Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1815600 - "tags" listed in POST in api-ref - bug in docs * https://bugs.launchpad.net/neutron/+bug/1816395 - L2 Networking with SR-IOV enabled NICs in neutron - bug in docs Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1815498 - Use pyroute2 to check vlan/vxlan in use - Fix proposed - https://review.openstack.org/#/c/636296/ * https://bugs.launchpad.net/neutron/+bug/1815933 - [RFE] Allow bulk-tagging of resources - Discussed at drivers meeting 2/15 Invalid bugs ------------ None Further triage required ----------------------- * https://bugs.launchpad.net/neutron/+bug/1815728 - Can delete port attached to VM without Nova noticing - The nova_notifier code should have done this, asked for more info, no answer yet * https://bugs.launchpad.net/neutron/+bug/1815989 - OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky - Asked for clarification on issue, Sean Mooney indicated it was os-vif related so added the component.

1 0

[nova] boot from volume with root_gb=0 flavors is not allowed now
by Mohammed Naser 18 Feb '19

18 Feb '19

Hi everyone, Just wanted to give a heads up about the change that recently merged in Nova which will affect Train (and current master, for deployment projects). https://review.openstack.org/#/c/603910/ As of that change, Nova will no longer allow you to to create a VM when the root_gb of a flavor is set to 0. This is to avoid a reported security issue which we've found a while ago: https://launchpad.net/bugs/1739646 If you're using devstack, you'll probably be okay as the following change has already fixed it: https://review.openstack.org/#/c/619319/ However, deployment projects will need to make that adjustment as well as deployers need to plan accordingly (everyone is going to upgrade to Train the day we release, right?) -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[manila] Fw: [nova] boot from volume with root_gb=0 flavors is not allowed now
by Tom Barron 18 Feb '19

18 Feb '19

Some of the jobs in manila gate were booting service VMs with root_gb=0 and got caught by this but were fixed here [1]. That's a devstack plugin fix, so as Mohammed warns, your distribution tests downstream may require their own adjustment. [1] https://review.openstack.org/#/c/637176

1 0

[keystone][service-catalog] Region "*" for identity in service catalog
by Artem Goncharov 18 Feb '19

18 Feb '19

Hi all, In a public cloud I am using there is currently one region, but should be multiple in future. Endpoint for each service has a region set. However the only exception is identity, which has an empty region (actually "*"). If I do not specify region_name during connection (with diverse tools) everything works fine. Some "admin" operations, however, really require region to be set. But if I set in (i.e. in clouds.yaml) I can't connect to cloud, since identity in this region has no explicit endpoint (keystoneauth1 is not ok with that, gophercloud as well) I was not able to find any requirements/conventions, how such setup should be really treated. On https://wiki.openstack.org/wiki/API_Special_Interest_Group/Current_Design/S… there are service catalogs for diverse clouds, and in case where a cloud has multiple region, there are multiple entries for keystone pointing to the same endpoint. Basically each time there is region properly set. In Keystone.v2 region was mandatory, but in v3 it is not anymore ( https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/…) I guess in a normal way you would not be even able to configure region "*", but it was somehow done. While there is only one region the problem is not that big, but as soon as second region is added it becomes problem. Does anyone knows if that is an "allowed" setup (but then tools should be adapted to treat it properly), or this is not an "allowed" configuration (in this case I would like to see some docs to refer properly). I would personally prefer second way of fixing catalog to avoid fixes in diverse tools, but I really need a weightful reference for that. Thanks a lot in advance, Artem

2 1

[ironic] Ironic Stein Mid-Cycle Notes
by Michael Turek 18 Feb '19

18 Feb '19

Ironic had it's virtual mid-cycle call on January 21st and 22nd. Discussions were around how far along we were with priorities this cycle, making the project more container friendly, Smart NIC support, bug triaging, and more. If you are interested in seeing more about these discussions, we suggest that you check out the etherpad where we kept notes. https://etherpad.openstack.org/p/ironic-stein-midcycle If you have anything you'd like to bring up about the notes or the mid-cycle, please reach out here or on #openstack-ironic Thanks!

1 0