May 2019 - openstack-discuss - lists.openstack.org

[dev][keystone] Keystone Team Update - Week of 6 May 2019
by Colleen Murphy 10 May '19

10 May '19

# Keystone Team Update - Week of 6 May 2019 ## News This was our first week back after the Forum and PTG in Denver and was a slow week for keystone since most of us were recovering. I wrote a recap of the marathon week[1]. [1] http://www.gazlene.net/denver-forum-ptg-2019.html ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 5 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 40 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 3 new bugs and closed 6. Many of these we were able to close together during the spec backlog and RFE review on the last day of the PTG last week. Bugs opened (3) Bug #1828126 (keystone:Undecided) opened by Dmitrii Shcherbakov https://bugs.launchpad.net/keystone/+bug/1828126 Bug #1828565 (keystone:Undecided) opened by Jose Castro Leon https://bugs.launchpad.net/keystone/+bug/1828565 Bug #1827761 (oslo.policy:Undecided) opened by jacky06 https://bugs.launchpad.net/oslo.policy/+bug/1827761 Bugs closed (5) Bug #1815972 (keystone:Wishlist) https://bugs.launchpad.net/keystone/+bug/1815972 Bug #1816163 (keystone:Wishlist) https://bugs.launchpad.net/keystone/+bug/1816163 Bug #1816164 (keystone:Wishlist) https://bugs.launchpad.net/keystone/+bug/1816164 Bug #1816167 (keystone:Wishlist) https://bugs.launchpad.net/keystone/+bug/1816167 Bug #1824239 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1824239 Bugs fixed (1) Bug #1816112 (keystone:Wishlist) fixed by no one https://bugs.launchpad.net/keystone/+bug/1816112 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Spec proposal freeze is in 4 weeks. As discussed at the PTG, we will be very firm about this deadline for Train work. ## Shout-outs Many thanks to everyone - cores, new contributors, casual contributors, members of other project teams, users and operators - who participated in Forum and PTG sessions and provided valuable input. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[Horizon] Openstack Dasboard Frozen at login screen
by Alejandro Ruiz Bermejo 10 May '19

10 May '19

Hi I'm having problems with Horizon (OpenStack Queens running in Ubuntu 18.04.1 LTS), I've installed it following the recomendations at the oficial guides and i can't login into the dasboard, i'm stuck at the login screen. I checked the content of */var/log/apache2/error.log* and this is the output: [Fri May 10 20:47:33.347995 2019] [wsgi:error] [pid 24256:tid 140032273983232] [remote 10.8.2.116:36002] INFO openstack_auth.plugin.base Attempted scope to domain Default failed, will attemptto scope to another domain.[Fri May 10 20:47:36.008849 2019] [wsgi:error] [pid 24256:tid 140032273983232] [remote 10.8.2.116:36002] INFO openstack_auth.forms Login successful for user "admin" using domain "Default", remote address 10.8.2.116.[Fri May 10 20:47:54.033509 2019] [wsgi:error] [pid 24255:tid 140032232019712] [remote 10.8.2.116:36008] INFO openstack_auth.plugin.base Attempted scope to domain Default failed, will attemptto scope to another domain.[Fri May 10 20:47:54.383471 2019] [wsgi:error] [pid 24255:tid 140032232019712] [remote 10.8.2.116:36008] INFO openstack_auth.forms Login successful for user "admin" using domain "Default", remote address 10.8.2.116. According to this i should be already logged into the admin dashboard but i'm still in the login screen Does anyone ever experienced this error, or knows what solution can be done???

1 0

[watcher] Getting infra to update launchpad bugs automatically
by Matt Riedemann 10 May '19

10 May '19

I've noticed that when pushing patches to watcher that the corresponding bug in launchpad isn't updated (in-progress and assign the owner). It looks like this is because the "hudson-openstack" user isn't in the watcher bug team (which I guess is watcher-drivers team?). Would it be possible to add that? Then bugs in launchpad will get automatically updated when posted to gerrit via infra tooling. -- Thanks, Matt

1 0

Documentation update
by saurabh683＠outlook.com 10 May '19

10 May '19

