text:
Add dependabot

Dependabot is GitHub tool for automated updates of released
dependencies and CVE fixes.
https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates
Signed-off-by: Martin Basti mbasti@redhat.com
Maintainers will complete the following section

[x] Commit messages are descriptive enough
[x] Code coverage from testing does not decrease and new code is covered
[x] JSON/YAML configuration changes are updated in the relevant schema
[x] Changes to metadata also update the documentation for the metadata
[x] Pull request has a link to an osbs-docs PR for user documentation updates
[x] New feature can be disabled from a configuration file

oh, and "dependabot", not "dependant" bot

oh, and "dependabot", not "dependant" bot

Yeah I cannot read/write, fixed

no release notes, only Github tooling change

authors: MartinBasti chmeliik

repo: containerbuildsystem/atomic-reactor


text:
Update user parameters related to remote sources

CLOUDBLD-4449
Signed-off-by: mkosiarc mkosiarc@redhat.com
Maintainers will complete the following section

[ ] Commit messages are descriptive enough
[x] Code coverage from testing does not decrease and new code is covered
[n/a] JSON/YAML configuration changes are updated in the relevant schema
[n/a] Changes to metadata also update the documentation for the metadata
[n/a] Pull request has a link to an osbs-docs PR for user documentation updates

LGFM

source: gharchive/pull-request

authors: mkosiarc rcerven

repo: containerbuildsystem/osbs-client

license_type: permissive

license_source: github-api


text:
add more debugging for update_labels, so we can find out why labels

aren't updated properly sometimes

CLOUDBLD-8615

Signed-off-by: Robert Cerven rcerven@redhat.com
Maintainers will complete the following section

[x] Commit messages are descriptive enough
[x] Code coverage from testing does not decrease and new code is covered
n/a JSON/YAML configuration changes are updated in the relevant schema
n/a Changes to metadata also update the documentation for the metadata
n/a Pull request has a link to an osbs-docs PR for user documentation updates

no rn, just added debug messages


text:
[io.containerd.runc.v1.linux] containerd-shim error when running in Riscv64

Description
I cannot execute containerd-shim while containerd-runc-shim-v2 execution is normal on riscv64.
Steps to reproduce the issue
Normal:
docker run --runtime io.containerd.runc.v2 hello-world
Abnormal:
docker run --runtime io.containerd.runc.v1.linux hello-world
Describe the results you received and expected
Current result:
[  122.965405] containerd-shim[218]: unhandled signal 11 code 0x2 at 0x0000000000035b78 in containerd-shim[10000+321000]
[  122.978894] CPU: 0 PID: 218 Comm: containerd-shim Not tainted 5.10.145-yocto-standard #1
Expected result:
Can work well as io.containerd.runc.v2
What version of containerd are you using?
containerd v1.6.18
Any other relevant information
$runc --version
1.1.3
$ uname -a
5.10.145-yocto-standard
$file containerd-shim
containerd-shim: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, stripped
$file containerd
containerd: ELF 64-bit LSB shared object, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0. stripped
Show configuration if it is related to CRI plugin.
No response

io.containerd.runc.v1.linux is deprecated and will be removed in containerd v2.0, so it is not going to support new architectures.
It should be also noted that running containers with RISC-V needs runc v1.2 (unreleased yet) for enabling seccomp.

source: gharchive/issue

authors: AkihiroSuda MinhNguyenBV

repo: containerd/containerd


text:
Files sdnoverlay.exe and sdnbridge.exe are reported as malicious software

Description
After downloading the windows release cri-containerd-cni-1.7.11-windows-amd64.tar.gz the antivirus reports the files
.\cni\bin\sdnoverlay.exe
.\cni\bin\sdnbridge.exe
als malicious software. For double check, if the file was uploaded to www.virustotal.com, they say that 43 / 72 of their security vendors analysis complain this as malicious.
Screenshot:

As other example for a newer release, uploading windows relase cri-containerd-cni-1.7.14-windows-amd64.tar.gz to www.virustotal.com, this reports only on 5 / 72 of their security vendors analysis as malicious.
So is this a false positive and can be added to exclusions, or is this really malicious?
Steps to reproduce the issue

Download https://github.com/containerd/containerd/releases/download/v1.7.11/cri-containerd-cni-1.7.11-windows-amd64.tar.gz
Extract tar.gz (and afterwards .zip)
Enable Antivirus Software (in my case TrendMicro) or Upload file to www.virustotal.com

Describe the results you received and expected
The result is, that the file was quarantined by antivirus software.
Expected behavior is, that antivirus software should not complain.
What version of containerd are you using?
1.7.11
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response

It should be a false positive.

authors: itwpcs kzys


text:
Add upgrade --dry-run or so

So that client-side automation tooling can poll for updates before downloading.  xref https://github.com/coreos/rpm-ostree/issues/4176 etc.

Hello,
I started to work on this as a first contribution but I am unsure how to wire things up.
Determining if a new update is available without pulling the whole image requires to run skopeo inspect  and look at the digest of the remote image.
This quite easy to implement but I see that skopeo and podman utils are gated behind the install feature, and given #81 , I suppose adding a requirement on skopeo for the upgrade subcommand is not something we want.
Given this comment https://github.com/coreos/rpm-ostree/pull/4486/files#r1246174405  it appears there is the necessary bits in ostree-rs-ext ?
I'll keep looking around but I wanted to make sure I am on the correct path, as I am just discovering all this ecosystem :)

This quite easy to implement but I see that skopeo and podman utils are gated behind the install feature, and given https://github.com/containers/bootc/issues/81 , I suppose adding a requirement on skopeo for the upgrade subcommand is not something we want.

No; bootc hard requires https://github.com/ostreedev/ostree-rs-ext/ which hard requires skopeo (indirectly via https://github.com/containers/containers-image-proxy-rs )
That's how upgrades work (which is related to but distinct from installs).

Given this comment https://github.com/coreos/rpm-ostree/pull/4486/files#r1246174405 it appears there is the necessary bits in ostree-rs-ext ?

Yes, just see the code implementing bootc upgrade - the key bit is https://docs.rs/ostree-ext/0.11.1/ostree_ext/container/store/struct.ImageImporter.html#method.prepare which is exactly the "fetch manifest without fetching layers".

Also, welcome and thanks for your interest!

authors: cgwalters jbtrystram

repo: containers/bootc


text:
nix thinks the vm is offline

Repro:
krunvm create --name nix nixos/nix
krunvm start nix nix -- --extra-experimental-features 'nix-command flakes' profile install 'nixpkgs#google-cloud-sdk'

This fails with:
warning: you don't have Internet access; disabling some network-dependent features
error: builder for '/nix/store/5jrd75v747s76s16zxk59384xfcjqn58-bash-5.2.tar.gz.drv' failed with exit code 1;
       last 4 log lines:
       > error:
       >        … writing file '/nix/store/v28dv6l0qk3j382kp40bksa1v6h7dx9p-bash-5.2.tar.gz'
       >
       >        error: unable to download 'https://ftpmirror.gnu.org/bash/bash-5.2.tar.gz': Timeout was reached (28)

Looks like it's because of this check:
https://github.com/NixOS/nix/blob/2.18.1/src/nix/main.cc#L456-L459
https://github.com/NixOS/nix/blob/2.18.1/src/nix/main.cc#L30-L54
I wonder if it's common for programs to inspect getifaddrs like that, and if so, what other problems would come up if it returned a fake non-loopback/link-local network interface.

virito-net got merged into libkrun, I assume that using the virtio-net backend will make it work.

authors: Rucadi dsilvasc

repo: containers/krunvm


text:
podman 1.9.2 fedora32 rootless gating test failures

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Gating tests for rootless are failing and that caused the bodhi update for 1.9.2 to get ejected from the stable set.
Click on /tmp/package-test.sh in the tests page

Steps to reproduce the issue:

See the Description

