Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
21:00:52 bauzas mriedem: there is a py3 issue
21:00:52 mriedem great
21:01:05 bauzas but I'm verifying it
21:01:09 mriedem wouldn't the py3 job fail on that?
21:01:13 bauzas not sure
21:01:18 mriedem it's voting
21:01:19 bauzas mriedem: do we have meeting ?
21:01:22 edleafe meeting today?
21:01:23 mriedem yes
21:01:23 mriedem crap
21:01:31 edleafe bauzas: jinx
21:01:52 mriedem short one
21:04:17 bauzas mriedem: nevermind my comment on py3
21:10:11 tonyb mriedem: I get the quote I'm just not sure how to interpret it in the context of this discussion
21:11:11 mriedem tonyb: that the reqs team can wait :)
21:11:21 mriedem and enjoy some cake while they are waiting
21:11:26 tonyb mriedem: :)
21:11:33 tonyb the cake is a lie!
21:12:04 mriedem unless it's mikal's birthday
21:17:07 pshedimb If anyone has idea about multi node devstack (latest version) setup
21:17:26 pshedimb My comupte node is generating this error when creating an instance
21:17:29 pshedimb ERROR nova.compute.manager [req-392e02de-349a-4791-b390-4449ff466427 None None] No compute node record for host fmwpaxeon39
21:17:48 pshedimb Intially I had placement config error
21:18:05 pshedimb I copied placement config from controller to compute node
21:18:16 pshedimb And now I'm having this error
21:22:15 diana_clarke pshedimb: is placement-api in your ENABLED_SERVICES?
21:23:35 dansmith that error isn't related to placement
21:23:44 dansmith and it's not an error if it's followed by "created a service record..."
21:25:23 pshedimb dansmith, On controller placement-api is enabled
21:25:49 pshedimb On compute node, I copied placement-api related conf to nova.conf manually
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 dansmith diana_clarke: the compute node record is service and old-school RT related
21:27:37 diana_clarke nevermind
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

Earlier   Later