Hi, First of all I would like to thank you for training labs. I successfully installed but I found the training labs README is not updated. I found the username password mentioned did not work for me. so I check the admin-openrc and demo-openrc and it worked. Also the demo project name is different in Horizon. https://github.com/openstack/training-labs Admin Login: * Username: admin * Password: admin_pass osbash@controller:~$ cat admin-openrc.sh export OS_USERNAME=admin export OS_PASSWORD=admin_user_secret export OS_PROJECT_NAME=admin export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_DOMAIN_NAME=Default export OS_AUTH_URL=http://10.0.0.11:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 osbash@controller:~$ cat demo-openrc.sh export OS_USERNAME=myuser export OS_PASSWORD=myuser_user_pass export OS_PROJECT_NAME=myproject export OS_USER_DOMAIN_NAME=default export OS_PROJECT_DOMAIN_NAME=default export OS_AUTH_URL=http://10.0.0.11:5000/v3 export OS_IDENTITY_API_VERSION=3 export OS_IMAGE_API_VERSION=2 osbash@controller:~$ -Thanks, Saurabh

2 1

[watcher][qa] Thoughts on performance testing for Watcher
by Matt Riedemann 10 May '19

10 May '19

Hi, I'm new to Watcher and would like to do some performance and scale testing in a simulated environment and wondering if anyone can give some pointers on what I could be testing or looking for. If possible, I'd like to be able to just setup a single-node devstack with the nova fake virt driver which allows me to create dozens of fake compute nodes. I could also create multiple cells with devstack, but there gets to be a limit with how much you can cram into a single node 8GB RAM 8VCPU VM (I could maybe split 20 nodes across 2 cells). I could then create dozens of VMs to fill into those compute nodes. I'm mostly trying to figure out what could be an interesting set of tests. The biggest problem I'm trying to solve with Watcher is optimizing resource utilization, i.e. once the computes hit the Tetris problem and there is some room on some nodes but none of the nodes are fully packed. I was thinking I could simulate this by configuring nova so it spreads rather than packs VMs onto hosts (or just use the chance scheduler which randomly picks a host), using VMs of varying sizes, and then run some audit / action plan (I'm still learning the terminology here) to live migrate the VMs such that they get packed onto as few hosts as possible and see how long that takes. Naturally with devstack using fake nodes and no networking on the VMs, that live migration is basically a noop, but I'm more interested in profiling how long it takes Watcher itself to execute the actions. Once I get to know a bit more about how Watcher works, I could help with optimizing some of the nova-specific stuff using placement [1]. Any advice or guidance here would be appreciated. [1] https://review.opendev.org/#/c/656448/ -- Thanks, Matt

3 4

Change in behavior in bandit 1.6.0
by Stephen Finucane 10 May '19

10 May '19

We've noticed a spate of recent test failures within the 'pep8' jobs in oslo recently. It seems these are because of the release of bandit 1.6.0. The root cause is that the '-x' (exclude) option seems to have changed behavior. Previously, to match a path like 'oslo_log/tests/*', you could state '-x test'. This option now expects a glob patterns, such as '-x oslo_log/tests/*'. If you use bandit, you probably have to update your 'tox.ini' accordingly. See [1] for an example. It's worth noting that bandit is one of the few packages we don't manage the version for [2], so if you're not already limiting yourself to a version, perhaps it would be a good idea to do so to avoid stable branches breaking periodically. Also, this is something that really shouldn't have happened in a minor version (backwards incompatible behavior change, yo) but it has so we'll live with it. I would ask though that the bandit maintainers, whoever ye be, be more careful about this kind of stuff in the future. Thanks :) Stephen [1] https://review.opendev.org/#/c/658249/ [2] https://github.com/openstack/requirements/blob/master/blacklist.txt

2 2

[glance] Train PTG summary
by Abhishek Kekane 10 May '19

10 May '19

Hi All, I attended OpenStack Train PTG at Denver in last week. It was an interesting event with lots of discussion happening around different OpenStack projects. I was mostly associated with Glance and cross-projects work related to Glance. There were other topics around Edge, UI and QA. >From Edge computing glance prospective, glance has already added a feature for enabling multiple backend support and the people from edge team will work on building more concrete use cases about glance. This cycle Glance is knee towards making multiple stores feature as concrete and enhance the cache management tool. Apart from this, glance will mostly focus on making appropriate changes for releasing glance-store version 1.0.0. Main task related to this is stabilization of multiple stores feature. Glance team has identified below tasks related to release of glance-store version 1.0.0 1. Add multiple stores support to Location API 2. Stabilize multiple stores support 3. Clean out deprecated configuration options 4. Modify deprecation warnings for single store configuration options (Should be removed in V cycle) 5. Resizing issue related to ceph backend Regarding Glance the focus is mostly on stabilizing the multiple stores feature, Glance team has identified below tasks towards the same; 1. Rethinking of file system access 2. Location API to support multiple stores 3. Store IDs will be lazy added to the images upon first access (existing images before enabling multiple stores support) 4. Correction of vocabulary (i.e. where 'backend' is exposed to user change it to 'store') 5. Necessary client changes Another major efforts will be carried out to "Use v2 API for cache management", Glance team will try it's best to deliver the basic cache-management tool to pre-cache the images. Below are some tasks identified related to this work; 1. /v2/cache - endpoint, for listing, deleting and pre-caching images 2. rabbitmq implementation for HA deployment - optional 3. RESTFul policy driven JSON output 4. Deprecate previous glance-cache-manage and glance-cache-prefetcher tools *Cross-Project work:* In this PTG we had discussion with Nova and Cinder regarding the adoption of multiple store feature of Glance. As per discussion we have finalized the design and Glance team will work together with Nova and Cinder towards adding multiple store support feature in Train cycle. Support for Glance multiple stores in Cinder: As per discussion, volume-type will be used to add which store the image will be uploaded on upload-to-image operation. Nova snapshots to dedicated store: Aggrement is, If instance is boot from image, we need to find the store of the base image and upload the snapshot or backup to the same store, if instance is boot from volume then nova creates 0 size image in glance which will be uploaded to default store (so no need to change in case of instance boot from volume scenario). Glance image properties and Cinder encrypted volume key management: new draft spec: https://review.opendev.org/#/c/656895/ Aggrement is, Cinder will add a metadata property 'delete_encryption_key_on_image_deletion' with True to image, and while image is deleted and if this property is present the Glance will make a call to Barbican to delete the related secret. Cinder/Glance creating image from volume with Ceph: References: https://review.openstack.org/#/c/608400/ Solution: Lets not make the size user settable and instead just resize bigger chunks at the time and shrink back after EOF. Below is the Train cycle planning and deadlines for Glance. *Train milestone planning:* *Train T1 - June 03-07:* glance_store v 1.0.0 'Store' vs. 'Backend': Getting the vocabulary correct Clear deprecated config options Modify deprecated warnings for single store config options Stabilize multiple store functionality Rethinking filesystem access Add support for location to identify the store based on location URI Add wrapper function to update store information to existing images Nova backup and snapshots to dedicated stores Cinder to utilize glance multiple store Remove 'owner_is_tenant' config option *Train T2 - July 22-26* Use v2 API for cache management Glance image properties and Cinder encrypted volume key management Cinder/Glance creating image from volume with Ceph *Train T3 - September 09-13* cluster awareness openstackclient vs python-glanceclient Clear deprecated options from glance Get rid of deprecation warning messages Release of non-client and client libraries glance-store (if required) python-glanceclient Glance PTG planning etherpad: https://etherpad.openstack.org/p/Glance-Train-PTG-planning Let me know if you guys need more details on this. Thanks & Best Regards, Abhishek Kekane

1 0

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting
by Miguel Lavalle 09 May '19

09 May '19

Dear Neutrinos, During the recent PTG in Denver we had session were we discussed RFEs. Other RFEs in the pipeline are still in the preliminary discussion stage. As a consequence, let's skip the meeting on May 10th. We will resume on the 17th Best regards Miguel

1 0

[nova][ptg] Summary: Extra specs validation
by Eric Fried 09 May '19

09 May '19

Spec: https://review.openstack.org/#/c/638734/ Summary: Schema for syntactic validation of flavor extra specs, mainly to address otherwise-silently-ignored fat-fingering of keys and/or values. Agreements: - Do it in the flavor API when extra specs are set (as opposed to e.g. during server create) - One spec, but two stages: 1) For known keys, validate values; do this without a microversion. 2) Validate keys, which entails - Standard set of keys (by pattern) known to nova - Mechanism for admin to extend the set for snowflake extra specs specific to their deployment / OOT driver / etc. - "Validation" will at least comprise messaging/logging. - Optional "strict mode" making the operation fail is also a possibility. efried .

2 1

[monasca] Monasca PTG sessions summary
by Witek Bedyk 09 May '19

09 May '19

Hello Team, I've put together some of the items we've discussed during the PTG last week [1]. Please add or update if anything important is missing or wrong. Thanks again for all your contributions during the Summit and the PTG. Cheers Witek [1] https://wiki.openstack.org/wiki/MonascaTrainPTG

1 0