Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qemu command does not start the qemu exporter in v0.5.0 (regression) #260

Closed
TheElectronWill opened this issue Feb 3, 2023 · 5 comments · Fixed by #291
Closed

qemu command does not start the qemu exporter in v0.5.0 (regression) #260

TheElectronWill opened this issue Feb 3, 2023 · 5 comments · Fixed by #291
Assignees
Labels
bug Something isn't working

Comments

@TheElectronWill
Copy link
Contributor

TheElectronWill commented Feb 3, 2023

Bug description

When the qemu exporter is enabled via the command line, it is not recognized. That is, scaphandre qemu says scaphandre: Couldn't determine which exporter to run. and stops. Other exporters like stdout work.

To Reproduce

With Scaphandre 0.5.0, I did:

carbo build
./target/debug/scaphandre qemu

and got the following error:

scaphandre: Couldn't determine which exporter to run.

I've also tried with the docker image hubblo/scaphandre:0.5.0 and hubblo/scaphandre:latest, same result.

Expected behavior

The qemu command should enable the qemu exporter, like it did before.

I've tested with previous versions (0.4.1 and 0.4.0), and it works, since I get:

> scaphandre qemu
Scaphandre qemu exporter
Sending ⚡ metrics

Environment

  • Ubuntu 22.04.1
  • linux 6.1.0-1004-oem
@TheElectronWill TheElectronWill added the bug Something isn't working label Feb 3, 2023
@bpetit
Copy link
Contributor

bpetit commented Feb 5, 2023

Thanks for this bug report ! I add it to next batch.

@TheElectronWill
Copy link
Contributor Author

TheElectronWill commented Feb 5, 2023

It seems that the problem is that the qemu feature is disabled, because warpten is enabled. I wonder if there's a reason that the two are exclusive?
e.g. in lib.rs, I've found

#[cfg(all(target_os = "linux", not(feature = "warpten")))]
use exporters::qemu::QemuExporter;

edit: I think I've got an idea for a nice refactoring of the initialization of the exporters, that will fix the bug and remove many duplicate code. I'll try it.

@bpetit
Copy link
Contributor

bpetit commented Mar 27, 2023

iirc it was mainly because the warpten exporter still needs to be rewritten to use MetricGenerator as the other exporters do.

Do you already have a PR somewhere about this or should I open one to fix the exporter, then remove this compilation condition ?

@TheElectronWill
Copy link
Contributor Author

TheElectronWill commented Mar 27, 2023

I have a refactoring ready but I cannot turn it into a PR today... It simplifies how exporters are started and how args are handled (by taking advantage of the features of clap 4 - it's much more than a version bump), but I have not rewritten the warpten exporter yet.
Thus, if you already have a fix for the warpten exporter, go ahead! I'll update my changes and come back :)

@bpetit bpetit linked a pull request Mar 28, 2023 that will close this issue
@bpetit
Copy link
Contributor

bpetit commented Apr 19, 2023

should be better in dev now. I'll try to review your refacto PR this week

@bpetit bpetit closed this as completed Jul 24, 2023
@bpetit bpetit added this to General Jun 19, 2024
@bpetit bpetit moved this to Previous releases in General Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Previous releases
Development

Successfully merging a pull request may close this issue.

2 participants