| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-01 | |||
| 11:57:13 | sean-k-mooney | kosamara: the code you are modifying is changing the hyperv element in https://libvirt.org/formatdomain.html#elementsFeatures | |
| 12:06:05 | lpetrut | kosamara: I guess you're overriding the signature returned through cpuid 0x40000000 | |
| 12:06:43 | lpetrut | sean-k-mooney: qemu can mimic some of the hyper-v enlightments | |
| 12:07:30 | sean-k-mooney | lpetrut: yep but im wondering if we shoudl entirely remove the hyperv element so that if nvidia make there check smarter in the future we dont need to change the code again | |
| 12:09:59 | lpetrut | but then I guess you'd lose all those hyper-v enlighments, which would probably affect Windows guests performance. I think the idea is to keep those, hiding the signature only. AFAIK, those guest features don't rely on the cpuid signature | |
| 12:10:25 | kosamara | sean-k-mooney: This is for kvm nodes. The <hyperv> element appears also on kvm nodes, when creating VMs from images with os_type='windows' | |
| 12:11:29 | sean-k-mooney | kosamara: yes i am aware. but im wondering if setting the vendor id is sufficent to hide everythin from the windows guest kernel. | |
| 12:11:44 | sean-k-mooney | or at least the driver layer | |
| 12:12:33 | kosamara | sean-k-mooney: I've tested inside the guest that I could install the nvidia drivers and run applications on the GPU. | |
| 12:12:48 | sean-k-mooney | lpetrut: i agree it would be nice to keep some of the performance aspects enabled if they are not observable within the guest. | |
| 12:13:42 | sean-k-mooney | kosamara: yes but is that because nvidia are just not current checking for other cpu flags that the enablments are setting or are you shure the vendor_id is enought to ensure we dont have to change this code again in the future | |
| 12:14:18 | kosamara | sean-k-mooney: unfortunately, I believe it's the 1st. | |
| 12:15:30 | sean-k-mooney | kosamara: in that case i would like at least a note to that effect in the code so that if we do have to revisit we understand exactly why the current workaround is not sufficent | |
| 12:16:20 | kosamara | The more explicit solution would be to remove the hyperv element as you say, but I've read that indeed this would reduce guest performance, like lpetrut says. | |
| 12:16:45 | sean-k-mooney | kosamara: well the kvm hidden flag also reduces the guest performance | |
| 12:18:36 | sean-k-mooney | it force the linux kernel to assume its running on phyical hardware so it cannont performa any optimisation that are posible when it knows its running on kvm | |
| 12:19:29 | kosamara | sean-k-mooney: since right now we don't need to cause another perf degradation though, I believe it's better to only do that if need be. I'll write a note on the code, thanks! | |
| 12:19:50 | openstackgerrit | Merged openstack/nova master: Add placement.concurrent_udpate to generation pre-checks https://review.openstack.org/581771 | |
| 12:35:19 | stephenfin | bauzas: I'm gone for another week and a half next Wednesday too | |
| 13:31:39 | openstackgerrit | Merged openstack/nova master: [placement] Use oslotest CaptureOutput fixture https://review.openstack.org/587129 | |
| 13:32:32 | openstackgerrit | Merged openstack/nova master: [placement] Use a non-nova log capture fixture https://review.openstack.org/587130 | |
| 13:32:40 | openstackgerrit | Merged openstack/nova master: [placement] Use a simplified WarningsFixture https://review.openstack.org/587131 | |
| 13:45:29 | openstackgerrit | Merged openstack/nova master: Fix comments in _anchors_for_sharing_providers and related test https://review.openstack.org/587679 | |
| 13:45:38 | openstackgerrit | Merged openstack/nova master: Convert 'placement_api_docs' into a Sphinx extension https://review.openstack.org/578826 | |
| 13:48:30 | openstack | bug 1784705 in OpenStack Compute (nova) "ResourceTracker.stats can leak across multiple ironic nodes" [High,In progress] https://launchpad.net/bugs/1784705 - Assigned to Matt Riedemann (mriedem) | |
| 13:48:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add recreate test for RT.stats bug 1784705 https://review.openstack.org/587614 | |
| 13:48:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make ResourceTracker.stats node-specific https://review.openstack.org/587636 | |
| 13:59:05 | dansmith | mriedem: don't you watch the stats leak bug tagged for rc1? | |
| 13:59:24 | mriedem | dansmith: it's not new, so not really an rc thing | |
| 13:59:27 | mriedem | regressed in ocata | |
| 13:59:36 | efried | mode #openstack-nova | |
| 13:59:38 | dansmith | but fairly critical no? | |
| 13:59:50 | mriedem | i would think so.... | |
| 14:00:04 | dansmith | so I dunno, seems important enough to go into rc1 to me | |
| 14:00:18 | mriedem | tssurya: do you know if cern is using the ComputeCapabilitiesFilter for baremetal scheduling where the baremetal flavors are have capabilities extra specs to link them to certain bm nodes? | |
| 14:00:30 | mriedem | dansmith: i wouldn't argue against getting it fixed asap of course :) | |
| 14:00:51 | mriedem | oath isn't using the filter and mgagne hasn't gotten to ocata yet to hit the regression | |
| 14:01:13 | dansmith | I was a little concerned before I saw the patch, mucking with RT and all, but I think it's probably pretty safe and my mind is boggling over this not having caught fire already | |
| 14:02:50 | mriedem | me too | |
| 14:03:12 | mriedem | but yeah this is essentially the same pattern used to change RT.compute_node (singular) into RT.compute_nodes | |
| 14:03:27 | mriedem | we just do a shit job of testing anything to do with RT.stats | |
| 14:03:33 | mriedem | like, | |
| 14:03:48 | mriedem | nova/tests/unit/compute/resource_tracker.py doesn't have *any* stats-specific assertions in it i don't think | |
| 14:04:08 | dansmith | doesn't surprise me | |
| 14:04:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make ResourceTracker.stats node-specific https://review.openstack.org/587636 | |
| 14:06:31 | mriedem | gibi: comments addressed, thanks ^ | |
| 14:06:38 | mriedem | oh you beat me | |
| 14:06:41 | gibi | mriedem: thanks. I'm +@ | |
| 14:06:43 | gibi | +2 | |
| 14:07:20 | dansmith | mriedem: so you aren't against me +Wing right? | |
| 14:07:36 | mriedem | dansmith: nope | |
| 14:07:39 | mriedem | i'm pro +W | |
| 14:09:07 | dansmith | hmm, I just thought of one thing, let me check | |
| 14:09:33 | bauzas | humpf | |
| 14:09:48 | bauzas | we merged this code a while now, but we just have this bug now | |
| 14:09:51 | bauzas | :/ | |
| 14:09:56 | bauzas | ocata my love | |
| 14:11:59 | sean-k-mooney | bauzas: which bug? | |
| 14:12:23 | sean-k-mooney | bauzas: mriedem patch? | |
| 14:12:29 | bauzas | yup | |
| 14:12:42 | bauzas | I mean, lemme be clear, I understand why we have it now | |
| 14:12:49 | bauzas | it's just that I'm a sad panda | |
| 14:12:59 | sean-k-mooney | bauzas: the no tests. | |
| 14:13:27 | openstackgerrit | Merged openstack/python-novaclient master: Use jsonutils of oslo.serialization https://review.openstack.org/587278 | |
| 14:13:39 | sean-k-mooney | i have have been trying to figure out how to run coverage test of nova on and off but never actully done it beacues im not sure i want to know | |
| 14:14:15 | sean-k-mooney | that said i would not mind spending a little tiem working on code coverage to learn some of the code base i dont normally touch | |
| 14:15:21 | mriedem | sean-k-mooney: https://review.openstack.org/587636 | |
| 14:15:48 | mriedem | tox -e cover only runs unit tests, so misses all functional test coverage | |
| 14:16:05 | sean-k-mooney | mriedem: yes i started to review it :) | |
| 14:16:07 | mriedem | but a coverage report doesn't give you any idea of end to end scenario coverage | |
| 14:16:20 | sean-k-mooney | mriedem: ya | |
| 14:19:11 | sean-k-mooney | they also need python 3... time to go install that on centos again. | |
| 14:19:39 | efried | melwitt, dansmith, mriedem: Thoughts on requesting +r for this channel? | |
| 14:19:56 | sean-k-mooney | efried: +r? | |
| 14:19:59 | dansmith | no way | |
| 14:20:16 | efried | sean-k-mooney: http://lists.openstack.org/pipermail/openstack-dev/2018-August/132692.html | |
| 14:20:27 | dansmith | sean-k-mooney: requires registered nicks to join | |
| 14:20:44 | sean-k-mooney | dansmith: ah ok to stop spam | |
| 14:20:47 | efried | yuh | |
| 14:21:08 | dansmith | freenode is catching them very quickly so one spam message every now and again is pretty minor, and it's just a recent wave | |
| 14:21:15 | sean-k-mooney | we are getting some but not a lot | |
| 14:21:29 | dansmith | yeah, +r would be a major overreaction IMHO | |
| 14:22:03 | sean-k-mooney | +r might also break some irc relays/bouncers | |
| 14:22:19 | dansmith | and casual users coming here to debug one thing | |
| 14:22:59 | dansmith | my bouncer gets un-authed often enough during netsplits, that I'm sure it would affect people with bouncers | |
| 14:23:15 | efried | okay, you're clearly opposed, I'll drop it for now. | |
| 14:24:59 | pooja_jadhav | efried: Hi | |
| 14:25:20 | efried | pooja_jadhav: Howdy. | |
| 14:25:54 | pooja_jadhav | efried: I need ur help in live migrate API testing. I am stuck at one point. | |
| 14:26:09 | dansmith | mriedem: I'll start up a patch for said node-removal cleanup | |
| 14:26:39 | openstack | Launchpad bug 1784874 in OpenStack Compute (nova) "ResourceTracker doesn't clean up compute_nodes or stats entries" [Low,Triaged] | |
| 14:26:39 | mriedem | dansmith: https://bugs.launchpad.net/nova/+bug/1784874 | |
| 14:26:44 | dansmith | mriedem: thanks | |
| 14:26:53 | efried | pooja_jadhav: I'm definitely not an expert in that realm. I'll do what I can - which will probably mean shunting you to mriedem and dansmith :) | |
| 14:27:15 | pooja_jadhav | efried: https://ask.openstack.org/en/question/62555/live-migrations-over-ssh-fail-from-nova-but-work-from-virsh/ (same happing with me right now) using virsh migrate i am able to migrate instance but using nova migrate API i can not. | |
| 14:28:32 | tssurya | mriedem: we don't | |
| 14:28:36 | sean-k-mooney | pooja_jadhav: have you exchaged passwordless ssh keys between all node for the use used in the migration | |
| 14:28:54 | sean-k-mooney | pooja_jadhav: e.g. nova for qemu+ssh://nova@compute-1/system | |
| 14:29:18 | pooja_jadhav | sean-k-mooney: yes, i have added password less ssh keys in authorize_keys file | |
| 14:29:30 | tssurya | we disabled that filter recently | |