Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-02
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
23:19:03 dansmith yar
23:19:28 mriedem multuple is py4 btw
23:19:37 mriedem which is an openstack goal for T
23:19:40 dansmith badumpum
23:20:59 dansmith ugh, requestspec is the new bdm
23:24:16 dansmith also I'm pretty sure we're serializing to legacy, then passing it to a method that unserializes it
23:24:21 dansmith but I don't even want to think about it right now
23:24:45 melwitt yeah, there's a small piece in between that can't yet handle objects, so it does that
23:24:50 dansmith no,
23:24:52 dansmith I think it's direct
23:24:56 dansmith lemme get links
23:25:18 melwitt oh. I know there's a thing where it serializes to pass to a specific method, then after it comes back it turns it back into an object. or something
23:25:24 dansmith https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L865
23:25:37 dansmith https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L595
23:25:38 dansmith yeah
23:25:58 openstackgerrit Dan Smith proposed openstack/nova master: Request zero root disk for boot-from-volume instances https://review.openstack.org/428481
23:26:05 dansmith mriedem: tests never failed if you push before jenkins finished
23:27:21 melwitt I wonder if I could bolt my sweet functional test onto that patch to further test it. or I could stack it over yours https://review.openstack.org/#/c/355091/8/nova/tests/functional/test_boot_from_volume.py
23:27:54 dansmith that is the worst test I've ever seen
23:28:47 melwitt I was about to be like *gasp* how could you say that!

Earlier   Later