| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-29 | |||
| 15:28:09 | aspiers | When it's reached, it's at least as important to update the code as the note, so I would write it more like: | |
| 15:28:14 | kashyap | aspiers: No, not just the note; the "remove the following code" as well | |
| 15:28:20 | kashyap | New phrasing coming soon to an IRC window near you | |
| 15:28:26 | aspiers | kashyap: "TODO(kchamart): Once MIN_LIBVIRT_VERSION reaches v4.7.0, remove the code [...] and rewrite the above note ..." | |
| 15:28:36 | aspiers | i.e. put the code removal first | |
| 15:29:05 | aspiers | Unfortunately my pedantry has no "off" button | |
| 15:31:50 | kashyap | I enjoy English phrasing pedantry. | |
| 15:32:16 | aspiers | Me too, for some reason | |
| 15:34:01 | kashyap | # TODO(kchamart): Once MIN_LIBVIRT_VERSION | |
| 15:34:01 | kashyap | aspiers: How about this: | |
| 15:34:02 | kashyap | # _destroy() API call (which gives SIGKILL 30 | |
| 15:34:02 | kashyap | # and (b) remove the following code that retries | |
| 15:34:02 | kashyap | # reaches v4.7.0, (a) rewrite the above note, | |
| 15:34:04 | kashyap | # seconds to take effect) -- because from v4.7.0 | |
| 15:34:06 | kashyap | # onwards, libvirt _automatically_ increases the | |
| 15:34:10 | kashyap | # timeout to 30 seconds. This was added in the | |
| 15:34:11 | kashyap | # following libvirt commits: | |
| 15:34:22 | aspiers | Yeah, that's good | |
| 15:34:35 | mriedem | sean-k-mooney: i bet you know the answer to this, is "x in y" where y is a set the same time as if y were a dict? | |
| 15:34:39 | aspiers | the (a) and (b) addresses the problem with the comma after "note" | |
| 15:34:56 | kashyap | aspiers: Yeah, indeed, it can't be misunderstood even if one tries to. | |
| 15:35:24 | sean-k-mooney | if y is a dict its checking is x in the keys | |
| 15:35:25 | aspiers | mriedem: same time as in complexity? or same thing? I think the answer to both is yes | |
| 15:35:38 | aspiers | yeah, what sean-k-mooney said | |
| 15:35:55 | sean-k-mooney | mriedem: if you want to check the values you need to do x in y.values | |
| 15:35:57 | aspiers | both should be O(1) | |
| 15:35:57 | mriedem | sean-k-mooney: yes i realize what it's looking for | |
| 15:36:04 | mriedem | i'm asking if both are O(1) | |
| 15:36:19 | sean-k-mooney | yes they are both O(1) | |
| 15:37:38 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.opendev.org/639091 | |
| 15:38:15 | kashyap | mdbooth: aspiers ^ Wording in the note rephrased to clearly spell out what's to do. | |
| 15:40:04 | aspiers | kashyap: is https://review.opendev.org/#/c/655193/ next on your list? since that's a major blocker for the newer changes on my SEV series | |
| 15:40:21 | kashyap | aspiers: Without guessing, is it the 'os_traits' rework? Yes | |
| 15:40:32 | aspiers | kashyap: and it sounds like pretty much all you have to do is empty x86.py | |
| 15:40:35 | kashyap | aspiers: Tomm is holiday; but today & Friday I'll be working on it, too. | |
| 15:40:35 | aspiers | OK, cool | |
| 15:40:41 | kashyap | aspiers: Yeah, let me do that right away | |
| 15:42:00 | kashyap | aspiers: It's amazing, what that change turned into. I was just a drive-by "observer" of the 'os_traits' repo & the corresponding call in driver.py. Thought I'll make a tiny change | |
| 15:42:04 | aspiers | kashyap: oh, and some simple nits from me in amd.py | |
| 15:42:07 | kashyap | ... and it turned into a multi-week thing | |
| 15:42:20 | kashyap | aspiers: Certainly, saw that. Typo: s/SVM/SEV/ | |
| 15:42:32 | kashyap | And others. Reading... | |
| 15:44:53 | aspiers | kashyap: that's what happened to me with https://review.opendev.org/#/c/538498/, more or less | |
| 15:45:31 | kashyap | aspiers: Ah, I saw this fly by. Thanks for the diagrams! | |
| 15:46:08 | aspiers | kashyap: https://docs.openstack.org/nova/latest/reference/update-provider-tree.html#taxonomy-of-traits-and-capabilities | |
| 15:46:12 | aspiers | added since then | |
| 15:48:21 | kashyap | aspiers: (While I wait on the almost-human-sounding-bot), what's the source on that neat digram? | |
| 15:48:27 | kashyap | s/digram/diagram/ | |
| 15:48:41 | aspiers | kashyap: it's just SVG | |
| 15:48:58 | aspiers | stephenfin: search and replace? ;-p | |
| 15:49:09 | kashyap | aspiers: Ah, okay. | |
| 15:49:11 | stephenfin | aspiers: Deleting cells v1 | |
| 15:49:21 | cdent | that'll show you! | |
| 15:49:22 | aspiers | ROFL | |
| 15:49:47 | stephenfin | :D | |
| 15:50:07 | aspiers | WTF, I'm #4 by LoC | |
| 15:50:15 | aspiers | How is that possible | |
| 15:50:30 | stephenfin | specs? | |
| 15:50:36 | cdent | ugh, this is not great: https://www.stackalytics.com/?metric=loc&module=placement-group | |
| 15:51:48 | edleafe | cdent: they have been saying that their numbers have been out of whack for a while | |
| 15:52:04 | cdent | edleafe: they reported recently that they fixed it. that looks right | |
| 15:52:23 | edleafe | I thought they were still working on it | |
| 15:52:39 | cdent | there was a post couple days ago | |
| 15:52:50 | cdent | but who knows, I don't think we can ever really fully rely on it | |
| 15:52:51 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/stein: docs: Don't version links to reno docs https://review.opendev.org/662025 | |
| 15:52:53 | melwitt | mriedem, johnthetubaguy: thanks for the reviews on counting quotas <3 I'm going to add a follow up patch for the nits/notes and then also propose the spec amendment for the deviations from the spec | |
| 15:53:27 | edleafe | You mean Eric has only contribute 25 lines of code?? | |
| 15:53:33 | aspiers | edleafe: they were missing a whole bunch of commits for nova, but I think that got fixed in the last day or 2 | |
| 15:54:39 | cdent | edleafe: of merged stuff in train, yeah, I'd say that's right | |
| 15:54:40 | aspiers | edleafe: it says 809 LoC for Eric | |
| 15:55:05 | aspiers | I'm looking at https://www.stackalytics.com/?metric=loc&release=train&module=nova-group | |
| 15:55:07 | edleafe | aspiers: for Train? | |
| 15:55:16 | edleafe | aspiers: ah, we're looking at placement | |
| 15:55:20 | aspiers | ah sorry | |
| 15:56:17 | mriedem | melwitt: just posted comments on https://review.opendev.org/#/c/638073/ | |
| 15:56:31 | mriedem | melwitt: i'm going to post a DNM patch to test the pg flow | |
| 15:57:16 | melwitt | whoa, that is a lot of comments | |
| 15:59:58 | mriedem | only 12, that's nothing | |
| 16:01:36 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.opendev.org/629597 | |
| 16:01:37 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/queens: fix up numa-topology live migration hypervisor check https://review.opendev.org/648939 | |
| 16:09:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: Test count_usage_from_placement=True with postgresql https://review.opendev.org/662028 | |
| 16:11:43 | phillw | Hi good people, a quick question if I may. Regarding using GPUs in compute nodes, I managed to find an article from CERN on the subject but nothing else (http://openstack-in-production.blogspot.com/2018/05/introducing-gpus-to-cern-cloud.html) Does anyone know of anything else current;y on-going / in the pipe line for this? | |
| 16:12:52 | mriedem | phillw: vGPUs? because that's documented here https://docs.openstack.org/nova/latest/admin/virtual-gpu.html | |
| 16:13:06 | phillw | mriedem: thanks :) | |
| 16:13:13 | mriedem | physical GPUs can be accessed using pci-passthrough since...juno? | |
| 16:13:26 | mriedem | vGPU support in the libvirt and xenapi drivers is since queens | |
| 16:13:47 | mriedem | https://docs.openstack.org/nova/latest/admin/pci-passthrough.html for the latter | |
| 16:13:56 | mriedem | *er pcpu pci passthrough | |
| 16:14:01 | mriedem | *pgpu | |
| 16:14:14 | mriedem | that doc mostly talks about sriov ports though | |
| 16:14:58 | sean-k-mooney | you sould also be about to use amds sriov based vgpu "MxGpu" or something like that via pci passthrough from juno or whenever we added that | |
| 16:15:44 | sean-k-mooney | i.e. if your gpu support virtualisation via sriov then that will jsut work like any other sriov vf with pci passhtough | |
| 16:15:57 | sean-k-mooney | the same we we supprot qat virtualistion via sriov | |
| 16:17:13 | phillw | I'll go and have a read up. A colleague of mine wants to use the gpu power for AI learning and I'm at the start of re-learning openstack after a break since 2014 :) | |
| 16:18:09 | mriedem | scanning the cern article it looks pretty comprehensive | |
| 16:18:14 | mriedem | and says what we just told you anyway :) | |
| 16:18:31 | mriedem | i'm not aware of who is using vgpus yet | |
| 16:18:32 | sean-k-mooney | the current state is we have dedicated support for the nvida data center gpus( which need a license) and untested support for sriov stuff which shoudl jsut work via pcie passthough | |
| 16:18:36 | mriedem | bauzas might know | |
| 16:18:38 | phillw | it missed out about deployment :) | |