Describe the results you received:
rootless tests failed
Describe the results you expected:
rootless tests should pass
(seems like @giuseppe has WIP for this)
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version:            1.9.2
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/amd64

Output of podman info --debug:
debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.14.2
  podmanVersion: 1.9.2
host:
  arch: amd64
  buildahVersion: 1.14.8
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.16-2.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.16, commit: 1044176f7dd177c100779d1c63931d6022e419bd'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: nagato.nanadai.me
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.6.13-300.fc32.x86_64
  memFree: 8152793088
  memTotal: 16416153600
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 8296329216
  swapTotal: 8296329216
  uptime: 4h 41m 8.68s (Approximately 0.17 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 27
    paused: 0
    running: 0
    stopped: 27
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 23
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.9.2-1.fc32.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):

/cc @mheon @giuseppe @edsantiago

lots of:
[2020-05-14T04:51:41.506Z]     # error creating temporary file: No such file or directory
[2020-05-14T04:51:41.506Z]     # Error: could not get runtime: error setting up the process: open /run/user/1000/libpod/pause.pid: no such file or directory
[2020-05-14T04:51:41.506Z]     # [ rc=125 ]

Direct link: https://jenkins-continuous-infra.apps.ci.centos.org/blue/rest/organizations/jenkins/pipelines/fedora-f32-build-pipeline/runs/484/nodes/220/steps/247/log/?start=0

OK I think I'm getting closer. The failing bodhi tests list three builds, not one, and I think the smoking gun is conmon. In September 2019 I added fedpkg gating tests for conmon, and nauseatingly did so by copying podman tests. (There was no better way at the time; still isn't). The rootless-testing mechanism in that copy of the podman tests is broken: it does not do the magic loginctl needed by podman.
I will manually run tests on this conmon build and will report back. This does not seem to be a podman issue.

Tests pass when run manually with the required loginctl. I've +1ed the bodhi build but it looks like there isn't actually any way to waive test results, despite documentation to the contrary.

repo: containers/libpod


text:
Warn on overriding user-specified storage driver w/ DB

Overriding storage.conf is not intuitive behavior, so pop up an error message when it happens, so people know that bad things are happening.
We have to retain this behaviour (the alternative was a breaking change), but the least we can do it make it obvious something unusual is happening.
I'm torn on Errorf vs Warnf here - Errorf makes this seem more serious than it is, but always prints, whereas Warnf is only visible with a log-level=debug

bot, retest this please

I would still like to make different drivers work correctly by moving the database into a per driver directory.

authors: mheon rhatdan


text:
e2e: omit long running tests by default.

Skip tests matching *long*, *fuzz*, or *stress* by default. Run them though when long_tests=yes is set.

@askervin @fmuyassarov @kad @pfl PTAL.

LGTM.
The only improvement that I could come up with is printing something like "SKIP $TEST_DIR (long_tests=no)", as I can imagine myself wondering after few months why ./run_tests.sh doesn't do anything.

Good point. I'm think I myself would not realize after a week why long tests are not run at all. Updated, adding printouts when we skip tests. I also inverted the control variable name and semantics to skip_long_tests, which feels more correct.

repo: containers/nri-plugins


text:
image: impl From for String

I considered converting the media type strings to constants so they can be
referenced without allocating a String but since these types aren't
comprehensive (ie we always have to deal with unknown types so we could never
impl From<String> for &'static str) I don't think that's necessary.
Signed-off-by: wayne warren wayne.warren.s@gmail.com

Codecov Report

Merging #146 (382d7f5) into main (c109fe1) will decrease coverage by 0.19%.
The diff coverage is 0.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #146      +/-   ##
==========================================
- Coverage   22.61%   22.43%   -0.19%
==========================================
  Files          23       23
  Lines        2069     2086      +17
  Branches     1146     1146
==========================================
  Hits          468      468
- Misses        791      808      +17
  Partials      810      810

@waynr may I ask you to squash your commits or sign-off the last one?

@saschagrunert WDYT?

authors: codecov-commenter saschagrunert utam0k waynr

repo: containers/oci-spec-rs


text:
Implement/adapt E2E test case covering Podman installation via Podman Desktop on Mac

We need to implement or adapt e2e test case to accommodate podman installation via podman desktop on Mac environment.

This is already covered by podman-desktop-e2e at: https://github.com/containers/podman-desktop-e2e/blob/87278c3f9ae38ed3810f8b2bcb16c02197c70dde/test/extended/podman-desktop/extension/podman/podman-extension_darwin.go#L35
We just need to provision the mac machine and set the envs on the podman-desktop-e2e container accordingly

This works out of a box actually thanks to @adrianriobo support in goax.

authors: adrianriobo odockal


text:
Rancher provider does not correctly handle unhealthy containers

What version of Traefik are you using (traefik version)?
Traefik: v1.2.0-rc2 / morbier
Rancher: v1.4.1
What is your environment & configuration (arguments, toml...)?
docker-compose.yml
version: '2'
services:
  traefik:
    image: traefik:v1.2.0-rc2
    stdin_open: true
    tty: true
    ports:
    - 80:80/tcp
    - 443:443/tcp
    - 8080:8080/tcp
    command:
    - --web
    - --rancher
    - --rancher.domain=development.cluster.rancher.foo.com
    - --rancher.endpoint=https://ui.cluster.rancher.foo.com
    - --rancher.accesskey=...
    - --rancher.secretkey=...
    - --logLevel=DEBUG
    labels:
      io.rancher.container.pull_image: always
      io.rancher.scheduler.global: 'true'

What did you do?
Upgraded a service via the Rancher UI, enabling the Start before Stopping toggle. This service is configured with a health check.
What did you expect to see?
The 'old' containers should be removed from the backend config when they are stopped by Rancher.
What did you see instead?
Containers which have been stopped by Rancher remain in the backend config until they are removed, leading to failed requests.

I just wanted to provide an update on this. The root issue here is the logic found on this line of the rancher provider.
The Rancher API returns a HealthState of initializing under many situations where the service as a whole can still be considered healthy. I'm currently working on fixing this and hope to send a pull request next week.

I don't think the root issue is not including the new container, though I think the pull request does make it include new containers earlier. In my experiments with the rancher api the issue is that the health state alone is not enough. The rancher api service returns a health state of "Healthy" for a whole bunch of cases where you wouldn't want to direct traffic to the container.
I think you need to check the "state" property as well to only include "running" containers, as stopped and purged containers will still return "Healthy" HealthState if they were healthy the last time the health check ran.

authors: jwentworth kelchm

repo: containous/traefik

license: MIT


text:
[WIP] test ouia-safe IDs

Summary
Just testing
Testing steps

Ref: https://ouia.readthedocs.io/en/latest/README.html#ouia-pagesafe
see footer in this example which has a spinner: https://ouia.readthedocs.io/en/latest/_static/example.html


text:
Bumping gatsby dependencies

This pull requests aims to bump the versions of the different gatsby plugins and react.
NB: bumping the React versions helped me fix an issue that many people seemed to have with gatsby 2.18.x => https://github.com/gatsbyjs/gatsby/issues/19064
I didn't have trouble running it locally, so let me know if it works for you 😊
Thanks for the starter BTW 🚀 !

@mfrachet Thanks for the PR! And sorry for no response here. I see you deleted the fork already. :) I'll close this pr and update deps myself now. :)
Anyways. Thanks and happy that it was useful. :)

authors: mfrachet stefanjudis


text:
Jupyter Notebooks in VSCode become unresponsive because the kernel gets disposed erroneously

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS: Windows 11 10.0.22631 Build 22631
- Continue: v0.8.40
- IDE: VS Code 1.87.2

Description
When using Continue with VSCode and connecting to a Jupyter Notebook in WSL, after about 3 minutes, the notebook becomes unresponsive and sends an error notification NO notebook document for 'file:///path/to/notebook.ipynb'
The Jupyter output shows:
16:27:25.603 [info] Dispose Kernel '/path/to/notebook.ipynb' associated with '/path/to/notebook.ipynb'

