- openstack-discuss - lists.openstack.org

[kolla] Today meeting cancelled Feb-13-2019
by Eduardo Gonzalez 13 Feb '19

13 Feb '19

Hi team, Due to job responsabilities i won't be able to hold today's meeting. Meeting topics haven't changed since last week. If have something wanna discuss please add to next week meeting or raise in the main IRC channel. Regards

1 0

[nova][dev] Which response code should be returned when migrate is called but the src host is offline?
by Lee Yarwood 13 Feb '19

13 Feb '19

Hello all, I can't seem to settle on an answer for $subject as part this bugfix: compute: Reject migration requests when source is down https://review.openstack.org/#/c/623489/ 409 suggests that the user is able to address the issue while 503 suggests that n-api itself is at fault. I'd really appreciate peoples thoughts on this given I hardly ever touch n-api. Thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

4 5

How *-conductor (database accessor) assure concurrency?
by 양유석 13 Feb '19

13 Feb '19

Hi, guys. Today, I encountered strange behaviors and it raise me a simple question which I never concerned about. It's about 'how database accessors like *-conductor assure DB data consistency?' What I've seen is ModelsNotFound in Trove which meaning there is no sqlalchemy query result for the Trove DB model. I'm not sure what's happening before, but what I found is DB entry is actually existed but trove-conductor could not find it emitting exception continuously. At the same time, different trove-conductor would be working normally after restart. First, I thought that sqlalchemy ensures concurrency but after reading related document ( https://docs.sqlalchemy.org/en/latest/orm/session_basics.html#is-the-sessio…) it does not guarantee at all, and user should take all responsibility to manage session. After, I thought oslo.concurrency is promising to ensure consistency by making lock inter process in that the name tells me. But I could not find any related code for locking. So.. What happens internally for *-manage? Any hints would be appreciated. Thanks.

1 0

[cinder][dev] Bug for deferred deletion in RBD
by Jae Sang Lee 13 Feb '19

13 Feb '19

Hello, I recently ran a volume deletion test with deferred deletion enabled on the pike release. We experienced a cinder-volume hung when we were deleting a large amount of the volume in which the data was actually written(I make 15GB file in every volumes), and we thought deferred deletion would solve it. However, while deleting 200 volumes, after 50 volumes, the cinder-volume downed as before. In my opinion, the trash_move api does not seem to work properly when removing multiple volumes, just like remove api. If these test results are my fault, please let me know the correct test method.

3 14

[scientific-sig] IRC Meeting 1100UTC: ISC participation, Summit Forum, GPFS follow-up
by Stig Telfer 13 Feb '19

13 Feb '19

Hi All - We have a Scientific SIG IRC meeting at 1100 UTC (just over an hour away) in channel #openstack-meeting. Everyone is welcome. This week’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_13th_20… <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_February_13th_20…> We’d like to continue the discussions on SIG participation in up-and-coming conferences, and also follow up on user experiences of the GPFS/Manila driver. If anyone has other items to raise, please do add them to the agenda. Cheers, Stig

1 0

Re: [kolla][mariadb] Multinode deployment fails due to bootstrap_mariadb or mariadb errors (Giuseppe Sannino)
by Viktor Shulhin 13 Feb '19

13 Feb '19

Hi Giuseppe, Seems like deployments with Ubuntu base distros are broken. I didn't find any solution for that. I have deployed Rocky with Centos based distro on Ubuntu 16.04 host recently. Some parameters from /etc/kolla/globals.yml are: kolla_base_distro: "centos" kolla_install_type: "binary" openstack_release: "rocky" >Hi all, >need your help. >I'm trying to deploy Openstack "Queens" via kolla on a multinode system (1 >controller/kolla host + 1 compute). >I tried with both binary and source packages and I'm using "ubuntu" as >base_distro.

1 0

[manila][glusterfs] on queens error
by Ignazio Cassano 13 Feb '19

13 Feb '19

Hello All, I installed manila on my queens openstack based on centos 7. I configured two servers with glusterfs replocation and ganesha nfs. I configured my controllers octavia,conf but when I try to create a share the manila scheduler logs reports: Failed to schedule create_share: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter.: NoValidHost: No valid host was found. Failed to find a weighted host, the last executed filter was CapabilitiesFilter. 2019-01-31 16:07:32.614 159380 INFO manila.message.api [req-241d66b3-8004-410b-b000-c6d2d3536e4a 89f76bc5de5545f381da2c10c7df7f15 59f1f232ce28409593d66d8f6495e434 - - -] Creating message record for request_id = req-241d66b3-8004-410b-b000-c6d2d3536e4a I did not understand if controllers node must be connected to the network where shares must be exported for virtual machines, so my glusterfs are connected on the management network where openstack controllers are conencted and to the network where virtual machine are connected. My manila.conf section for glusterfs section is the following [gluster-manila565] driver_handles_share_servers = False share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver glusterfs_target = root@10.102.184.229:/manila565 glusterfs_path_to_private_key = /etc/manila/id_rsa glusterfs_ganesha_server_username = root glusterfs_nfs_server_type = Ganesha glusterfs_ganesha_server_ip = 10.102.184.229 #glusterfs_servers = root(a)10.102.185.19 ganesha_config_dir = /etc/ganesha PS 10.102.184.0/24 is the network where controlelrs expose endpoint 10.102.189.0/24 is the shared network inside openstack where virtual machines are connected. The gluster servers are connected on both. Any help, please ? Ignazio

3 14

[keystone] x509 authentication
by Lance Bragstad 12 Feb '19

12 Feb '19

Hi all, We've been going over keystone gaps that need to be addressed for edge use cases every Tuesday. Since Berlin, Oath has open-sourced some of their custom authentication plugins for keystone that help them address these gaps. The basic idea is that users authenticate to some external identity provider (Athenz in Oath's case), and then present an Athenz token to keystone. The custom plugins decode the token from Athenz to determine the user, project, roles assignments, and other useful bits of information. After that, it creates any resources that don't exist in keystone already. Ultimately, a user can authenticate against a keystone node and have specific resources provisioned automatically. In Berlin, engineers from Oath were saying they'd like to move away from Athenz tokens altogether and use x509 certificates issued by Athenz instead. The auto-provisioning approach is very similar to a feature we have in keystone already. In Berlin, and shortly after, there was general agreement that if we could support x509 authentication with auto-provisioning via keystone federation, that would pretty much solve Oath's use case without having to maintain custom keystone plugins. Last week, Colleen started digging into keystone's existing x509 authentication support. I'll start with the good news, which is x509 authentication works, for the most part. It's been a feature in keystone for a long time, and it landed after we implemented federation support around the Kilo release. Chances are there won't be a need for a keystone specification like we were initially thinking in the edge meetings. Unfortunately, the implementation for x509 authentication has outdated documentation, is extremely fragile, hard to set up, and hasn't been updated with improvements we've made to the federation API since the original implementation (like shadow users or auto-provisioning, which work with other federated protocols like OpenID Connect and SAML). We've started tracking the gaps with bugs [0] so that we have things written down. I think the good thing is that once we get this cleaned up, we'll be able to re-use some of the newer federation features with x509 authentication/federation. These updates would make x509 a first-class federated protocol. The approach, pending the bug fixes, would remove the need for Oath's custom authentication plugins. It could be useful for edge deployments, or even deployments with many regions, by allowing users to be auto-provisioned in each region. Although, it doesn't necessarily solve the network partition issue. Now that we have an idea of where to start and some bug reports [0], I'm wondering if anyone is interested in helping with the update or refactor. Because this won't require a specification, we can get started on it sooner, instead of having to wait for Train development and a new specification. I'm also curious if anyone has comments or questions about the approach. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509

4 6

[openstack-ansible] bug squash day!
by Mohammed Naser 12 Feb '19

12 Feb '19

Hi team, As you may have noticed, bug triage during our meetings has been something that has kinda killed attendance (really, no one seems to enjoy it, believe it or not!) I wanted to propose for us to take a day to go through as much bugs as possible, triaging and fixing as much as we can. It'd be a fun day and we can also hop on a more higher bandwidth way to talk about this stuff while we grind through it all. Is this something that people are interested in, if so, is there any times/days that work better in the week to organize? Thanks! Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 9

[neutron] CI issue related to pyroute2 and latest oslo.privsep
by Slawomir Kaplonski 12 Feb '19

12 Feb '19

Hi, Recently we had one more issue related to oslo.privsep and pyroute2. This caused many failures in Neutron CI. See [1] for details. Now fix (more like a workaround) for this issue is merged [2]. So if You saw in Your patch failing tempest/scenario jobs and in failed tests there were issues with SSH to instance through floating IP, please now rebase Your patch. It should be better :) [1] https://bugs.launchpad.net/neutron/+bug/1811515 [2] https://review.openstack.org/#/c/631275/ — Slawek Kaplonski Senior software engineer Red Hat

2 2