| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-07 | |||
| 16:02:33 | mriedem | i'm also a bit disappointed that cern hasn't been more involved | |
| 16:02:40 | mriedem | but they seem...distracted lately as well | |
| 16:03:09 | mriedem | sean-k-mooney: idk even know what https://review.opendev.org/#/c/674072 is about | |
| 16:03:18 | mriedem | but it looks like it's not fun | |
| 16:04:04 | sean-k-mooney | we only allow you to specify the numa affinity policy for pci device in teh pci alias. the spec origially had flavor and image properites for it | |
| 16:04:22 | sean-k-mooney | neutron sriov dose not use pci alias | |
| 16:04:24 | mriedem | which original spec | |
| 16:04:25 | mriedem | ? | |
| 16:04:42 | sean-k-mooney | so we entirely broke the original neuton port usecase. | |
| 16:04:47 | sean-k-mooney | one sec ill get it | |
| 16:05:14 | mriedem | "lack of a feature is not a bug" | |
| 16:05:19 | sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/queens/implemented/share-pci-between-numa-nodes.rst | |
| 16:05:27 | sean-k-mooney | https://github.com/openstack/nova-specs/commit/74b47ac2f968b13b7d15987063d0f52ecba02a7e#diff-b5d95cd01ee920f26b55b45f2777b7aa is wher whe chaned it | |
| 16:06:06 | mriedem | ok i'm pretty sure i didn't review any of this https://review.opendev.org/#/q/topic:bp/share-pci-between-numa-nodes+(status:open+OR+status:merged) | |
| 16:06:13 | mriedem | looks like it was jay, sylvain and gibi | |
| 16:06:56 | mriedem | i do, however, always enjoy the late "oh btw this thing we landed 3 releases ago didn't do what it was supposed to but our QE team just got around to testing it" | |
| 16:06:57 | sean-k-mooney | mriedem: that is true which is why i want non redhat core to basicaly decide if this is valid to adress as a bugfix as redhat folk have a conflict of interest | |
| 16:07:25 | sean-k-mooney | well we knew it was broken for a while but planned to fix it in U | |
| 16:07:50 | sean-k-mooney | we have a custom request to support this that came in last week e.g. after spec freeze | |
| 16:08:10 | mriedem | so you want to slide it in as a bug fix? | |
| 16:08:11 | sean-k-mooney | so this is why im asking is this something we can address upstream in Train | |
| 16:08:43 | mriedem | you know i'm not going to let you backport this right? | |
| 16:09:09 | sean-k-mooney | well we do actully have a bug for it but i also added the wrong one | |
| 16:09:14 | sean-k-mooney | mriedem: and yes i know | |
| 16:09:40 | mriedem | this smells like a blueprint to me, not a bug | |
| 16:10:15 | sean-k-mooney | given we are pass m2 is this something that people would be willing to consider of train as a blueprint | |
| 16:10:41 | sean-k-mooney | i am happy to file one and ask for a blueprint exception | |
| 16:11:01 | mriedem | christ | |
| 16:11:28 | mriedem | tell you what, if you can lean on dansmith and he can lean on me then we can talk | |
| 16:11:33 | mriedem | but i just -1ed this as needing a blueprint | |
| 16:11:35 | openstackgerrit | Merged openstack/nova stable/stein: Replace non-nova server fault message https://review.opendev.org/674828 | |
| 16:11:38 | sean-k-mooney | mriedem: i am also ok with punting it but that just forces me to consider downstrema only way to adres this. | |
| 16:11:42 | dansmith | wut | |
| 16:11:42 | openstackgerrit | Merged openstack/nova stable/stein: Revert "[libvirt] Filter hypervisor_type by virt_type" https://review.opendev.org/672723 | |
| 16:12:04 | mriedem | dansmith: "we forgot to do a thing in queens" https://review.opendev.org/#/c/674072/ | |
| 16:13:11 | dansmith | mriedem: if a config flag to disable certain processor flags for the biggest SEV in decades is a feature, then ffs, this surely is | |
| 16:13:30 | sean-k-mooney | this is the orignal bug report by the way https://bugs.launchpad.net/nova/+bug/1795920 | |
| 16:13:31 | openstack | Launchpad bug 1795920 in OpenStack Compute (nova) "SR-IOV shared PCI numa not working " [Undecided,Confirmed] | |
| 16:13:56 | melwitt | since everybody's in a good mood this morning, think it's a good time to ask for reviews on multi-cell archive_deleted_rows https://review.opendev.org/507486 | |
| 16:20:26 | mriedem | RAGE | |
| 16:20:55 | stephenfin | Terrible game, that | |
| 16:21:01 | mriedem | oh right you wanted to backport that too... :) | |
| 16:23:59 | huaqiang | dansmith: about the evenly distributing PCPUs/VCPUs in instance, I have replied in v7 | |
| 16:24:11 | dansmith | huaqiang: yeah, I know, and so have others | |
| 16:24:26 | huaqiang | I need your comment | |
| 16:24:39 | dansmith | huaqiang: I don't like that we're just letting the user define the orientation of every last electron instead of being abstract | |
| 16:24:43 | dansmith | but that's just my opinion | |
| 16:24:55 | dansmith | it's clear that others feel it's very important to be able to arrange all the electrons | |
| 16:26:00 | sean-k-mooney | dansmith: i dont know if you saw my conversation with alex_xu this morning | |
| 16:26:13 | huaqiang | I just think if the cpu maks is provided, administrator can have more choice | |
| 16:26:13 | dansmith | I *saw* it, but didn't pay close attention | |
| 16:26:15 | sean-k-mooney | you are right that we prviosuly discussed an alternitive | |
| 16:26:20 | melwitt | lol arranging electrons? *slowly backs away* | |
| 16:26:34 | dansmith | huaqiang: yeah I know.. everyone wants full control of everything | |
| 16:26:37 | sean-k-mooney | e.g. a tally count of how many pcpu and vcpu | |
| 16:27:05 | sean-k-mooney | and then a conention that per numa node we place the numa local vcpu first followed by the numa local pcus | |
| 16:27:13 | dansmith | sean-k-mooney: seems like arranging the dedicated cpus first and the non-dedicates ones after would still give you all the control you need, since you can already control numa nodes, memory assignment, etc | |
| 16:27:25 | sean-k-mooney | this make the core 0 is for the os eveythring else if for the app case just work | |
| 16:27:29 | dansmith | but I know I should just forget about this ever trying to be anything other than manual bitmasks for everything | |
| 16:27:49 | sean-k-mooney | dansmith: you want the non dedicate ones first | |
| 16:28:02 | sean-k-mooney | there are some things in the kernel you cant move off core 0 | |
| 16:28:07 | sean-k-mooney | at least not eaisly | |
| 16:28:08 | melwitt | mriedem: I think I asked about backporting --before, not this :) but yeah, both are things that would help with operability for queens *emoji with eyelashes* | |
| 16:28:10 | dansmith | whatever | |
| 16:28:37 | sean-k-mooney | dansmith: well it is a valid alternitve im not totally against | |
| 16:28:57 | sean-k-mooney | but if we were to go that route i think we would need time to think about it and spec out | |
| 16:29:05 | sean-k-mooney | meaning this defintly would be moved to U | |
| 16:29:34 | sean-k-mooney | the mask is consitent with realtiem cpus btu i get the concern over complexity | |
| 16:31:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add useful error log when _determine_version_cap raises DBNotAllowed https://review.opendev.org/675148 | |
| 16:31:11 | mriedem | mnaser: noonedeadpunk: ^ did an OSA nova bug get filed? | |
| 16:31:15 | mriedem | if so i can tack it on there | |
| 16:32:20 | huaqiang | dansmith: got. thanks | |
| 16:32:36 | mriedem | melwitt: oh right yeah | |
| 16:32:56 | mriedem | is queens the major RHOSP release all of the customers are on now because that seems to be where all of the recent customer stuff is coming from | |
| 16:33:05 | sean-k-mooney | mriedem: yes | |
| 16:33:06 | mriedem | non-LTS RHOSP i should say | |
| 16:33:08 | melwitt | that is correct, heh | |
| 16:33:56 | sean-k-mooney | queens is osp 13. osp 10(netwon) is EOL in december so everyone is moving to 13. | |
| 16:34:02 | melwitt | we're maybe probably gonna backport both of these I think. because RDO cloud and/or our CI runs on queens and not having these tools has been pain for those running the clusters | |
| 16:34:22 | melwitt | *backport downstream, at least | |
| 16:35:48 | mnaser | mriedem: i think noonedeadpunk did not do one so perhaps OSA instead can tack on | |
| 16:35:48 | mriedem | super. i'm now tasked internally with helping to deploy and operate a distribution based on mitaka, so things are really moving forward in the world. | |
| 16:35:56 | mnaser | lololol | |
| 16:36:10 | melwitt | oooof, damn | |
| 16:36:47 | mriedem | and the only red hat recruiter emails i get are for consulting gigs :/ \o/ | |
| 16:37:02 | mriedem | need to fire up the old beat farmer dream | |
| 16:37:22 | mriedem | at least that way i can get in on some sweet sweet government subsidies | |
| 16:37:40 | melwitt | lol xD | |
| 16:46:55 | mriedem | stein release wip proposed https://review.opendev.org/#/c/675152/ | |
| 16:47:34 | mriedem | artom: sean-k-mooney: ^ has the ovs hybrid plug revert resize thing in it too | |
| 16:47:35 | noonedeadpunk | mriedem: not yet:( | |
| 16:47:54 | noonedeadpunk | I'll fill in then right now | |
| 16:48:17 | mriedem | melwitt: thanks for hitting those backports | |
| 16:48:23 | melwitt | deps on route to the gate | |
| 16:48:25 | melwitt | np | |
| 16:48:39 | mriedem | you can bug me about the all cells archive thing, i've been meaning to get to it, just sidetracked | |
| 16:48:42 | melwitt | *en route (how embarrassing) | |
| 16:49:11 | melwitt | yesss, thanks | |
| 16:49:44 | sean-k-mooney | oh ok cool for tansparancey there is this revert fo that https://review.opendev.org/#/c/675021/ but artom and i both belive the issue that they were trying to fix is unrelated | |
| 16:50:33 | artom | mriedem, it's already downstream, but thanks :) | |