Earlier  
Posted Nick Remark
#openstack-nova - 2019-01-09
12:08:33 sean-k-mooney jaypipes: cpu_thread_policy is only supported by libvirt also
12:08:34 alex_xu sean-k-mooney: not all the virt driver implement numa affinity also
12:08:47 jangutter sean-k-mooney: local branch name is: review/jan_gutter/bp/vrouter-os-vif-conversion
12:08:47 jaypipes alex_xu: "emulator" specifically refers to a libvirt/QEMU implementation detail :)
12:08:47 sean-k-mooney alex_xu: yes but at least 2 implement it
12:08:53 sean-k-mooney hyperv and libvirt
12:08:57 alex_xu jangutter: yea, I agree with you that
12:09:26 alex_xu jangutter: sorry, ping the wrong name...
12:09:30 sean-k-mooney jangutter: yep that is why it create that topic upstream :)
12:09:41 alex_xu hah
12:10:03 jangutter sean-k-mooney: aaaah.... sorry, I pasted the wrong link in.... let me repaste the correct link...
12:10:31 jangutter It added: Gerrit topic: https://review.openstack.org/#q,topic:bp/vrouter-os-vif-conversion,n,z where it should have added https://review.openstack.org/#/q/topic:bp/vrouter-os-vif-conversion,n,z
12:11:21 sean-k-mooney jangutter: hum weird
12:11:50 jangutter sean-k-mooney: it picked the correct topic, but it generated a URL where "#q," should be "#/q/"
12:12:14 jangutter sean-k-mooney: maybe the link was valid on an older version of gerrit?
12:12:34 alex_xu jaypipes: we also should put it into the same level of 'nodes' field, right? sean-k-mooney mention that also
12:12:43 alex_xu we can't set cpu thread policy for each node
12:13:09 jangutter sean-k-mooney: sorry, just realised, I can probably ask this on #openstack-infra (facepalm).... it's been a looooong Monday.
12:13:46 sean-k-mooney jangutter: hehe dont worry about it but they will likely have a better answer
12:13:49 jangutter alex_xu: heh, no worries, I was confused for a bit, then I realised something autocompleted.
12:14:00 ygk_12345 sean-k-mooney: how to enable logging in libvirtd ?
12:14:11 jaypipes alex_xu: is that a fundamental problem with the underlying modeling? in other words, is this: https://github.com/openstack/nova/blob/master/nova/objects/instance_numa_topology.py#L56 incorrectly placed on the NUMA cell instead of the InstanceNUMATopology object? :)
12:14:19 alex_xu jangutter: yea, I type tab too early :)
12:15:14 alex_xu jaypipes: interesting...we put that attribute into cell obj
12:15:31 alex_xu jaypipes: but we only have one extra spec to set cpu policy for the whole guest
12:15:47 sean-k-mooney jaypipes well there is no fundemental resone we could not do this per cell but we only support setting for the entire instnace
12:16:29 jaypipes sean-k-mooney: overkill? :)
12:16:36 sean-k-mooney totally
12:17:01 sean-k-mooney i mean at that point we might as well let people chose the cpus
12:17:34 sean-k-mooney i mean that is what they really wanted all along...
12:18:49 sean-k-mooney jaypipes: my guess would be we store it in the instance cell to not need to pass it as a paramater to fuctions later when calulating the pinning or some other reason liek that
12:18:56 alex_xu actually those policy can easy to get from the flavor extra spec
12:19:05 sean-k-mooney alex_xu: yes
12:19:55 sean-k-mooney alex_xu: wasing the main point of this spec that it would be reading the numa/cpu related extra specs and image metadata and presenting the compined view to the admin
12:20:08 sean-k-mooney *wasn't
12:20:41 alex_xu at least I don't want to the api user to parse the extra spec, and copy the parse rule which inside nova
12:20:57 alex_xu and yes, we have image meta for those policy also
12:21:00 jaypipes alex_xu, sean-k-mooney, yonglihe: easy to get sidetracked here. my bottom line recommendation: a) don't put emulator_threads_policy in the HTTP response AND b) put the cpu_threads_policy as an attribute at the same level in the HTTP response as "nodes" (like sean-k-mooney and alex_xu suggest)
12:21:31 sean-k-mooney jaypipes: sure that sounds resonable
12:22:38 alex_xu jaypipes: cool
12:27:16 sean-k-mooney jaypipes: alex_xu what is the process for specless blueprint by the way
12:27:23 sean-k-mooney jaypipes: alex_xu specifcally for https://blueprints.launchpad.net/nova/+spec/libvirt-disable-pmu-for-realtime-guests
12:28:07 alex_xu sean-k-mooney: get an approve in nova meeting? I guess
12:28:15 jangutter sean-k-mooney: Last time I proposed one, it went up as an agenda item on the Nova meeting.
12:28:38 sean-k-mooney ya i was going to add it for this weeks
12:29:29 sean-k-mooney if it gets punted to next cycle it wont kill me but it was a simple addtion i was going to work on after m2 as a 1 patch feature
12:41:31 openstackgerrit Merged openstack/nova-specs master: Fix format flavor-extra-spec-image-property-validation https://review.openstack.org/629311
12:41:34 gibi nehaalhat: I was able to mock the placement function you need http://paste.openstack.org/show/740847/
12:44:22 nehaalhat gibi: ok
12:46:12 kashyap gibi: Hi there; when you get a moment: I've answered your question on the review. What Martin posted on the review is the successful test evidence.
12:47:07 openstackgerrit Chris Dent proposed openstack/nova master: Remove link to placement configuration from nova config docs https://review.openstack.org/628185
12:47:07 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from nova install docs https://review.openstack.org/628184
12:47:08 openstackgerrit Chris Dent proposed openstack/nova master: Remove placement from contributor doc https://review.openstack.org/628186
12:47:56 kashyap gibi: The test results posted by Martin's matches my own (which I also posted in the review).
12:48:27 kashyap Thanks for reviewing!
12:48:42 gibi kashyap: ohh, then I have to read a bit more carfeully :)
12:49:23 kashyap Heh, no problem at all. It is low-level QMP log; so not everyone can make sense of it. I just added context as to what it means in the bug comment and the review
12:50:27 kashyap I didn't spell out my own results in the review explicitly; I merely _linked_ to several files. And I did the comparison of Martin's test with mine manually.
12:50:51 gibi kashyap: that context helps :) I'm +2 on that patch
12:55:19 kashyap Thanks a ton!
12:55:40 kashyap gibi: I'm getting the follow-up docs patch; just need to rST-ify my .txt file
12:55:41 gibi kashyap: I thank you for the effort
12:56:54 kashyap gibi: I'm hoping melwitt or someone can ACK the blueprint today / this week -- https://blueprints.launchpad.net/nova/+spec/support-qemu-native-tls-for-live-migration
12:57:41 gibi kashyap: could you please add it to the nova meeting agenda? that way I can make sure we won't forget it
12:57:57 kashyap gibi: Definitely; let me go find the agenda page
12:58:13 gibi kashyap: https://wiki.openstack.org/wiki/Meetings/Nova
12:58:35 kashyap Meanwhile, I added it to also to: https://etherpad.openstack.org/p/nova-stein-blueprint-status
12:58:38 kashyap Thanks!
13:01:58 gibi kashyap: cool
13:04:45 kashyap Alright, added it to the agenda (as part of: "Open discussion").
13:07:03 gibi thanks
13:28:25 openstackgerrit Paul-Emile Element proposed openstack/os-traits master: Add new traits for TPM support https://review.openstack.org/629299
14:18:18 openstackgerrit Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256
14:22:22 yonglihe Jay, alex_xu, sean, numa info spec revised. thank you, guys.
14:23:27 yonglihe 'show-server-group' spec, https://review.openstack.org/#/c/612255/11, this is quite small, hope it could make it.
14:26:59 openstackgerrit Iury Gregory Melo Ferreira proposed openstack/nova master: Rename Ironic jobs https://review.openstack.org/629504
14:27:12 sean-k-mooney two nits inline but i think the current version is largely fine.
14:27:19 sean-k-mooney yonglihe: ^%
14:40:30 jaypipes yonglihe: done
14:43:16 yonglihe got, working on that. Jay, thanks.
14:43:36 openstackgerrit Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256
14:43:52 yonglihe sean, updated. thanks.
14:59:17 openstackgerrit Yongli He proposed openstack/nova-specs master: add 'show-server-group' spec https://review.openstack.org/612255
15:00:09 yonglihe Jay Pipes, done
15:02:31 dpawlik Hello, could you review: https://review.openstack.org/#/c/628956/ and https://review.openstack.org/#/c/628128/ ? thanks
15:04:55 sean-k-mooney dpawlik: does are queens stable backprot lyarwood ^ that might be something you might be interested in
15:50:06 openstackgerrit Yikun Jiang proposed openstack/nova master: Per aggregate scheduling weight https://review.openstack.org/628163
16:24:09 melwitt jaypipes: hey, I dunno if you saw my reply on the counting quotas from placement spec https://review.openstack.org/#/c/509042/ but I think we can't consider removing user-specific quotas until we migrate to keystone limits + oslo.limit
16:25:21 jaypipes melwitt: ack, and I wasn't suggesting removing them yet, just that we should plan to just use keystone and the hierarchical projects stuff in future.
16:28:18 melwitt jaypipes: ah, ok. yeah, that is the plan when we move to keystone limits + oslo.limits user-specific quotas will be dropped as part of that. described in johnthetubaguy's spec if you're interested https://review.openstack.org/#/c/602201/
16:31:45 cfriesen so there's a review up for the os-traits portion of the emulated TPM stuff. Am I correct that we'd need a new version of os-traits to pick that up in nova?
16:32:00 jaypipes melwitt: ++
16:32:12 jaypipes cfriesen: yes.
16:32:23 jaypipes cfriesen: and an updated requirements.txt in nova.
16:33:26 cfriesen right. so what's the process for triggering the new package version? is that something we need to request formally somewhere?
16:34:54 melwitt cfriesen: you can request a release of the package via the openstack/releases repo, like this https://review.openstack.org/#/c/612843/
16:35:03 gibi melwitt: hi! kashyap has a bp https://blueprints.launchpad.net/nova/+spec/support-qemu-native-tls-for-live-migration that hasn't been approved but it seems it was discussed before. Do you remember if anything blocks that bp? The implementation seems to be ready
16:37:16 melwitt gibi: yeah, I think everyone is OK with the feature but the discussion was around whether it needed a spec or not. IIRC dansmith suggested the docs and references related to the feature be proposed along with the implementation, which I thought was a good idea,
16:37:58 gibi melwitt: kashyap prepares a followup patch top of the implementation that adds documentation how to set up the compute hosts for tls
16:38:02 melwitt kashyap said he's done that and the bp is on the agenda for the nova meeting tomorrow, where we can get additional ACKs for approving it as specless

Earlier   Later