Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-18
17:39:07 mlavalle de nada
17:47:25 openstackgerrit sean mooney proposed openstack/os-vif master: do not always plug ovs ports. https://review.openstack.org/631829
17:56:11 openstackgerrit sean mooney proposed openstack/os-vif master: Cleanup device at the end of 'test_iproute_object_closes_correctly' test https://review.openstack.org/629112
17:56:12 openstackgerrit sean mooney proposed openstack/os-vif master: Import IP implementation modules outside privsep context https://review.openstack.org/629025
18:10:44 gibi melwitt sean-k-mooney hansmoleman leakypipes mlavalle: summary of the hangouts call about the bandwidth feature is on the ML http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001879.html
18:11:08 mlavalle gibi: thanks. have a nice weekend
18:11:24 melwitt gibi: thanks, have a good weekend o/
18:11:33 gibi same to you
18:19:47 openstackgerrit Merged openstack/nova master: Remove args(os=False) in monkey_patch https://review.openstack.org/568999
18:28:45 sean-k-mooney melwitt: leakypipes i have submited a patch to release os-vif 1.14.0 to unblock the gates. https://review.openstack.org/#/c/631860/1 it depends on 3 patches that still need to be merged. when zuul comments back will ye be around later to review them?
18:30:56 melwitt sean-k-mooney: we usually use Depends-On in the release patch to hold it for specific things (so it won't pass CI until ready)
18:31:19 sean-k-mooney the release repo jobs dont actully support depends-on
18:31:28 sean-k-mooney i usually add it out of habit
18:31:35 sean-k-mooney but it will fail the validate job
18:31:41 sean-k-mooney until the depencys are merged
18:31:47 melwitt on the first patch, you +2ed your own patch
18:32:10 melwitt yeah, I meant validate job will hold it
18:32:22 sean-k-mooney ya i generally avoid that but im not goint to +w so im going to leave that to others.
18:32:45 sean-k-mooney if we want to have 2 +2 + mine that is fine too
18:36:35 melwitt sean-k-mooney: ok, if os-vif has a single +2 policy, or a self-approval-allowed policy, I haven't been aware of it
18:37:05 sean-k-mooney melwitt: but yes point taken i normally take more time but the neutron folks been pushing to fix this.
18:37:54 leakypipes sean-k-mooney: +2 on bottom patch.
18:38:42 sean-k-mooney self approval + one other has been what we did for quite a while before added nova-core to os-vif as there were 3 active reviews so usually the patch was written by one of those 3
18:38:57 sean-k-mooney but as i said i generally avoid it
18:39:43 melwitt ok, I wasn't aware of that. thanks
18:45:25 sean-k-mooney leakypipes: since i need to resping the 3 change will i fix the typos in the first while im at it?
18:48:40 sean-k-mooney melwitt: by the way if you want to change to 2 independet +2s for os-vif we can. since nova-core has been added there are more peole that can review but its still mainly myself stephen and jay that do in pratice https://www.stackalytics.com/?module=os-vif
18:48:49 leakypipes sean-k-mooney: up to you. I'm happy to fast-+2 after
18:49:57 sean-k-mooney ok i might as well. it will delay the check jobs but we will have to wait for the gate jobs after anyway so it wont be much of a delay
18:50:06 melwitt sean-k-mooney: no, wasn't implying I want a change. I just didn't know the policy was different than the usual
19:07:40 leakypipes fried_rice: k, I'm +2 on all of https://review.openstack.org/#/q/topic:static-rt-in-compute-mgr
19:30:51 sean-k-mooney by the way for Depends-on are we ment to use ther gerrit url or change id now with zuul v3
19:32:40 sean-k-mooney i think Depends-On: https://review.openstack.org/#/c/629025/8 is prefered over Depends-on: I1852038b8d40d4aa52c4f8e661bc78e54e0fc966 correct?
19:37:29 melwitt sean-k-mooney: yes, supposed to use gerrit url now i.e. https://review.openstack.org/629025 but you don't need to change it. I was just mentioning FYI for next time to make it easier to see what changes your release request depends on
19:39:07 sean-k-mooney melwitt: well i need to update the sha so ill add it. thanks. i was 90% sure but could not find it documented
20:06:36 openstackgerrit sean mooney proposed openstack/os-vif master: do not always plug ovs ports. https://review.openstack.org/631829
20:06:37 openstackgerrit sean mooney proposed openstack/os-vif master: Cleanup device at the end of 'test_iproute_object_closes_correctly' test https://review.openstack.org/629112
20:06:38 openstackgerrit sean mooney proposed openstack/os-vif master: Import IP implementation modules outside privsep context https://review.openstack.org/629025
20:07:57 hansmoleman dansmith: yeah https://review.openstack.org/#/c/631811/ fixed that tracing once we upgrade
20:08:47 dansmith mriedem: cool, +1d
20:21:12 hogepodge melwitt: mriedem: Do you know if there's a workaround to this bug? https://bugs.launchpad.net/nova/+bug/1755756
20:21:14 openstack Launchpad bug 1755756 in OpenStack Compute (nova) "ImageUnacceptable: Image is unacceptable: 'qemu-img info' parsing failed" [Undecided,New] - Assigned to pandatt (pandatt)
20:21:38 hogepodge I'm running in to it running a source build on CentOS
20:24:47 mriedem hogepodge: i've never looked at that bug before
20:25:32 mriedem comment from dansmith in there suggests newer qemu-utils might help
20:26:25 dansmith yup
20:26:40 hogepodge dansmith: how do I get those on CentOS?
20:26:44 dansmith it's a new argument that isn't in the older ones. nova always passes it, which means it fails if it's too old
20:26:48 dansmith hogepodge: dunnoski
20:27:20 hogepodge yes, there's a check that shouldn't allow that flag to be sent for older versions (centos install 1.53 by default)
20:27:20 mriedem looking at the nova code, we are doing a version check https://github.com/openstack/nova/blob/stable/queens/nova/virt/images.py#L49-L72
20:27:43 hogepodge yup, which must be failing
20:28:17 dansmith noted on the bug I think
20:28:43 mriedem hogepodge: what version of nova?
20:29:01 hogepodge master
20:29:10 mriedem that's unpossible
20:29:25 dansmith might also be that backports caused that version calculus to be wrong either on ubuntu or centos
20:29:35 dansmith backports against the distro qemu package I mean
20:29:36 mriedem libvirt driver on master requires qemu >= 2.5
20:29:56 hogepodge ah, ok. I wonder if I botched the qemu install
20:30:09 mriedem https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L224
20:30:10 dansmith mriedem: pretty sure that the issue was that we installed something, got qemu-utils=something, then upgraded to cloud archive, got a new qemu, but it was fine with the older qeu-utils, and didn't upgrade it
20:30:55 mriedem dansmith: ah ok, so qemu could be 2.10 but qemu-utils could be 2.5 or something
20:30:56 dansmith meaning qemu==N doesn't require qemu-utils==N, just qemu-utils==anything
20:30:59 dansmith right
20:31:00 hogepodge I think what's happening is I've installed centos-release-qemu-ev which has updated qemu in my libvirt container, but not in my compute containers
20:31:00 mriedem yeah
20:31:03 mriedem oh packaging fun
20:35:55 hogepodge Thanks for the info and helping me think through it. I'm going to patch what I think the problem is in Loci, rebuild, and try again. Still, if 2.5 is required I'd just remove that check rather than leave it in as buggy. I can send a patch up if you'd like.
20:37:30 mriedem well, if qemu-img version == qemu-utils version the check would be correct
20:38:12 mriedem i mean, we could instead run qemu-img version or something and try to parse that, but that sucks
20:38:25 mriedem or parse the output for "unrecognized option '--force-share'"
20:38:34 mriedem but that also kind of sucks when we're already doing a version check
20:40:54 dansmith or just log a better error message and not reinvent everything in the bowels
20:42:20 leakypipes mriedem: hey, I hate launchpad bug search :( do you remember the bug report about rebuild getting a NoValidHost cuz the rebuild wasn't taking into account the original instance's resources properly?
20:44:10 fried_rice leakypipes: Thanks. mriedem, you got https://review.openstack.org/#/q/topic:static-rt-in-compute-mgr in your queue (somewhere :P ) ?
20:53:34 mriedem leakypipes: that doesn't ring a bell - we'd only get novalidhost on rebuild if the image changes
20:53:49 mriedem are you saying something with the scheduler filters in that case isn't getting the original request spec or something?
20:53:55 mriedem like project/user or image id or something?
20:54:19 mriedem fried_rice: oh boy...
20:54:19 mriedem umm
21:07:11 leakypipes mriedem: I was certain there was a patch I reviewed recently-ish that had to do with capacity of a host being falsely exceeded when trying to rebuild a host. maybe it's just old age and I'm exhibiting dementia.
21:07:57 mriedem rebuild or evacuate?
21:10:50 mriedem fried_rice: i don't suppose cern was able to verify that series on their ironic cluster yet right?
21:11:15 mriedem i think their ironic compute service code is still queens
21:11:19 fried_rice mriedem: I don't think so, no.
21:11:24 fried_rice they were gonna, soon.
21:23:23 openstackgerrit Paul-Emile Element proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
21:42:47 mriedem fried_rice: ok done
21:42:54 mriedem i will have to review the rest of the series next week
22:25:25 fried_rice mriedem_away: Thanks. There's more to the series, if you can. But in particular the top patch (https://review.openstack.org/#/c/620711/) is right near some of the report client singleton stuff you did.
22:46:53 fried_rice leakypipes: a moment of your time?
22:47:40 fried_rice On this RMD thing, I agree as written it's way overblown and crosses a number of lines in the sand.
22:48:13 fried_rice However, I think there are some nuggets of possibilities in there if it is scaled way back and framed in terms of the architecture we've got in place (and forthcoming).
22:52:33 fried_rice - update_provider_tree creates inventory in appropriate providers for ^ (for Train, since we don't have numa modeling, "appropriate providers" == the compute node RP) based on querying RMD or whatever
22:52:33 fried_rice - flavor can contain resource requests for those resource classes in the same way it does today
22:52:33 fried_rice - spawn can pass RMD the allocation information to get the real resources attached to the VM
22:52:33 fried_rice So like:
22:52:33 fried_rice - standard resource classes for just the hard guaranteed minimums, e.g. MIN_LL_CACHE_MB and MIN_MEMORY_BW_MBYTES_SEC
22:54:19 fried_rice None of this dynamic allocation BS; no "burst max" values; communication with RMD via something other than a REST interface to a new service (like via a special file system; maybe I'm misunderstanding, but I think that's a thing).

Earlier   Later