even though the notebook was not closed, and cells were not modified.
This issue was brought up in the vscode-jupyter github issues, but was closed once it was determined to be an issue with Continue.
To reproduce

Create a jupyter notebook file in WSL in VSCode
Run a cell
Wait at least 3 minutes
Try to run another cell
Run into Dispose Kernel issue

Log output
workbench.desktop.main.js:sourcemap:651  INFO Started local extension host with pid 175788.
workbench.desktop.main.js:sourcemap:651   ERR Extension 'ms-python.debugpy' appears in product.json but enables LESS API proposals than the extension wants.
package.json (LOSES): portsAttributes, contribIssueReporter, debugVisualization
product.json (WINS): portsAttributes
workbench.desktop.main.js:sourcemap:651   ERR Extension 'ms-python.python' appears in product.json but enables LESS API proposals than the extension wants.
package.json (LOSES): contribEditorContentMenu, quickPickSortByLabel, testObserver, quickPickItemTooltip, terminalDataWriteEvent, terminalExecuteCommandEvent, contribIssueReporter
product.json (WINS): contribEditorContentMenu, quickPickSortByLabel, portsAttributes, handleIssueUri, testObserver, quickPickItemTooltip, terminalDataWriteEvent, terminalExecuteCommandEvent
workbench.desktop.main.js:sourcemap:651  INFO Invoking resolveAuthority(wsl)...
workbench.desktop.main.js:sourcemap:651  INFO [LocalProcess0][resolveAuthority(wsl,1)][0ms] obtaining proxy...
workbench.desktop.main.js:sourcemap:651  INFO [LocalProcess0][resolveAuthority(wsl,1)][0ms] invoking...
workbench.desktop.main.js:sourcemap:651  INFO [LocalProcess0][resolveAuthority(wsl,1)][774ms] returned WebSocket(127.0.0.1:63828)
workbench.desktop.main.js:sourcemap:651  INFO resolveAuthority(wsl) returned 'WebSocket(127.0.0.1:63828)' after 775 ms
workbench.desktop.main.js:sourcemap:651  INFO Creating a socket (renderer-Management-bba385ff-b435-4b9a-806c-9f3a3a3190b7)...
workbench.desktop.main.js:sourcemap:651  INFO Creating a socket (renderer-ExtensionHost-d6927b1e-e06c-4c3c-97a4-d95a30b44317)...
workbench.desktop.main.js:sourcemap:651  INFO Creating a socket (renderer-Management-bba385ff-b435-4b9a-806c-9f3a3a3190b7) was successful after 433 ms.
workbench.desktop.main.js:sourcemap:651   ERR Extension 'ms-python.debugpy' appears in product.json but enables LESS API proposals than the extension wants.
package.json (LOSES): portsAttributes, contribIssueReporter, debugVisualization
product.json (WINS): portsAttributes
workbench.desktop.main.js:sourcemap:651   ERR Extension 'ms-python.python' appears in product.json but enables LESS API proposals than the extension wants.
package.json (LOSES): contribEditorContentMenu, quickPickSortByLabel, testObserver, quickPickItemTooltip, terminalDataWriteEvent, terminalExecuteCommandEvent, contribIssueReporter
product.json (WINS): contribEditorContentMenu, quickPickSortByLabel, portsAttributes, handleIssueUri, testObserver, quickPickItemTooltip, terminalDataWriteEvent, terminalExecuteCommandEvent
workbench.desktop.main.js:sourcemap:651   ERR [ms-python.debugpy]: issue/reporter is a proposed menu identifier. It requires 'package.json#enabledApiProposals: ["contribIssueReporter"]' and is only available when running out of dev or with the following command line switch: --enable-proposed-api ms-python.debugpy
workbench.desktop.main.js:sourcemap:651   ERR [ms-python.python]: issue/reporter is a proposed menu identifier. It requires 'package.json#enabledApiProposals: ["contribIssueReporter"]' and is only available when running out of dev or with the following command line switch: --enable-proposed-api ms-python.python
workbench.desktop.main.js:sourcemap:1215 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
mountTo @ workbench.desktop.main.js:sourcemap:1215
workbench.desktop.main.js:sourcemap:651  INFO Creating a socket (renderer-ExtensionHost-d6927b1e-e06c-4c3c-97a4-d95a30b44317) was successful after 813 ms.
workbench.desktop.main.js:sourcemap:651  WARN No search provider registered for scheme: vscode-remote, waiting
workbench.desktop.main.js:sourcemap:1215 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
mountTo @ workbench.desktop.main.js:sourcemap:1215
workbench.desktop.main.js:sourcemap:1985 Activating extension 'ms-python.debugpy' failed: Extension 'ms-python.debugpy' CANNOT use API proposal: debugVisualization.
Its package.json#enabledApiProposals-property declares: portsAttributes but NOT debugVisualization.
 The missing proposal MUST be added and you must start in extension development mode or use the following command line switch: --enable-proposed-api ms-python.debugpy.
$onExtensionActivationError @ workbench.desktop.main.js:sourcemap:1985
workbench.desktop.main.js:sourcemap:651  INFO [perf] Render performance baseline is 19ms
workbench.desktop.main.js:sourcemap:651   ERR [Extension Host] ex
workbench.desktop.main.js:sourcemap:148 [Extension Host] ex
p @ workbench.desktop.main.js:sourcemap:148
workbench.desktop.main.js:sourcemap:651   ERR [Extension Host] Error: timeout
	at Timeout.p (/home/jeffliu/.vscode-server/extensions/ms-toolsai.jupyter-2024.2.0-linux-x64/dist/extension.node.js:55:1754)
	at listOnTimeout (node:internal/timers:569:17)
	at process.processTimers (node:internal/timers:512:7)
workbench.desktop.main.js:sourcemap:148 [Extension Host] Error: timeout
	at Timeout.p (/home/jeffliu/.vscode-server/extensions/ms-toolsai.jupyter-2024.2.0-linux-x64/dist/extension.node.js:55:1754)
	at listOnTimeout (node:internal/timers:569:17)
	at process.processTimers (node:internal/timers:512:7)
p @ workbench.desktop.main.js:sourcemap:148
workbench.desktop.main.js:sourcemap:1985 Activating extension 'vscode-icons-team.vscode-icons' failed: ENOENT: no such file or directory, open 'C:\project_path\share\jupyter\lab\static\package.json'.
$onExtensionActivationError @ workbench.desktop.main.js:sourcemap:1985
workbench.desktop.main.js:sourcemap:651   ERR adding EXISTING notebook file:///project_path/explore/ollama_test.ipynb : Error: adding EXISTING notebook file:///project_path/explore/ollama_test.ipynb
	at u.$acceptDocumentAndEditorsDelta (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:9190)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3593)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
workbench.desktop.main.js:sourcemap:651  WARN Settings pattern "application.*" doesn't match any settings
workbench.desktop.main.js:sourcemap:1215 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
mountTo @ workbench.desktop.main.js:sourcemap:1215
3workbench.desktop.main.js:sourcemap:651   ERR unknown text editor: c47e83d9-7fc8-4cc2-943c-4ad2c3ab2723. known editors:  : Error: unknown text editor: c47e83d9-7fc8-4cc2-943c-4ad2c3ab2723. known editors:
	at u.getEditorById (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:1429)
	at L.$acceptEditorPropertiesChanged (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:150:149920)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3454)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
12workbench.desktop.main.js:sourcemap:651   ERR NO notebook document for 'file:///project_path/explore/ollama_test.ipynb': Error: NO notebook document for 'file:///project_path/explore/ollama_test.ipynb'
	at u.getNotebookDocument (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:1699)
	at $.$acceptModelChanged (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:135:28768)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3593)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
