Add incus bug command

[bensmrs]

Closes: #2337

I thought that just stripping sensitive data was a bit weak for a whole new command, so I decided to go a bit wild.

@stgraber, please create an OAuth app called “Incus” or “Incus Client” (or the like) under the lxc org and give me its clientID. In the meantime, you can test it on my personal public repo hardcoded in this PR code.

This PR doesn’t take any care about proxies, so additional patches may be needed (I’d like to be pointed to the right direction). Additionally, the issues generated by incus bug report don’t include a type, so you may need additional work on GitHub side to get them automatically typed as Bug.

[bensmrs]

A future addition to this command would be to dump the current Markdown file if the issue can’t be created (e.g. network or auth issues), and allow to reimport it later on; I’ll probably have a look at it tomorrow.

[bensmrs]

Not sure why this last commit is needed…

[stgraber]

The ability to directly report the issue on Github is interesting but I think is going to cause us more issues than it's worth :)

The problems I'm seeing are:

• We ask the user to check that there are no other similar issues but they're very unlikely to actually do that if they don't have Github already open
• The user may not have a Github account and will only notice that all the way at the end
• The machine they're running this on may not have outside connectivity, which again will only be noticed way too late in the process
• The Github prompt for this to work is rather scary and will likely dissuade a lot of users

I think that last point is the most problematic with this approach unfortunately.

The user will have gone through the process of answering a bunch of questions on the CLI to then have to go through a page that basically says.

"Authorize Incus Bug Reporter", "Make sure you trust this device as it will get access to your account." and it then requests access to read and write all public repository data including:

• Code
• Issues
• Pull requests
• Wikis
• Settings
• Webhooks and services
• Deploy keys

So I would effectively never use that feature myself as those permissions are extremely scary to the point I wouldn't trust any incus binary on a system where I'm not the one who built the binary.

Those permissions are sufficient to completely delete all public repositories an account has access to, or worse, inject code, push tags and make releases on all such repositories.

[stgraber]

I think for something like this to be viable, Github would need to support a different API where we can anonymously push issue data, then the user can go to a URL we provide, review the issue and then post it.

Launchpad has something like that in place for crash reports and that's been working pretty well.

[stgraber]

So as it stands, I think we're better off going back to the original idea of a hidden incus buginfo command which spits out some information about the systems for inclusion in a bug report.

I think we could have that show an equivalent of:

• Filtered incus info (drop API extensions, replace sensitive config key values with STRIPPED or similar place holder)
• System statistics, basically a count of:
  • Projects
  • Instances
  • Profiles
  • Networks
  • Storage pools
  • Images

As a safe but useful baseline.

We can then add some useful subcommands, for example:

incus buginfo instance XYZ --project bar would:

• Include incus config show --expanded
• Include incus profile show for each profile it uses
• Include incus storage show for each pool it uses
• Include incus network show for each network it uses
• Include incus console --show-log output
• Include incus info --show-log output

Or incus buginfo goroutines which would:

• Set core.debug_address to a random localhost port
• Get http://127.0.0.1:PORT/debug/pprof/goroutines?debug=2
• Reset core.debug_address to its previous value

Or incus buginfo record which would:

• Connect to the events endpoint
• Show a message telling the user to hit ENTER to start recording all activity
• Show a message telling the user to hit ENTER again after they're down reproducing their issue
• Spit out a text version (similar to incus monitor --pretty) of everything that happened during that time

Basically incus buginfo would give us the baseline we want in all bug reports, then more specialized incus buginfo FOO sub-commands would be things we can ask users to run to capture the extra data we need without having to give detailed step by step instructions every time.

We can also suggest running some of those directly in the bug template.

[bensmrs]

We ask the user to check that there are no other similar issues but they're very unlikely to actually do that if they don't have Github already open

Honestly, how many bug reporters actually check that before checking the box on GitHub? (I’m biased because I read all the issues as they come, so I think I/we can’t really answer this one)

The user may not have a Github account and will only notice that all the way at the end

Fair, albeit fixable by alerting the user or authenticating early.

The machine they're running this on may not have outside connectivity, which again will only be noticed way too late in the process

Yeah, that one is pretty bad, but fixable by dumping the report and allowing to import it.

The Github prompt for this to work is rather scary and will likely dissuade a lot of users

Oh yeah… The solution to make it less scary is an actual GitHub App (vs. OAuth App), but I think that that’d require a PKI infrastructure to sign each client, so… very bad.
With my OCaml package maintainer hat, we use GitHub tokens with opam publish, so that may be a solution (that I don’t like very much…).
People can use a token that can only access the Incus repository and post issues.

So I would effectively never use that feature myself as those permissions are extremely scary to the point I wouldn't trust any incus binary on a system where I'm not the one who built the binary.

I agree. I trust myself enough to use my own code; I would trust Debian packages; I would recompile and verify checksums for the rest.

Those permissions are sufficient to completely delete all public repositories an account has access to, or worse, inject code, push tags and make releases on all such repositories.

Thanks GitHub I guess. Fine-grained tokens could work, outside of the OIDC dance.

I think for something like this to be viable, Github would need to support a different API where we can anonymously push issue data, then the user can go to a URL we provide, review the issue and then post it.

Launchpad has something like that in place for crash reports and that's been working pretty well.

I looked into it, and the only thing I found is auto-filling issues with URL parameters. Unfortunately, the character limit for URLs seems to be 2048, so it’s not enough for a server config dump.
We could also have an issue type that asks us to copy-paste the final output of incus bug report and have that command return the formatted Markdown.

I’ll need some reflection time to react to your last message.

[bensmrs]

Oh shoot, I’ve been trapped by GitHub’s UI into clicking the wrong button again…