Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
21:26:57 mriedem bauzas: thanks for https://review.openstack.org/#/c/428352/
21:27:13 diana_clarke dansmith: oh, I just recall that being one of the answers to the same question here: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-02-01.log.html#t2017-02-01T13:08:33
21:27:14 pshedimb dansmith, It is not followed by " "created a service record..."
21:27:17 mriedem bauzas: if you still have some stomach left, https://review.openstack.org/#/c/427499/
21:27:37 diana_clarke nevermind
21:27:37 dansmith diana_clarke: the compute node record is service and old-school RT related
21:28:00 bauzas mriedem: I had an open question on https://review.openstack.org/#/c/428352/ about older allocation records
21:28:10 bauzas mriedem: I'm not sure we auto-heal previous records
21:28:17 mriedem bauzas: probably a question for jaypipes
21:28:20 mriedem or cdent
21:28:23 bauzas yup
21:28:26 bauzas folks ?
21:29:11 bauzas mriedem: dansmith: oh man, totally forgot to amend the nova-status check for filters
21:29:13 mriedem i've got to run for awhile
21:29:20 mriedem bauzas: that's not stopship imo
21:29:24 mriedem and we could backport if needed
21:29:37 bauzas mriedem: okay, go to your meeting
21:29:55 cdent bauzas: we check allocations every periodic job in the resource tracker. if what's on the server is different from what we have now, we rewrite it
21:30:15 bauzas cdent: that's what I thought but I wanted to be sure
21:30:46 cdent bauzas: you want me to leave that response on the review too, or okay?
21:30:49 bauzas cdent: so the patch above will autofix allocations after the 60-sec default period, cool
21:30:53 cdent yes
21:31:00 bauzas cdent: nope, not needed, I +Wd it
21:31:06 cdent great
22:04:13 openstackgerrit Jiri Suchomel proposed openstack/nova master: Retry few times when creating the initial connection to libvirtd. https://review.openstack.org/416928
22:24:56 mriedem i'm back
22:28:41 EmilienM mriedem: https://review.openstack.org/#/c/428424/ is available for review when you have time (as PTL you need to sign-off)
22:35:43 mriedem EmilienM: i'm not going to dig into that one today probably
22:36:52 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926
22:38:24 melwitt dansmith: do you know which part of the scheduler/placement code treats RequestSpec root_gb as 0 if BFV during scheduling? I haven't found it yet
22:38:32 EmilienM mriedem: ok, just don't forget it please
22:42:16 dansmith melwitt: here's where we request it: https://review.openstack.org/#/c/417961/41/nova/scheduler/filter_scheduler.py
22:42:19 mriedem edleafe: are you working on the unit tests in https://review.openstack.org/#/c/428375/ ?
22:42:49 dansmith melwitt: but looking at that, we probably have to adjust that logic?
22:43:18 dansmith melwitt: like if is_bfv(), don't include root_gb in there
22:43:24 melwitt dansmith: yeah, I think so. right
22:44:30 dansmith for some reason I had in my head that the math there equaling zero means we don't ask for DISK_GB,
22:44:37 dansmith but if we want root_gb!=0 then we need one more if in there
22:44:49 dansmith melwitt: you want me to work that up?
22:45:01 mriedem i swear i mentioned something about that to bauzas during that review
22:45:07 mriedem because the report client was checking is_bfv
22:45:16 dansmith I did too
22:45:20 dansmith but in irc
22:45:42 melwitt yeah, the reporting is working I think. that means compute hosts won't advertise less disk available if they have bfv instances on them
22:45:45 openstackgerrit Ed Leafe proposed openstack/nova master: Add check for invalid allocation amounts https://review.openstack.org/416752
22:45:51 dansmith yeah
22:45:55 dansmith that's been there for a while
22:46:01 melwitt but that doesn't address the issue of asking for disk when during a request if bfv
22:46:12 dansmith yep, it's a two-liner I think
22:46:13 melwitt -when
22:46:20 edleafe mriedem: yeah - just updated https://review.openstack.org/416752first
22:47:08 melwitt dansmith: yeah, if you want to add that, sure. what's there currently is just making sure disk isn't requested if the flavor has 0 disk. but the bfv thing is flavor can have disk but it ends up on a volume and not on the compute host
22:47:22 dansmith yep yep
22:48:05 mriedem https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@151
22:48:12 mriedem was my comment / question i think
22:49:52 dansmith gdi gerrit
22:50:21 mriedem it seems like the ultimate agreement was we needed to check for bfv in there, and then didn't
22:50:39 melwitt okay, so bauzas was saying wait until cinder is telling the capacity and then check against that. in the future
22:50:55 mriedem which would still be a different resource provider
22:51:00 mriedem is what dan clarified
22:51:20 melwitt okay, so that means we have to pass by this RP then? sorry I don't know how this works
22:51:21 mriedem you'd have an aggregate for the shared storage pool
22:51:25 mriedem with compute RPs in that aggregate
22:51:32 dansmith that's just to get the math right,
22:51:40 dansmith we still don't want to charge it against the compute node if it's a volume
22:51:59 melwitt yeah
22:52:34 dansmith we have BDMs by this point, but I'm not sure they make it to the scheduler to make this easy ...
22:54:12 mriedem edleafe: so https://review.openstack.org/#/c/428375/ depends on https://review.openstack.org/416752 ?
22:54:21 mriedem edleafe: if so, can you rebase them to stack up that way?
22:54:48 edleafe mriedem: I separated them at cdent's request
22:57:06 mriedem sdague: jaypipes: if you're around, would be good to get this in https://review.openstack.org/#/c/427499/
22:57:21 mriedem b/c anyone using nova-status when upgrading to ocata will be possibly busted w/o it
22:57:26 mriedem well, the status check will fail
22:57:36 mriedem which we probably don't want to happen on it's maiden voyage
23:02:03 edleafe So what's the preferred way of dealing with keystone auth exceptions when placement isn't configured? Seems that 726 tests hit the compute node destroy path, which will call placement in https://review.openstack.org/#/c/428375/
23:02:21 edleafe I would prefer to configure it, if possible :)
23:08:15 openstackgerrit Dan Smith proposed openstack/nova master: Request zero root disk for boot-from-volume instances https://review.openstack.org/428481
23:08:30 dansmith melwitt: working on tests now, but want to see a run of that ^ to make sure I've correctly guessed which of the ten BDM formats we have right there
23:10:15 mriedem edleafe: the @safe_connect decorator
23:10:26 dansmith if we had more than a couple hours I'd just rev the rpc api, but..
23:10:41 edleafe mriedem: heh, I was just trying that out...
23:12:30 mriedem edleafe: although you might need to use the scheduler report client / placement fixture that bauzas used in his scheduler tests
23:12:53 edleafe mriedem: we'll see
23:15:15 mriedem dansmith: root_bdm() can return None
23:15:24 mriedem so that will likely explode for a bunch of tests
23:15:26 dansmith mriedem: I know
23:15:27 dansmith duh
23:15:29 dansmith sheesh
23:15:38 dansmith just wanted to make sure YOU knew
23:15:43 dansmith and 6 is the number of tests
23:17:47 mriedem plus
23:17:48 mriedem PLUS
23:17:57 mriedem according to https://github.com/openstack/nova/blob/master/nova/objects/block_device.py#L364 it has to be per-instance
23:18:11 dansmith mriedem: I don't think that applies here,
23:18:16 mriedem i meant tempest tests btw
23:18:17 dansmith because this is a BDM that we replicate for each,
23:18:26 dansmith not a set of bdms from multuple instances
23:18:30 dansmith multiple
23:18:53 mriedem oh right
23:19:00 mriedem copies the list, and then sets the instance uuid on each bdm in thelist

Earlier   Later