Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-17
15:14:30 sean-k-mooney bauzas: ya i need a +1 form a nova core and then infra need to +2 it
15:14:44 bauzas sean-k-mooney: ok, briefly looking
15:14:56 bauzas in theory, it's a +1 from the PTL or the Release Management liaison
15:15:03 sean-k-mooney bauzas: technically yes
15:15:08 bauzas lucky for you, I'm the nove liaison :)
15:15:15 bauzas nova* (of course)
15:16:23 sean-k-mooney edleafe: ah that explains why i have not seen him this week. he mentioned he would be away but was not sure if it was all week
15:18:41 bauzas sean-k-mooney: +1d FWIW, I leave you chase the release folks
15:20:01 sean-k-mooney bauzas: no worries. thanks
15:22:06 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix comments in get_all_with_shared() https://review.openstack.org/533195
15:23:41 gibi ildikov: I have only question in the multiattach api patch, https://review.openstack.org/#/c/271047/55/nova/compute/api.py@3700
15:24:40 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Fix allocation_candidates not to ignore shared RPs https://review.openstack.org/533396
15:26:43 stephenfin sean-k-mooney: You might do a follow up patch to 'openstack/requirements' to blacklist os-vif 1.8.0 too
15:27:29 ildikov gibi: hmm, I'm not sure I fully understand the question
15:27:51 sean-k-mooney stephenfin: oh good point i guess we should wait for the auto generated one for 1.8.1 to be submitted then i can modify it to blacklist 1.8.0
15:27:53 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: QEMU native LUKS decryption for volumes https://review.openstack.org/523958
15:29:28 gibi ildikov: so in the _check_attach_and_reserve_volume we differentiate between two cases
15:29:38 sean-k-mooney stephenfin: i think it will just updat this one https://review.openstack.org/#/c/532987/ but ill wait for it to be submitted.
15:30:08 gibi ildikov: and if this is the case when the user attaches a new volume to a running instance then we don't check the multiattach capabilities
15:30:11 sean-k-mooney stephenfin: by the way can you take a look at https://review.openstack.org/#/c/533766/ this is the nova unit test change that is required for os-vif 1.8.x
15:30:44 gibi ildikov: at least based on the code comment I commented on
15:31:06 stephenfin sean-k-mooney: Stuck in meetings til EOD (Intel flashbacks, heh) but I'll try squeeze it in. If not, I'll tackle it tomorrow (y)
15:31:07 ildikov gibi: we always check this first: if volume['multiattach'] and not supports_multiattach:
15:31:38 gibi ildikov: true, but the compute version is not checked in the if branch
15:31:39 stephenfin sean-k-mooney: Oh, wait. It's tiny. Done
15:31:41 sean-k-mooney stephenfin: cool no problem, its pretty trivial
15:31:55 sean-k-mooney ya just missing the datapath field.
15:32:07 gibi ildikov: it is only checked in the else branch
15:32:49 ildikov gibi: ah ok, I see now
15:33:46 gibi ildikov: it could be that we check the compute version is some other point in the call stack for the if case
15:36:32 ildikov gibi: we do fail in reserve_block_device_name here: https://review.openstack.org/#/c/531244/9/nova/compute/rpcapi.py
15:37:48 tetsuro bauzas: Hi, if you have time, could you have a look at https://review.openstack.org/#/c/534807/ ?
15:40:47 ildikov gibi: which might not be satisfying enough for that 'if'
15:41:33 ildikov gibi: but that's my guess for now :)
15:42:18 bauzas sean-k-mooney: saw https://review.openstack.org/#/c/534807/ ?
15:42:22 bauzas just respin
15:42:26 gibi ildikov: thanks I think I see now. compute.api._attach_volume() calls _create_volume_bdm that will call the rpc
15:42:40 bauzas tetsuro: you pointed me sean-k-mooney's patch, was that intentional ?
15:42:43 gibi ildikov: in case of attaching a volume to an existing instance
15:43:07 ildikov gibi: yep, that flow sounds correct
15:43:28 gibi ildikov: so it fails before _check_attach_and_reserve_volume is called in _attach_volume
15:43:29 tetsuro bauzas: sorry, just a mistake
15:43:44 gibi ildikov: this is why we don't need an extra check in _check_attach_and_reserve_volume for the attach volume case
15:44:21 tetsuro bauzas: could you have a look at https://review.openstack.org/#/c/531347/ ?
15:44:52 bauzas tetsuro: short patch, will look :)
15:45:42 ildikov gibi: +1
15:45:47 tetsuro bauzas: thanks in advance
15:46:50 smcginnis bauzas: Hey, are you good with the new version on https://review.openstack.org/#/c/534807/ ?
15:47:07 smcginnis bauzas: I assume so, but would be good to have your +1 on there for historical reference.
15:47:22 bauzas smcginnis: I'm on it
15:47:23 bauzas +1d
15:47:28 gibi ildikov: then +2 from me :)
15:47:35 smcginnis bauzas: Thanks!
15:47:39 bauzas smcginnis: thanks for the catch on a minor release
15:48:08 smcginnis bauzas: Wouldn't have been the end of the world, but I think this version is more appropriate. ;)
15:48:28 ildikov gibi: much appreciated
15:48:32 bauzas smcginnis: any release documentation about semver we have could help me
15:48:45 ildikov gibi: will update the tests if I have to upload a new version
15:49:07 bauzas in general, I struggle with identifying .y releases, and just accept .zs
15:49:25 smcginnis bauzas: I only know of the site: https://semver.org/
15:49:26 sean-k-mooney smcginnis: a z stream release would techically have implied abi compatiblity aswell as api compatiblity. we are breaking the abi form 1.8.0 so you were right it should have been 1.9.0
15:50:16 gibi ildikov: cool. that test nit is not super important
15:50:21 smcginnis It's always a tricky and somewhat subjective thing to look at commit messages and determine. ;)
15:57:09 ildikov gibi: noted, tnx :)
16:11:59 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Test alloc_cands with indirectly sharing RPs https://review.openstack.org/519601
16:12:00 openstackgerrit Tetsuro Nakamura proposed openstack/nova master: Support relay RP for allocation candidates https://review.openstack.org/533437
16:27:13 claudiub stephenfin: hi. can you take a look at the autospec patch? https://review.openstack.org/#/c/447505/ Jenkins says it's ok. thanks!
16:27:35 stephenfin claudiub: Won't get it today, but it's now on the (rather big) list for tomorrow :)
16:27:44 claudiub yeay. :D
16:51:44 openstackgerrit Matthew Booth proposed openstack/nova master: Pass disk_info dict to libvirt_info https://review.openstack.org/529329
16:51:44 openstackgerrit Matthew Booth proposed openstack/nova master: Fix libvirt volume tests passing invalid disk_info https://review.openstack.org/529328
16:51:45 openstackgerrit Matthew Booth proposed openstack/nova master: Remove redundant swap_volume tests https://review.openstack.org/531179
16:51:45 openstackgerrit Matthew Booth proposed openstack/nova master: Expose volume host type and path independent of libvirt config https://review.openstack.org/530786
16:51:46 openstackgerrit Matthew Booth proposed openstack/nova master: Local disk serial numbers for the libvirt driver https://review.openstack.org/529380
16:51:46 openstackgerrit Matthew Booth proposed openstack/nova master: Don't generate fake disk_info in swap_volume https://review.openstack.org/530787
16:57:08 openstackgerrit Merged openstack/nova master: Address nits in I46d483f9de6776db1b025f925890624e5e682ada https://review.openstack.org/530462
16:57:28 openstackgerrit Merged openstack/nova master: Remove unnecessary execute permissions in files https://review.openstack.org/533686
17:10:22 sean-k-mooney bauzas: jaypipes stephenfin just fyi os-vif u-c/g-r patch https://review.openstack.org/#/c/534839/. ye dont need to do anything here ill follow up with infra once zuul comments back
17:10:38 jaypipes sean-k-mooney: ack, thank you sir
17:11:08 bauzas sean-k-mooney: +1d for the sake of consistency with myself
17:26:55 cdent jaypipes, efried : is there code in progress somewhere that includes parent references in the provider summaries of an /allocation_candidates response? (so much code at the moment, hard to find stuff). Or maybe it already done?
17:27:17 jaypipes cdent: I'm currently working on that area
17:27:48 cdent is there anything up in gerrit yet, or is that yet to come?
17:29:01 cdent jaypipes: the reason I ask is because I'm trying to confirm some of my understandings about how this ought to work.
17:29:15 cdent by cooking some gabbi scenarios
17:29:31 cdent but it looks like what I'm trying to do is not quite possible yet
17:29:41 jaypipes cdent: I'm currently working on the alloc candidates stuff with n-r-p in the https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-resource-providers series
17:30:11 cdent yeah, that's where I was looking
17:31:18 cdent jaypipes: is the expectation that in provider summaries, anything with a parent will have parent_provider_uuid field?
17:33:01 jaypipes cdent: yup, zactly.
17:33:17 cdent roger, con aye, ten degrees down bubble
17:37:14 openstackgerrit Jackie Truong proposed openstack/nova master: Account for deprecation of personality files https://review.openstack.org/534849
17:51:33 cdent jaypipes: another, more theorectical, question. sean-k-mooney has a various times talked about moving vcpu and memory to the nested numa node, in which case the allocation records in allocation_requests will be against that. when that happens are we assuming that the nova-scheduler will climb the provider tree hierarchy...
17:52:01 cdent ...recreated from provider summaries, to find the compute node where the actual spawn will happen?
17:53:33 jaypipes cdent: yes
17:53:42 cdent cool
18:04:16 sean-k-mooney cdent: well we schedule resouce based on the leaf nodes to select the set of roots nodes that can fufil the request so yes.
18:04:20 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
18:06:37 openstackgerrit Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371
18:08:07 openstackgerrit Jay Pipes proposed openstack/nova master: fix _get_trees_matching_all() when sum children https://review.openstack.org/534866

Earlier   Later