Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-27
07:56:20 melwitt kashyap: np, it was ... a learning experience
07:56:34 melwitt (it took me a long time to figure out how to test it) :P
07:56:55 kashyap melwitt: :-) Are the confusing bits from the commit message replaced?
07:57:28 kashyap melwitt: From the bug report, seems like you've tested it directly from `virsh` :-)
07:57:53 melwitt kashyap: yeah, mriedem updated the commit message to take out the part about ceph + writeback because I don't think that's related to the bug. that is, I don't think there's anything in nova that makes ceph automatically configure itself for writeback
07:58:25 kashyap melwitt: Yep, just noticed. Thank you
07:58:45 kashyap Also feel free to edit away the commit message even if you didn't write if it's wrong / confusing :-)
07:58:46 melwitt kashyap: no, I was able to reproduce it in unit tests. the virsh stuff is from the downstream bug report, I thought it would more clearly illustrate what the problem was
07:58:59 kashyap Ah, right
07:59:21 melwitt in case ppl don't know what "cache mode" means, just to show it's part of the domain xml stuff
07:59:34 melwitt k, noted for the future :)
07:59:53 kashyap Yeah, true
08:00:10 kashyap melwitt: Also about the different cache modes, this is a nice page that explains what it means: https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/
08:00:32 melwitt ah, nice. thanks
08:00:35 bauzas melwitt: GO TO BED!
08:00:38 kashyap But MattR also copied some verbiage from somewhere in Nova conf as well.
08:01:01 kashyap melwitt: Yeah, I was wondering. Wauw, isn't it 01:00 AM for you there?!
08:01:19 kashyap Surprised to hear you answer to my ping here actually.
08:01:24 melwitt bauzas: I will, soon :) was stubbornly working on solving something
08:01:51 bauzas melwitt: Ted Mosby said a couple of times that nothing good can happen after 2am, so you only have 1 hour left
08:02:17 melwitt lol
08:05:14 melwitt kashyap: oh, in case you didn't know, the reason we were moving so fast on that change is because newton eol was being held back on it
08:05:42 kashyap melwitt: Ah, I recall dansmith saying during a call last week
08:06:03 kashyap melwitt: Thank you for the unit test fixes. I struggle a bit with it
08:06:32 melwitt np. writing the tests is the most challenging part for me most of the time
08:07:36 kashyap melwitt: Any tips you have (write later, when you rested) to get better at it are welcome :-)
08:07:50 melwitt heh, k
08:07:56 kashyap Maybe just: keep reading and tinkering more and write more of them :-)
08:08:41 melwitt yeah, that's most of it. gets better with practice
08:11:38 melwitt alright yall, seeya in some hours
08:14:52 kashyap Get some sleep.
08:14:55 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Add instance action record for attach/detach interface https://review.openstack.org/512190
08:19:17 openstackgerrit Yikun Jiang proposed openstack/python-novaclient master: Use utils.prepare_query_string instead of duplicated code https://review.openstack.org/515640
08:21:19 openstackgerrit Merged openstack/nova master: libvirt: Don't disregard cache mode for instance boot disks https://review.openstack.org/514339
08:33:25 openstackgerrit Jianghua Wang proposed openstack/nova master: vgpu: add enabled white list https://review.openstack.org/512580
08:33:25 openstackgerrit Jianghua Wang proposed openstack/nova master: vGPU: XenAPI: get vgpu stats from hypervisor https://review.openstack.org/512965
09:10:54 openstackgerrit Chen Hanxiao proposed openstack/python-novaclient master: inject file: add description of injecting multiple files. https://review.openstack.org/515655
09:27:49 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Remove 'vendordata_driver' opt https://review.openstack.org/397835
09:28:05 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Validate '[api] vendordata_providers' options https://review.openstack.org/513318
09:29:29 stephenfin mikal: Could you have a look at https://review.openstack.org/#/c/513318 and the preceding patch?
09:54:20 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: fix memory stats https://review.openstack.org/515666
10:02:33 openstackgerrit Yikun Jiang proposed openstack/python-novaclient master: Use utils.prepare_query_string instead of duplicated code https://review.openstack.org/515640
10:07:50 openstackgerrit Merged openstack/nova master: Complete dostring of live_migration related methods https://review.openstack.org/490807
10:13:40 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: implement get_inventory() driver method https://review.openstack.org/506175
10:19:44 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: resolve the error of VM_MISSING_PV_DRIVERS for PV VM https://review.openstack.org/514902
10:43:36 jianghuaw bauzas, could you help to look at this patch? https://review.openstack.org/#/c/339204
11:30:09 openstackgerrit Merged openstack/python-novaclient master: Use generic user for both zuul v2 and v3 https://review.openstack.org/512515
11:42:26 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: implement get_inventory() driver method https://review.openstack.org/506175
12:01:48 jmccarthy Any folks notice an issue where on a xen compute, in horizon, you may get a working console, or working console logging (depending on the instance you spin up) - but not both ?
12:25:59 jaypipes bauzas, stephenfin, gibi: series starting at https://review.openstack.org/#/c/509027/ should be relatively easy reviews. just cleanups in the resource_provider.py module.
12:28:36 gibi jaypipes: opening...
12:58:17 gibi jaypipes: what is the reason you pass a whole RP object to get_all_by_resource_provider ? It only uses the id of that RP today so it would be enough to pass that id.
12:58:50 jaypipes gibi: because I don't then have to reconstruct a ResourceProvider object for each allocation record.
12:59:21 jaypipes gibi: and that would entail more joins and/or queries to the DB
13:01:56 bauzas jianghuaw: jaypipes: I had a comment in https://review.openstack.org/#/c/339204/8
13:03:08 leakypipes bauzas: nice catch :)
13:04:25 bauzas oh man, friday
13:04:46 gibi leakypipes: I'm not sure we are looking at the same patch. I try to understand TraitList.get_all_by_resource_provider() here https://review.openstack.org/#/c/509027/5/nova/objects/resource_provider.py@2289
13:05:10 gibi leakypipes: and I don't see how this connects to the allocation records you refer to
13:05:31 leakypipes gibi: lol. sorry, thought you were referring to the AllocationList.get_all_by_provider()
13:05:33 bauwser leakypipes: honestly, it's a known problem, and we should maybe discuss about how to modify the RC to use bytes and not GB but meh
13:05:59 bauwser changing that should be a very huge modification unfortunately
13:06:18 leakypipes gibi: I have no idea why that isn't get_by_provider_id()...
13:06:26 leakypipes gibi: lemme fix.
13:06:37 openstackgerrit Hironori Shiina proposed openstack/nova-specs master: Ironic: Resize and cold migration support https://review.openstack.org/449155
13:06:38 leakypipes gibi: might just be copy-pasta
13:07:13 gibi leakypipes: thanks
13:07:20 leakypipes gibi: sorry about that!
13:08:08 gibi leakypipes: no problem
13:08:30 leakypipes gibi: although...
13:08:41 leakypipes gibi: based on the commit message
13:09:12 leakypipes gibi: looks like this was intentional to make the calling interfaces consistent
13:09:20 leakypipes gibi: from the commit message:
13:09:20 leakypipes In following patches, I change similar method on List objects like UsageList.get_all_by_resource_provider_uuid() and AllocationList.get_all_by_resource_provider_uuid() to match this new pattern of get_all_by_resource_provider() and passing in a ResourceProvider object.
13:09:49 leakypipes gibi: those "following patches" were re-ordered and are actually already merged.
13:10:35 gibi leakypipes: that removes some of my confusion :) anyhow if there is pattern and it is intentional then I'm OK with it
13:10:43 leakypipes gibi: so, long story short, I did it for consistency with the other calls
13:11:18 gibi leakypipes: make sense now, thanks for the explanation
13:25:57 belmoreira mriedem, dansmith I continue to test how to migrate from newton to ocata with cellsV1
13:26:15 belmoreira If I have multiple nova_api(s) DBs/placements I will need to merge the allocation tables when moving to pike and cellsV2
13:26:30 belmoreira This is not easy to achieve because "allocations" table uses the "resource_provider_id" instead "resource_provider_uuid"
13:26:36 jmccarthy Question about using libvirt + xen on xen compute, anyone familiar with how to get changes to 'stick' when virsh editing the xml ? I'm trying to add another serial device to file, for console logging for example: http://paste.openstack.org/show/624831/
13:26:42 belmoreira There is any way to recreate the "allocations" table from scratch when I'm in pike?
13:26:58 jmccarthy (I have what is on the right, but I think I need what is on the left)
13:27:43 mriedem belmoreira: would likely have to write a tool to migrate the entries out of the separate placement/api db's into the global one when you upgrade
13:27:53 mriedem we mentioned this as one of the trade offs the other day of doing placement per cell for now
13:28:37 dansmith what mriedem said
13:28:51 dansmith belmoreira: the use of integer ids is for performance there
13:30:27 mriedem bauwser: what is your -1 for specifically on this? https://review.openstack.org/#/c/515530/
13:31:37 bauwser mriedem: on a meeting
13:34:58 fried_rice mriedem superdan Can we please move the ksa adapter series along a little bit? It's been stagnating. Here's one that involves placement https://review.openstack.org/#/c/492247/ -- sdague was +2 6 weeks ago and no actual changes since.
13:37:05 sdague fried_rice: it has a gerrit cannot merge on it atm
13:37:21 fried_rice sdague Aaargh, missed that.
13:37:33 fried_rice rebasing...
13:37:47 superdan also, I'm not really the best person to look at that
13:37:52 superdan probably mriedem and sdague though
13:38:26 mriedem fried_rice: you're just doing all of these separately right?
13:38:38 mriedem for some reason i thought they were all lined up behind the glance one, which looked scary
13:38:39 fried_rice mriedem Yes
13:38:49 fried_rice mriedem Oh, some of them are lined up behind the glance one.

Earlier   Later