| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-13 | |||
| 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 | |
| 18:27:25 | sean-k-mooney | when the host went off line | |
| 18:27:54 | bnemec | aspiers: +2. Thanks for taking care of this! | |
| 18:28:03 | aspiers | bnemec: yw | |
| 18:28:20 | mriedem | sean-k-mooney: don't think so | |
| 18:28:27 | mriedem | unless you reset the instance state to ERROR | |
| 18:28:29 | sean-k-mooney | im fine to leave that up to the operator to clean up too, but im just wondering about the case where the reason their are pending migration or evacuation is because of a host failure | |
| 18:28:51 | sean-k-mooney | or reset it ot active | |
| 18:28:57 | sean-k-mooney | but ok | |
| 18:29:58 | sean-k-mooney | if it was in resize_verify or whatever the state is when we havent confirmed yet but was successafaly migrated we would proably want to reset it to active | |
| 18:30:04 | mriedem | if you're in the middle of a migration and the source host went offline, i don't see why you'd delete the service - just bring the service back up if possible | |
| 18:31:31 | sean-k-mooney | ya im somewhat unclear why the compute service is being deleted with outstanding migrations too | |
| 18:32:14 | sean-k-mooney | also reset state to active instead of confirming might not be right as it likely would not have updated the db correctly for the new host | |
| 18:32:46 | sean-k-mooney | so you would want to confirm. let it error out and then rest to active/hardreboot to fix it right | |
| 18:33:54 | mriedem | well the good news is a contracted google recruiter has contacted me about opportunities in the bay area of new york so if i want to avoid this problem i can just follow that lead and up-root my entire life | |
| 18:34:03 | mriedem | delete compute service problems be damned! | |
| 18:34:43 | sean-k-mooney | haha well that is one way to solve it yes then you can work on kubernetes problems | |
| 18:35:28 | sean-k-mooney | its really a seperate issue but should we allow you to confim a resize/migration if the souce host is down without erroring out? | |
| 18:35:29 | mriedem | then after 6 months you get there and they're like, "ok we have this resource leak issue when you delete a pod" | |
| 18:36:33 | mriedem | sean-k-mooney: i'm not sure what happens in that case, i haven't tried it, but i'd think the cast to the source compute would blow up and you'd get a 500 response from the confirmResize API | |