Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-04
14:15:49 macsz johnthetubaguy: np :)
14:44:17 openstackgerrit Sean Dague proposed openstack/nova: Add aggregate notification related enum values https://review.openstack.org/396209
15:03:06 gabor_antal Hey, would someone please review this patch? https://review.openstack.org/#/c/411816/
15:09:05 openstackgerrit Matt Riedemann proposed openstack/nova: Enable Neutron by default https://review.openstack.org/416083
15:13:42 johnthetubaguy mriedem: is that a disney themed snack?
15:13:57 mriedem sdague: sfinucan: thanks for going through that use_neutron series
15:14:02 mriedem johnthetubaguy: touche
15:14:05 mriedem but not this time
15:14:12 sdague mriedem: no prob, I'm still chugging up the stack right now
15:14:18 mriedem johnthetubaguy: it's -25 F with wind chill here today
15:14:29 mriedem keeps out the riff-raff
15:14:30 johnthetubaguy mriedem: thats proper nasty
15:14:40 johnthetubaguy the temperature that is :)
15:15:37 kashyap mriedem: Holy moly, -25...
15:15:48 kashyap Here I am trying to keep myself warm without heating from -1
15:16:16 mriedem coffee helps
15:16:28 dansmith mriedem: wow.. it's 24F here now, forecast for 17 tonight and we're all raising hell about it
15:16:29 edleafe mriedem: Yeah, it's like the arctic here in San Antonio - just under 50F!
15:16:58 mriedem dansmith: it's a good thing all those hipsters have beards and stocking caps year round
15:16:59 sfinucan mriedem: np. I'll grab the last one once Jenkins is happy
15:16:59 dansmith 7F with the wind chill I guess
15:17:03 dansmith mriedem: heh
15:17:33 mriedem edleafe: my wife was in phoenix last week complaining about it being about that temp
15:18:09 edleafe mriedem: yeah, having to wear a light hoodie is too much to bear
15:23:24 mriedem bauzas: are you around?
15:23:48 bauzas mriedem: indeed
15:23:56 bauzas just doing lots of internal stuff
15:24:25 mriedem bauzas: was wondering where you're at with https://blueprints.launchpad.net/nova/+spec/resource-providers-scheduler-db-filters
15:24:48 bauzas mriedem: the API change is waiting for reviews and I'm working on implementing the scheduler change
15:25:06 bauzas which is the only change needed for ^
15:25:19 openstackgerrit sahid proposed openstack/nova: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023
15:25:21 openstackgerrit sahid proposed openstack/nova: objects: add new field cpus_overhead in NUMACell https://review.openstack.org/400874
15:25:21 openstackgerrit sahid proposed openstack/nova: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364
15:25:22 openstackgerrit sahid proposed openstack/nova: numa: fit instance toplogy with cpu overhead onto cores https://review.openstack.org/400875
15:25:23 openstackgerrit sahid proposed openstack/nova: virt: update overhead to take into account vCPUs https://review.openstack.org/385024
15:25:25 openstackgerrit sahid proposed openstack/nova: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878
15:25:26 openstackgerrit sahid proposed openstack/nova: numa: take into account cpus overhead https://review.openstack.org/400876
15:25:27 openstackgerrit sahid proposed openstack/nova: numa: update numa usage incording the cpu overhead https://review.openstack.org/400877
15:25:40 mriedem bauzas: ok i knew about https://review.openstack.org/#/c/392569/
15:25:44 mriedem just haven't gone through it yet
15:25:58 mriedem but wanted to know if you were at least doing the scheduler side stuff locally already, sounds like you are
15:26:46 bauzas indeed
15:26:55 mriedem btw, i was wondering, even though we're going to use the placement API for simple resource classes/filters like cpu/memory/disk, don't we still end up calling ComputeNodeList.get_all() for the other more advanced filters?
15:27:18 mriedem or is the idea to widdle the original list of compute nodes based on what the placement API gives us
15:27:34 mriedem regardless of the order of the scheduler filters in the config
15:27:37 johnthetubaguy (I thought it was the later)
15:27:48 bauzas mriedem: the latter yes
15:27:51 mriedem ok
15:28:28 bauzas (sorry, I'm awfully busy today, hopefully being less impacted tomorrow :/ )
15:28:45 mriedem np. on that note, i'm running to a meeting.
15:35:18 sdague cdent: are you fine with this - https://review.openstack.org/#/c/407180/6 ?
15:38:33 cdent sdague: I think the code has some stylistic issues, but functionally it's okay. I can go ahead and leave those comments now, but I wouldn't want it to block.
15:39:16 openstackgerrit Christopher Martin proposed openstack/nova: Bugfix: Changes to Instance Soft Delete https://review.openstack.org/386756
15:39:35 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(2): Introduce base PowerVM driver (disk drv) https://review.openstack.org/409401
15:43:48 cdent sdague, edleafe: I've left those comments
15:56:16 openstackgerrit Gábor Antal proposed openstack/nova: Added missing decorator for instance.create.error https://review.openstack.org/416597
16:02:05 jaypipes edleafe: hey! you know I love my C code :)
16:09:54 cfriesen any chance of getting some reviewers for https://review.openstack.org/#/c/260339/ ? (It's not my patch, but it's a useful fix.) There's a note about a possible tempest race in the bug, so would we need to fix the tempest test before fixing nova?
16:10:44 openstackgerrit Gábor Antal proposed openstack/nova: Removed unnecessary parantheses and fixed formation https://review.openstack.org/370549
16:19:33 openstackgerrit melanie witt proposed openstack/nova: WIP Count resources to check quota for cells https://review.openstack.org/416521
16:20:42 edleafe cdent: Not sure what I was going for there, but yeah, it looks wrong. Will fix.
16:21:21 cdent ✔
16:30:14 openstackgerrit Gleb Stepanov proposed openstack/python-novaclient: Add evacuate host method https://review.openstack.org/349179
16:30:52 sfinucan mriedem: Boom https://review.openstack.org/#/c/416083
16:32:09 openstackgerrit Gábor Antal proposed openstack/nova: Removed unnecessary parantheses and fixed formation https://review.openstack.org/370549
16:32:33 sfinucan :P
16:32:42 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(3): Introduce base PowerVM driver (console) https://review.openstack.org/409402
16:36:29 openstackgerrit Ed Leafe proposed openstack/nova: Do not post allocations that are zero https://review.openstack.org/407180
16:36:43 edleafe cdent: should be better ^^
16:37:29 cdent edleafe: decided you didn't like my concern about self.used?
16:38:57 edleafe cdent: you mean protecting against negative used values?
16:39:24 cdent yes, and also being explicit about the conditional being numeric
16:39:48 edleafe cdent: not sure I follow
16:40:39 cdent I just think that self.used == 0 or self.used <= 0 is more explicit/readable than not self.used
16:41:02 mriedem sdague: mtreinish: easy one https://review.openstack.org/#/c/416401/
16:41:06 mriedem sfinucan: thanks
16:41:09 edleafe cdent: self.used == 0 is major ugly in Python
16:41:27 edleafe <= 0 is another thing
16:41:31 mtreinish mriedem: +2
16:41:45 cdent but it is _exactly_ what you mean to be testing for there, especially based on the message raised if it is true
16:42:00 edleafe cdent: if you think we need to guard against negative values, I'll add <= 0
16:42:40 cdent a) just out of curiosity why is self.used == 0 ugly? b) I'm not sure if we do or not, I'm asking, not telling
16:43:07 mriedem dansmith: there will be a thrilling cells v2 meeting in 17 minutes yes?
16:43:34 mriedem dare i say titilating
16:44:09 edleafe cdent: 0, False, empty string/dict/list/tuple/set/etc are all boolean False, so you don't test for == 0, or == {}, or the like
16:44:43 cdent edleafe: I understand that, and that's my point: you _are_ testing for 0 here. Not False or empty
16:45:03 openstackgerrit Sylvain Bauza proposed openstack/nova: Expose a REST API for a specific list of RPs https://review.openstack.org/392569
16:45:06 cdent because the fields definition has already established that used must be an int
16:45:10 dansmith mriedem: figured yeah
16:45:17 edleafe cdent: if you are getting unexpected parameter types here, you have much bigger problems
16:45:46 bauzas jaypipes: mriedem: dansmith: others, wanna bite https://review.openstack.org/392569 ?
16:46:07 cdent edleafe: hmm, I think we are miscommunicating a bit. At what stage of the process are ovo field types validated?
16:46:56 mriedem bauzas: it's in a tab
16:47:05 cdent if it is _before_ create is called, then self.used is always an int, and therefore the most limited and explicit (and thus readable) conditional is self.used == 0
16:47:17 bauzas mriedem: just added a new test, so Ctrl-R is needed :)
16:47:21 cdent edleafe: that's all I'm saying
16:47:45 mriedem tdurakov: pkoniszewski: it would be awesome if we had a diagram of the call stack during live migration so i didn't have to relearn it everytime i'm reviewing something like this https://review.openstack.org/#/c/140045/51/nova/virt/hyperv/livemigrationops.py
16:47:53 edleafe cdent: if it could be an unexpected type, then you should do the type checking sepately
16:48:11 cdent yes, we agree on that
16:48:38 edleafe cdent: but if it's the correct type, then == 0 is ugly

Earlier   Later