Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-10-14
08:15:54 sean-k-mooney i can only do it with altgr because left alt is bound ot other things in vscode
08:17:09 sean-k-mooney oh no for me alt space is grabbed by kde
08:17:34 sean-k-mooney its the applicaton laucher
08:17:58 bauzas just created a new file
08:18:24 bauzas https://paste.opendev.org/show/btgI58rkgJvf4i6XkWcO/
08:18:33 bauzas I wasn't seeing any keys when catting
08:18:41 bauzas but lemme check the chars
08:19:00 sean-k-mooney do cat -vet nova/poc_wip.py
08:19:07 sean-k-mooney and you wil see the unicode
08:21:17 bauzas interesting https://paste.opendev.org/show/bd91pr4uhj1SrmkHRjry/
08:22:01 sean-k-mooney ya so M-BM-
08:22:10 sean-k-mooney is what a non breaking space looks like
08:22:30 bauzas lemme try with vim to write another file
08:23:05 sean-k-mooney there are plugins by the way for vscode to remove "irrgualar spaces"
08:23:24 sean-k-mooney this is apprently a common enough thing that people took the time to write one
08:23:42 sean-k-mooney i didnt want to recomend any specific one sicne i have never tested them or veted them
08:25:05 sean-k-mooney "Fix Irregular Whitespace" is the most downloaded one
08:25:28 bauzas can also reproduce it with vim
08:25:57 opendevreview Taketani Ryo proposed openstack/nova-specs master: Adjust the SEV/SEV-ES code for multiple cc support https://review.opendev.org/c/openstack/nova-specs/+/962578
08:26:00 bauzas so that's not an editor issue, definitely a keyboard mapping problem
08:27:35 bauzas oh fuck I found why
08:27:48 bauzas that's PEBKAC
08:28:01 bauzas I'm typing too fast so I wasn't releasing the altgr key when hitting space
08:28:32 bauzas so I was typing 'hashtag' (altgr-3) then 'alternative-mapping' (alt-gr space)
08:29:04 bauzas doh, I should set altgr-space to write a space
08:33:20 opendevreview Bogdan Dobrelya proposed openstack/nova master: Determine the device type from configuration first https://review.opendev.org/c/openstack/nova/+/963702
08:37:16 sean-k-mooney bauzas: ya that is what i was assuming and because you have # on altgr 3 unlike the rest of us where it etiehr does not hava modifyier or its shift 3
08:37:31 sean-k-mooney you are just more likely ot pres altgr space then the rest of us
08:40:13 bauzas yeah, I tested : shift-space produces a space, while altgr-space produces a non-visible combination of "M-BM- + space"
09:02:05 bauzas checked Gnome and my mapping is French (alt.) : confirmed that it hits nobreakspace
09:02:18 bauzas that probably changed in a fedora upgrade
09:09:31 bauzas changed my mapping to French, now it should be fixed
09:09:43 bauzas thanks all
09:42:54 opendevreview Bogdan Dobrelya proposed openstack/nova master: Determine the device type from configuration first https://review.opendev.org/c/openstack/nova/+/963702
11:23:09 tkajinam hmm it seems functional tests in osc-placement is failing due to a warning log added to placement recently https://bugs.launchpad.net/placement/+bug/2127848
11:24:01 tkajinam gibi, I wonder if that log should be really a warning or can it be debug ? https://opendev.org/openstack/placement/blame/commit/af09d65c3e24f214c43aebcb9cd069703ee87050/placement/objects/allocation_candidate.py#L827
11:35:39 tkajinam (by the way we should use warning instead of warn...
11:35:41 opendevreview Takashi Kajinami proposed openstack/placement master: Replace LOG.warn https://review.opendev.org/c/openstack/placement/+/963948
11:45:55 sean-k-mooney tkajinam: it depend on if its actionable or not
11:46:38 sean-k-mooney it proably shoudl be info level
11:47:08 sean-k-mooney with that said osc-placemetn shoudl not be asserting anyting related to placmenet logging
11:47:41 sean-k-mooney so this feels more like a osc placement bug in the test setup
11:48:31 sean-k-mooney the placemetn logs form the placemetn fixture shoudl be capsture in the est setup and filtered out of that assertion
11:49:31 sean-k-mooney in a real envonment that log woudl not be aviabel to the client
11:50:08 sean-k-mooney tkajinam: so the proper fix woudl be to install a log filter int eh osc-palcement functional tests i think to null route the placement logs
11:56:31 tkajinam sean-k-mooney, yeah I agree the issue and the lo level should be separate...
11:57:03 tkajinam sean-k-mooney, I looked into the logging setting but it looks tricky to me. the core problem is that the test does not use actual nova api but uses placement api fixture and filtering all placement logs mean we lost all api logs https://opendev.org/openstack/osc-placement/src/branch/master/osc_placement/tests/functional/base.py#L77
11:57:20 tkajinam the test does not use actual *placement* api, I mean
11:57:56 tkajinam maybe we could raise it to ERROR ?
12:00:33 sean-k-mooney tkajinam: correct we shoudl nto have access to any of the api logs in osc-placement
12:01:12 sean-k-mooney osc-placmenet is the openstack client plugin and in real code it will only have access to the api respocne not hte logs
12:01:15 tkajinam it may be correct for assertions but I'm a bit afraid of loosing debuggability in test failures
12:01:27 sean-k-mooney so if any test is relying on the logs then that test is invlaid
12:02:30 sean-k-mooney we can keep the logs for the fixture but we shoudl not be loging the placment logs to stdout or stderr in generall but we shoudl atttach teh logs to the test output
12:05:04 sean-k-mooney we can proably do somethign like this https://github.com/openstack/nova/blob/master/nova/config.py#L56-L89
12:05:39 sean-k-mooney add a log filt to the root loger that will intercept and redirect the logging else where but ill admit i have not tired
12:05:59 tkajinam ok
12:06:25 tkajinam let me give it some tries but I might just end up with bumping the log level filter to error
12:07:34 sean-k-mooney perhaps like this https://github.com/openstack/nova/blob/8b81b5f91ffe1f9c38a483d151b82316d443dbf6/nova/tests/fixtures/nova.py#L190-L199
12:08:09 sean-k-mooney we may be able ot patch where placmenet or the placment fixutrer setup up logging iwth our own funciton
12:08:47 sean-k-mooney tkajinam: i assume this is repoducable if we just clone master and run the tests?
12:09:03 tkajinam yup
12:09:16 tkajinam replace openstack-placement>=1.0.0 in tox.ini by git+https://opendev.org/openstack/placement#egg=openstack-placement
12:09:25 tkajinam so that it uses non-released version
12:09:39 tkajinam (that's what you need after clone, before tox -e functional
12:09:52 sean-k-mooney ack. ill see if i can play around with it locally too
12:09:55 sean-k-mooney tanks for reporting this
12:10:39 sean-k-mooney im on pto the rest of the week and i dont have too much time today so i cant promis ill make much progress but i have a littel time between meeting today
12:11:59 gibi tkajinam: that log will disappeare once we land a fix https://review.opendev.org/c/openstack/placement/+/962776 . I (wrongly) assumed that we will land the two patches close together so did not worried about the extra logs in the reproduce commit
12:13:15 sean-k-mooney gibi: well it found a bug as a result but that also a good pont it shoudl be resovle when the actual fix lands
12:14:53 gibi it was a log I added to prove that root cause of the bug
12:15:00 gibi it is not necessary in production
12:15:18 gibi I can spin up a patch that removes it independently from https://review.opendev.org/c/openstack/placement/+/962776
12:15:34 gibi so we can restore the sanity of the osc-placement's gate
12:17:13 gibi I did not load context on why osc-placement test depends on placmenet api logs. But that can be (and probably should be) fixed separately from unblocking the gate
12:19:21 tkajinam gibi, ah, thanks !
12:22:55 opendevreview Balazs Gibizer proposed openstack/placement master: Remove troubleshooting logs https://review.opendev.org/c/openstack/placement/+/963952
12:23:05 gibi sean-k-mooney: , tkajinam ^^
12:23:13 opendevreview Takashi Kajinami proposed openstack/osc-placement master: Filter out placement api logs in functional tests https://review.opendev.org/c/openstack/osc-placement/+/963953
12:24:14 tkajinam ^^^ sean-k-mooney gibi: this is the initial try to filter out these logs in osc-placement functional tests
12:24:18 tkajinam gibi, thanks !
12:25:50 gibi tkajinam: I'm OK with that. If CI is green then I think we can land your test setup fix
12:26:05 gibi that will probably land faster than my placement log removal patch
12:26:06 sean-k-mooney tkajinam: i think that is fine we could proably be more granular but im not oppose to that
12:27:07 tkajinam yeah we could probable filter more specific module but I tend to try with that wider filtering and see if that kills out life
12:27:16 tkajinam * our life
12:27:35 tkajinam my concern with narrow filtering is that we may face similar problems frequently in the future
12:28:48 tkajinam so far it worked in my local reproducer but let's see how CI passes...
12:28:55 sean-k-mooney so what i was going to propsoe is lsightly diffent. i was going to try and capture the placment api logs into a seperate stringio buffer and make them aviabel in tests but only log them if you run the test in debug mode
12:30:41 sean-k-mooney so similar to how https://github.com/openstack/placement/blob/master/placement/tests/functional/fixtures/capture.py works internally
12:31:46 sean-k-mooney or rather similar ot how https://github.com/openstack/oslotest/blob/9c1cb8e6df468a459783b49d59c60eee3cf83d4d/oslotest/log.py#L35 works internaly
12:33:11 sean-k-mooney currently the way our test are setup teh python loing module is set up to log to stdout and stderr
12:33:13 sean-k-mooney then https://github.com/openstack/oslotest/blob/9c1cb8e6df468a459783b49d59c60eee3cf83d4d/oslotest/output.py#L64-L71
12:33:29 sean-k-mooney intercept that if we enabel that fixture
12:35:09 sean-k-mooney so what i want to try and do is see if i can redirect the placement loggers to a stringstream or stringio buffer instead and add them to the base test class as self.placment_api_log
12:35:54 sean-k-mooney tkajinam: gibi just to be clear im fine with proceexcing with tkajinam's patch if it passes ci
12:36:20 gibi cool. I think tkajinam's fix can land fast to unblock the gate
12:37:00 gibi there is at least on green functional run already in 963953
12:37:11 gibi I mean in https://zuul.opendev.org/t/openstack/status?change=963953
12:41:02 tkajinam sean-k-mooney, I didn't try that way first, because in these functional tests of osc-placement we have a single root logger which receives both placement log and osc-placmenet's log

Earlier   Later