| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-13 | |||
| 13:52:04 | mriedem | efried: oh i guess you did | |
| 13:52:36 | mriedem | or artom i guess ^ | |
| 13:52:41 | efried | I'm basically +1 on whatever you wind up with. alex_xu or luyao could add some words about vpmem, but I'm not sure if that's supposed to be a tech preview or a trumpet-from-rooftops, or whatever | |
| 13:53:04 | efried | also, I think "first draft" was due today, so we're done :P | |
| 13:54:20 | artom | mriedem, I'm happy with it, left a note | |
| 14:07:06 | stephenfin | dansmith/mriedem/efried: This is going to cause gate issues and should be merged, right? https://review.opendev.org/682025 | |
| 14:11:39 | mriedem | sob | |
| 14:12:27 | mriedem | no wonder this didn't go down :/ http://status.openstack.org/elastic-recheck/#1843615 | |
| 14:21:56 | sean-k-mooney | mriedem: i did get a passing test run with numa+pcpus+vpmem last night by the way | |
| 14:22:24 | mriedem | how are you testing vpmem in the gate? | |
| 14:22:26 | sean-k-mooney | https://review.opendev.org/#/c/681771/ https://zuul.opendev.org/t/openstack/build/6a67b28d6e9e4b739e7575df7943a69d | |
| 14:22:28 | mriedem | doesn't that require special hardware? | |
| 14:22:36 | sean-k-mooney | it just had the code merged | |
| 14:22:40 | sean-k-mooney | didnt test the feature | |
| 14:22:50 | mriedem | stephenfin: thanks for calling that out - infra just pushed it to the gate | |
| 14:23:08 | stephenfin | np | |
| 14:23:21 | sean-k-mooney | but we did test with pinning+hugepage+multi numa https://review.opendev.org/#/c/681771/2/playbooks/nfv/nfv.yaml | |
| 14:24:43 | mriedem | sean-k-mooney: iow, vpmem didn't obviously regress any RT stuff with numa+pcpu in the same run | |
| 14:25:01 | sean-k-mooney | mriedem: right | |
| 14:25:06 | sean-k-mooney | no idea if it works | |
| 14:25:16 | sean-k-mooney | but when its not used it does not seam to break anything | |
| 14:26:09 | sean-k-mooney | unfortuetly it looks like the intel pmem ci did not run on that | |
| 14:27:41 | mriedem | idk if it's the new version of firefox i'm on, but i can't copy text from gerrit comments anymore, which is super annoying | |
| 14:27:58 | dansmith | from non-editing ones, I have the same issue in chrome | |
| 14:28:09 | dansmith | not always consistent, but sometimes.. it's weird | |
| 14:28:12 | sean-k-mooney | i have been having issue with that too but i can sometimes get ti to work | |
| 14:36:47 | melwitt | yeah, same. I couldn't remember if copying from comments in gerrit was ever possible (I guess it was) | |
| 14:40:33 | sean-k-mooney | i can get ctrl+insert to wrok and ctrl+c to work in some cases but its really inconsitent | |
| 14:45:02 | mriedem | do we have a patch up to mark train in the rest api history doc? | |
| 14:47:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Denote max version for Train in REST API history doc https://review.opendev.org/682069 | |
| 14:50:25 | dansmith | mriedem: do you want to throw an rpc alias in there? | |
| 14:51:01 | mriedem | separate patch? | |
| 14:51:12 | dansmith | both are aliases right? | |
| 14:51:16 | mriedem | sean-k-mooney: adrianc: shouldn't the note here https://docs.openstack.org/nova/latest/admin/pci-passthrough.html be updated to mention sriov live migratoin support in train? | |
| 14:51:38 | mriedem | dansmith: feel free to throw something up, i'm trying to wrap up these cycle highlights | |
| 14:51:52 | dansmith | just seemed like appropriate for the same patch but okay | |
| 14:52:43 | sean-k-mooney | not really | |
| 14:52:58 | sean-k-mooney | that is flavor based pci passthouhg | |
| 14:53:23 | sean-k-mooney | we could not that if you dont use this you can doe neutron based sriov and live migate | |
| 14:53:27 | sean-k-mooney | if that is what you ment | |
| 14:53:58 | sean-k-mooney | but i prefer to keep the flavor based apparoch which uses an alias seperate form the neutron port approch which does not | |
| 14:54:32 | sean-k-mooney | the sriov live migration only work for neutron ports | |
| 14:54:43 | mriedem | oh right yeah, | |
| 14:54:56 | mriedem | guess i wouldn't have thought about that except for the conditionals in the RT claims code | |
| 14:58:06 | sean-k-mooney | ya the proabme with generic pci devices is that even if the supprot sriov and you passthogh the PF | |
| 14:58:09 | sean-k-mooney | *VF | |
| 14:58:40 | sean-k-mooney | guest kerenls generall dont expect gpus or fpga to go away and we dont have an indireciton mecanisum like macvtap | |
| 14:58:56 | sean-k-mooney | so its not realy safe to detatch them wtihout impacting the guest | |
| 14:59:10 | sean-k-mooney | vfio-mediated device or mdev | |
| 14:59:25 | sean-k-mooney | give you that indrection but few thing support that yet | |
| 14:59:57 | sean-k-mooney | which is why we declare all of the flavor based stuff out of scope and just did the simpelest thing which is nics | |
| 15:00:04 | sean-k-mooney | that is also what most people wanted | |
| 15:02:35 | mriedem | hmm, i wonder if i should clarify that in the highlights, | |
| 15:02:45 | mriedem | because it just says "live migration support for sriov ports when using the libvirt driver" | |
| 15:02:51 | mriedem | i guess "ports" is good enough? | |
| 15:03:29 | sean-k-mooney | am maybe but i would leave that up to more docs focused people | |
| 15:03:34 | sean-k-mooney | ports is enough for me | |
| 15:03:45 | sean-k-mooney | we coudl say neutron ports | |
| 15:04:00 | mriedem | as opposed to, | |
| 15:04:21 | mriedem | what was that neutron replacement from cisco? | |
| 15:04:23 | sean-k-mooney | as aopposed to just sriov port say sriov neutron ports | |
| 15:04:30 | sean-k-mooney | vpp | |
| 15:04:35 | sean-k-mooney | ? | |
| 15:04:35 | mriedem | it had another name | |
| 15:04:47 | sean-k-mooney | oh yes am | |
| 15:04:49 | mriedem | that yaml based port definition thing that was a drop in for neutron | |
| 15:04:57 | mriedem | quark? | |
| 15:05:05 | sean-k-mooney | no but it was like that | |
| 15:05:13 | sean-k-mooney | prothon or some partical thing | |
| 15:05:33 | mriedem | porthole | |
| 15:05:46 | mriedem | anyway, saying "neutron ports" in openstack is redundant | |
| 15:06:02 | sean-k-mooney | ya as i said it looks fine to me | |
| 15:06:13 | sean-k-mooney | stephenfin: any opipion ^ | |
| 15:06:54 | stephenfin | nope :) | |
| 15:15:28 | mriedem | stephenfin: wasn't this supposed to fail https://review.opendev.org/#/c/681938/ ? | |
| 15:15:52 | stephenfin | Yes. Yes it was. | |
| 15:16:00 | stephenfin | So my diagnosis is wrong | |
| 15:16:35 | stephenfin | That code is definitely wrong, on account of it leaving Nones in there, but what did I do to trigger it... | |
| 15:16:36 | mriedem | unless my patch is wrong | |
| 15:16:58 | stephenfin | it looks okay | |
| 15:18:10 | mriedem | i see that the flavor is configured properly from the n-cpu logs | |
| 15:18:11 | mriedem | https://zuul.opendev.org/t/openstack/build/a7ae03ac0af24dc6b474a54de9d5cf86/log/controller/logs/screen-n-cpu.txt.gz#1924 | |
| 15:18:16 | mriedem | f86c41da98dc6230d777d7c4',properties=ImageMetaProps,protected=<?>,size=12716032,status='active',tags=<?>,updated_at=2019-09-13T04:45:17Z,virtual_size=<?>,visibility=<?>), allow threads: True {{(pid=18284) _get_desirable_cpu_topologies /opt/stack/nova/nova/virt/hardware.py:572}} | |
| 15:18:16 | mriedem | FACE='required'},flavorid='42',id=11,is_public=True,memory_mb=64,name='m1.nano',projects=<?>,root_gb=1,rxtx_factor=1.0,swap=0,updated_at=None,vcpu_weight=0,vcpus=1) and image_meta ImageMeta(checksum='443b7623e27ecf03dc9e01ee93f67afe',container_format='bare',created_at=2019-09-13T04:45:17Z,direct_url=<?>,disk_format='qcow2',id=e085b93e-a43c-42f1-9496-2b46f103dd3d,min_disk=0,min_ram=0,name='cirros-0.4.0-x86_64-disk',owner='4323 | |
| 15:18:16 | mriedem | Sep 13 04:50:30.647385 ubuntu-bionic-rax-ord-0011241791 nova-compute[18284]: DEBUG nova.virt.hardware [None req-f2beffe4-882b-4f73-ab07-ba3c859361ab tempest-AggregatesAdminTestJSON-598247452 tempest-AggregatesAdminTestJSON-598247452] Getting desirable topologies for flavor Flavor(created_at=2019-09-13T04:48:13Z,deleted=False,deleted_at=None,description=None,disabled=False,ephemeral_gb=0,extra_specs={trait:COMPUTE_NET_ATTACH_I | |
| 15:19:33 | stephenfin | mriedem: I know - you don't have cpu_model set on the host | |
| 15:19:42 | stephenfin | or cpu_flags | |
| 15:19:47 | stephenfin | both in the 'libvirt' group | |
| 15:19:54 | mriedem | https://zuul.opendev.org/t/openstack/build/a7ae03ac0af24dc6b474a54de9d5cf86/log/controller/logs/screen-placement-api.txt.gz#337 | |
| 15:19:54 | mriedem | and the scheduling request in placement | |
| 15:19:57 | stephenfin | I missed that /o\ | |
| 15:20:09 | mriedem | oh | |
| 15:20:17 | mriedem | so this is only if you use the cpu flag traits stuff | |
| 15:20:24 | stephenfin | Not quite | |
| 15:20:33 | openstackgerrit | Merged openstack/nova master: Find instance in another cell during floating IP re-association https://review.opendev.org/656594 | |
| 15:21:08 | stephenfin | It's only if you have '[libvirt] cpu_model' and '[libvirt] cpu_flags' (or maybe just the first - I'll check) set on the host | |
| 15:21:31 | stephenfin | which I _think_ most people will have because (a) live migration and (b) spectre/meltdown | |
| 15:21:55 | mriedem | you mean cpu_models and cpu_model_extra_flags yeah? | |
| 15:22:08 | stephenfin | that's the one | |
| 15:22:09 | mriedem | and yeah those are both [] in this run | |