| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-07 | |||
| 15:59:16 | mriedem | i love being continually distracted about asking to review specs and plans and code for things that do not even have a chance for train | |
| 15:59:34 | mkrai | sean-k-mooney, I have already posted spec for the ironic reconfigure API that will be needed by the resize API | |
| 15:59:36 | sean-k-mooney | gibi: are you ok with https://review.opendev.org/#/c/674072 adressing bug: #179520 as a bugfix to the original spec | |
| 15:59:36 | openstack | bug 179468 in python-cups (Ubuntu) "duplicate for #179520 applet.py crashed with TypeError in on_job_hold_activate()" [High,Fix released] https://launchpad.net/bugs/179468 - Assigned to Pascal De Vuyst (pascal-devuyst) | |
| 15:59:36 | mriedem | meanwhile my mega cross-cell resize series is not getting review but has been up for 2 cycles | |
| 16:00:17 | mkrai | sean-k-mooney, https://review.opendev.org/#/c/672252/ | |
| 16:00:29 | mkrai | I will add this link to the etherpad | |
| 16:00:54 | efried | mriedem: I'm going out on a limb and saying distraction is not the most significant factor in lack of reviews on cross-cell resize. | |
| 16:00:58 | efried | At least for me that's true | |
| 16:01:03 | gibi | sean-k-mooney: yeah I'm OK with that being a bugfix. Maybe a link to the original spec / bp in the commit message would help | |
| 16:01:07 | sean-k-mooney | mriedem: ^ that question is also to use as well are you ok with https://review.opendev.org/#/c/674072 adressing the feature gap in the orginal spec. | |
| 16:01:10 | efried | "I'm askeird" is the major reason | |
| 16:01:28 | mriedem | efried: i'm not saying it's a walk in the park | |
| 16:01:38 | sean-k-mooney | gibi: sure ill add one | |
| 16:01:46 | efried | fwiw, I have been intending to wade in | |
| 16:01:52 | mriedem | that's why i had integration testing of cross-cell resize working before putting out a review guide | |
| 16:01:55 | efried | but procrastinating successfully so far | |
| 16:02:13 | mriedem | which is more than i can say for a lot of the features we merge... | |
| 16:02:19 | efried | yeah yeah | |
| 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 | |