workbench.desktop.main.js:sourcemap:651   ERR unknown text editor: c47e83d9-7fc8-4cc2-943c-4ad2c3ab2723. known editors:  : Error: unknown text editor: c47e83d9-7fc8-4cc2-943c-4ad2c3ab2723. known editors:
	at u.getEditorById (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:1429)
	at L.$acceptEditorPropertiesChanged (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:150:149920)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3454)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
workbench.desktop.main.js:sourcemap:651   ERR NO notebook document for 'file:///project_path/explore/ollama_test.ipynb': Error: NO notebook document for 'file:///project_path/explore/ollama_test.ipynb'
	at u.getNotebookDocument (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:1699)
	at $.$acceptModelChanged (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:135:28768)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3593)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
workbench.desktop.main.js:sourcemap:651   ERR NO notebook document for 'file:///project_path/explore/ollama_test.ipynb': Error: NO notebook document for 'file:///project_path/explore/ollama_test.ipynb'
	at u.getNotebookDocument (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:155:1699)
	at r.$cellExecutionChanged (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:150:218120)
	at s.S (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5519)
	at s.Q (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:5285)
	at s.M (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:4375)
	at s.L (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:3454)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:147:2241)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:173:8050)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at r.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:14091)
	at u.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:17156)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:15608)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at p.acceptChunk (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11865)
	at p.value (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:105:11152)
	at n.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:1902)
	at n.fire (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:80:2119)
	at n.z (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19768)
	at n.acceptFrame (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:19574)
	at i.n (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:18073)
	at /home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:15293
	at Socket.y (/home/jeffliu/.vscode-server/bin/863d2581ecda6849923a2118d93a088b0745d9d6/out/vs/workbench/api/node/extensionHostProcess.js:170:13198)
	at Socket.emit (node:events:514:28)
	at addChunk (node:internal/streams/readable:324:12)
	at readableAddChunk (node:internal/streams/readable:297:9)
	at Readable.push (node:internal/streams/readable:234:10)
	at TCP.onStreamRead (node:internal/stream_base_commons:190:23)

+1 to this problem, also documented on a vsCode repo issue  here https://github.com/microsoft/vscode/issues/214848#issuecomment-2170580029, where @babakamini also narrowed the issue down to this to this extension
I am also getting this issue on MacOS Ventura when connecting to a linux server over SSH.

I am having the same issue, can't use Continue with Jupyter in VSCode...

Same issue here....
[info] Disposing request as the cell (-1) was deleted

Hi,
Same issue here when using from Ubuntu server via SSH.
Disabling indexing is a work around. I hope it helps
Here are my VScode logs :
console.ts:137 [Extension Host] Error updating the sqliteFts index: Error: SQLITE_CONSTRAINT: UNIQUE constraint failed: fts_metadata.id C @ console.ts:137 $logExtensionHostMessage @ mainThreadConsole.ts:39 S @ rpcProtocol.ts:458 Q @ rpcProtocol.ts:443 M @ rpcProtocol.ts:373 L @ rpcProtocol.ts:299 (anonymous) @ rpcProtocol.ts:161 y @ event.ts:1196 fire @ event.ts:1227 fire @ ipc.net.ts:650 U.onmessage @ localProcessExtensionHost.ts:378 log.ts:439   ERR unknown text editor: 0a28d7b1-da06-403e-92c8-20004159d542. known editors:  : Error: unknown text editor: 0a28d7b1-da06-403e-92c8-20004159d542. known editors:   	at $.getEditorById (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:160:1516) 	at R.$acceptEditorPropertiesChanged (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:155:164785) 	at E.S (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:152:5970) 	at E.Q (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:152:5736) 	at E.M (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:152:4762) 	at E.L (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:152:3589) 	at n.value (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:152:2282) 	at l.y (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:664) 	at l.fire (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:881) 	at s.fire (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:14502) 	at n.value (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:178:8481) 	at l.y (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:664) 	at l.fire (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:881) 	at s.fire (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:14502) 	at h.z (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:17638) 	at n.value (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:17012) 	at l.y (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:664) 	at l.fire (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:82:881) 	at u.acceptChunk (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:12248) 	at /home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:107:11518 	at Socket.w (/home/jgodfroy/.vscode-server/cli/servers/Stable-5437499feb04f7a586f677b155b039bc2b3669eb/server/out/vs/workbench/api/node/extensionHostProcess.js:175:13305) 	at Socket.emit (node:events:518:28) 	at addChunk (node:internal/streams/readable:559:12) 	at readableAddChunkPushByteMode (node:internal/streams/readable:510:3) 	at Readable.push (node:internal/streams/readable:390:5) 	at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

Same issue here, are there any updates?

I resolved it with a peculiar workaround. I found that opening the WSL's home directory as a workspace in VSCode did not cause this issue, but since my frequently used files are under /mnt, I created a soft link to /mnt in the /home folder. Ever since then, I've been able to use it stably without crashes.

@Gibo-Chun interesting, however the issue also exists when connected to a remote Linux (via SSH)

@Gibo-Chun interesting, however the issue also exists when connected to a remote Linux (via SSH)

I am sorry to hear that. I have not encountered this problem on romote Linux so far. I wonder whether this can help you. https://github.com/continuedev/continue/issues/1771 #1171

I resolved it with a peculiar workaround. I found that opening the WSL's home directory as a workspace in VSCode did not cause this issue, but since my frequently used files are under /mnt, I created a soft link to /mnt in the /home folder. Ever since then, I've been able to use it stably without crashes.

Did you mean opening WSL's home directory or any folder under it? If its the latter, this problem persists.

I think Continue doesn't support WSL. if yes, why?

Also having this issue unfortunately when I SSH into an Ubuntu machine. Would love a solution, since me and my team work with notebooks quite often.

any continue developer is here?

I am having the same issue. I tried multiple versions (released and pre-released; even v0.8.44 still has this problem)

I am having the same issue. I tried multiple versions (released and pre-released; even v0.8.44 still has this problem)

If you don't use new functions, v0.8.27 might be the last version without the problem, and you can downgrade to that version.

I resolved it with a peculiar workaround. I found that opening the WSL's home directory as a workspace in VSCode did not cause this issue, but since my frequently used files are under /mnt, I created a soft link to /mnt in the /home folder. Ever since then, I've been able to use it stably without crashes.

@Gibo-Chun Did you mean opening WSL's home directory or any folder under it? If its the latter, this problem persists.

I means the former. The latter failed in my case too.

Does anybody know if the Continue team has been able to trace the issue? Thanks!

I think yes! V0.8.46 works great for me, no disposal.
On Thu, Aug 22, 2024 at 16:01 terosset @.***> wrote:

Does anybody know if the Continue team has been able to trace the issue?
Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/continuedev/continue/issues/1463#issuecomment-2305629301,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASE7G4OICCEFKKJMRP2HKZTZSZGT3AVCNFSM6AAAAABJDA4FNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVGYZDSMZQGE
.
You are receiving this because you commented.Message ID:
@.***>

Still breaking jupyter notebooks for me, currently on 0.8.46. MacOS 12, working on remote linux server via ssh.

My team and I have been experiencing this problem for the past several months. Still happens on 0.8.47 and 0.9.200. We are connecting to a Linux host over SSH from a Windows 10 client.

Also having this problem. MacOS 12 remote SSH to Ubuntu 22.04

0.8.51 does not work with jupyter; some cells are processed, then it stops without errors and it looks like as if the connection to the jupyter runtime is lost

tried 0.9.212 and 0.8.27. Both have the problem of unresponsive cells when running a cell. No error message was shown. Ssh terminal still works. If I switch to a single py file, both Continue Dev and the py file work fine.

tried 0.9.212 and 0.8.27. Both have the problem of unresponsive cells when running a cell. No error message was shown. Ssh terminal still works. If I switch to a single py file, both Continue Dev and the py file work fine.

Anychance you are getting a notification that said something like "No notebook document found"?

