| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-13 | |||
| 16:01:03 | mriedem | i got it | |
| 16:03:57 | mriedem | looks like all my rechecks were dropped | |
| 16:03:59 | mriedem | weeeee | |
| 16:19:37 | sean-k-mooney | artom: i noticed you updated your numa migration stuff yesterday | |
| 16:20:07 | sean-k-mooney | artom: have you more changes pending or shoudl i plan to review it/test it next week | |
| 16:20:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rework all things metadata'y https://review.opendev.org/640730 | |
| 16:20:42 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Rename 'configuration drive' to 'config drive' https://review.opendev.org/641723 | |
| 16:21:39 | stephenfin | efried: Think I asked you this before, but what's the chances of getting https://review.opendev.org/640730 blindly approved? | |
| 16:21:40 | stephenfin | It's docs only and I think it's a huge improvement, but I've no idea how to break it up more than I have without rewriting the whole darn thing | |
| 16:22:21 | mriedem | stephenfin: maybe ask dansmith to review it again first :) | |
| 16:22:35 | stephenfin | I think I've done that a few times too :( | |
| 16:22:37 | mriedem | since he did the most thorough review | |
| 16:23:07 | dansmith | stephenfin: done what a few times? | |
| 16:23:26 | stephenfin | dansmith: Have a look at that ridiculously big metadata doc rework patch of mine | |
| 16:23:33 | stephenfin | (https://review.opendev.org/640730) | |
| 16:23:43 | artom | sean-k-mooney, just a rebase for now, bottomg patch is WIP | |
| 16:23:57 | artom | To indicate that the whole series isn't ready yet | |
| 16:24:25 | dansmith | stephenfin: just wanted to make sure you weren't implying you had asked me to revisit a few times | |
| 16:24:31 | sean-k-mooney | artom: ok so saving the updated xml after the migration is still pending | |
| 16:24:56 | sean-k-mooney | artom: that was the main thing that needed to be fixed and the rest is cleanup right | |
| 16:26:58 | stephenfin | I think I may have and I get why you haven't, if so. Not intending to point fingers at all though. I'd just like to be done with it | |
| 16:28:16 | artom | sean-k-mooney, the XML is fine, IIRC, it's the database numa_topology that wasn't saved | |
| 16:28:46 | dansmith | stephenfin: point being, I'm quite sure I didn't hear anything after that review, but I'm looking at it right now | |
| 16:28:54 | sean-k-mooney | artom: maybe i just recall we didnt save somthing | |
| 16:29:18 | stephenfin | dansmith: Ah, sorry. That's my mistake so | |
| 16:29:23 | stephenfin | And thank you | |
| 16:36:22 | dansmith | mriedem: for the tenth and last time, can you hit this? https://review.opendev.org/#/c/640730/7 | |
| 16:36:33 | sean-k-mooney | stephenfin: i personlay prefer the ... then assuming people will guess its not a full respocne but its proably fine eitehr way | |
| 16:36:57 | stephenfin | sean-k-mooney: Too late. mriedem already did the deed | |
| 16:37:00 | stephenfin | mwahaha | |
| 16:37:03 | sean-k-mooney | stephenfin: that was regarding mriedem change but he has updated it already | |
| 16:37:06 | sean-k-mooney | yep i know | |
| 16:37:18 | stephenfin | No take backsies | |
| 16:37:23 | mriedem | dansmith: lucky for y'all i just got a fresh pack of red markers | |
| 16:37:42 | sean-k-mooney | stephenfin: damn i have not heard that in a while | |
| 16:43:54 | efried | stephenfin: looking now. | |
| 16:46:01 | aspiers | efried: oslo.log guidelines feedback addressed, when you are looking for some light relief | |
| 16:46:29 | efried | ack | |
| 17:18:39 | openstackgerrit | melanie witt proposed openstack/nova master: Warn for duplicate host mappings during discover_hosts https://review.opendev.org/651947 | |
| 17:19:14 | melwitt | dansmith: ^ updated | |
| 17:21:53 | dansmith | gdi | |
| 17:22:51 | melwitt | what | |
| 17:23:09 | dansmith | you're supposed to wait a month between all updates | |
| 17:23:29 | melwitt | :) | |
| 17:24:41 | efried | stephenfin: I'm going to wait until that sucker renders so I can at least feel I've done due diligence on the links and stuff. | |
| 17:30:10 | melwitt | \o\ | |
| 17:50:47 | artom | mriedem, so https://review.opendev.org/#/c/522106/ can be abandoned | |
| 17:53:03 | mriedem | artom: not really | |
| 17:53:08 | mriedem | https://review.opendev.org/#/c/581410/ isn't really describing scheduler hints in detail, | |
| 17:53:18 | mriedem | it's just describing scheduler hints vs flavor extra specs | |
| 17:53:25 | mriedem | which is more of an admin/operator thing than end user | |
| 17:53:54 | artom | mriedem, are we reading the same first paragraph of https://docs.openstack.org/nova/latest/reference/scheduler-hints-vs-flavor-extra-specs.html#scheduler-hints? | |
| 17:53:59 | mriedem | i agree the in-tree hints are described now in the api-ref | |
| 17:54:15 | mriedem | artom: i wrote https://docs.openstack.org/nova/latest/reference/scheduler-hints-vs-flavor-extra-specs.html#scheduler-hints? | |
| 17:54:39 | artom | mriedem, I know - it's almost word for word as what's in https://review.opendev.org/#/c/522106/8/api-guide/source/server_concepts.rst, no? | |
| 17:55:12 | artom | OK, maybe not word for word | |
| 17:55:44 | mriedem | i think the api-guide would benefit from (1) a short description of what are scheduler hints, (2) an example api request, and then (3) links to the thing above (hints vs extra specs) and the server create api reference for the description of the available in-tree hints | |
| 17:56:02 | mriedem | our api-ref doesn't have a sample with a scheduler hint in | |
| 17:56:04 | mriedem | *it | |
| 17:56:13 | mriedem | so every time i write a test that uses one, i have to look this up | |
| 17:56:51 | mriedem | b/c 1. there are 2 param names accepted for hints and 2. it's at the top level of the request rather than within the server object | |
| 17:57:30 | openstackgerrit | Merged openstack/os-vif master: set ignore_basepython_conflict = True in tox.ini https://review.opendev.org/665034 | |
| 17:57:37 | artom | Well, I signed up for this, might as well finish it | |
| 17:57:47 | artom | mriedem, same patch? Smells like a new change | |
| 17:58:59 | artom | Can I achieve peak arrogance by trading you reviews on https://review.opendev.org/#/c/644881/? | |
| 17:59:30 | artom | I guess same change to preserve review history | |
| 18:01:03 | mriedem | i would do the same patch for review history yes | |
| 18:01:10 | mriedem | add yourself as co-author | |
| 18:01:19 | mriedem | and because you asked for https://review.opendev.org/#/c/644881/ yet again i'm going to say i'll never review it again now | |
| 18:01:21 | mriedem | you're welcome | |
| 18:02:47 | openstackgerrit | sean mooney proposed openstack/os-vif stable/stein: set ignore_basepython_conflict = True in tox.ini https://review.opendev.org/665195 | |
| 18:07:20 | openstackgerrit | sean mooney proposed openstack/os-vif stable/stein: Fix mock of built in "open" function in unit tests https://review.opendev.org/665196 | |
| 18:08:15 | mriedem | artom: before you raise HR alarms downstream, i was joking | |
| 18:08:27 | melwitt | mriedem: this is a bit old and has a +2 from dansmith now, you're probably the best person to review since it's about nova-manage cells stuff https://review.opendev.org/651947 | |
| 18:08:57 | artom | mriedem, you haven't touched me inappropriately (yet?), so no HR alarms | |
| 18:09:01 | artom | ;) | |
| 18:09:29 | mriedem | dansmith: you know how we have this warning about stopping nova-compute before deleting it? https://developer.openstack.org/api-ref/compute/?expanded=delete-compute-service-detail#delete-compute-service otherwise dragons? it strikes me now that the delete compute service API should just be checking if the service is up and if so, fail the request with a 409 | |
| 18:10:06 | sean-k-mooney | artom: a +1 from zuul, how did you apise the ci gods to make that happen | |
| 18:10:15 | dansmith | mriedem: maybe, unless there's a reason to delete and have it recreate or something | |
| 18:10:23 | artom | sean-k-mooney, which patch? | |
| 18:10:35 | dansmith | mriedem: the other thing would be that unless you also force down, you can't stop and delete inside of a minute or whatever the service timeout is | |
| 18:11:01 | sean-k-mooney | artom: you have more then one with a +1 :P the hybrid_plug events one | |
| 18:11:04 | mriedem | yeah you'd have to force down | |
| 18:11:30 | mriedem | dansmith: the problem with the recreate is the new provider it will create in placement with no allocations for the instances on that host, which will f up scheduling | |
| 18:11:32 | artom | sean-k-mooney, except for the double words thing (that was fixed) I'm not aware of any Zuul issues | |
| 18:11:59 | mriedem | you can heal that with the heal_allocations CLI of course... | |
| 18:12:08 | mriedem | well, for non-nested / sharing allocations | |
| 18:12:29 | dansmith | mriedem: sure | |
| 18:12:45 | sean-k-mooney | artom: it was more the fact its taken a few hours for zuul to notice and run on your patch for the last few days then it being flaky | |
| 18:13:06 | artom | sean-k-mooney, oh, yeah, it's slow | |
| 18:13:13 | mriedem | i'm just down a hole on how we're orphaning providers today and how best to shore that up | |
| 18:16:30 | sean-k-mooney | im following the thread on the ml bug trying to stay out of it to a degree to leave ops speak up | |
| 18:16:59 | sean-k-mooney | although it looks like the last few mails are back and forth between you erric and chris | |
| 18:24:02 | mriedem | i think likely the best thing to do is a phased conservative approach, | |
| 18:24:18 | mriedem | 1. land my change that fixes it to delete all providers, not just the first (the ironic case), | |
| 18:24:34 | mriedem | 2. if deleting any provider fails, don't delete the compute service and bail (option 1 in the email), | |
| 18:25:02 | mriedem | 3. check for and cleanup allocations for evacuations - something we can be pretty sure we can get rid of safely | |
| 18:25:47 | mriedem | that leaves in-progress or unconfirmed migrations, and in that case i think we likely just should be saying "you can't delete the compute service until these migrations are done" | |
| 18:26:46 | sean-k-mooney | ya that seam sane. the issue that im not sure how to solve/if we shoul solv eis if you had in progeress migration and the host failed/went offline | |
| 18:27:17 | sean-k-mooney | can you evaucate an instance that was migrating | |