Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-10
15:57:38 dansmith hmm
15:57:45 dansmith I wonder what the performance of that is
15:57:50 mriedem i've always seen these in sqla-migrate but never played with one
15:58:00 mriedem zzzeek_: how terrible are check constraints?
15:58:20 dansmith wait,
15:58:20 zzzeek_ mriedem: most mysql / mariadb variants ignore them
15:58:25 lyarwood http://docs.sqlalchemy.org/en/latest/core/constraints.html#check-constraint
15:58:28 lyarwood Note that some databases do not actively support check constraints such as MySQL.
15:58:30 zzzeek_ mriedem: which is why you never see thme :)
15:58:30 dansmith you have to do your own uniqueness checking in the contraint then
15:58:33 lyarwood ^ yeah what zzzeek_ said
15:58:34 mriedem gdi
15:58:49 zzzeek_ lyarwood: mariadb 10.2 does now. oddly enough this creates more problems :)
15:59:35 dansmith mriedem: I'm sure DB2 supports them and is just hanging out by the punch bowl waiting for someone to care
15:59:47 mriedem i <3 DB2
15:59:52 dansmith I know you do
16:00:00 mriedem i heard ms azure rolled out a dbaas service and i noticed it didn't include db2
16:00:03 mriedem i was hurt
16:00:14 dansmith and shocked, I'm sure
16:00:22 mriedem it does include pg
16:02:07 mriedem ok so if we had an 'active' column on the bdms table, we could set that to true when we do something like set the connection_info on it
16:02:11 mriedem which means it's attached
16:02:29 mriedem but still,
16:02:40 mriedem you could have >1 bdm on the same volume which are both 'active'
16:02:58 mriedem if that volume is multiattach=true
16:04:57 mriedem wonder if there is something that can be done on the cinder side, i.e. a rule saying, you can't have >1 attachment record to the same volume for different instances if the volume is multiattach=false
16:05:15 mriedem or if that's already the rule they have in place
16:14:46 mriedem lee bugged out, but i might have a fix on the cinder side
16:14:51 smcginnis mriedem: I think we can't due to things like migration.
16:14:52 mriedem glory hallelujah
16:15:13 mriedem smcginnis: i'll poke you with the patch when it's up, and i'll hope lee can apply and see if it solves his issue
16:15:25 smcginnis mriedem: OK, sounds like a plan.
16:19:31 openstackgerrit Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886
16:21:25 melwitt mriedem: thanks for adding the neutron stuff to the forum ideas etherpad
16:21:32 mriedem np
16:22:37 mriedem lyarwood: does that also fix bug 1732428?
16:22:37 openstack bug 1732428 in OpenStack Compute (nova) "Unshelving a VM breaks instance metadata when using qcow2 backed images" [Medium,In progress] https://launchpad.net/bugs/1732428 - Assigned to Matt Riedemann (mriedem)
16:24:18 lyarwood mriedem: no, flatten is specific to the rbd imagebackend
16:24:49 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option https://review.openstack.org/554688
16:26:16 jgriffith lyarwood: I added a note to https://bugs.launchpad.net/cinder/+bug/1762687
16:26:16 openstack Launchpad bug 1762687 in Cinder "Concurrent requests to attach the same non-multiattach volume to multiple instances can succeed" [High,New]
16:26:28 lyarwood thanks ./me looks
16:26:33 jgriffith I think the race is the condition check in _reserve_volume on the cidner side
16:26:37 jgriffith mriedem: ^^
16:27:23 mriedem jgriffith: just about got something here
16:27:46 jgriffith mriedem: oh... so I guess that means I was wrong?
16:27:55 mriedem haven't read the comment yet,
16:27:58 mriedem just fixing tests
16:28:01 jgriffith Oh... LOL
16:28:12 jgriffith mriedem: so what you're saying is "there's a chance" :)
16:28:22 smcginnis :)
16:28:28 jgriffith if this were slack I'd insert stupid gif here
16:30:12 smcginnis I think that's the whole reason why folks like slack over irc. :)
16:31:11 melwitt dansmith: this is the patch we talked briefly about on friday at the ptg about flattening rbd images if not CONF.use_cow_images. I had asked the room if there was any usefulness in someone configuring that way and you had said some people would to get better performance https://review.openstack.org/#/c/457886
16:31:20 mriedem lyarwood: can you test this out? https://review.openstack.org/560074
16:31:27 lyarwood mriedem: sure can
16:33:17 mriedem dansmith: melwitt: just fyi, i'll be out for a few hours this afternoon
16:33:56 melwitt k
16:33:57 dansmith melwitt: okay, was there more to that question?
16:36:18 melwitt dansmith: lyarwood rebased it a little while ago and it reminded me that I had been meaning to ask if you could review it. I added the bit about using the CONF.use_cow_images config option as a toggle for flattening
16:36:28 dansmith okay
16:40:59 lyarwood mriedem: that appears to be enough but I'm just spamming requests from the cli again
16:43:23 mriedem lyarwood: ok i'm updating it per jgriffith's comment
16:43:59 jgriffith lyarwood: so just the refresh was enough?
16:44:17 lyarwood mriedem: that's a different issue though right? That's allowing concurrent attach requests for multiattach volumes that are reserved?
16:44:34 jgriffith lyarwood: if so that's great, and we can consider that if adding reserve to the status check has consequences (I still think it might)
16:46:19 lyarwood jgriffith: yeah as above I can't see how adding reserved helps with this non-multiattach race tbh
16:46:50 lyarwood jgriffith: we only expect available or downloading in that case right?
16:46:57 mriedem yeah
16:47:17 jgriffith lyarwood: yes
16:47:20 mriedem and yes i think adding 'reserved' would only be for racing to attach the same multiattach volume to separate instances
16:47:29 jgriffith mriedem: +1
16:47:31 lyarwood kk
16:47:37 lyarwood just checking, thanks
16:47:42 mriedem so if just the volume refresh fixes it, then i could remove the 'reserved' part of this patch, and that can be done later if it's a problem
16:52:56 lyarwood mriedem: yup I'd drop it for now tbh but it's really up to the cinder folks
16:53:41 mriedem lyarwood: if it fixes your issue for non-multiattach volumes then i'm happy to simplify the patch
16:53:52 mriedem i need some time to write a test anyway
17:08:59 cfriesen_ mriedem: did you ever get any further with https://bugs.launchpad.net/nova/+bug/1696125 ? I think we're seeing it too, though it showed up in the guise of a stalled heat stack deletion.
17:08:59 openstack Launchpad bug 1696125 in OpenStack Compute (nova) "Detach interface failed - timeout waiting to detach tap device in linuxbridge job (pike)" [High,In progress] - Assigned to Matt Riedemann (mriedem)
17:11:24 openstackgerrit Sam Yaple proposed openstack/nova stable/pike: Fix wrapping of neutron forbidden error https://review.openstack.org/560087
17:11:40 openstackgerrit Sam Yaple proposed openstack/nova stable/ocata: Fix wrapping of neutron forbidden error https://review.openstack.org/560088
17:12:04 cfriesen_ mriedem: and we're not using linuxbridge
17:16:13 mriedem cfriesen_: no, slipped out of mind since we're not hitting it in the gate anymore
17:17:26 mriedem SamYaple: you have to first backport that to stable/queens
17:17:33 mriedem oh wait
17:17:37 SamYaple mriedem: its in stable queens
17:17:38 SamYaple i checked
17:17:42 mriedem yeah :)
17:17:43 mriedem nvm
17:20:22 SamYaple yea it got me too. its just a 5 month old branch, when queens was still master
17:20:28 SamYaple 5 month old patch*
17:21:02 kashyap dansmith: Just read the scroll. Thanks for the explanation
17:21:56 kashyap dansmith: And yes, I did realize I had to remove 'test.nested'. Just didn't commit to it in the paste-bin. /me tinkers a bit
17:26:29 openstackgerrit Eric Fried proposed openstack/nova master: Test case: ResourceClass.normalize_name with ß https://review.openstack.org/560092
17:26:29 openstackgerrit Eric Fried proposed openstack/nova master: Make ResourceClass.normalize_name handle sharp S https://review.openstack.org/560093
17:30:14 melwitt efried: how did you find that? ^
17:30:29 efried melwitt: Nice one, right?
17:30:37 melwitt yeah o.O
17:30:52 efried I actually found it while working on https://review.openstack.org/#/c/556628/ which I'm now going to abandon (because reasons I'm posting here is a minute)

Earlier   Later