tried 0.9.212 and 0.8.27. Both have the problem of unresponsive cells when running a cell. No error message was shown. Ssh terminal still works. If I switch to a single py file, both Continue Dev and the py file work fine.

Anychance you are getting a notification that said something like "No notebook document found"?

You are right. I got :
ERR NO notebook document for 'file:///home/pythonProject/Report/Combine_Order_Step_1.ipynb'

I think this has to do with auto completion function. I read other post that mention Pylance is the issue, but after downgrading it like they suggested didn't help.
I end up disabling the auto complete function by clicking the "Continue" logo on the bottom right status bar row. The problem gone away but I had to sacrafice AI auto completion.

tried 0.9.212 and 0.8.27. Both have the problem of unresponsive cells when running a cell. No error message was shown. Ssh terminal still works. If I switch to a single py file, both Continue Dev and the py file work fine.

Anychance you are getting a notification that said something like "No notebook document found"?

You are right. I got :
ERR NO notebook document for 'file:///home/pythonProject/Report/Combine_Order_Step_1.ipynb'

I think this has to do with auto completion function. I read other post that mention Pylance is the issue, but after downgrading it like they suggested didn't help.
I end up disabling the auto complete function by clicking the "Continue" logo on the bottom right status bar row. The problem gone away but I had to sacrafice AI auto completion.

I downgrade Pylance to 2023.11.40, and disable Continue's autocompletion function. New error message:
ERR unknown text editor: 3292c9c3-31fb-4306-aeb7-0fe85fc191d8. known editors:  : Error: unknown text editor: 3292c9c3-31fb-4306-aeb7-0fe85fc191d8. known editors:

tried 0.9.212 and 0.8.27. Both have the problem of unresponsive cells when running a cell. No error message was shown. Ssh terminal still works. If I switch to a single py file, both Continue Dev and the py file work fine.

Anychance you are getting a notification that said something like "No notebook document found"?

You are right. I got :
ERR NO notebook document for 'file:///home/pythonProject/Report/Combine_Order_Step_1.ipynb'

I think this has to do with auto completion function. I read other post that mention Pylance is the issue, but after downgrading it like they suggested didn't help.
I end up disabling the auto complete function by clicking the "Continue" logo on the bottom right status bar row. The problem gone away but I had to sacrafice AI auto completion.

I downgrade Pylance to 2023.11.40, and disable Continue's autocompletion function. New error message:
ERR unknown text editor: 3292c9c3-31fb-4306-aeb7-0fe85fc191d8. known editors:  : Error: unknown text editor: 3292c9c3-31fb-4306-aeb7-0fe85fc191d8. known editors:

Hmm I didn't got that, presumably you've already reloaded VSCode? You might need to do an extension bisect check to locate the extension that's having an issue. Just to "Ctrl + Shift + P -> Bisect"

Fixed for me using version: v0.8.27
The problem is that using command + I looks very slow.

It looks like others may be experiencing this even without Continue installed: https://github.com/microsoft/vscode-jupyter/issues/15716#issuecomment-2210755708

It looks like others may be experiencing this even without Continue installed: microsoft/vscode-jupyter#15716 (comment)

@sestinj That's in the case of WSL or Azure ML setups.
Myself and many others are getting this issue from this extension specifically, when running on MacOS (or even similar) and using a remote machine with Jupyter notebooks.
Sad because I really liked Continue. I can use this at v0.8.27 but if it never gets fixed I will have to switch to an alternative extension that does the exact same thing but doesn't break.

It looks like others may be experiencing this even without Continue installed: microsoft/vscode-jupyter#15716 (comment)

@sestinj That's in the case of WSL or Azure ML setups. Myself and many others are getting this issue from this extension specifically, when running on MacOS (or even similar) and using a remote machine with Jupyter notebooks.
Sad because I really liked Continue. I can use this at v0.8.27 but if it never gets fixed I will have to switch to an alternative extension that does the exact same thing but doesn't break.

I am using a MAC + SSH as well. So far disabling continue 100% solves this problem. But I can live with turning off autocomplete, which makes the frequency of the issue greatly reduced.

It looks like others may be experiencing this even without Continue installed: microsoft/vscode-jupyter#15716 (comment)

@sestinj That's in the case of WSL or Azure ML setups.
Myself and many others are getting this issue from this extension specifically, when running on MacOS (or even similar) and using a remote machine with Jupyter notebooks.
Sad because I really liked Continue. I can use this at v0.8.27 but if it never gets fixed I will have to switch to an alternative extension that does the exact same thing but doesn't break.

I second this, only getting this error when using Continue on a Jupyter notebook on WSL. Uninstalling the extension makes the bug go away, but Continue was just a really good way of using self-hosted machine learning models for coding assistance. Sad to see this issue is still around.

Thanks for clarifying this. I've marked this to be looked at this week. I hope to share more details soon

I can provide trace logs if needed.

+1
Continue extension breaks Jupyter notebooks in mac + ssh mode.

same issue with Continue while connected to remote container.

I can confirm that this issue appears over a VS Code 'Remote Tunnel' as well. Downgrading v0.8.27 resolves it - but not ideal.

I can confirm I run with the very same issue on mac connected to a remote container.

I also confirm, my setup is Windows + WSL jupyter notebook

I got the similar error, any updated ?

Our dev team have suffered from this problem for whole autumn. We are running jupyter notebooks in ubuntu server via VScode remote ssh tunnels feature. Notebooks are currently working with continue v0.8.27, but the features of the latest versions are much better... Pls fix this.

experiencing the same issue when doing development with jupyter notebook + remote ssh

