| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-31 | |||
| 13:58:30 | bauzas | sean-k-mooney: changing our pep8 tool is a totally different effort than changing the limit | |
| 13:58:36 | sean-k-mooney | unless you have a 720p screen you can open two 90 char termins in a 1080 screen and still have space | |
| 13:58:51 | sean-k-mooney | bauzas: its not changing the pep8 tool by the way | |
| 13:58:59 | sean-k-mooney | its still using flake8 | |
| 13:59:00 | bauzas | sean-k-mooney: sorry I meant the formatter | |
| 13:59:22 | sean-k-mooney | but isnt of autopep8 which does minimal formating it would be black which does everything for you | |
| 13:59:58 | bauzas | sean-k-mooney: if black stays optional, I'm not opposed to it | |
| 14:00:12 | bauzas | sean-k-mooney: are you planning to make it a tox target ? | |
| 14:00:17 | sean-k-mooney | in terms of developer mental healt not having auto formating is defferntly bad for burn out | |
| 14:00:41 | sean-k-mooney | bauzas: it would have to be enforced in ci | |
| 14:00:47 | bauzas | well, I certainly had burnout conditions in the past that didn't occur because of the formatting... | |
| 14:00:48 | sean-k-mooney | otherwise there is no real point | |
| 14:01:21 | sean-k-mooney | i condiered stopping working on nova because of the effort required to get patches merged much of which was becasue of style considerations | |
| 14:01:45 | bauzas | a formatter wouldn't help, no ? | |
| 14:02:00 | sean-k-mooney | it would | |
| 14:02:13 | sean-k-mooney | auto fromating would remove debates of how to format thigns | |
| 14:02:19 | sean-k-mooney | its what the tool does and done | |
| 14:02:44 | bauzas | I'm certainly not one who debated the stylish things | |
| 14:03:16 | bauzas | for line limits, I'm not opposed to use either brackets or backslashes, eg. | |
| 14:03:24 | bauzas | or even local variables | |
| 14:03:41 | bauzas | at least, I could comment on it, but I'm not *opposed* to it | |
| 14:04:28 | bauzas | so, if you felt exhausted by those debates, I really feel your frustration and I think we should rather document the fact that we shouldn't enforce exact styling guidelines | |
| 14:05:00 | bauzas | yet again a code review issue and not a tool miss | |
| 14:05:10 | bauzas | (not saying pypià | |
| 14:05:10 | bauzas | (not saying pypià | |
| 14:05:13 | bauzas | ;) | |
| 14:20:22 | dansmith | sean-k-mooney: bauzas: the other day we were talking about something related to file-backed memory support in libvirt/nova | |
| 14:20:47 | dansmith | I don't remember for what, but I wrote something to get support started for the guy that added that support, which never got merged: https://review.opendev.org/c/openstack/devstack/+/574792 | |
| 14:21:00 | kashyap | sean-k-mooney: What is the "black default is 88"? | |
| 14:21:10 | dansmith | it just got some "is this still interesting" action recently, so... is it worth getting that merged? | |
| 14:21:19 | bauzas | kashyap: that means by default black generates lines of 88 chars | |
| 14:21:37 | bauzas | dansmith: reloading the context | |
| 14:21:39 | kashyap | I don't know what is "black" here. Maybe I'm being too dense | |
| 14:21:47 | bauzas | kashyap: https://pypi.org/project/black/ | |
| 14:22:02 | kashyap | Ah, it's a tool! | |
| 14:22:06 | kashyap | Thanks | |
| 14:23:34 | bauzas | kashyap: and there is blue, a fork of black https://pypi.org/project/blue/ | |
| 14:23:57 | bauzas | see, we diverted from a very interesting ping from dansmith | |
| 14:24:01 | kashyap | bauzas: Yeah, I recall seeing that in passing; th | |
| 14:24:01 | dansmith | black's coding style is so ugly | |
| 14:24:05 | kashyap | s/th/thx/ | |
| 14:24:09 | bauzas | dansmith: stay, please | |
| 14:24:26 | bauzas | I need to convince a few people here | |
| 14:25:29 | bauzas | dansmith: do you remember if we discuss the file-backed memory case in a meeting or somewhere else ? | |
| 14:25:51 | dansmith | bauzas: it was downstream in a meeting I think, I don't remember the context | |
| 14:25:57 | bauzas | hah | |
| 14:26:23 | bauzas | well, I'd say this is just a libvirt knob | |
| 14:26:34 | bauzas | so, to answer your question, worth merging yeah | |
| 14:26:39 | dansmith | aight | |
| 14:27:09 | dansmith | presumably we need a test case that uses/enables it | |
| 14:27:14 | bauzas | I like the 'you can't overcommit memory if you file-back your memory" ting | |
| 14:27:16 | dansmith | which probably existed as a depends-on to this somewhere | |
| 14:29:08 | bauzas | yeah, this is a very old patch | |
| 14:29:41 | bauzas | damn, needs to run, forgot my kid | |
| 14:33:20 | sean-k-mooney | dansmith: sorry in a meeting | |
| 14:34:15 | sean-k-mooney | dansmith: you were askign about file backed memory | |
| 14:34:29 | sean-k-mooney | dansmith: we have some support | |
| 14:34:51 | sean-k-mooney | dansmith: we dont support live migration between file backed and non file backed ectra | |
| 14:35:03 | dansmith | sean-k-mooney: I know, I worked on the support in nova with the original author :) | |
| 14:35:05 | sean-k-mooney | was there a specific question you had | |
| 14:35:16 | dansmith | sean-k-mooney: I also wrote this devstack support for him to finish, but that never happened | |
| 14:35:29 | sean-k-mooney | dansmith: no devstack support is required | |
| 14:35:29 | dansmith | so I'm wondering if I should abandon or finish this patch | |
| 14:35:46 | sean-k-mooney | dansmith: i manullay tested it when it was beeing merged :) | |
| 14:35:59 | sean-k-mooney | dansmith: the docs are curently wrong about needignto create a partion | |
| 14:36:22 | dansmith | sean-k-mooney: um | |
| 14:36:34 | dansmith | we have a conf flag for it, no? | |
| 14:36:46 | sean-k-mooney | yes | |
| 14:37:06 | sean-k-mooney | but you can set that with [[post-conf| $NOVA_CPU_CONF]] | |
| 14:37:08 | dansmith | ... | |
| 14:37:19 | sean-k-mooney | its what i have done every time i used that | |
| 14:37:26 | dansmith | sure, but also we need to enable it in libvirtd? or did at the time | |
| 14:37:28 | sean-k-mooney | and we dont want to mount the file backed memory on tempfs | |
| 14:37:32 | sean-k-mooney | no | |
| 14:37:37 | sean-k-mooney | you dont need to enable anything in libvirt | |
| 14:38:13 | dansmith | to what, end up with memory file-backed on your root disk? | |
| 14:38:35 | sean-k-mooney | yes that is how its ment to be used | |
| 14:38:43 | sean-k-mooney | the file is cached in ram using the hosts page cache | |
| 14:38:51 | dansmith | no, it's not.. or not how this feature was intended | |
| 14:39:01 | dansmith | the original author had a box that looked like a memory-backed filesystem over IB fabric or whatever, so they needed to configure libvirt to use that mount for the memory | |
| 14:39:28 | dansmith | so part of this was so they could actually configure a devstack to do that, and not stack, then configure and restart libvirt | |
| 14:39:28 | sean-k-mooney | dansmith: i was also raisign adding supprot for this for dpdk before that autro got there feature merged | |
| 14:40:00 | sean-k-mooney | dansmith: to be clear i brought up supporting filebacked memroy for dpdk and it was rejected | |
| 14:40:11 | sean-k-mooney | then later tehy brought it up for a security usecse and it was accpeted | |
| 14:40:19 | sean-k-mooney | file backed memmroy can use a file on disk | |
| 14:40:31 | sean-k-mooney | you dont need to do any config in libvirt | |
| 14:41:01 | dansmith | I understand you *can* but I'm not sure why you would, unless you have something very fast that looks like a disk, but isn't, in which case you'd need to tell libvirt where to put it specifically | |
| 14:41:18 | sean-k-mooney | dansmith: so that you can have more "ram" the system ram | |
| 14:41:24 | dansmith | but whatever, sounds like you think I should not finish this because we don't need it for CI testing specifically | |
| 14:41:45 | sean-k-mooney | i also dont think you shoudl deploy it in production on temfs | |
| 14:41:51 | dansmith | sean-k-mooney: right but "more ram a the speed of a disk" is not very useful | |
| 14:42:14 | sean-k-mooney | if your disk are fast optane ssd it is | |
| 14:42:14 | dansmith | the tempfs was so that it didn't generate IO in the workers | |
| 14:42:44 | sean-k-mooney | and as i said the host page cache also acclerates recently acccess part of the files | |
| 14:43:46 | sean-k-mooney | dansmith: are you working on addign file backed memory testing to ci by the way | |
| 14:43:54 | sean-k-mooney | or were you just automating it in devstack for local use | |
| 14:43:58 | dansmith | I'm not doing anything | |
| 14:44:20 | sean-k-mooney | oh i was confused by https://review.opendev.org/c/openstack/devstack/+/574792 but i guess matt was the last uploader | |
| 14:44:53 | sean-k-mooney | an it was revived 3 days ago | |
| 14:45:29 | sean-k-mooney | dansmith: sorry i was trying to figure out teh context of this | |