| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-05 | |||
| 19:56:12 | sean-k-mooney | we may have drop the propsoal since we did not need it in train | |
| 19:57:24 | efried | regardless, the point is that we don't expect that trait to ever make sense in a GET /a_c query because we have no way to express the SAME_HOST part of it in GET /a_c | |
| 19:57:29 | mriedem | as for anti-affinity....there is a member_of=!in, so for server groups you could create a provider aggregate for any host a member of that group is on and then when scheduling others you'd say !in for any other provider aggregate that represents other hosts in the group that has members, maybe - or not, it's all confusing and a tangent to what i'm trying to solve | |
| 19:57:45 | efried | it's, like, a tautological impossibility. | |
| 19:58:46 | mriedem | well, saying "no never because we can't ever" and "because GET /a_c doesn't have some semantics today" is a conflict, but sure | |
| 19:58:50 | mriedem | i agree today it's not possible | |
| 19:59:33 | mriedem | anyway, that's kind of why i didn't really want to put a bunch of words in a comment in os-traits about the state of how things are done between nova and placement today | |
| 19:59:38 | mriedem | it's super duper tight coupling | |
| 20:00:04 | efried | it's tight coupling between os-traits and placement, not anything and nova. | |
| 20:00:25 | mriedem | efried: if you're asking for a comment about why the trait can't be used in GET /a_c then that seems like something that should go in the nova change that's using the trait | |
| 20:00:40 | mriedem | because that is the code that would eventually be changed, not where the trait lives in os-traits | |
| 20:00:55 | mriedem | i mean, if you're asking about a reminder to yourself if someone tries to do this some day | |
| 20:01:00 | efried | that would also be good. | |
| 20:02:08 | eandersson | This RabbitMQ issue is so weird. | |
| 20:02:22 | eandersson | The compute queues only are getting messages, but they are staying as un'ackd. | |
| 20:02:57 | sean-k-mooney | eandersson: have you restarted the nova compute agent | |
| 20:03:00 | eandersson | We suspect RabbitMQ still, but it's weird that it is only affectin compute. | |
| 20:03:21 | eandersson | Yea sean-k-mooney they are kept as unac'kd even after restarting the agent. So for sure a RabbitMQ issue, but don't know what triggers it. | |
| 20:03:29 | efried | mriedem: responded x2 | |
| 20:03:33 | mriedem | efried: so to recap, what i'd like to do is (1) remove the mention from the os-traits commit message about eventually doing GET /a_c or whatever, (2) *not* leave a coupled comment next to the trait, and instead (3) put a comment about that in the nova patch https://review.opendev.org/#/c/695220/ | |
| 20:03:57 | efried | mriedem: (2) do leave a comment, (3) do put a comment. | |
| 20:04:00 | efried | They're different comments | |
| 20:04:27 | sean-k-mooney | eandersson: oh ok so its not the issue where the compute agent does not recreate the topic queue if the rabbmq server goes offline | |
| 20:05:11 | sean-k-mooney | eandersson: im not sure what that issue is then | |
| 20:05:55 | efried | (2) I suggested in the os-traits patch, just talks about GET /a_c. (3) should have your specific libvirt scenario described | |
| 20:07:56 | openstackgerrit | Matt Riedemann proposed openstack/os-traits master: Add COMPUTE_SAME_HOST_COLD_MIGRATE trait https://review.opendev.org/666604 | |
| 20:08:06 | mriedem | done | |
| 20:09:35 | mriedem | artom: dansmith: shall i just abandon the backportable workaround option that is https://review.opendev.org/#/c/676022/ and focus on the trait-based master-only solution to the extremely latent bug? | |
| 20:09:47 | mriedem | if it's this latent people obviously don't care enough so backports are a meh to me at this point | |
| 20:09:57 | efried | mriedem: +2, thanks for bearing with me. | |
| 20:10:05 | mriedem | same | |
| 20:12:35 | dansmith | mriedem: sounds like that would sidestep the whole argument, so.. yes? | |
| 20:13:33 | efried | It's got a bug heat of 32 fwiw. | |
| 20:13:50 | efried | Multiple people commented on it over the almost-2y it's been open. | |
| 20:14:02 | efried | so having a backportable solution doesn't seem like a terrible idea to me. | |
| 20:14:16 | efried | but I need to relook at how ugly it is. | |
| 20:14:45 | mriedem | i've abandoned | |
| 20:14:51 | mriedem | people can cherry pick it downstream if they really need it | |
| 20:14:58 | efried | okay | |
| 20:15:38 | efried | mriedem: I guess you're going to rebase and clean up the other one now, so I should wait to review? | |
| 20:16:01 | efried | yeah | |
| 20:16:14 | mriedem | i'm not going to get to that today but it won't be much different | |
| 20:16:25 | mriedem | probably crank it out in the wee morn | |
| 20:16:34 | efried | I didn't open any of the files, but the commit message at least needs an overhaul. | |
| 20:17:12 | mriedem | ubetcha | |
| 20:17:48 | efried | okay, let's see if I can think clearly enough to get back to rg/rp mappings... | |
| 20:18:46 | efried | mriedem: if you're feeling magnanimous, you could hit the bottom three patches here, fairly simple: https://review.opendev.org/#/c/696418/ | |
| 20:19:34 | mriedem | oh god request groups | |
| 20:19:45 | mriedem | i think melwitt said she wanted to learn more about this part of the code | |
| 20:19:49 | efried | hahaha | |
| 20:20:17 | efried | In my IRC client, melwitt shows up a nice grasshopper green. Coincidence? | |
| 20:21:23 | mriedem | as in the kung fu grasshopper pupil green? | |
| 20:21:45 | mriedem | or the "oh god request groups, i think i'm going to be sick" green | |
| 20:32:21 | mriedem | gibi: a few nits in https://review.opendev.org/#/c/696245/ if you want to start a FUP patch for that series | |
| 20:34:17 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use provider mappings from Placement (mostly) https://review.opendev.org/696992 | |
| 21:00:27 | efried | meeting now | |
| 21:14:10 | efried | mriedem: The vote in the meeting was unanimous: do a spec for the ironic owner filter | |
| 21:14:17 | efried | (unanimous: both of us) | |
| 21:14:54 | sean-k-mooney | im not sure i normally get a vote so it was also unilatreral | |
| 21:15:26 | sean-k-mooney | but close enough | |
| 21:16:54 | efried | We don't really vote officially on things like that anyway, so it was all opinion | |
| 21:16:58 | efried | and you know what they say about opinions. | |
| 21:17:47 | sean-k-mooney | :) as an fyi i will be going on vacation in about a week so im going to rebase the two feature im trying to get merged into a chain since they will conflict if i dont | |
| 21:20:09 | sean-k-mooney | for what its worth of the two option i kind of prefer the tradtional filter for filtering nodes by owner | |
| 21:21:26 | sean-k-mooney | if we did it a placemnt way i woudl thing an aggreate feel more natual for grouping RP the a custom trait | |
| 21:22:27 | sean-k-mooney | anyway that is just my gut reaction so i have not really tought about it much | |
| 21:27:27 | efried | sean-k-mooney: we've already established that a trait won't work without hackitude. | |
| 21:27:59 | sean-k-mooney | ack ya noticed the comment form mriedem after i wrote that | |
| 21:52:44 | efried | dansmith: TypeError: Object of type 'datetime' is not JSON serializable | |
| 21:52:52 | efried | This on a cast of prep_resize | |
| 21:53:04 | efried | The payload appears to have datetime.datetime objects in the image meta | |
| 21:53:24 | efried | what's odd is, this wasn't failing before I changed something in a totally different place | |
| 21:54:49 | dansmith | efried: nothing obvious, other than that oslo.serialization has some quiet handling of that | |
| 21:55:07 | dansmith | and there was also some proposed change recently specifically about that, but I think we determined it wasn't going to be a problem | |
| 21:57:39 | efried | that's pretty bizarre | |
| 21:57:52 | dansmith | what is? | |
| 21:58:10 | efried | Is it possible this stack trace is a red herring and the problem is really somewhere else? | |
| 21:58:42 | dansmith | isn't that pretty much always a true statement? :) | |
| 22:08:53 | melwitt | mriedem, efried: lol, you rascals (just read the mentions about request groups) | |
| 22:09:19 | efried | you got ToRed | |
| 22:09:23 | efried | as my father would say | |
| 22:09:30 | efried | (Transfer of Responsibility) | |
| 22:14:54 | efried | dansmith: I think my venv might have just been out of date. Repro'd same result against master. Rebuilding... | |
| 22:16:09 | efried | yuh, that cleared it up. | |
| 22:17:51 | sean-k-mooney | stale pyc files | |
| 22:17:56 | sean-k-mooney | maybe | |
| 22:18:15 | sean-k-mooney | still an odd error | |
| 22:18:17 | efried | no, don't we get bad magic number when that happens? In this case I'm betting it was a downrev of oslo.serialization or similar. | |
| 22:18:31 | efried | don't care enough to track it down exactly. | |
| 22:43:42 | openstackgerrit | Eric Fried proposed openstack/nova master: Use provider mappings from Placement (mostly) https://review.opendev.org/696992 | |
| 22:44:50 | efried | mriedem, dansmith, sean-k-mooney, gibi, stephenfin: I think this is done ^ | |
| 22:44:50 | efried | It uses placement 1.34 to get rid of the hack where we were calculating mappings based on allocations, in all code paths except revert_resize. | |
| 22:45:52 | efried | and knocks down another two microversions in the parity gap. | |
| 22:53:21 | sean-k-mooney | oh thi si sremoving the code we had on the nova side to compute that and using the info returned form placement correct | |
| 22:54:24 | efried | yeah, unfortunately it doesn't remove the code yet, cause it's still needed by revert_resize. Haven't figure out how we're going to fix that yet. Maybe I leave that to gibi :P | |
| 22:54:50 | sean-k-mooney | will we need to keep it for upgrade too? | |
| 22:54:53 | sean-k-mooney | for n-1 | |
| 22:55:19 | efried | I wouldn't have thought so. The data is identical (for existing use cases), just the method of computing that changed. | |
| 22:55:34 | efried | We no longer support downrev placements, you gotta upgrade placement first. | |
| 22:56:13 | sean-k-mooney | sure but did we ever need to look this up on the compute node or was it only used in the schduler | |