e2e: fix "Failed to compile e2e"

Issue #, if available:
Got lots of errors when run "make run-e2e" like below
Failed to compile e2e:

/root/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.2.11/framework/cluster_helpers.go:231:12: cannot use input.Client (variable of type client.Client) as type Getter in struct literal:
	client.Client does not implement Getter (wrong type for Get method)
		have Get(ctx context.Context, key "k8s.io/apimachinery/pkg/types".NamespacedName, obj client.Object, opts ...client.GetOption) error
		want Get(ctx context.Context, key "k8s.io/apimachinery/pkg/types".NamespacedName, obj client.Object) error

The issue is because of one of the break changes between controller-runtime 0.12 and 0.13 see https://github.com/kubernetes-sigs/controller-runtime/releases/tag/v0.13.0
Description of changes:
It can be fixed by downgrading sigs.k8s.io/controller-runtime from 0.13.1 to 0.12.3
Testing performed:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@rohityadavcloud @davidjumani @g-gaston @dims
An alternative way to fix the e2e compilation error is, upgrade to cluster-api 1.4.2 (released last week)
However, it would be a major change.

I would say merge this PR and #230 , then do a release. After that work on upgrading to cluster-api 1.3 or 1.4.

/approve
/ok-to-test

Codecov Report
Patch and project coverage have no change.

Comparison is base (4d7274d) 34.06% compared to head (9026d48) 34.06%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #242   +/-   ##
=======================================
  Coverage   34.06%   34.06%
=======================================
  Files          43       43
  Lines        3907     3907
=======================================
  Hits         1331     1331
  Misses       2394     2394
  Partials      182      182

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@weizhouapache
I'm cool merging this.
However, why does the main go.mod need to change? It seems like the breaking changes only affect the test module?
Also, what does everyone think about having a presubmit that builds the e2e tests? Just to make sure we don't break this again in the future.

However, why does the main go.mod need to change? It seems like the breaking changes only affect the test module?

I just checked CAPI v1.2.11 and v1.2.12, they depend on sigs.k8s.io/controller-runtime v0.12.3 so this seems to have been inadvertently bumped. For as long as we depend on CAPI v1.2, sigs.k8s.io/controller-runtime v0.12.3 seems to be correct.

Also, what does everyone think about having a presubmit that builds the e2e tests? Just to make sure we don't break this again in the future.

I think this would be a good idea, but that would require a Cloudstack cluster somewhere to run the e2e tests.

@weizhouapache I'm cool merging this.
However, why does the main go.mod need to change? It seems like the breaking changes only affect the test module?
Also, what does everyone think about having a presubmit that builds the e2e tests? Just to make sure we don't break this again in the future.

However, why does the main go.mod need to change? It seems like the breaking changes only affect the test module?

I just checked CAPI v1.2.11 and v1.2.12, they depend on sigs.k8s.io/controller-runtime v0.12.3 so this seems to have been inadvertently bumped. For as long as we depend on CAPI v1.2, sigs.k8s.io/controller-runtime v0.12.3 seems to be correct.

thanks @hrak for the checking.
I was hesitated to create this PR because downgrade of a dependency is always not suggested in my opinion.
your check gives me more confidence that v0.12.3 might be a better version.
meanwhile, I am working on cluster-api 1.4.2, which works fine with the latest controller-runtime v0.14.5

Also, what does everyone think about having a presubmit that builds the e2e tests? Just to make sure we don't break this again in the future.

I think this would be a good idea, but that would require a Cloudstack cluster somewhere to run the e2e tests.

we can setup local environments in our lab, similar as we use jenkins to test all cloudstack PRs.
cc @rohityadavcloud @davidjumani

I just checked CAPI v1.2.11 and v1.2.12, they depend on sigs.k8s.io/controller-runtime v0.12.3 so this seems to have been inadvertently bumped. For as long as we depend on CAPI v1.2, sigs.k8s.io/controller-runtime v0.12.3 seems to be correct.

That doesn't explain why the main module needs to change, does it? The fact that core capi v1.2.11 uses controller-runtime v0.12.3 doesn't mean that the core capi code is incompatible with newer versions of controller-runtime.
The capi test module is definitely incompatible with newer version of controller-runtime, but that's a separate module. And that module is only imported from the capc test/e2e module.
I'm just trying to understand the need for the change here :)

I think this would be a good idea, but that would require a Cloudstack cluster somewhere to run the e2e tests.

we can setup local environments in our lab, similar as we use jenkins to test all cloudstack PRs.

That would be awesome, but I was only suggesting doing a "dry-run" of the tests, at least as a first step. Like just checking that the code is valid at a compiler level. To make sure we don't break the code by bumping dependencies in the future.

I just checked CAPI v1.2.11 and v1.2.12, they depend on sigs.k8s.io/controller-runtime v0.12.3 so this seems to have been inadvertently bumped. For as long as we depend on CAPI v1.2, sigs.k8s.io/controller-runtime v0.12.3 seems to be correct.

