| *** tbachman_ is now known as tbachman | 03:53 | |
| gibi | bauzas: o/ There is a good chance that I have to be away from the keyboard during the team meeting today | 07:37 |
|---|---|---|
| gibi | stephenfin, sean-k-mooney[m]: your view would me much appreciated here https://review.opendev.org/c/openstack/nova/+/843443/1#message-ac73126bbaa46cbbccdccb15c4c6d28358a328fc | 08:07 |
| bauzas | elodilles: thanks for the nova-stable-maint additions ;) | 08:16 |
| bauzas | gibi: ack, no worries | 08:16 |
| elodilles | bauzas: np :) | 08:28 |
| sean-k-mooney2 | gibi: ah the autopep8 change. i intentionally did not put it in test-reqirements since others experessed that they wanted ti to be optional and not require autopep8 | 09:48 |
| *** sean-k-mooney2 is now known as sean-k-mooney | 09:49 | |
| sean-k-mooney | am | 09:49 |
| sean-k-mooney | so we could do as you suggest | 09:49 |
| sean-k-mooney | and move it there and pin | 09:49 |
| gibi | I affraid that we start listing deps in different palces | 09:49 |
| gibi | places | 09:49 |
| sean-k-mooney | or we could add it to global requirements and pin in upper-constraits | 09:49 |
| sean-k-mooney | gibi: now that devestack does not install test-requiremetns | 09:49 |
| gibi | I don't know if we track test only requirements in global | 09:50 |
| sean-k-mooney | its less of an issue with me to do that | 09:50 |
| sean-k-mooney | gibi: we have flake8 i think | 09:50 |
| sean-k-mooney | and pytest | 09:50 |
| gibi | noe flake is not in global but pytest is in global | 09:50 |
| sean-k-mooney | gibi: https://github.com/openstack/requirements/blob/master/global-requirements.txt#L396= | 09:50 |
| gibi | ohh cool | 09:51 |
| sean-k-mooney | so ya we have a section for test tools | 09:51 |
| gibi | then I would like to track autopep8 in global | 09:51 |
| sean-k-mooney | would you like me to add it with a patch | 09:51 |
| gibi | I can do it | 09:51 |
| gibi | I just wanted to make an agreement first | 09:52 |
| sean-k-mooney | ok i think that will be better longterm | 09:52 |
| gibi | yepp | 09:52 |
| sean-k-mooney | by the way on a related not stephenfin made an intersting point on the mailing list | 09:52 |
| sean-k-mooney | apprently we can now tell git blame to ignore commits | 09:53 |
| sean-k-mooney | so if i was to push a ptach to pre-commit normalis all the quotes for example | 09:53 |
| gibi | yepp I saw. I still think it will be a big debate to blackify nova | 09:53 |
| sean-k-mooney | we can tell git blame to ignore that | 09:53 |
| sean-k-mooney | oh i was not plannign to add black | 09:53 |
| sean-k-mooney | jus ta few more pre-comit hooks | 09:54 |
| sean-k-mooney | using black is an option i guess but i wanteed to avoid the linelenth debate | 09:54 |
| gibi | I'm a bit of all or nothing. as any normalization gives us the backport conflict so why not then do all the normalization at once | 09:54 |
| sean-k-mooney | and just make some small imporvements | 09:54 |
| gibi | black handles linelegth | 09:54 |
| gibi | you can ask it to restrict to 79 | 09:55 |
| sean-k-mooney | i would like to do all | 09:55 |
| sean-k-mooney | i really really wish we had auto code formating | 09:55 |
| gibi | -l, --line-length INTEGER How many characters per line to allow. | 09:55 |
| gibi | [default: 88] | 09:55 |
| gibi | what an insteresting default :) | 09:55 |
| sean-k-mooney | but i dont want to break people's workflow just for my comfort | 09:55 |
| sean-k-mooney | gibi: there was an articl on why that was chosen i think | 09:56 |
| sean-k-mooney | gibi: the issue is i dont think there is currently a way to set that in a file | 09:56 |
| gibi | yeah now that you said it | 09:56 |
| *** tbachman_ is now known as tbachman | 09:57 | |
| sean-k-mooney | oh the other hand i think have autoformating using any tool woudl improve new contibutor experince | 09:57 |
| sean-k-mooney | and all our live in the long run | 09:57 |
| gibi | I totally agree | 09:57 |
| gibi | I just want a single commit to reformat everything with a tool and then forget about it | 09:57 |
| gibi | gradual change will mean a lot of commit to ignore later | 09:58 |
| sean-k-mooney | yep same | 09:58 |
| * gibi goes to get something to eat | 09:59 | |
| sean-k-mooney | also https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length | 09:59 |
| sean-k-mooney | apprently it now follow the flak8 max-line-lenth | 09:59 |
| sean-k-mooney | which was missing for so long | 09:59 |
| gibi | I still use https://github.com/gibizer/zuul-log-search/blob/main/tox.ini#L30 | 09:59 |
| sean-k-mooney | yep we coudl do that but the disadvantage is | 10:00 |
| sean-k-mooney | it wont work for ides | 10:00 |
| sean-k-mooney | like vscode | 10:00 |
| sean-k-mooney | im using nano/emacs so not an issue for me personally i would be runnign black with precommit | 10:00 |
| sean-k-mooney | but ya go eat. i can wip up a patch if we want to consider it | 10:01 |
| sean-k-mooney | im not really show how it would look | 10:01 |
| gibi | ack | 10:01 |
| stephenfin | gibi: sean-k-mooney: If you do normalization, I see no reason not to apply that normalization to stable branches also | 11:43 |
| sean-k-mooney | hum we coudl i guess | 11:43 |
| gibi | including downstream? :) | 11:43 |
| sean-k-mooney | im just fixign a few long lines on a black patch | 11:43 |
| sean-k-mooney | gibi: it woudl get imported downstream if we did it upstream | 11:43 |
| sean-k-mooney | but also yes | 11:43 |
| gibi | sean-k-mooney: ahh good point | 11:44 |
| stephenfin | gibi: yeah, what sean-k-mooney says | 11:44 |
| stephenfin | I mean, in theory black's "slow" formatter checks to make sure the AST is identical before and after so there will be no functional differences | 11:44 |
| sean-k-mooney | yep that is true for the most part | 11:45 |
| sean-k-mooney | also its faster tehn autopep8 | 11:45 |
| sean-k-mooney | or flake8 | 11:45 |
| gibi | there will be a sh*tload of merge conflicts in open reviews but that is just one-time pain | 11:45 |
| gibi | and easy to resolve by rebase, run black, push | 11:46 |
| sean-k-mooney | the patch is pretty bix but the list of files where i actully need to make code chages by intoducing new varbailes is pretty small | 11:54 |
| sean-k-mooney | https://paste.opendev.org/show/be8e3ZYGZeIjFv8uOcvz/ | 11:54 |
| sean-k-mooney | well that or () to put things onto a new line | 11:54 |
| sean-k-mooney | black was able to handel almost all of it its slef but some of our mock names are kind of long | 11:55 |
| sean-k-mooney | over all the code is looking quite readable after the format | 11:57 |
| sean-k-mooney | stephenfin: you will like htat it seam to be quite close to your coding style already | 11:57 |
| stephenfin | sean-k-mooney: yeah, I've been slowly forcing myself to move to that style of late since it seems to be getting pretty widespread now | 11:59 |
| sean-k-mooney | same but mainly because of you | 11:59 |
| sean-k-mooney | to premempt you asking me to change things in nits :) | 11:59 |
| gibi | :) | 12:00 |
| sean-k-mooney | got to make you work harder for those -1 stats :) | 12:00 |
| gibi | sean-k-mooney: did you moved to 88 char line limit as the paster suggests? | 12:00 |
| sean-k-mooney | ya | 12:01 |
| sean-k-mooney | so the reason i did that is to mvoe to 79 with black | 12:01 |
| sean-k-mooney | i would need to add project.toml | 12:01 |
| sean-k-mooney | which i could do | 12:01 |
| sean-k-mooney | but that seam like an even bigger change | 12:01 |
| gibi | I would add -l 79 to the black command line as a stopgap | 12:01 |
| sean-k-mooney | once i have this passing for 88 i can add a scond commit for 79 | 12:01 |
| sean-k-mooney | if we want 79 we could sqaush them | 12:02 |
| sean-k-mooney | gibi: i have configured flak8 for 88 too in this patch | 12:03 |
| sean-k-mooney | so im not removing flak8 or hacking | 12:03 |
| sean-k-mooney | they will still enforce checks but im makign them compatibale with black | 12:03 |
| gibi | ahh I see | 12:03 |
| gibi | I'm OK with the two commit to review but I would like to squash before we merge | 12:03 |
| sean-k-mooney | yep so the reason im going to do two commits is 1 we can decide if we prefer one vs the other | 12:04 |
| sean-k-mooney | and two i know i will likely have to resolve more long nested calls for 79 | 12:04 |
| sean-k-mooney | i.e. obj.sub_obj.long_function_name.... | 12:05 |
| sean-k-mooney | our convention of mock_full_long_function_name.return_value.assert_called_once_with( | 12:06 |
| sean-k-mooney | sometimes is over 88 when all on one line | 12:06 |
| gibi | I see | 12:06 |
| sean-k-mooney | lol i just opend the libvirt driver unit test and emacs warned me of performance issues with large files | 12:09 |
| sean-k-mooney | to be fiar to ti it is 32k lines long | 12:10 |
| sean-k-mooney | we really do need to decompsoe the libvirt driver into more moduels and split up the unit test file eventually | 12:10 |
| sean-k-mooney | its just a lot of merge conflicts | 12:11 |
| sean-k-mooney | its one of those things that we just need to decide to do at teh end or start of a cycle | 12:12 |
| gibi | sean-k-mooney: I totally agree. pycharm simply dies on that file :D | 12:14 |
| sean-k-mooney | i dont know if im the only one that does this but one trick i have adopted recently for fixing pep8 issue is starting form the end fo the file and working backwards | 12:21 |
| sean-k-mooney | that way the earlier errors dont change line number | 12:21 |
| gibi | good idea :) | 12:22 |
| gibi | if we merge the black patch you can forget this trick :) | 12:22 |
| sean-k-mooney | hehe mostly true | 12:22 |
| sean-k-mooney | self.task.compute_rpcapi.finish_revert_snapshot_based_resize_at_source.assert_called_once_with( | 12:22 |
| sean-k-mooney | that is an example of something it cant fix | 12:23 |
| opendevreview | ribaudr proposed openstack/python-novaclient master: Microversion 2.91: Support specifying destination host to unshelve https://review.opendev.org/c/openstack/python-novaclient/+/831651 | 12:24 |
| sean-k-mooney | i am manually fixign those like this | 12:24 |
| sean-k-mooney | mock_finish_at_source = ( | 12:24 |
| sean-k-mooney | self.task.compute_rpcapi.finish_revert_snapshot_based_resize_at_source | 12:24 |
| sean-k-mooney | ) | 12:24 |
| sean-k-mooney | mock_finish_at_source.assert_called_once_with( | 12:25 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 12:40 |
| opendevreview | Balazs Gibizer proposed openstack/osc-placement master: Support microversion 1.39 https://review.opendev.org/c/openstack/osc-placement/+/828545 | 12:47 |
| opendevreview | Balazs Gibizer proposed openstack/osc-placement master: Support microversion 1.39 https://review.opendev.org/c/openstack/osc-placement/+/828545 | 12:48 |
| Uggla | sean-k-mooney, pep8 from the end of file, good idea. | 12:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Add service version check workaround for FFU https://review.opendev.org/c/openstack/nova/+/831174 | 12:50 |
| Uggla | gibi, a black patch ? To get rid of formatting ? | 12:51 |
| gibi | Uggla: yepp | 12:51 |
| sean-k-mooney | well more make a tool do it | 12:52 |
| Uggla | gibi, oh, that will be really cool. | 12:52 |
| * sean-k-mooney likes the irony of spending 90mins manually formating stuff black cant so we could use black to format code | 12:53 | |
| gibi | sean-k-mooney: even the best hero needs help from a sidekick \ | 12:54 |
| sean-k-mooney | one thing i dont like but i dont see a way to avoid is i have to #noqa: E501 lambdas | 13:00 |
| sean-k-mooney | i.e. if a lamda defition does not fit on one line i have to ignore the line lenght | 13:01 |
| sean-k-mooney | since there is not a valid way to break it up that black wont undo | 13:01 |
| sean-k-mooney | there might be a config setting i could tweak in a followup but for now im just ignoring the lenght check in that specific case | 13:02 |
| sean-k-mooney | the other option is to allow lamdas to be named but we block that currently | 13:03 |
| sean-k-mooney | so i cant just pull it out into a varible or similar | 13:03 |
| sean-k-mooney | and pulling them out into private fucntiosn is more then i want to do in this patch | 13:03 |
| sean-k-mooney | im really trying to keep the manual changes as small as possible | 13:04 |
| sean-k-mooney | we can always go back and fix that later by looking for the #noqa comments | 13:04 |
| gibi | yeah, I think the official suggestion is that if it does not fit into a line then it should be def | 13:07 |
| gibi | but I agree not do change everything in one go | 13:08 |
| *** whoami-rajat__ is now known as whoami-rajat | 13:42 | |
| bauzas | sean-k-mooney: gibi: fwiw, I loudly replied to the E501 thread | 13:44 |
| bauzas | tl:dr: this is a at least a bikeshed and maybe a pandora box that will generate a lot of efforts for something needless | 13:45 |
| opendevreview | Merged openstack/nova stable/ussuri: [CI] Install dependencies for docs target https://review.opendev.org/c/openstack/nova/+/839813 | 13:45 |
| sean-k-mooney | bauzas: perhaps but im still going to finish my nova black patch | 13:48 |
| sean-k-mooney | bauzas: dealing with formating it perhaps the thing i hate most about working on nova other then the dowstream paperwork | 13:49 |
| bauzas | sean-k-mooney: take it as you wish, but I won't accept any change touching this limit | 13:50 |
| bauzas | this will also break style consistency between projects and some people using terms with 80 chars will see a difference | 13:50 |
| bauzas | while the other way is just because people feel useless to have 80 chars on a 1440 display | 13:51 |
| bauzas | this is maybe useless, but changing the default has a cost I'm not ready to pay | 13:51 |
| bauzas | and I wish our contributor energy would be better used to some other things but just a stylish nitty modification | 13:52 |
| bauzas | pro-tip : 80-char limit allows you to open multiple files in parallel, that being said | 13:52 |
| bauzas | btw. sean-k-mooney you wanted me to review some os-vif changes | 13:54 |
| bauzas | that looks to me better use of my worktime | 13:54 |
| sean-k-mooney | bauzas: i can reduce it down to 79 then and keep the limit | 13:56 |
| sean-k-mooney | the black defaul is 88 | 13:57 |
| sean-k-mooney | which works fine even on 1080 screesn or my phone | 13:57 |
| sean-k-mooney | which is actully 1080 on landscpae so i guess thats the same | 13:57 |
| bauzas | sean-k-mooney: changing our pep8 tool is a totally different effort than changing the limit | 13:58 |
| 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 |
| sean-k-mooney | bauzas: its not changing the pep8 tool by the way | 13:58 |
| sean-k-mooney | its still using flake8 | 13:58 |
| bauzas | sean-k-mooney: sorry I meant the formatter | 13:59 |
| sean-k-mooney | but isnt of autopep8 which does minimal formating it would be black which does everything for you | 13:59 |
| bauzas | sean-k-mooney: if black stays optional, I'm not opposed to it | 13:59 |
| bauzas | sean-k-mooney: are you planning to make it a tox target ? | 14:00 |
| sean-k-mooney | in terms of developer mental healt not having auto formating is defferntly bad for burn out | 14:00 |
| sean-k-mooney | bauzas: it would have to be enforced in ci | 14:00 |
| bauzas | well, I certainly had burnout conditions in the past that didn't occur because of the formatting... | 14:00 |
| sean-k-mooney | otherwise there is no real point | 14:00 |
| 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 |
| bauzas | a formatter wouldn't help, no ? | 14:01 |
| sean-k-mooney | it would | 14:02 |
| sean-k-mooney | auto fromating would remove debates of how to format thigns | 14:02 |
| sean-k-mooney | its what the tool does and done | 14:02 |
| bauzas | I'm certainly not one who debated the stylish things | 14:02 |
| bauzas | for line limits, I'm not opposed to use either brackets or backslashes, eg. | 14:03 |
| bauzas | or even local variables | 14:03 |
| bauzas | at least, I could comment on it, but I'm not *opposed* to it | 14:03 |
| 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:04 |
| bauzas | yet again a code review issue and not a tool miss | 14:05 |
| bauzas | (not saying pypià | 14:05 |
| bauzas | ;) | 14:05 |
| dansmith | sean-k-mooney: bauzas: the other day we were talking about something related to file-backed memory support in libvirt/nova | 14:20 |
| 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:20 |
| kashyap | sean-k-mooney: What is the "black default is 88"? | 14:21 |
| dansmith | it just got some "is this still interesting" action recently, so... is it worth getting that merged? | 14:21 |
| bauzas | kashyap: that means by default black generates lines of 88 chars | 14:21 |
| bauzas | dansmith: reloading the context | 14:21 |
| kashyap | I don't know what is "black" here. Maybe I'm being too dense | 14:21 |
| bauzas | kashyap: https://pypi.org/project/black/ | 14:21 |
| kashyap | Ah, it's a tool! | 14:22 |
| kashyap | Thanks | 14:22 |
| * kashyap still uses 72-column width personally, like a brute creature | 14:22 | |
| bauzas | kashyap: and there is blue, a fork of black https://pypi.org/project/blue/ | 14:23 |
| bauzas | see, we diverted from a very interesting ping from dansmith | 14:23 |
| * bauzas needs to click again | 14:24 | |
| kashyap | bauzas: Yeah, I recall seeing that in passing; th | 14:24 |
| dansmith | black's coding style is so ugly | 14:24 |
| * dansmith runs | 14:24 | |
| kashyap | s/th/thx/ | 14:24 |
| bauzas | dansmith: stay, please | 14:24 |
| bauzas | I need to convince a few people here | 14:24 |
| bauzas | dansmith: do you remember if we discuss the file-backed memory case in a meeting or somewhere else ? | 14:25 |
| *** mfo is now known as Guest830 | 14:25 | |
| *** mfo_ is now known as mfo | 14:25 | |
| dansmith | bauzas: it was downstream in a meeting I think, I don't remember the context | 14:25 |
| bauzas | hah | 14:25 |
| bauzas | well, I'd say this is just a libvirt knob | 14:26 |
| bauzas | so, to answer your question, worth merging yeah | 14:26 |
| dansmith | aight | 14:26 |
| dansmith | presumably we need a test case that uses/enables it | 14:27 |
| bauzas | I like the 'you can't overcommit memory if you file-back your memory" ting | 14:27 |
| dansmith | which probably existed as a depends-on to this somewhere | 14:27 |
| bauzas | yeah, this is a very old patch | 14:29 |
| bauzas | damn, needs to run, forgot my kid | 14:29 |
| sean-k-mooney | dansmith: sorry in a meeting | 14:33 |
| sean-k-mooney | dansmith: you were askign about file backed memory | 14:34 |
| sean-k-mooney | dansmith: we have some support | 14:34 |
| sean-k-mooney | dansmith: we dont support live migration between file backed and non file backed ectra | 14:34 |
| dansmith | sean-k-mooney: I know, I worked on the support in nova with the original author :) | 14:35 |
| sean-k-mooney | was there a specific question you had | 14:35 |
| dansmith | sean-k-mooney: I also wrote this devstack support for him to finish, but that never happened | 14:35 |
| sean-k-mooney | dansmith: no devstack support is required | 14:35 |
| dansmith | so I'm wondering if I should abandon or finish this patch | 14:35 |
| sean-k-mooney | dansmith: i manullay tested it when it was beeing merged :) | 14:35 |
| sean-k-mooney | dansmith: the docs are curently wrong about needignto create a partion | 14:35 |
| dansmith | sean-k-mooney: um | 14:36 |
| dansmith | we have a conf flag for it, no? | 14:36 |
| sean-k-mooney | yes | 14:36 |
| sean-k-mooney | but you can set that with [[post-conf| $NOVA_CPU_CONF]] | 14:37 |
| dansmith | ... | 14:37 |
| sean-k-mooney | its what i have done every time i used that | 14:37 |
| dansmith | sure, but also we need to enable it in libvirtd? or did at the time | 14:37 |
| sean-k-mooney | and we dont want to mount the file backed memory on tempfs | 14:37 |
| sean-k-mooney | no | 14:37 |
| sean-k-mooney | you dont need to enable anything in libvirt | 14:37 |
| dansmith | to what, end up with memory file-backed on your root disk? | 14:38 |
| sean-k-mooney | yes that is how its ment to be used | 14:38 |
| sean-k-mooney | the file is cached in ram using the hosts page cache | 14:38 |
| dansmith | no, it's not.. or not how this feature was intended | 14:38 |
| 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 |
| 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 |
| sean-k-mooney | dansmith: i was also raisign adding supprot for this for dpdk before that autro got there feature merged | 14:39 |
| sean-k-mooney | dansmith: to be clear i brought up supporting filebacked memroy for dpdk and it was rejected | 14:40 |
| sean-k-mooney | then later tehy brought it up for a security usecse and it was accpeted | 14:40 |
| sean-k-mooney | file backed memmroy can use a file on disk | 14:40 |
| sean-k-mooney | you dont need to do any config in libvirt | 14:40 |
| 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 |
| sean-k-mooney | dansmith: so that you can have more "ram" the system ram | 14:41 |
| dansmith | but whatever, sounds like you think I should not finish this because we don't need it for CI testing specifically | 14:41 |
| sean-k-mooney | i also dont think you shoudl deploy it in production on temfs | 14:41 |
| dansmith | sean-k-mooney: right but "more ram a the speed of a disk" is not very useful | 14:41 |
| sean-k-mooney | if your disk are fast optane ssd it is | 14:42 |
| dansmith | the tempfs was so that it didn't generate IO in the workers | 14:42 |
| sean-k-mooney | and as i said the host page cache also acclerates recently acccess part of the files | 14:42 |
| sean-k-mooney | dansmith: are you working on addign file backed memory testing to ci by the way | 14:43 |
| sean-k-mooney | or were you just automating it in devstack for local use | 14:43 |
| dansmith | I'm not doing anything | 14:43 |
| 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 |
| sean-k-mooney | an it was revived 3 days ago | 14:44 |
| sean-k-mooney | dansmith: sorry i was trying to figure out teh context of this | 14:45 |
| * artom doesn't care what, if any, code formatting tool we use, just don't have a single massive commit with 'black all teh coed!!1' | 14:52 | |
| artom | How to break git blame 101. | 14:52 |
| dansmith | I'm also not in favor of reformatting more code than is necessary during a change, because that also make history look like more was changed | 14:53 |
| artom | In fact, that argument would prevent us from ever switching to an automatic formatter, unless it can be smart enough to only touch code that's already being changed in a commit. | 14:53 |
| opendevreview | Merged openstack/placement stable/victoria: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/840767 | 14:58 |
| bauzas | dansmith: artom: sean-k-mooney: as I said, we can create a consensus in the documentation for explaining we should not have a specific styling guideline more than using https://github.com/openstack/nova/blob/master/nova/hacking/checks.py | 15:08 |
| bauzas | so, we wouldn't need to have the black formatter | 15:08 |
| bauzas | that said, | 15:09 |
| bauzas | nova meeting in 50 mins now here | 15:09 |
| sean-k-mooney | bauzas: sure but i think that is a wrong thing fore the heal of the project longterm | 15:11 |
| elodilles | bauzas: may i update the wiki (stable section)? or do you want to do it by yourself? | 15:24 |
| bauzas | elodilles: feel free to do it, I'm done | 15:37 |
| elodilles | bauzas: ack | 15:38 |
| elodilles | done | 15:40 |
| opendevreview | Merged openstack/os-vif master: Delete trunk bridges to avoid race with Neutron https://review.opendev.org/c/openstack/os-vif/+/841499 | 15:41 |
| bauzas | reminder: nova meeting in 13 min here. | 15:47 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue May 31 16:00:35 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | EHLO | 16:00 |
| elodilles | o/ | 16:00 |
| Uggla | qo/ | 16:00 |
| gmann | o/ | 16:01 |
| bauzas | not sure if gibi is around, but let's start to discuss (he told me he couldn't be in our meeting) | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 14 new untriaged bugs (-1 since the last meeting) | 16:03 |
| bauzas | thanks elodilles :) | 16:03 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (0 since the last meeting) in Storyboard for Placement | 16:03 |
| elodilles | o:) | 16:03 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
| bauzas | elodilles: do you want to discuss about some bug ? | 16:03 |
| elodilles | bauzas: nothing to discuss i think, | 16:03 |
| bauzas | cool | 16:03 |
| bauzas | thanks for the bug triage etherpad btw. | 16:04 |
| elodilles | i only triaged two bugs and they were more or less clear (or incomplete) | 16:04 |
| bauzas | nice | 16:04 |
| bauzas | so, after you, we're done with the roster | 16:04 |
| bauzas | if someone wants to triage, let me know now | 16:04 |
| bauzas | for next week | 16:05 |
| bauzas | ok, looks not | 16:05 |
| bauzas | then, let's rerun the roster :) | 16:06 |
| elodilles | ++ | 16:06 |
| bauzas | I'll be the next bug baton folk | 16:06 |
| bauzas | I can run it for two weeks if needed as I'll ask to not have a meeting next week | 16:06 |
| elodilles | i guess gibi is not here to object :) | 16:07 |
| bauzas | heh, I'll see him f2f next week | 16:08 |
| bauzas | so I could pass him the baton :p | 16:08 |
| elodilles | :) | 16:08 |
| bauzas | anyway | 16:08 |
| bauzas | #info Next bug baton is passed to bauzas | 16:08 |
| * bauzas has to run then | 16:08 | |
| bauzas | meh, joking | 16:09 |
| bauzas | next topic, then | 16:09 |
| bauzas | #topic Gate status | 16:09 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:09 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:09 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:09 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:09 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:09 |
| bauzas | all the jobs look good to me | 16:10 |
| bauzas | something to tell about the gate ? | 16:10 |
| bauzas | ok, looks not, continuing | 16:11 |
| bauzas | #topic Release Planning | 16:12 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:12 |
| bauzas | #info Zed-2 is in 6 weeks | 16:12 |
| bauzas | the tick is clicking | 16:12 |
| bauzas | I'll ask for a spec review day maybe in two weeks's meeting | 16:12 |
| bauzas | nothing to tell here, I'm slowing reviewing a few specs | 16:13 |
| bauzas | and oh, this reminds me to modify Launchpad for those accepted blueprints | 16:14 |
| * bauzas forgot to do it last week | 16:14 | |
| bauzas | anything to talk about specs, per say ? | 16:14 |
| bauzas | - | 16:15 |
| bauzas | #topic OpenInfra Summit | 16:16 |
| bauzas | #info bauzas, gibi and stephenfin will attend the summit (at least for those I know) | 16:16 |
| bauzas | so, then I have a question for those around | 16:16 |
| bauzas | shall we cancel next week's meeting ? | 16:16 |
| bauzas | I have a vote ! | 16:16 |
| bauzas | #startvote Cancel Nova meeting next week ? (yes/no) | 16:16 |
| opendevmeet | Begin voting on: Cancel Nova meeting next week ? Valid vote options are , yes, no, . | 16:16 |
| opendevmeet | Vote using '#vote OPTION'. Only your last vote counts. | 16:16 |
| bauzas | #vote yes | 16:17 |
| elodilles | #vote yes | 16:17 |
| gmann | though I will travel but ok for me to cancel, | 16:17 |
| gmann | #vote yes | 16:17 |
| Uggla | #vote yes | 16:17 |
| gmann | *I will not travel | 16:17 |
| bauzas | gmann: you'll be missed | 16:17 |
| bauzas | I'll close the vote | 16:17 |
| bauzas | but, before this | 16:17 |
| bauzas | if someone wants run the meeting, he can | 16:18 |
| bauzas | this is just I'm not sure we'll have a quorum then | 16:18 |
| bauzas | let's end the vote | 16:18 |
| bauzas | #endvote | 16:18 |
| opendevmeet | Voted on "Cancel Nova meeting next week ?" Results are | 16:18 |
| opendevmeet | yes (4): Uggla, gmann, elodilles, bauzas | 16:18 |
| bauzas | so, | 16:19 |
| bauzas | I haven't seen interest by someone to run it, | 16:19 |
| bauzas | #agreed June 7th nova meeting is CANCELLED. | 16:19 |
| bauzas | I'll send an email accordingly | 16:19 |
| bauzas | one last point, if some people read our minutes, | 16:20 |
| bauzas | #info We'll provide a Nova meet-and-greet Operators feedback session on Wednesday, June 8, 2:50pm - 3:20pm. Operators are welcome. | 16:20 |
| bauzas | I can proxy any opinions or thoughts at the forum, btw. | 16:20 |
| bauzas | stick around on IRC, you could be pinged | 16:20 |
| gmann | bauzas: good idea. is there any etherpad i can add topic? | 16:21 |
| bauzas | gmann: I surely can create one | 16:22 |
| gmann | I would like to get soem feedback on SRBAC especially on scope thing | 16:22 |
| gmann | thanks, that will be great I will not be there but I think you can discuss it and I will add details in etherpad | 16:22 |
| bauzas | gmann: so you imagine some feedback etherpad, or rather some etherpad for adding notes before and remarks after ? | 16:22 |
| bauzas | ah, I see | 16:22 |
| gmann | bauzas: latter one | 16:22 |
| bauzas | gmann: this is an excellent idea, let's setup this | 16:23 |
| gmann | +1 | 16:23 |
| bauzas | gmann: I wish the Forum sessions would have their own etherpads tho | 16:23 |
| gmann | we are trying to get this topic for ope meetup also but getting per project feedback also will be great | 16:23 |
| gmann | bauzas: yeah, that also work, anywhere I can add this topic so that you remember it | 16:23 |
| bauzas | gmann: oh, you meant about operators feedback at our meet-and-greet ? gotcha. | 16:24 |
| gmann | yeah | 16:24 |
| bauzas | gmann: then, I'll start an etherpad and I'll discuss this with gibi as he co-hosts | 16:24 |
| gmann | thanks | 16:24 |
| bauzas | this is a good point, we have a few things we'd like operators to play witgh | 16:24 |
| bauzas | like the unified limits | 16:24 |
| gmann | indeed | 16:24 |
| bauzas | remember tho, operators play old versions, so they couldn't be that helpful | 16:25 |
| bauzas | but this is not a reason to ask | 16:25 |
| bauzas | to not* ask | 16:25 |
| gmann | yeah, just if we can get initial feedback what they think on these new things | 16:25 |
| bauzas | gotcha | 16:25 |
| bauzas | and brilliant idea | 16:25 |
| bauzas | gmann: you're doing my homework ! | 16:26 |
| gmann | :) | 16:26 |
| bauzas | ok, next topic, I guess ? | 16:26 |
| bauzas | looks so | 16:27 |
| bauzas | #topic Review priorities | 16:27 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | 16:27 |
| bauzas | #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there. | 16:27 |
| bauzas | #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have | 16:28 |
| bauzas | looks we found a consensus on my proposal for https://review.opendev.org/c/openstack/project-config/+/837595 | 16:28 |
| bauzas | sean-k-mooney: could you then please provide a new rev for it ? ^ | 16:29 |
| sean-k-mooney | ah i tought you were going to update it but sure | 16:30 |
| bauzas | sean-k-mooney: oh, I can do it | 16:31 |
| bauzas | #action bauzas to update https://review.opendev.org/c/openstack/project-config/+/837595 | 16:32 |
| bauzas | sean-k-mooney: no worries, I'll take it | 16:33 |
| bauzas | next topic then | 16:33 |
| bauzas | #topic Stable Branches | 16:33 |
| bauzas | elodilles: feel free to take the mic | 16:33 |
| elodilles | #info ussuri is unblocked, thanks to gmann's tempest pinning patches | 16:34 |
| bauzas | \o/ | 16:34 |
| gmann | yeah, and stable/victoria is also pinned with old tempest | 16:34 |
| elodilles | #info stable branches are now unblocked, but intermittent failures need further investigations. melwitt's tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:34 |
| elodilles | gmann: thanks! \o/ | 16:34 |
| gmann | took almsot 1 week to get all these merged | 16:34 |
| elodilles | :S | 16:34 |
| elodilles | #info placement's stable/branches are unblocked back till victoria (see melwitt's etherpad ^^^) | 16:34 |
| bauzas | \o/ agai, | 16:35 |
| gmann | cyborg-tempest plugin job which is non voting in nova gate also will be fixed by #link https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/843329 | 16:35 |
| elodilles | gmann: ack, thanks for that, too! | 16:36 |
| elodilles | (that's all from my side) | 16:36 |
| bauzas | :) | 16:36 |
| bauzas | greatly appreciated, thanks gmann | 16:36 |
| gmann | np! | 16:37 |
| bauzas | and thanks melwitt for the tracking | 16:37 |
| bauzas | moving on | 16:37 |
| bauzas | we have one last item | 16:37 |
| bauzas | #topic Open discussion | 16:37 |
| bauzas | (levy14) Discuss ability to call Barbican from inside VM without supplying credentials | 16:38 |
| bauzas | levy14: around ? | 16:38 |
| levy14 | yep | 16:38 |
| levy14 | was not around last week to put it on the agenda | 16:38 |
| bauzas | levy14: I'll be honest, I'm not sure we have quorum for discussing your point today, but we can try | 16:38 |
| levy14 | but my org would greatly benefit if any code in a vm could call barbican to fetch secrets. now there are secrets in code, in config files, injected but not properly handled. I'd like to get rid of that. | 16:39 |
| levy14 | without having to put the credentials in the code, I mean | 16:39 |
| levy14 | I see this as a big security improvement for users of nova | 16:40 |
| sean-k-mooney | i actuly see it as the opisite form a nova point of view | 16:40 |
| sean-k-mooney | is potentally a large security whole | 16:40 |
| sean-k-mooney | nova today almost excilulive does not handel any tenatn secrets | 16:41 |
| bauzas | yup, that's what we said | 16:41 |
| sean-k-mooney | nova or admins by default cannot retirve secrets form barbican | 16:41 |
| sean-k-mooney | only the user can | 16:42 |
| levy14 | I understand. but that forces users of nova to improvise. and it's not good what users do. the outcome is nasty. | 16:42 |
| sean-k-mooney | yep thats also true | 16:42 |
| levy14 | if there would be a feature to allow this specific use case, that would make life of nova users much better | 16:42 |
| sean-k-mooney | realisticaly the simpelte way to achive this today id via an external vender data service | 16:42 |
| sean-k-mooney | which could inject a bootstrap token via the metadta api | 16:43 |
| sean-k-mooney | simialr to how nova-join works https://opendev.org/x/novajoin#design | 16:43 |
| levy14 | the problem with that is that I cannot realitically get it implemented across the federation of sites we represent | 16:43 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/admin/vendordata.html | 16:43 |
| sean-k-mooney | levy14: what you are trying to achive is somethign simialr to k8s ablity to inject secrets into the pods right | 16:44 |
| sean-k-mooney | kubernets allows secreates to be injected via config maps or other mechanium such that the pod applciation can the interact with the k8s apis | 16:45 |
| sean-k-mooney | levy14: what you want is a way for nova instance to be able to bootstrap talkign to keystone/barbican | 16:45 |
| sean-k-mooney | so that they can programitacly get teh secretes that are stored there | 16:45 |
| levy14 | not necessarily. I would like a transparent mechanism. that watches for outgoing https reguests to barbican and adds a header with the auth to access the secrets. based on some form of vm identity | 16:45 |
| sean-k-mooney | levy14: nova does not controll the guest networking | 16:46 |
| sean-k-mooney | so such a serice woudl be outside our scope | 16:46 |
| levy14 | sean-k-mooney: they can do that today, if they inject a secret. but that needs them to properly tend and handle the secret with care. users don't care, they are sloppy. | 16:46 |
| sean-k-mooney | one posiablity but its a hack | 16:47 |
| sean-k-mooney | woudl be to take teh token we are invoked with and include it in the metadata | 16:47 |
| sean-k-mooney | that token would expire | 16:47 |
| sean-k-mooney | but it woudl be suffient for the app to bootsrap potenally by issueing an application credetial | 16:48 |
| levy14 | sean-k-mooney: it was just a suggestion. or a way to describe what I expect to happen, don't know which project implements it. I thought I bring it up in nova, as it seems some sort of vm identity is needed for it to work | 16:48 |
| sean-k-mooney | if you want the http request to be intercepted transparently you would need service function chaning or similar to implement that | 16:48 |
| sean-k-mooney | levy14: that the thing vms dont have an identiy | 16:49 |
| sean-k-mooney | they are owned by porjects | 16:49 |
| sean-k-mooney | secrets are owned by users | 16:49 |
| levy14 | sean-k-mooney: maybe they should start having one | 16:49 |
| sean-k-mooney | perhaps | 16:49 |
| levy14 | or secrets in barbican can be set up so that an entire project has access to them? | 16:49 |
| sean-k-mooney | im not sure but that would still not allow nova to access them | 16:50 |
| sean-k-mooney | services and cloud admins cannot acces barbican secrets | 16:50 |
| levy14 | so the possibilities are: | 16:50 |
| sean-k-mooney | that is doen intentiolly for improved security | 16:50 |
| levy14 | 1. metadata service | 16:51 |
| levy14 | 2. interception of network calls outgoing from a vm | 16:51 |
| sean-k-mooney | those are two possiblities yes | 16:52 |
| levy14 | any other? | 16:52 |
| sean-k-mooney | for 1 you would have to define what the metadata service will provide the vm | 16:52 |
| levy14 | and anyone sees this as a valuable feature for nova? | 16:53 |
| sean-k-mooney | 2 is not in scope of nova | 16:53 |
| sean-k-mooney | levy14: if it was done securly maybe. | 16:53 |
| sean-k-mooney | but i also see it as a non trivial feature | 16:53 |
| jrosser_ | i did some more looking at this after it was discussed ~ 1 week ago | 16:54 |
| levy14 | sean-k-mooney: I am sure is non-trivial | 16:54 |
| jrosser_ | and came to the same conclusion that there was no user associated with a VM so it was not possible to generate a usable token, even though it was possible to assert the identity of the vm | 16:54 |
| levy14 | sean-k-mooney: but I see it very valuable to have | 16:55 |
| bauzas | timebox : we only have 5 mins left | 16:55 |
| sean-k-mooney | levy14: do you feel comfortable wrting a spec propsoal even an incomplete one with your usecases | 16:55 |
| sean-k-mooney | levy14: and or would you be able to implement this with our guidance | 16:56 |
| bauzas | yes, we should rather discuss this by a spec | 16:56 |
| levy14 | sean-k-mooney: I can try writing an (incomplete) spec, I am not up to implement it myself | 16:56 |
| sean-k-mooney | jrosser_: i could see us adding a --application-credetial or something to the api | 16:56 |
| sean-k-mooney | jrosser_: i.e. you precreate one and tell nova to pass it to the guest via the metadtaa service | 16:57 |
| jrosser_ | i think that spcifying a service user for a VM might be enough | 16:57 |
| jrosser_ | anyway this is a rabbit hole and i don't want to disrupt your meeting | 16:57 |
| bauzas | jrosser_: no worries, we don't have other discussions | 16:57 |
| bauzas | at least, looks to me we have a consensus : levy14 will provide an incomplet spec or a backlog one | 16:58 |
| bauzas | levy14: do you know about https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html ? | 16:58 |
| jrosser_ | tldr was that other $clouds let you associate a service user (thats already in your project) with that VM, and that combined with a JWT from the metadata to auth against keystone would give you a token for that service user | 16:59 |
| bauzas | anyway, we're at the last minute for our meeting | 16:59 |
| levy14 | I saw the page, seemed convoluted. next week I'm at openinfra, but for the week after that I'll try to create a spec. | 16:59 |
| sean-k-mooney | jrosser_: i think the closest thing to a service user we have in openstack in an application credential | 16:59 |
| bauzas | levy14: ok, then, we're done today | 17:00 |
| bauzas | thanks folks | 17:00 |
| bauzas | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Tue May 31 17:00:56 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.log.html | 17:00 |
| bauzas | sean-k-mooney: gibi: elodilles: fwiw, I'll be off tomorrow | 17:01 |
| elodilles | thanks o/ | 17:01 |
| elodilles | bauzas: ack | 17:01 |
| sean-k-mooney | bauzas: ack | 17:01 |
| sean-k-mooney | bauzas: for rest of week or you back thursday | 17:01 |
| bauzas | sean-k-mooney: no, only tomorrow | 17:19 |
| bauzas | I have a few appointments so I thought it was better to just take one day off | 17:19 |
| sean-k-mooney | bauzas: cool i did have one topic for the meeting but it can wait till next week | 17:20 |
| bauzas | sean-k-mooney: which meeting ? | 17:20 |
| bauzas | the upstream nova one ? | 17:20 |
| sean-k-mooney | the nova one | 17:20 |
| sean-k-mooney | ya | 17:20 |
| sean-k-mooney | we didnt have time anyway | 17:20 |
| bauzas | hah, we just said that we won't have a meeting next week | 17:21 |
| sean-k-mooney | but i had a previous downstream meeting that ran over | 17:21 |
| sean-k-mooney | oh well it can wai | 17:21 |
| sean-k-mooney | *wait | 17:21 |
| bauzas | sean-k-mooney: but if you want, you can run the meeting | 17:21 |
| sean-k-mooney | its not urgent | 17:21 |
| sean-k-mooney | no its fine i just wanted input on a patch | 17:21 |
| bauzas | sean-k-mooney: this is just that gibi, stephenfin and me at least won't be around | 17:21 |
| sean-k-mooney | bauzas: ya no worreis i frogot summit was next week | 17:22 |
| sean-k-mooney | i was going to turn https://review.opendev.org/c/openstack/nova/+/842359 into a real patch with a release note | 17:22 |
| sean-k-mooney | but wanted to get input form other before i do | 17:22 |
| sean-k-mooney | i.e. is this somethign we want to do | 17:22 |
| sean-k-mooney | before i spend time on it | 17:22 |
| bauzas | hah | 17:23 |
| bauzas | no worries | 17:23 |
| bauzas | I understand your point and we can surely discuss this the other week | 17:24 |
| bauzas | sean-k-mooney: just add your topic in the agenda in order to not forget it | 17:24 |
| sean-k-mooney | sure will do | 17:25 |
| gibi | away | 17:58 |
| gibi | ehh | 17:58 |
| gibi | bauzas: I can take the triage baton next week over a beer :) | 18:02 |
| opendevreview | sean mooney proposed openstack/nova master: update nova to use black for code formating. https://review.opendev.org/c/openstack/nova/+/844120 | 18:36 |
| sean-k-mooney | i have run unit and functional test on that locally and they appear to pass so im pretty confident that there has been no effective code change in ^ | 18:42 |
| sean-k-mooney | black, pep8 and fast8 also pass and so does pre-commit | 18:43 |
| gibi | sean-k-mooney: thanks | 18:48 |
| sean-k-mooney | lol just realised it updated leet files 1337 | 18:48 |
| sean-k-mooney | in my somewhat biased opipion the code is more readable. im also not a black fangirl by any means its jut looks nicer to me | 18:49 |
| artom | Are "Cinder multi-backend feature disabled" a known thing on stable/victoria? | 18:58 |
| sean-k-mooney | am ping me tomorrow but im not sure what that means | 19:45 |
| sean-k-mooney | i assume that is a tempest config option | 19:45 |
| gmann | artom: it is enabled, it is enabled tempest-slow job and in cinder-tempest-lvm-multibackend which pass in victoria | 20:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!