Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-06
16:50:00 melwitt at first I thought maybe ron lund was ron swanson from parks and rec but it wasn't
16:50:23 melwitt that's the only ron I could think of
16:53:40 ronlund i also personally know a ron bruns
16:53:43 ronlund also a powerful name
16:53:51 ronlund really anyone named "ron" shouldn't be fucked with
16:54:21 ronlund ask maya, she'll tell you
16:55:41 melwitt I dunno anyone named ron in real life
16:56:07 ronlund ron bruns is a cattleman from baltic, south dakota
16:56:17 ronlund i think he even sold insurance on the side...
16:56:27 melwitt an enterprising fellow
16:56:46 cdent sounds like ron doesn’t like taxes
16:57:37 sean-k-mooney cdent: someone likes taxes?
16:58:23 sean-k-mooney people tolerate taxes in retrun for services but i have never meet anyone who actully likes them
16:58:31 cdent well presumably anyone who cares for their fellow person in society has some small amount of like for taxes
17:00:01 cdent but ron, being a strong ron, sounds like the sort that might reject the federal gov’s right to tax
17:02:10 penick Aww whaaaat "JunoMan signed on at October 4, 2017 at 9:40:36 PM PDT and has been idle for 1 day, 12 hours, 21 minutes, "
17:02:36 openstackgerrit Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506
17:02:51 ronlund sdague: the "should use allow passing user_data to rebuild" thread has taken a weird path,
17:03:04 ronlund sdague: effectively putting me on the fence about whether or not we should add that when removing personality from rebuild
17:03:20 superdan MrJuno: bravo
17:03:29 MrJuno Gotta own it
17:03:34 sean-k-mooney ronlund: how so? i have not been folowing it
17:03:52 ronlund sdague: it's not like it would be hard to add, and we are saying that user_data replaces personality files, and people do love their rebuild
17:04:02 ronlund sean-k-mooney: just the amount of love for rebuild
17:04:08 sdague ronlund: I'd be fine with that
17:04:31 MrJuno rybridges I think I shall decree that all members of the OpenStack team at Oath wear the scarlet letter J until we're on Ocata
17:04:56 ronlund i originally assumed that personality files were added to rebuild b/c they aren't persisted like user_data is, but looking at the change that added personality files to rebuild, there was no explanation of why in the commit message
17:05:05 ronlund it predated gerrit so i wasn't surprised by that
17:05:17 jgwentworth yeah, ppl not using floating ips like keeping their ip and volumes stay attached and all that jazz
17:08:07 cdent ronlund: so ron bruns probably feeks like he’d be even happier without that thieving corporation tax
17:08:43 ronlund i don't know his actual feelings on taxes. he's genuinely a nice guy, so i doubt it bothers him that much.
17:09:20 cdent a weak ron
17:09:43 openstackgerrit Merged openstack/nova master: Add error notification for instance.interface_attach https://review.openstack.org/506643
17:13:20 jgwentworth uh oh, I'm seeing on some gate runs of the py27 unit test job it's not running all the unit tests, only the os profiler test http://logs.openstack.org/66/509766/1/check/gate-nova-python27-ubuntu-xenial/794e1a9/testr_results.html.gz
17:13:57 jgwentworth this is bad
17:19:36 jgwentworth I think maybe it's only happening on stable
17:21:16 jgwentworth I see it on stable/pike and stable/ocata
17:22:22 jgwentworth stable/newton looks okay
17:24:25 sean-k-mooney jgwentworth: is it on master
17:24:40 jgwentworth sean-k-mooney: I'm not seeing it on master
17:25:11 sean-k-mooney jgwentworth: thats not so bad then because master should prevent anything getting backported if the unit tests fail
17:25:28 sean-k-mooney though i guess it would not catch dependecy issues
17:25:37 jgwentworth yeah, definitely not as bad as on master
17:26:18 superdan sean-k-mooney: help, but not prevent.. a backport could assert something that is true on master and not on stable and we'll think it's okay to merge
17:26:21 sean-k-mooney i guess that has something to do with the zuul v2->v3->v2 changes in the last few weeks
17:26:42 jgwentworth ronlund: I noticed on stable/pike and stable/ocata there's something wrong with our unit test jobs and they're running the os test profiler test instead of all of the unit tests ^
17:27:30 ronlund jgwentworth: sounds like an issue for mtreinish
17:28:03 ronlund did some stestr stuff get mixed up in stable?
17:28:35 sean-k-mooney jgwentworth: that should be defiend by this job spec correct https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/python-jobs.yaml#L109-L131
17:29:37 jgwentworth I dunno, I'm not familiar with how this works but that looks like probably
17:30:18 ronlund the zuulv3 jobs were defined elsewhere
17:30:21 ronlund in openstack-zuul-jobs
17:30:29 ronlund but that's for zuulv3, the zuulv2 stuff should be as before
17:30:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Deprecate allowed_direct_url_schemes and nova.image.download.modules https://review.openstack.org/510195
17:30:32 ronlund but i'm no expert
17:30:52 ronlund i would be suspect of something with stestr but we shouldn't be using that in stable
17:31:49 ronlund cdent: btw i got a recreate of the scheduling 409 failure on https://review.openstack.org/#/c/507918/
17:32:01 ronlund http://logs.openstack.org/18/507918/6/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4f175d/logs/screen-n-sch.txt.gz#_Oct_04_18_32_08_753794
17:32:15 ronlund it doesn't have a logging patch in that run which logs which instance failed and prompted retries
17:32:24 ronlund but maybe not necessary to debug?
17:32:32 jgwentworth newton: https://review.openstack.org/#/c/509441/ ocata: https://review.openstack.org/#/c/509440/ pike: https://review.openstack.org/#/c/509439/
17:32:53 sean-k-mooney looking at https://review.openstack.org/#/c/509766/ its reporting as jenkins not zuul so i guess the python job is running as zuul v2.5 not v3
17:33:01 jgwentworth newton job is fine, ocata and pike are messed up
17:33:02 ronlund well i guess we should know because the instance uuid is logged right before it
17:33:38 jgwentworth sean-k-mooney: yeah, this is the old jenkins stuff that I'm looking at
17:35:55 jgwentworth mtreinish we need you
17:37:09 ronlund hmm and we only ever put RP inventory once - which is what i expected since it's the fake driver and inventory doesn't change
17:37:09 ronlund http://logs.openstack.org/18/507918/6/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4f175d/logs/screen-placement-api.txt.gz#_Oct_04_18_27_24_496283
17:37:30 jgwentworth I know that ostestr uses stestr underneath starting in a specific version. so if our ostestr version is sufficiently new, we could be getting stestr behavior
17:37:45 ronlund so what else can cause "Inventory changed while attempting to allocate: Another thread concurrently updated the data." if not updating the RP inventory?
17:37:54 ronlund leakypipes: ^ any ideas?
17:38:52 ronlund other allocations on the same resource provider at the same time i suppose
17:39:59 sean-k-mooney ronlund: should there not be a db lock on the inventory while a transaction is in flight that would prevent multiple concurent updates
17:40:39 ronlund we're not actually updating the inventory
17:40:45 ronlund besides the first time when the RP is created
17:40:58 ronlund we are making allocations in a loop in the scheduler
17:41:07 ronlund one by one, this isn't concurrent as far as i know
17:41:27 sean-k-mooney unless you have 2+ schduers doing this at the same time
17:42:53 sean-k-mooney just looking at http://logs.openstack.org/18/507918/6/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4f175d/logs/screen-placement-api.txt.gz#_Oct_04_18_27_24_496283 so there we are creating the inventory right?
17:43:12 sean-k-mooney or is the payload of the put an update
17:43:48 jgwentworth okay, so it's running all the tests, just showing the results of the os profiler run only, so it looks like this is just a display problem
17:44:13 jgwentworth like, it's picking up the wrong results to show in the testr_results html
17:44:38 sean-k-mooney jgwentworth: thats good because looking at https://raw.githubusercontent.com/openstack-infra/project-config/master/zuul.d/projects.yaml and the job definition everything looks correct
17:44:44 ronlund sean-k-mooney: it's only 1 scheduler
17:44:53 openstackgerrit Merged openstack/nova master: api-ref: note that project_id filter only works with all_tenants https://review.openstack.org/509650
17:45:40 ronlund sean-k-mooney: and yes, PUT /placement/resource_providers/c8d3d366-c0a0-481d-b7e7-b3e31b8b73e8/inventories is updating the inventory for the compute node resource provider with uuid c8d3d366-c0a0-481d-b7e7-b3e31b8b73e8
17:45:48 ronlund that happens when nova-compute starts up and creates the compute node
17:46:09 ronlund gotta run to get my license renewed, bbiab
17:46:13 sean-k-mooney ronlund: my point was its not safe to decorment an inventory by doing a put with the new value if you have 2 schduler that will create a race
17:46:39 ronlund sean-k-mooney: the PUT has a generatoin id in it
17:46:41 ronlund like an etag
17:47:06 ronlund and we're only doing it once anyway
17:47:14 ronlund so i don't think that's the issue
17:47:15 sean-k-mooney oh ok so if it does not match the current generation then the scecond put will fail and retry
17:47:32 ronlund the 2nd put would fail and the client would have to fetch the latest generation and update their requet
17:47:40 ronlund the server doesn't do it automatically
17:47:47 ronlund the consumer allocation is what's failing with the 409
17:47:53 ronlund there is no generation id on the consumer allocation
17:47:56 andreykurilin superdan: as expected, your fix works :)
17:48:03 jgwentworth I'm guessing it has something to do with the newer ostestr being stestr underneath and somehow it's messing up the result gathering

Earlier   Later