| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-26 | |||
| 13:59:52 | mriedem | that also allows people to opt out if they dont' have the kernel fix | |
| 14:07:46 | dansmith | efried: kashyap: I know we've strayed a bit, but I always wanted the workarounds to be booleans that all default to False, opting into different behavior, not multi-value tunables | |
| 14:08:04 | dansmith | efried: kashyap: so enable_old_memory_somethingorother=True if they need the old behavior or whatever it is | |
| 14:08:37 | dansmith | setting some regular-looking conf tunable to some value is less like a workaround and more like ... config | |
| 14:09:17 | efried | Yeah, I'm not totally convinced this should be a [workaround] in the first place -- perhaps it should be an actual conf opt. | |
| 14:10:11 | dansmith | if it's actually a conf thing (setting to some value) then not a workaround, IMHO | |
| 14:10:30 | dansmith | but if it's "I don't have a modified kernel to fix X" then that can be true/false | |
| 14:11:13 | efried | Either way, the opt is for someone who understands the issue, and (IMO) it's an unnecessary extra step making them understand how True/False maps to "prefer"/"strict". But meh, not going to put in my mouthguard for this one. | |
| 14:11:52 | efried | I don't understand enough about the issue to know whether there's a chance this will need to be worked around at all / some nontrivial percentage of the time or for how long. | |
| 14:11:58 | dansmith | sounds like it's config and not really a workaround then, which is fine | |
| 14:14:34 | bauzas | gibi: /me scratches his head when he sees a lot of good helper methods https://github.com/openstack/nova/blob/master/nova/tests/functional/integrated_helpers.py#L582 and the likes | |
| 14:15:38 | bauzas | gibi: I'll passing a new revision today or tomorrow for https://review.opendev.org/#/c/670112 but please tell me whether we could use the above $ | |
| 14:15:39 | bauzas | ^ | |
| 14:31:50 | kashyap | dansmith: Hiya, just back. Reading your / Eric's remarks | |
| 14:32:42 | kashyap | dansmith: Yeah, I agree with your intention on a workaroud being: "a bool that makes it possible to opt-in to behaviour X". | |
| 14:33:35 | kashyap | efried: And yes, I'm still not convinced either to have a workaroud yet; however, making _everything_ configurable is not desirable either. "Death by a thousand config cuts" | |
| 14:36:07 | gibi | bauzas: I think you can use assertRequestMatchesUsage and the rest of the helpers. There are some limitations documented there about the structure though | |
| 14:36:13 | kashyap | efried: On the issue, the tl;dr is: today, if you boot a Nova instance on a NUMA host without a "DMA32" zone (one of the zones into which the kernel divides the memory) on the NUMA node, then your instance hard-fails to boot. | |
| 14:36:27 | kashyap | (And you can detect this "DMA32" thing by running `grep DMA /proc/zoneinfo` on the host.) | |
| 14:37:41 | kashyap | efried: And no, please remove that mouthguard - you _do_ make a good point: for someone to understand the mapping of bool to 'preferred'/'strict', it's needless gory details | |
| 14:38:11 | kashyap | I'll mull on it more and comment on the change. | |
| 14:38:23 | kashyap | Thanks for the input, both. | |
| 14:42:07 | mriedem | oh donnyd donnyd donnyd | |
| 14:42:12 | mriedem | you've opened a can of worms | |
| 14:42:29 | donnyd | Is it a good or bad can? | |
| 14:42:50 | donnyd | like fresh worms or worms that have been sitting in the sun for 3 weeks | |
| 14:44:11 | mriedem | moldy worms | |
| 14:44:33 | mriedem | i, of course, can't help but take that bait | |
| 14:44:38 | donnyd | LOL | |
| 14:45:11 | donnyd | Well they are just observations.. not saying anything is right, wrong.. indifferent.. | |
| 14:46:56 | mriedem | it's fun to see how the sausage gets made though huh | |
| 14:47:25 | donnyd | its quite interesting from my perspective - i have been building these things for quite a long time | |
| 14:47:27 | mriedem | fwiw every closed source project i worked on before openstack was also a clusterf*ck | |
| 14:47:46 | donnyd | openstack isn't a charlie foxtrot. | |
| 14:47:46 | mriedem | come release time anyway | |
| 14:47:56 | donnyd | I don't think that is the case at all... | |
| 14:48:04 | mriedem | the thing i mostly enjoy is the foundation marketing that says "20 release ON TIME" | |
| 14:48:16 | mriedem | *releases | |
| 14:48:19 | donnyd | I just think humans have a tendency to delay until they cannot anymore | |
| 14:48:31 | mriedem | yup, i noted that in my reply | |
| 14:48:34 | mriedem | and that's our MO here as well | |
| 14:49:37 | mriedem | and the squeeky wheel gets the grease... | |
| 14:49:51 | donnyd | that is a true story in literally all things | |
| 14:51:08 | mriedem | i've left some squeeky hinges in my house go ungreased out of spite | |
| 14:51:17 | donnyd | I also think nobody consumes the milestones because they are perceived to be "beta" | |
| 14:51:22 | mriedem | "gdi i *just* greased you" | |
| 14:52:03 | donnyd | and maybe changing around the perception would increase the consumption | |
| 14:52:12 | mriedem | at this point in the game i don't think that's likely | |
| 14:52:45 | mriedem | if anything, | |
| 14:52:54 | mriedem | people have wanted to consume at a much slower pace as time as gone on | |
| 14:53:03 | mriedem | hence all the demands for LTS branches and stuff | |
| 14:53:12 | donnyd | hence the 9 month major cycle | |
| 14:53:17 | donnyd | or even 12 month | |
| 14:53:23 | mriedem | blech | |
| 14:53:33 | mriedem | we'll just wait until the last minute to cram even less stuff in :) | |
| 14:53:55 | mriedem | and, | |
| 14:54:06 | mriedem | it will be double the shit that someone has to consumer and grok from the release notes when they do | |
| 14:54:12 | mriedem | *consume | |
| 14:54:48 | donnyd | how is that different from say an ubuntu or centos release though? | |
| 14:55:19 | donnyd | centos/rhel | |
| 14:56:08 | donnyd | Also thank you for replying | |
| 14:56:28 | mriedem | i can't say how those distro dev cycles are different, | |
| 14:56:33 | mriedem | but i imagine there much more strictly controlled | |
| 14:56:36 | mriedem | *they're | |
| 14:57:18 | mriedem | and when rhel i'm paying a support license so i expect more rigor before the thing is released than just "here it is, here are the release notes, have fun" | |
| 14:57:21 | mriedem | *with rhel | |
| 14:57:23 | mriedem | man i can't type today | |
| 14:58:22 | mriedem | i'm also not sure how moving from 6 to 12 months cycles would go over with someone like vexxhost that does actually do proper CI/CD and doesn't wait 18 months before upgrading | |
| 14:58:39 | mriedem | kashyap: sure, whatever - "pay for play" | |
| 14:59:05 | kashyap | I need to first load up on the topic being discussed. (I've got the -discuss list open, with Donny's email) | |
| 15:00:56 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/684407 | |
| 15:01:54 | kashyap | donnyd: That's indeed a barrel of worms; it was discussed to nauseating levels. See this epic thread from 2015: | |
| 15:02:05 | kashyap | donnyd: "Re-evaluating the suitability of the 6 month release cycle" -- https://openstack.nimeyo.com/34284/openstack-dev-evaluating-suitability-month-release-cycle | |
| 15:02:17 | kashyap | donnyd: Before you click that, go fill up your giant mug of tea, I say. | |
| 15:02:20 | donnyd | mriedem: but vexxhost could surely make use of more often . releases | |
| 15:02:34 | kashyap | It's a long and worthwhile read. (Especially "looking back") | |
| 15:03:10 | donnyd | well to be fair... that was 4 years ago | |
| 15:03:36 | kashyap | donnyd: To get the tl;dr of suggestion, see "The modest proposal" | |
| 15:03:42 | kashyap | [quote] | |
| 15:03:43 | kashyap | Based on these observations I would suggest that OpenStack aim to | |
| 15:03:44 | kashyap | This will have a number of consequences which I'd expect to be | |
| 15:03:44 | kashyap | ie do 6 releases a year. | |
| 15:03:44 | kashyap | switch to a development cycle that is exactly 2 months long. | |
| 15:03:46 | kashyap | beneficial to the project on balance. | |
| 15:03:48 | kashyap | [/quote] | |
| 15:04:29 | kashyap | donnyd: 4 years ago, but many things wrote there apply perfectly well today. | |
| 15:06:19 | donnyd | but 4 years ago our community was probably 2x the size it is now wasn't it? (i wasn't here, so i can't actually quantify that) | |
| 15:06:32 | mriedem | lyarwood: we have a few open stable/stein changes that we could get in before the next release but i think the biggest ticket one ends at https://review.opendev.org/#/c/684407/ since that resolves an upgrade issue introduced in stien | |
| 15:06:35 | mriedem | dansmith: ^ | |
| 15:07:03 | mriedem | donnyd: yes much bigger and much more diverse | |
| 15:07:04 | kashyap | donnyd: It _was_ larger; but shortening the cycle length applies even today. | |
| 15:07:27 | kashyap | donnyd: It reduces the: "hey, our distro is gonna be based on X upstream release, we _must_ shove our feature upstream in time!" | |
| 15:07:41 | kashyap | s/distro/"long-term OpenStack distro"/ | |
| 15:07:54 | kashyap | (Among other things) | |
| 15:08:24 | donnyd | for the record.. I am happy either way | |
| 15:13:22 | kashyap | donnyd: Nod; but yes, as both of you said, it's the "human nature" element. And "planning is guessing". Go a "six-month plan"? Call it a "six-month guess". | |
| 15:13:25 | kashyap | (https://m.signalvnoise.com/planning-is-guessing/) | |
| 15:14:51 | donnyd | right... "everyone has a plan until they get punched in the mouth" | |
| 15:14:57 | donnyd | - mike tyson | |
| 15:15:48 | donnyd | so wouldn't the message there be create smaller plans?? | |