Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-07
15:55:24 efried mkrai: Hi there. I recall mriedem had some ideas about that design. dansmith could probably provide some good input as well. To be clear, this is going to be a U release thing, you're just looking for initial design help?
15:55:35 sean-k-mooney mkrai: yes i have it open
15:55:37 gibi sean-k-mooney: we might improve the test to dump the file path when the assert fails
15:55:56 mkrai efried, Yes!
15:56:02 mkrai sean-k-mooney, Thanks!
15:56:22 huaqiang dansmith: hello
15:58:06 sean-k-mooney efried: mkrai could start on any ironic internal prep work that was need this cycle but the ironic driver changes would be next cycle i guess
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

Earlier   Later