Not working in container mode about jaeger-vscode

[objectiser]

@zwx00 Are you referring to running vscode this way: https://code.visualstudio.com/docs/remote/containers?

I haven't had much time to invest in working on this extension - but if you have a proposal of how this would work that would be great. When you say "point me in the right direction" - what type of information are you looking for?

The binaries are available from https://github.com/jaegertracing/jaeger/releases/tag/v1.21.0 - only the "all-in-one" executable would be required.

[zwx00]

Hey, yes that's what I meant. One simple solution would be to let users override the location to point the extension to the correct jaeger instance. That would somewhat defeat the purpose of the extension though.

[objectiser]

Yeah, I think if vscode is running in a container environment, it probably does make sense for it to make use of a Jaeger instance running separately. But in that case, only one of the current actions is relevant? i.e. showing the UI, but start/stop wouldn't be relevant.

So would the proposal be to add the configuration to enable override of the jaeger instance location? If this was done, wonder if it would be possible to disable the start/stop actions?

[zwx00]

The value of the webview running inside the vscode environment is questionable, if the user already went through the trouble of installing and configuring Jaeger UI themselves, they can access it through the web browser too IMO. It's surely possible to disable those actions, and I'm happy to open a PR for this when I find time. It would include a configuration page for the extension, where it would be possible to point to an external Jaeger instance. Did you plan any more involved features for this extension, eg. integrating the jager data with the code editor itself somehow?

…

On Sun, Dec 13, 2020 at 5:26 PM Gary Brown ***@***.***> wrote: Yeah, I think if vscode is running in a container environment, it probably does make sense for it to make use of a Jaeger instance running separately. But in that case, only one of the current actions is relevant? i.e. showing the UI, but start/stop wouldn't be relevant. So would the proposal be to add the configuration to enable override of the jaeger instance location? If this was done, wonder if it would be possible to disable the start/stop actions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIIDJHRNVIFRQORYQTXFEDSUTTMFANCNFSM4UQOMD3A> .

[objectiser]

Agree, it doesn't really benefit users who are already running Jaeger instance separately.

Did you plan any more involved features for this extension, eg. integrating
the jager data with the code editor itself somehow?

Not currently - but if anyone has any suggestions they will definitely be welcome. But until then, it doesn't seem like it would be worth adding the config for external instance.

[zwx00]

Ok, thanks. Feel free to close this.

…

On Sun, 13 Dec 2020 at 18:12, Gary Brown ***@***.***> wrote: Agree, it doesn't really benefit users who are already running Jaeger instance separately. Did you plan any more involved features for this extension, eg. integrating the jager data with the code editor itself somehow? Not currently - but if anyone has any suggestions they will definitely be welcome. But until then, it doesn't seem like it would be worth adding the config for external instance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIIDJAKJEF6TURUKRTGX3DSUTYXDANCNFSM4UQOMD3A> .