That doesn't explain why the main module needs to change, does it? The fact that core capi v1.2.11 uses controller-runtime v0.12.3 doesn't mean that the core capi code is incompatible with newer versions of controller-runtime.

@g-gaston
currently we have not seen any other issues caused by controller-runtime v0.13.0.
However, it is a blocker issue for e2e tests. there are two options to fix it
(1) downgrade controller-runtime to v0.12.3, or
(2) upgrade cluster-api (to v1.4.2) and other dependencies.
I've shared my thoughts in the decription of issue https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/issues/246
this PR is not needed if we decide not to run e2e tests for 0.4.X releases.

The capi test module is definitely incompatible with newer version of controller-runtime, but that's a separate module. And that module is only imported from the capc test/e2e module.
I'm just trying to understand the need for the change here :)

I think this would be a good idea, but that would require a Cloudstack cluster somewhere to run the e2e tests.

we can setup local environments in our lab, similar as we use jenkins to test all cloudstack PRs.

That would be awesome, but I was only suggesting doing a "dry-run" of the tests, at least as a first step. Like just checking that the code is valid at a compiler level. To make sure we don't break the code by bumping dependencies in the future.

@g-gaston
if we just compile e2e, it is simple. it can be probably done by github actions.
I would suggest to run e2e tests on real cloudstack enviroments.

That doesn't explain why the main module needs to change, does it? The fact that core capi v1.2.11 uses controller-runtime v0.12.3 doesn't mean that the core capi code is incompatible with newer versions of controller-runtime.

Thats a fair point, the provider has been running fine in our env using the current 0.13.1 controller-runtime dep.

(1) downgrade controller-runtime to v0.12.3

The last release pegged controller-runtime at 0.11.1 so we aren't really downgrading anything.
Lets make the dependencies make sense for CAPI 1.12.x and release as has been suggested, then focus on CAPI upgrades.

It seems like controller-runtime was upgraded here to support k8s 1.24
Given the controller seem to have been working fine, if it's not required to fix the e2e tests, I vote to leave the main module untouched in order to reduce risk.

It seems like controller-runtime was upgraded here to support k8s 1.24
Given the controller seem to have been working fine, if it's not required to fix the e2e tests, I vote to leave the main module untouched in order to reduce risk.

same as @chrisdoherty4 , I checked the go.mod of latest release (v0.4.8), the verison is v0.11.1
https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/blob/v0.4.8/go.mod#L25
The v0.4.9-rc1/rc2/rc3/rc4 do use the newer version v0.13.1, but there is no official release v0.4.9 yet.
https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/blob/v0.4.9-rc4/go.mod#L25

/lgtm


[feature] error handling

Consistent error handling is crucial. The server should also not leak internal data. Would be cool to make this consistent and easy. Think we're halfway there already tho

https://github.com/dominictarr/explain-error

done!


Made MessageBox and WindowBox close buttons optional

Just proposing a small change that made my life a bit easier.
Ideally, this would be done using flags, but that's a much bigger change than just this.
This change also keeps the API intact.
What a message box looks like without the close button:

@muit Sorry, this change breaks the API and adds an unneeded parameters for most use cases. I'm not merging it.

I get that. Thats why I suggested flags could be used instead.
I find this particular feature very useful, I did attach an example :)
So I dont care that much on the method that provides this functionality, rather on the functionality itself.

How does it beak the API though? No code needs to change, its an optional parameter

@muit I'm afraid optional parameters are not supported in plain C language.

Ahh! Didnt know that!
Miguel