I'd like to post log message that consistently pops up in Jupyter debug log when Jupyter notebook stop responding, looks like it has something to do with data streaming from remote -> local, but I am not sure what is the actual purposes of the stream and what initiates it.
16:34:47.455 [info] Disposing request as the cell (1) was deleted ~/[MASK]00.DataSetCheck.ipynb
16:34:47.456 [debug] Disposing kernel associated with ~/[MASK]00.DataSetCheck.ipynb, isClosed=true
16:34:47.457 [info] Dispose Kernel '~/[MASK]00.DataSetCheck.ipynb' associated with '~/[MASK]00.DataSetCheck.ipynb'
16:34:47.457 [debug] Cancel pending cells
16:34:47.460 [debug] Shutdown session eac0a4e6-bf46-475b-a69a-834ebc01bb6a, .jvsc74a57bd0162acd2e2db6c09933586b353efaebccac36360220c1c6227cd703d80c4ad48b./home/~/Toolkits/Anaconda/envs/radiomics/python./home/~/Toolkits/Anaconda/envs/radiomics/python.-m#ipykernel_launcher - start called from Error:
	at R_.shutdown (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:304:1140)
	at R_.dispose (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:304:623)
	at bs (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:115:867)
	at e (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:285:31789)
	at n_.dispose (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:285:32034)
	at fy.disposeOldKernel (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:285:23341)
	at fy.<anonymous> (/home/~/.vscode-server/extensions/ms-toolsai.jupyter-2024.8.1-linux-x64/dist/extension.node.js:285:21548)
	at gh.value (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:156:35160)
	at T.B (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:732)
	at T.C (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:802)
	at T.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:1019)
	at nh.$acceptDocumentAndEditorsDelta (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:155:13137)
	at Zb.S (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:155752)
	at Zb.Q (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:155532)
	at Zb.M (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:154621)
	at Zb.L (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:153859)
	at gh.value (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:152523)
	at T.B (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:732)
	at T.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:950)
	at no.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:9399)
	at gh.value (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:174:13273)
	at T.B (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:732)
	at T.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:950)
	at no.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:9399)
	at Im.A (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:12515)
	at gh.value (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:10935)
	at T.B (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:732)
	at T.fire (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:29:950)
	at m5.acceptChunk (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:7880)
	at file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:7166
	at Socket.t (file:///home/~/.vscode-server/cli/servers/Stable-384ff7382de624fb94dbaf6da11977bba1ecd427/server/out/vs/workbench/api/node/extensionHostProcess.js:31:15393)
	at Socket.emit (node:events:519:28)
	at addChunk (node:internal/streams/readable:559:12)
	at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
	at Readable.push (node:internal/streams/readable:390:5)
	at Pipe.onStreamRead (node:internal/stream_base_commons:191:23)
16:34:47.461 [debug] Dispose Kernel process 531368.
16:34:47.484 [debug] Kernel got disposed, hence there is no longer a kernel associated with ~/[MASK]00.DataSetCheck.ipynb

Can confirm bug persist in v0.8.56

Thanks for clarifying this. I've marked this to be looked at this week. I hope to share more details soon

Following up Nate @sestinj, in case there were any updates that week, or since.

Same here, F

Same here with Windows 11 and SSH to Ubuntu server 22.04

Hello,
I am by no means an expert, but I found that if I change C:\Users\User\.vscode\extensions\continue.continue-0.8.59-win32-x64\out\extension.js
line 540956:
if (!relativeFilePath.includes("Microsoft VS Code") && !ignoreInstance.ignores(relativeFilePath)) {
  recentlyEditedFilesCache.set(filepath, filepath);
}

It works!

Hello,
I am by no means an expert, but I found that if I change C:\Users\User\.vscode\extensions\continue.continue-0.8.59-win32-x64\out\extension.js line 540956:
if (!relativeFilePath.includes("Microsoft VS Code") && !ignoreInstance.ignores(relativeFilePath)) {
  recentlyEditedFilesCache.set(filepath, filepath);
}

It works!
edit: or not.. it worked for 5 minutes..

Tried and bug persisted unfortunately

I can confirm I'm running into the same issue in a similar remote SSH setting.

I have also been troubled by this problem for a long time.
My current solution is to add *.ipynb under C:\Users\username\.continue\.continueignore. I hope it can help everyone.

For me it seems to be caused by the combination of Ruff and Continue together. If I disable Ruff, I get no issues with Jupyter Notebooks; but no more linting & formatting that way.
Others that experience the same?

For me it seems to be caused by the combination of Ruff and Continue together. If I disable Ruff, I get no issues with Jupyter Notebooks; but no more linting & formatting that way.
Others that experience the same?

I am using ruff and continue so I figured it might be the same for me. Disabled ruff but the problem persisted. Only stops if I disable continue :(
ruff: v2024.56.0
continue: v0.8.60

Same issue here. Remote SSH, no ruff, continue 0.8.61.

I tried 0.9.245 and Jupyter problem did not take place at least within my brief trial. However, it did happen when I tried manipulating an ipynb throu SSH.

I tried 0.9.245 and Jupyter problem did not take place at least within my brief trial. However, it did happen when I tried manipulating an ipynb through SSH.

I guess you aren't using Windows and connect to WSL neither right?

I tried 0.9.245 and Jupyter problem did not take place at least within my brief trial. However, it did happen when I tried manipulating an ipynb through SSH.

I guess you aren't using Windows and connect to WSL neither right?

I made some correction to clarify my setting. My local machine is Windows11.

I tried 0.9.245 and Jupyter problem did not take place at least within my brief trial. However, it did happen when I tried manipulating an ipynb through SSH.

I guess you aren't using Windows and connect to WSL neither right?

I made some correction to clarify my setting. My local machine is Windows11.

Interesting...
Hope that the dev team can find the problem as soon as possible😢

The commit seen above solved the problem very reliably for me. I was previously seeing a crash after exactly 3 minutes every single time I opened an .ipynb and no longer see the crash at all after any period of time. For reference, I am testing on darwin-arm64, version 0.9.246 over Remote SSH to a small EC2 instance.
If folks here can try the latest version 0.9.246 and let me know whether it is working or giving different outcomes that would be very helpful.

The commit seen above solved the problem very reliably for me. I was previously seeing a crash after exactly 3 minutes every single time I opened an .ipynb and no longer see the crash at all after any period of time. For reference, I am testing on darwin-arm64, version 0.9.246 over Remote SSH to a small EC2 instance.
If folks here can try the latest version 0.9.246 and let me know whether it is working or giving different outcomes that would be very helpful.

It works for me 🎉 . Connected via SSH with continue and jupyter activated and the kernel is not dying!!

Fix seems to work! The kernel was working whole day yerterday! 🎉

Pre-release version 0.9.246 also fixed the problem for me when connecting to a Linux server via ssh from a Mac. Yay!

I still have the problem after updating to 0.9.246. I am using Jupyter Notebook via ssh on Mac. "NO notebook document for 'file:///home/....ipynb'"

I still have the problem after updating to 0.9.246. I am using Jupyter Notebook via ssh on Mac. "NO notebook document for 'file:///home/....ipynb'"

Are you using plotly by any chance?

Are you using plotly by any chance?
No

authors: AngelUrq B3hem0th Capsar DSep Davietay Gibo-Chun JnsLns Konano MRKonrad MrDasix PolushinM alabamagan anhalu dankvitek derluke edgBR icannos ilyanoskov in-principio jeffliu-LL jugodfroy ktakanopy lulmer magnooj ml-w mrvlasyuk msjfuria otavio-silva pascal456 peterkilfeather sattary sestinj shinthor sususu98 terosset tf-koichi theonlyfoxy timchann124 timsu92 ttkrpink wjacobward

repo: continuedev/continue


text:
✨ add Cohere as Reranker

Description
Closes #1122
Checklist

[x] The base branch of this PR is preview, rather than main

@maxbrunet flawless, thank you for the PR!
Related to this, I'm curious whether you're aware of any good re-ranking benchmarks outside of those from MTEB, particularly if they are specific to code?

Thank you @sestinj, would you have an idea when we can expect these features to be released?

Related to this, I'm curious whether you're aware of any good re-ranking benchmarks outside of those from MTEB, particularly if they are specific to code?

I asked Coral, our showcase chatbot, and it literally pointed me to one of your blog posts, so I might not bring much news to you unfortunately: https://blog.continue.dev/an-introduction-to-code-llm-benchmarks-for-software-engineers/
By asking around, Human Eval, MBPP, DS1000 were mentioned to me, and these 2 projects not in the blog post:

https://github.com/github/CodeSearchNet
https://github.com/Jun-jie-Huang/CoCLR

@maxbrunet I just now am pushing a pre-release version (0.9.119) including all of the updates.
Hilarious that it brought back our post... The links you shared are new to me though, thank you!

Sorry misspoke on releasing yesterday. Working on a fix that had to happen before, then ideally today will be out

No worries, would it possible to have matching Git tags on the commits used to build them too? I had not realized there were versions published without Git tag
Also what about JetBrains?

@maxbrunet JetBrains doesn't yet have support for codebase retrieval, but this isn't far off, just a small refactor I want to get in beforehand.
It's true that pre-releases don't get tagged or added to GitHub releases. The plan is to only tag main releases because pre-release happens so much more frequently (unless there's a really strong reason why this should be considered)

JetBrains doesn't yet have support for codebase retrieval

Ok, that's fine, no hurry, beyond cobase retrieval, I was also wondering if Cohere as model provider was released there

The plan is to only tag main releases because pre-release happens so much more frequently (unless there's a really strong reason why this should be considered)

Git tags are cheap and make it easy to identify if a commit is part of a release, e.g.

It also makes it straightforward to bisect between two releases if something breaks

That's a fair enough point about bisecting. Seems reasonable enough for us to start tagging pre-releases then
I'm working on getting JetBrains 0.0.46 out the door right now, but the store will probably accept it on Monday morning. This will include the Cohere model provider

authors: maxbrunet sestinj


text:
codedeploy script: handle deploying to multiple regions, codebases can set their own defaults

sequentially handle deploy for a set of more than one AWS region

can we keep tokyo and nairobi on the old version of this gem and deploy with that, until we update their deploy scripts?

We're also deploying tokyo to EU so we should ensure we roll out any updates to both regions.
TBH we'll likely forget about those apps, so I'd try to do now instead of leaving the tech debt, especially if it's not too complicated to update.

i am planning to do the updates to tokyo and nairobi immediately, but wanted to merge this update first :)

authors: anero warsucks

repo: controlshift/hashicorptools

license: mit

license_source: bigquery


text:
🛑 MPS - TESTPROCESS is down

In e3b4601, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 880 ms

Resolved: MPS - TESTPROCESS is back up in 2824c34 after 6 minutes.

repo: conuti-das/status-lfrcs


text:
🛑 MPS - TESTPROCESS is down

In 1ce6c53, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MPS - TESTPROCESS is back up in fff770a after 10 minutes.


text:
fix AggregationAreaController (convert to WGS84)

Previously it was streaming the raw, possibly projected geometries
without even checking whether they were in WGS84 or not. It did not
complain that they were not in WGS84, just said they were too big (since
the units were meters or feet instead of degrees as expected).
This is one small part of #213 which we are applying as a bugfix.

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@dca754b). Click here to learn what that means.
The diff coverage is 0%.

@@          Coverage Diff           @@
##             dev     #239   +/-   ##
======================================
  Coverage       ?   22.74%
  Complexity     ?      105
======================================
  Files          ?       63
  Lines          ?     2467
  Branches       ?      231
======================================
  Hits           ?      561
  Misses         ?     1870
  Partials       ?       36

Impacted Files
Coverage Δ
Complexity Δ

...al/taui/controllers/AggregationAreaController.java
12.32% <0%> (ø)
2 <0> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dca754b...ac3e1a8. Read the comment docs.

authors: abyrd codecov-io

repo: conveyal/analysis-backend


text:
Add continuous language option

What
Add continuous language option

Added a module to determine whether a language can ignore whitespace.
If it is a language that can be ignored (i.e. a continuation language), whitespace is made maybe

Why
In particular, languages like Japanese, where words are not separated by spaces, cannot be parsed, so this has been fixed.

For instance 砂糖300g <- 砂糖=sugger

How
Add ContinuousLanguageLocale module to judge that current locale use continuous language.

hmm
While loading ./spec/ingreedy_spec.rb a `raise SyntaxError` occurred, RSpec will now quit.
Failure/Error: require File.join(path, "dictionary_collection")

SyntaxError:
  /home/runner/work/ingreedy/ingreedy/lib/ingreedy/dictionary_collection.rb:11: syntax error, unexpected ','
  ...cale] = Dictionary.new(locale:, **attributes)
  ...                              ^
  /home/runner/work/ingreedy/ingreedy/lib/ingreedy/dictionary_collection.rb:41: syntax error, unexpected ','
  ...le] ||= Dictionary.new(locale:, **load_yaml(locale))
  ...                              ^
  /home/runner/work/ingreedy/ingreedy/lib/ingreedy/dictionary_collection.rb:41: syntax error, unexpected ')', expecting `end'
  ...w(locale:, **load_yaml(locale))
  ...                              ^
  /home/runner/work/ingreedy/ingreedy/lib/ingreedy/dictionary_collection.rb:52: syntax error, unexpected end-of-input, expecting `end'

