| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-06 | |||
| 16:47:58 | efried | aspiers: that one is *also* a failure scenario | |
| 16:48:05 | aspiers | yeah that's what I'm saying | |
| 16:48:23 | aspiers | CONF.libvirt.hw_machine_type set to x86_64=q35 would be the non-failure scenario | |
| 16:48:27 | aspiers | I can add that | |
| 16:48:48 | aspiers | efried: kudos for eagle eyes as usual :) | |
| 16:49:07 | efried | where are you going to add it? | |
| 16:50:25 | efried | aspiers: is it adequate to undo one of those three lines of delta here https://review.opendev.org/#/c/680065/8/nova/tests/unit/scheduler/test_utils.py ? | |
| 16:50:37 | efried | and then maybe also add the case next to the one in the fourth patch? | |
| 16:51:35 | efried | aspiers: there's one more comment in there, in case you agree and want to make that change at the same time. | |
| 16:51:46 | aspiers | efried_afk: ok thanks! | |
| 17:45:31 | mriedem | dansmith: so linkedin told me it was a big day for you and i was looking at the suggested comments and i thought this one was a good fit https://photos.app.goo.gl/WrC1wjQYu7Btfz2g8 | |
| 17:48:10 | dansmith | heh | |
| 17:48:21 | dansmith | yeah, I wish linkedin wouldn't ask people to do that | |
| 17:48:34 | dansmith | and/or I wish people would ignore all that crap like I do :) | |
| 17:49:55 | sean-k-mooney | i think mose people do | |
| 17:50:35 | aspiers | haha | |
| 17:51:01 | sean-k-mooney | dansmith: the real question is does it feel like 6 or 12 | |
| 17:51:25 | dansmith | sean-k-mooney: see, you're doing it, although indirectly :) | |
| 17:55:25 | mriedem | i just laugh at the AI/ML generated auto responses | |
| 17:55:34 | mriedem | i hate them on my phone but am too lazy to figure out how to disable | |
| 17:55:50 | mriedem | because no my every response to my wife's text messages shouldn't be, "I know, right?" | |
| 17:56:31 | melwitt | I know that you can disable profile updates from notifying the world but I don't know if that encompasses work anniversaries too | |
| 17:56:55 | mriedem | heh, messaging > settings > smart reply (disable) | |
| 17:56:57 | mriedem | that was easy | |
| 17:57:08 | mriedem | "I know, right?" | |
| 18:05:06 | sean-k-mooney | ok i havent got anything useful done in an hour some im goign to get dinner. i might be back online later. if not have a nice weekend o/ | |
| 18:05:50 | dansmith | sean-k-mooney: it's friday. turn. off. the. laptop. | |
| 18:13:36 | mriedem | but is bauzas still up working on a friday night? | |
| 18:13:45 | mriedem | b/c i'm +2 on https://review.opendev.org/#/c/680394/4 and the 2 above it | |
| 18:16:46 | mriedem | gibi: when you're back and collecting comments, i approved but left a comment about defining constants for https://review.opendev.org/#/c/655109/24 | |
| 18:27:51 | mriedem | if anyone is adventurous, there are +2s waiting for a +W on 4 of the bw provider move series https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports+status:open+label:Code-Review=2 | |
| 18:28:17 | mriedem | they are all about min compute service version checking and functional tests | |
| 18:28:19 | mriedem | so pretty easy | |
| 18:28:46 | mriedem | the bottom one is only big b/c of a lot of test coverage | |
| 18:38:40 | mriedem | dansmith: so i've got an rpc compat thing i'd like to remove but need to get out of my head, | |
| 18:39:23 | mriedem | before this change, https://review.opendev.org/#/c/582417/ conductor would always send a legacy request spec dict to compute's prep_resize method during cold migrate/resize and compute would never send it back to conductor on reschedule, | |
| 18:39:39 | mriedem | with that change, prep_resize on the comput takes a RequestSpec object if you're not pinned | |
| 18:39:49 | mriedem | and compute passes back whatever it gets | |
| 18:40:15 | mriedem | there were no changes to the conductor compute task api rpc interface b/c it always took a request spec and passed it through (for the api calling conductor initially) | |
| 18:40:35 | mriedem | what i'd really like to do is remove this compat code when compute doesn't send a request spec back on reschedule https://review.opendev.org/#/c/582417/7/nova/conductor/manager.py | |
| 18:41:07 | mriedem | which should be possible if we aren't supporting older-than-stein computes in train or ussuri, | |
| 18:41:15 | dansmith | violates the rpcapi though | |
| 18:41:22 | mriedem | where i think i f'ed up was that the compat code in conductor isn't handling request spec being a dict | |
| 18:41:46 | mriedem | no i don't think it violates the rpc api because there was no change to the conductor rpc api to remove the request spec that compute passes back | |
| 18:41:50 | mriedem | it's just a pass through | |
| 18:41:55 | mriedem | the only interface that changed was the compute rpc api | |
| 18:42:15 | dansmith | the object could be None there which means old version right? | |
| 18:42:15 | mriedem | so the only time compute won't send a request spec back up is if it's pre-stein | |
| 18:42:36 | mriedem | well, if you're pinned to less than conductor 1.13 yeah... | |
| 18:42:58 | dansmith | right | |
| 18:43:09 | mriedem | which was mitaka https://review.opendev.org/#/c/277800/ but yeah | |
| 18:43:15 | dansmith | so you can't remove the ability to take an N.0 call unless you bump majors | |
| 18:43:26 | mriedem | right so conductor 2.0 to make request spec required and RequestSpec object | |
| 18:43:26 | dansmith | I mean, | |
| 18:43:41 | dansmith | I realize other shit will break if you go that old, but either we stick to these rules or we don't | |
| 18:43:47 | mriedem | yeah | |
| 18:44:11 | mriedem | i just came across that todo while reviewing gibi's series and though i'm glad we have that, and was going to remove the compat, but then realized i can't | |
| 18:44:38 | mriedem | so i'll be amending that todo comment i guess since i don't feel like taking on a conductor 2.0 bump | |
| 18:45:27 | dansmith | aye | |
| 18:51:33 | openstackgerrit | Merged openstack/nova master: objects: Remove ConsoleAuthToken.to_dict https://review.opendev.org/652970 | |
| 19:25:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/680762 | |
| 19:25:09 | mriedem | ok i think that handles both issues (bad comment and dict compat) | |
| 19:34:18 | openstackgerrit | Merged openstack/nova master: Bump min for oslo.service & .privsep to fix SIGHUP https://review.opendev.org/679974 | |
| 19:40:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup request spec handling in _cold_migrate https://review.opendev.org/680763 | |
| 19:40:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Isolate request spec handling from _cold_migrate https://review.opendev.org/680763 | |
| 19:41:02 | efried | dansmith: I haven't looked at all yet, but it's almost 3 and I'm still not dug out, and wanted to catch you today if possible -- did a) the vpmem Resource ovo stuff and b) the forbidden aggs stuff shake out satisfactorily? | |
| 19:41:26 | dansmith | I haven't gotten to them yet | |
| 19:50:17 | dansmith | efried: do you know why the isolated aggs set was rebased this morning? | |
| 19:50:32 | dansmith | doesnt' seem like anything changed and it means we still don't have a ci run on it yet | |
| 19:50:58 | efried | dansmith: I don't. Maybe so the owner can retain commiter-hood? | |
| 19:51:25 | dansmith | that's not how that works | |
| 19:51:54 | aspiers | efried: on further thought, I think https://review.opendev.org/#/c/680065/ is fine as it stands - see the comments I just posted | |
| 19:51:56 | efried | dansmith: oh, it looks like the bottom patch needed an ovo hash bump -- oops, that's my bad. | |
| 19:52:13 | dansmith | oh okay I thought I checked all the files but maybe I missed that one | |
| 19:52:21 | dansmith | (for changes I mean) | |
| 19:52:31 | efried | https://review.opendev.org/#/c/671072/14..15/nova/tests/unit/objects/test_objects.py | |
| 19:53:24 | dansmith | yeah I know | |
| 19:59:36 | efried | aspiers: beaut, thanks for following up. +A | |
| 20:04:15 | aspiers | efried: yw. Don't hesitate to ask if I can (attempt to) help explain other oddities in the remaining two patches | |
| 20:22:07 | mriedem | artom: dansmith: since stephen and sean aren't around, i'll ask you this https://review.opendev.org/#/c/621476/62/nova/api/openstack/compute/server_topology.py@66 | |
| 20:22:10 | mriedem | since i don't know numa | |
| 20:22:53 | dansmith | same pagesize on all cells, is that what you mean? | |
| 20:22:57 | mriedem | yeah | |
| 20:23:21 | dansmith | they will all have a pagesize and they'll all be identical | |
| 20:23:30 | dansmith | I asked that earlier in artom's series | |
| 20:23:42 | mriedem | if they will all have a page size why is that conditional? | |
| 20:24:12 | dansmith | oh, not sure they will all always have a pagesize, but if any do, they'll be the same | |
| 20:24:35 | dansmith | now, that's a libvirt/x86 thing.. I can imagine power allowing multiples because some team in DB2 asked for it in 1996 | |
| 20:24:54 | mriedem | ok, that works for me | |
| 20:24:55 | dansmith | all that probably depends on the hypervisor and arch | |
| 20:25:11 | mriedem | this is an intel (tm) api so don't worry about it | |
| 20:25:15 | dansmith | so I'm sure this api will be broken for other ones that aren't considered here | |
| 20:25:19 | dansmith | WONderful | |
| 20:25:46 | mriedem | powerstackers was burned out of governance b/c eric wouldn't lead them anymore | |
| 20:25:59 | mriedem | and the z folks have moved onto openshift on mainframes | |
| 20:26:06 | dansmith | shocking | |
| 20:26:37 | mriedem | has to be weird when the german customers ask for sles + openshift on their z mainframe | |
| 20:52:51 | mriedem | so this is the 2.78 server numa topology command output right now in the proposed change: http://paste.openstack.org/show/772110/ | |
| 20:52:54 | mriedem | that....sucks | |
| 20:58:12 | sean-k-mooney | libvirt/qemu support having muliple page size even in the same numa node but we dont support that in openstack and likely never will | |