| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-07 | |||
| 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 :) | |
| 16:50:53 | artom | sean-k-mooney, yeah, he's barking up the wrong tree with that as far as I'm concerned | |
| 16:51:35 | sean-k-mooney | the timelines dont match up as you said | |
| 16:52:31 | sean-k-mooney | we could ad special case support for midonet trivially but there is somthing else going on there | |
| 16:52:58 | artom | Their errors are the mm executable returning an error, nothing to do with events | |
| 16:53:56 | sean-k-mooney | ah ok i didnt look at the compute log until now | |
| 16:53:58 | noonedeadpunk | mriedem: ok, seems that you've already linked patch to some bug | |
| 16:55:33 | artom | sean-k-mooney, he gave me a good night scare though, I got the gerrit review email right before bed | |
| 16:56:44 | sean-k-mooney | ya im sure the heart rate spike didnt help you drifting off to sleep | |
| 16:57:02 | mriedem | noonedeadpunk: yeah and old bug | |
| 16:57:04 | mriedem | *an | |
| 16:57:55 | mriedem | sean-k-mooney: were you going to update this? https://review.opendev.org/#/c/647735/ | |
| 16:58:10 | mriedem | i'd like to make sure we don't lose track of documenting the features we add | |
| 16:58:11 | sean-k-mooney | yes | |
| 16:58:25 | sean-k-mooney | i also have to document the vpmu image property | |
| 16:58:32 | mriedem | oh i know | |
| 16:58:44 | mriedem | was just going through https://review.opendev.org/#/c/671338/ | |
| 16:59:58 | sean-k-mooney | ah right but yes ill update both. im almost finish fixing some other typos in an os-vif patch so i might as well update the glance patchs before i start anything else | |
| 17:00:11 | sean-k-mooney | want me to add you to them | |