Omitting the hash value seems to be a Ruby 3.1 feature, sorry
https://blog.saeloun.com/2021/09/28/ruby-allow-value-omission-in-hash-literals/
It should be Dictionary.new(locale: locale, **load_yaml(locale))

Please also consider bumping version.rb to 0.1.1 🙇 Actually maybe there is no need to do this

hmm. I think so too.

authors: liamnichols sota-horiuchi

repo: cookpad/ingreedy


text:
[Bug]: An error occurred during authenticating with GitLab.

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description
When i create application from gitlab source, An error occurred during authenticating with GitLab. may be request gitlab user info api was wrong!

Steps To Reproduce

(in Coolify) In Git Sources, add a new GitLab source.
In a new browser tab, navigate to your GitLab instance and find the UI to add a new application.
(in GitLab) Enter the Callback URL as https://coolify.yourdomain.com/webhooks/gitlab.
(in GitLab) check the following scopes: api, read_repository, email.
(in GitLab) Save the application and copy the Application ID .
(in Coolify) In your new source, paste the Application ID.
(in GitLab) In the newly created application, copy the Secret.
(in Coolify) Paste the Secret.
(in Coolify) Enter the OAuth ID. It will be the located at the end of the url of your GitLab application: https://yourgitlabdomain.com/oauth/applications/123456.
(in Coolify) Hit save.
(in Coolify) In Applications add a new application with GitLab as the source.
If you're still logged into GitLab, an authorization popup will appear. Click authorize.

Version
3.12.22

Is this still an issue?

authors: andrasbacsai nekic

repo: coollabsio/coolify


text:
Batch size does not decrease encoding time.

Hello,
I am using the plugin and python package to encode and noticed that increasing the batch size doesn't increase the encoding speed.
I have 4070ti and I got the following results.
Batch size: Time in sec
1: 141.44510889053345
2: 279.85611724853516
3: 424.3098211288452
4: 425.72585558891296
Code I used to get the result:
times = {}
for i in range(1,5):
start_time = time.time()
img_encoder = ImageEncoder(ckpt, batch_size=i)
img_encoder.encode_image(image_path,feature_dir)
init_settings, encode_settings = geosam.split_settings(settings)
times[i] = time.time() - start_time

I found a few issues in your code that I'm not sure if you have passed the batch parameter correctly.
init_settings, encode_settings = geosam.split_settings(settings)

This line doesn't seem to be used to encode image in your code. Besides, if you are using parameters from a file, you need to update the batch in settings:
settings.update({"batch_size":i})
init_settings, encode_settings = geosam.split_settings(settings)

ImageEncoder only needs to be instantiated once. Instantiating it multiple times may lead to the checkpoint being loaded into memory multiple times, causing high memory usage.
So, I suggest changing it to:
times = {}
img_encoder = ImageEncoder(ckpt, batch_size=i)
for i in range(1,5):
    start_time = time.time()
    img_encoder.batch_size=i
    img_encoder.encode_image(image_path, feature_dir)
    times[i] = time.time() - start_time

Regarding increasing the batch size, the encoding time did not decrease. There are many similar discussions online, and it seems that there is no consensus.
https://discuss.pytorch.org/t/increasing-batch-size-didnt-help-reduce-training-time/100960
https://discuss.pytorch.org/t/execution-time-does-not-decrease-as-batch-size-increases-with-gpus/85750
https://discuss.pytorch.org/t/increasing-batch-size-didnt-help-reduce-training-time/100960
As for SAM, I think this may be because SAM is a large model, and one batch has already occupied all the CUDA cores of your computer. Increasing the batch size in memory will only reduce the number of I/O operations and cannot reduce the model’s running time. In our early tests on A100, increasing the batch size could reduce the running time.
In your case, increasing the batch size seems to increase the running time. I guess this may be because our code does not clear the data in the GPU after encoding the image, which causes insufficient GPU memory and a certain amount of I/O with the computer’s memory to prevent memory explosion, thereby reducing the subsequent running speed. We have updated GeoSAM-Image-Encoder to clear memory after each image encoding. We recommend testing it again after reinstalling it using the following code:
pip install GeoSAM-Image-Encoder --upgrade
# or
pip install GeoSAM-Image-Encoder==1.0.4

Thanks for your feedback. We will test this issue and try to find the problems.