From: Ray @.>
Sent: Monday, October 10, 2022 4:49:26 PM
To: raysan5/raygui @.>
Cc: Miguel Fernandez Arce @.>; Mention @.>
Subject: Re: [raysan5/raygui] Made MessageBox and WindowBox close buttons optional (PR #231)
@muithttps://github.com/muit I'm afraid optional parameters are not supported in plain C language.
—
Reply to this email directly, view it on GitHubhttps://github.com/raysan5/raygui/pull/231#issuecomment-1273433025, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA4AXCXU6UMWKOYBPFQ46VTWCQUHNANCNFSM6AAAAAARA3JOHE.
You are receiving this because you were mentioned.Message ID: @.***>


Reduce pressure on Elasticsearch in staging env

As discussed, the previous config seems to lead to indexing failures in the staging environment due to Elasticsearch tripping memory-related circuit breakers and/or timing out.

I thought we've already applied the change; but now I see:

yrodiere enabled auto-merge 2 days ago

Those auto-merge PRs are getting stuck as some other PR gets merged 🙈 😖

Those auto-merge PRs are getting stuck as some other PR gets merged 🙈 😖

Yep, it only merges if it can be fast-forwarded I think.


Restrict tag category colors to those supported by PatternFly.

Removes color generation from the hub and addon-windup.  Delegated to the UI.
Updated colors for seeded categories to be within supported PF colors.

We stopped generating color for newly imported TagCategories and those created by Windup in the following PRs:
https://github.com/konveyor/tackle2-hub/pull/279
https://github.com/konveyor/tackle2-addon-windup/pull/91
@mturley curated a list of 16 distinct colors and created a UI component that supports them. Changed the hub to seed TagCategories with those colors in #284.


Build pipeline no longer works

The github actions/pylint configurations are out of date and now error

Thanks for the heads up, should be fixed in master.


PowerToys Run crashes while performing a search.--

Microsoft PowerToys version
0.72.0
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
PowerToys Run
Steps to reproduce
-- Initiate PowerToys Run
-- Press   to invoke PT Run
-- Search for a program (in my case, it was "Revo Uninstaller".
-- The program does indeed appear in the search box, but inmediately closes.
---> The program crashes (closing the program instantly).
I am using an AMD processor.
✔ Expected Behavior
That the program appears on top of the search bar, and let my press  to run it.
❌ Actual Behavior
It does not give my time (not even two seconds) to run the program.
Instead:  it crashes, closing everithing inmediatelly.
I have to go to PowerToys to re-run the program to enable it again.
Other Software
No response

/bugreport

PowerToysReport_2023-08-06-16-10-14.zip
Thank you for your kind help.-

Indeed it looks like it is crashing quite a bit, according to the event viewer logs here.
Something that might help understanding which plugin is causing this might be to start with all plugins disabled, enable a plugin and restart PowerToys and so on, enabling the plugins one by one until it's identified.
Something else that might help here would be a crash dump.
One way of achieving this would be by creating an entry in the Registry Editor (regedit.msc), for Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\PowerToys.PowerLauncher.exe , according to the instructions in https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
It should look something like this in the end (but for PowerLauncher):

After that, please replicate the bug, navigate to %LOCALAPPDATA%\CrashDumps in the File Explorer and upload the zipped PowerToys.PowerLauncher.exe.*.dmp file to a GitHub comment.
/needinfo

PowerToys.PowerLauncher.exe.1932.zip
Thank you, David, for your help.

ERROR_CODE: (NTSTATUS) 0xc06d007e - <Unable to get error code text>

STACK_TEXT:
000000de`4317f7d0 00007ff8`a4ff87b8     : 00000000`00000000 00007ff8`a5020058 00000260`9ccaac30 000000de`4317fa78 : KERNELBASE!RaiseException+0x6c
000000de`4317f8b0 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : thumbnail_handler+0x87b8

Loaded symbol image file: thumbnail-handler.dll
Image path: C:\Program Files\Soda PDF Desktop 14\thumbnail-handler.dll
Image name: thumbnail-handler.dll

I have analyzed the dump and the crash is caused by thumbnail-handler.dll that is a library of Soda PDF Desktop 14 probably used to generate thumbnails for PDF files.
Are you able to reproduce the crash? If yes, can you try to disable Generate thumbnails from files option in PowerToys Run settings page and give a try?
/needinfo

Thank you, Davide.
I will try to disable that option, and come back to you.
Additionally, I noticed that it only, but always, crashes when searching
for the app:  "Revo Uninstaller".
Can it be related to the Generate thumbnails option?
Spencer
On Tue, 8 Aug 2023 at 12:25, Davide Giacometti @.***>
wrote:

ERROR_CODE: (NTSTATUS) 0xc06d007e -
STACK_TEXT:
000000de4317f7d0 00007ff8a4ff87b8     :<PHONE_NUMBER>000000 00007ff8a5020058 000002609ccaac30 000000de4317fa78 : KERNELBASE!RaiseException+0x6c
000000de4317f8b0<PHONE_NUMBER>000000     :<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000<PHONE_NUMBER>000000 : thumbnail_handler+0x87b8
Loaded symbol image file: thumbnail-handler.dll
Image path: C:\Program Files\Soda PDF Desktop 14\thumbnail-handler.dll
Image name: thumbnail-handler.dll
I have analyzed the dump and the crash is caused by thumbnail-handler.dll
that is a library of Soda PDF Desktop 14 probably used to generate
thumbnails for PDF files.
Are you able to reproduce the crash? If yes, can you try to disable Generate
thumbnails from files option in PowerToys Run settings page and give a
try?
/needinfo
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/27860#issuecomment-1670097239,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGDJIX35ZERYIA7SGUMFUR3XUKABBANCNFSM6AAAAAA3FM4TKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

It worked!
After disabling the Generate Thumbnails option, it worked without crashes.
Maybe it was crashing mainly after searching for "Revo Uninstaller", because it displayed a PDF for the help file (Revo Uninstaller Pro Help)

Why is this program (Soda PDF) is causing this problem?  Can it be fixed?
Thank you.-

It is most likely caused by that pdf.
Not sure how much we can do on PoweToys aside from the setting that disable thumbnails.

Soda PDF have a thumbnail provider to create thumbnail preview for PDF files in Windows Explorer
I'll verify if Soda PDF is up to date