Hi @4del-Yousefi ,
My previous guess should be correct based on testing on A100. Even on A100 (6912 cuda cores), when the batch size is increased to 2, the cuda utilization has reached 99%. Increasing the batch size further only puts more data into the GPU, but the GPU cuda cores have been fully utilized and cannot reduce the overall running speed. Therefore, only when the number of cuda cores is extremely large can a significant decrease in runtime be observed when increasing batch size.
Below are my test code and running times:
##  Download example dataset and sam `vit_l` checkpoint
wget https://raw.githubusercontent.com/coolzhao/Geo-SAM/main/rasters/beiluhe_google_img_201211_clip.tif
wget https://dl.fbaipublicfiles.com/segment_anything/sam_vit_l_0b3195.pth
wget https://raw.githubusercontent.com/coolzhao/Geo-SAM/dev/GeoSAM-Image-Encoder/examples/data/setting.json

import time
import geosam
from geosam import ImageEncoder

checkpoint_path = './sam_vit_l_0b3195.pth'
image_path = './beiluhe_google_img_201211_clip.tif'
feature_dir = './'

## init ImageEncoder
img_encoder = ImageEncoder(checkpoint_path)

## test
times = {}
for i in range(1,5):
    start_time = time.time()
    img_encoder.batch_size=i
    img_encoder.encode_image(image_path, feature_dir)
    times[i] = time.time() - start_time

print(times)

{1: 5.970345973968506,
2: 3.5587611198425293,
3: 3.5929696559906006,
4: 3.5436811447143555}

authors: 4del-Yousefi Fanchengyan coolzhao

repo: coolzhao/Geo-SAM


text:
1.4.3 - Fix for #904

We track the human readable timeline_name and return it during emitted signals

Please note this is KIND of a breaking merge, as rather anyone who was doing comparisons with the randomly generated ID, will now have to do it with the human readable name/path-name

repo: coppolaemilio/dialogic


text:
Vagrant examples using out-dated user-data.sample

The user-data.sample file within the hack/ directory for Vagrant isn't up to date it seems. It's missing some stuff relating to the checkpointer's checkpoint-secrets directory, and im not sure what else, but the checkpointer isn't running when I attempt to use Vagrant.

Can you update with what hack cluster you're using (single-node or multi-node) and logs from kubelet trying to start the pod, or logs from the pod starting or something? I've run on single-node and multi-node several times without issue with the checkpointer.
Also, looking at https://github.com/coreos/bootkube/blob/master/hack/multi-node/user-data.sample#L32 it seems the dir is being created by that unit.

@chancez also, be sure you  rm -rf $dir/cluster in case you had old rendered cluster assets. The script does not remove and recreate that dir every run.

Oh whoops, I didn't have that in the README I was referencing. I had an open vim buffer referring to the old README before I ran git pull so I didn't notice that addition.

authors: chancez derekparker

repo: coreos/bootkube


text:
handlers: Add /robots.txt

I've seen /new pop up in Google results, and there's nothing of value
to crawl here anyway. Prevent all nice robots from snooping around,
especially from tutorial URLs.

lgtm, thanks.

authors: jedsmith philips


text:
etcd3 api documentation

I work in a primarily java and python organization. We would like to start integrating etcd3 into our system. I understand that etcd3 is still in alpha, but by the time we are done with dev/integration work etcd3 will most likely be production ready.
To that end  I was looking for documentation, similar to v2 api docs ("Communicating with etcd" section at https://coreos.com/etcd/docs/latest/), on v3 api. However, I came up with very few pages, and they require reading proto and go source code. The pages that I'm referring to are: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_reference_v3.md and
https://coreos.com/etcd/docs/latest/rfc/v3api.html
So I'm wondering if there is documentation similar to v2 api docs? In case that reading of source code and protobuf definitions (i.e. .proto files) is required, how stable are definitions and examples/v3 client code?

@eho-eho We have reference doc for v3 api https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_reference_v3.md.
If you look for Java client, we have https://github.com/coreos/jetcd.
You can do the same thing for Python. Generate Protocol Buffer files in Python, and write client code in Python.

@eho-eho Proto is the API spec and it is stable. We do not have an API spec for v2, the doc for v2 is example style. We now use etcdctl as example doc: https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/interacting_v3.md
I understand not all people are comfortable reading protos. We are still trying to figure out the best approach here.

@gyuho
Thanks for the pointer to jetcd.
@xiang90
Thanks for the link. I'm OK with reading protos. The only thing that I was wondering about is stability. Don't like when things change under me, that's all.

@eho-eho We will make it backward compatible. So closing this issue.

authors: eho-eho gyuho xiang90

repo: coreos/etcd


text:
quay.io/coreos/etcd HTTPS Health Check

I want to run the official etcd image in Docker Compose with TLS. Other services in the compose file depend on etcd so I have a health check dependency setup such as with
  proxy:
    image: quay.io/coreos/etcd:latest
    ...
    healthcheck:
      test:
      - CMD-SHELL
      - wget -qO- http://127.0.0.1:2379/health || exit 1

  skydns:
    image: gcr.io/google_containers/skydns:2015-10-13-8c72f8c
    ...
    depends_on:
      proxy:
        condition: service_healthy

That worked fine using HTTP but as I'm transitioning to HTTPS, the following
  proxy:
    image: quay.io/coreos/etcd:latest
    ...
    healthcheck:
      test:
      - CMD-SHELL
      - wget -qO- https://127.0.0.1:2379/health || exit 1

no longer work unless I install the libressl package in Alpine Linux that
forces me to maintain my own image which is not ideal.

Why not have separate image of yours with libressl? We only use Alpine Linux as base image to run sh inside container.

Is there another way to accomplish this without having to build my own image such as running HTTP only on localhost and HTTPS publicly?

@AverageHumanoid yes, the flag would be something like --listen-client-urls http://loccalhost:2379,https://outside-ip:2379

This works but https://0.0.0.0:2379 can not be used together with http://127.0.0.1:2379 so I need to get the specific address by creating another docker-entrypoint.sh. After Docker execing into the container, wget -qO- http://127.0.0.1:2379/health works but how come etcdctl --endpoints "http://127.0.0.1:2379" returns certificate error over HTTP?

@AverageHumanoid what flags are you using to launch etcd?

@heyitsanthony
etcd \
--name 4b105194f85d \
--data-dir /tmp \
--listen-client-urls https://172.17.0.4:2379,http://127.0.0.1:2379 \
--discovery https://discovery.etcd.io/f2892c0c05151b1b68fa1d90a9e80515 \
--proxy on \
--cert-file /certs/proxy1.pem \
--key-file /certs/proxy1-key.pem \
--peer-cert-file /certs/proxy1.pem \
--peer-key-file /certs/proxy1-key.pem \
--peer-client-cert-auth \
--peer-trusted-ca-file /certs/ca.pem

etcdctl \
--endpoints "http://127.0.0.1:2379" \
-ca-file /certs/ca.pem \
--cert-file /certs/client.pem \
--key-file /certs/client-key.pem \
cluster-health

Also works.

@AverageHumanoid I realized etcdctl may be syncing its endpoints and then choosing the https one-- try it with etcdctl --no-sync --endpoints "http://127.0.0.1:2379"?

@heyitsanthony etcdctl --no-sync works so this resolves my problem.

authors: AverageHumanoid gyuho heyitsanthony


text:
Godeps: semantic versioning cheggaaa/pb

Fix https://github.com/coreos/etcd/issues/4832.

/cc @xiang90 @heyitsanthony
Thanks.

lgtm

lgtm

authors: gyuho heyitsanthony xiang90


text:
Use --random-fully when creating MASQ rules

Description

This makes Flannel apply a workaround for the infamous Linux conntrack race that causes major problems for many Kubernetes deployments, often manifesting as DNS delays or failures (see https://github.com/kubernetes/kubernetes/issues/56903, https://github.com/weaveworks/weave/issues/3287, https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts and many others).
Todos

[ ] Tests

Release Note

If the underlying iptables binary supports it, use --random-fully when creating MASQ rules

Change looks good. Confirmed that v1.6.2 of iptables is in the latest alpine release so taking this PR.

authors: tomdee vainu-arto

repo: coreos/flannel