-
Notifications
You must be signed in to change notification settings - Fork 650
nerdctl inspect
response responds to DevContainers with null
values
#3310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
kind/unconfirmed-bug-claim
Unconfirmed bug claim
Comments
nerdctl inspect
response does not include Ports: { }
for containers without published portsnerdctl inspect
response does not include Ports: {}
for containers without published ports
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 14, 2024
Related to containerd#3310 New behavior will always initialize a PortMap for the inspect response. If published ports are available, then values will be included in the response. Signed-off-by: Sam Chew <[email protected]>
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 14, 2024
Related to containerd#3310 New behavior will always initialize a PortMap for the inspect response. If published ports are available, then values will be included in the response. Signed-off-by: Sam Chew <[email protected]>
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 14, 2024
Related to containerd#3310 New behavior will always initialize a PortMap for the inspect response. If published ports are available, then values will be included in the response. Signed-off-by: Sam Chew <[email protected]>
1 task
nerdctl inspect
response does not include Ports: {}
for containers without published portsnerdctl inspect
response responds to DevContainers with null
values
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 15, 2024
Related to containerd#3310 New behavior will always initialize a NetworkSettings entity within the inspect response. If the target container does not exist, the NetworkSettings will be full of "zero-value" members. If the target container is active, but ports were not published, then the Ports key of NetworkSettings will have an empty structure value. If the target container is active and ports were published, then the Ports key of NetworkSettings will have populated values. Signed-off-by: Sam Chew <[email protected]>
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 15, 2024
Related to containerd#3310 New behavior will always initialize a NetworkSettings entity within the inspect response. If the target container does not exist, the NetworkSettings will be full of "zero-value" members. If the target container is active, but ports were not published, then the Ports key of NetworkSettings will have an empty structure value. If the target container is active and ports were published, then the Ports key of NetworkSettings will have populated values. Signed-off-by: Sam Chew <[email protected]>
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 16, 2024
Related to [containerd#3310](containerd#3310) New behavior will always initialize a NetworkSettings entity for the inspect response, including Ports child member. If inspecting a running container with published ports, then all information will be correctly returned. If inspecting a running container without published ports, then NetworkSettings will include an initialized Ports member. If inspecting a stopped/exited container, then an entirely initialized, "empty-value" NetworkSettings is returned. Signed-off-by: Sam Chew <[email protected]>
1 task
chews93319
added a commit
to chews93319/nerdctl
that referenced
this issue
Aug 16, 2024
Related to [containerd#3310](containerd#3310) New behavior will always initialize a NetworkSettings entity for the inspect response, including Ports child member. If inspecting a running container with published ports, then all information will be correctly returned. If inspecting a running container without published ports, then NetworkSettings will include an initialized Ports member. If inspecting a stopped/exited container, then an entirely initialized, "empty-value" NetworkSettings is returned. Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153
pushed a commit
to Shubhranshu153/nerdctl
that referenced
this issue
Sep 8, 2024
Related to [containerd#3310](containerd#3310) New behavior will always initialize a NetworkSettings entity for the inspect response, including Ports child member. If inspecting a running container with published ports, then all information will be correctly returned. If inspecting a running container without published ports, then NetworkSettings will include an initialized Ports member. If inspecting a stopped/exited container, then an entirely initialized, "empty-value" NetworkSettings is returned. Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153
pushed a commit
to Shubhranshu153/nerdctl
that referenced
this issue
Sep 8, 2024
Related to [containerd#3310](containerd#3310) New behavior will always initialize a NetworkSettings entity for the inspect response, including Ports child member. If inspecting a running container with published ports, then all information will be correctly returned. If inspecting a running container without published ports, then NetworkSettings will include an initialized Ports member. If inspecting a stopped/exited container, then an entirely initialized, "empty-value" NetworkSettings is returned. Signed-off-by: Sam Chew <[email protected]>
Shubhranshu153
pushed a commit
to Shubhranshu153/nerdctl
that referenced
this issue
Sep 8, 2024
Related to [containerd#3310](containerd#3310) New behavior will always initialize a NetworkSettings entity for the inspect response, including Ports child member. If inspecting a running container with published ports, then all information will be correctly returned. If inspecting a running container without published ports, then NetworkSettings will include an initialized Ports member. If inspecting a stopped/exited container, then an entirely initialized, "empty-value" NetworkSettings is returned. Signed-off-by: Sam Chew <[email protected]>
That was fixed by #3318 right? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When using VSCode DevContainers with
finch
to re-open a "workspace within a container" (after successfully opening "workspace within a container" once and exiting), the "DevContainers Log" reports the following error:TypeError: Cannot read properties of null (reading 'Ports')
.After some investigation, we observed two scenarios with
finch
usingnerdctl
:nerdctl inspect --mode=dockercompat
omits thePorts
key-value pair from theNetworkSettings
.nerdctl inspect --mode=dockercompat
inspects an "Exited" container, theNetworkSettings
key contains anull
value.Compared to the Docker scenarios:
docker inspect
, thePorts
key-value pair is present withinNetworkSettings
entity, but the value is an empty structure.docker inspect
inspects an "Exited" container, theNetworkSettings
key contains a complete structure of expected keys, all with "zero-value" values.This bug affects integration of VSCode DevContainers with
finch
because DevContainers expects the completeNetworkSettings
structure with all "zero-value" members for both of the scenarios.Steps to reproduce the issue
Scenario 1: Container without published ports returns NetworkSettings without Ports entity
a.
finch run -p 8080:80 -d alpine:latest sleep infinity
, which invokesnerdctl run -p 8080:80 -d alpine:latest sleep infinity
a.
finch inspect --mode=dockercompat <container_id>
, which invokesnerdctl inspect --mode=dockercompat <container_id>
Ports
entity withinNetworkSettings
structa.
finch run -d alpine:latest sleep infinity
, which invokesnerdctl run -d alpine:latest sleep infinity
a.
finch inspect --mode=dockercompat <container_id>
, which invokesnerdctl inspect --mode=dockercompat <container_id>
Ports
entity withinNetworkSettings
structInspecting an Exited Container
a.
finch run -p 8070:70 -d alpine:latest sleep infinity
, which invokesnerdctl run -p 8070:70 -d alpine:latest sleep infinity
a.
finch inspect --mode=dockercompat <container_id>
, which invokesnerdctl inspect --mode=dockercompat <container_id>
Ports
entity withinNetworkSettings
structa.
finch container stop <container_id>
, which invokesnerdctl container stop <container_id>
a.
finch inspect --mode=dockercompat <container_id>
, which invokesnerdctl inspect --mode=dockercompat <container_id>
null
value ofNetworkSettings
structDescribe the results you received and expected
For the "container with published port", the
NetworkSettings
includes the expectedPorts
struct and all appropriate information. This is already successful and should be maintained during any changes.The expected results should be as follows for the two scenarios:
nerdctl inspect --mode=dockercompat
should include thePorts
key-value pair within theNetworkSettings
with a value of{ }
.nerdctl inspect --mode=dockercompat
inspects an "Exited" container, theNetworkSettings
key should map to a struct containing all keys mapping to "zero-value" values.What version of nerdctl are you using?
Observed behavior with both:
- Local build from branch
release/1.7
- Local build from branch
main
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information
No response
The text was updated successfully, but these errors were encountered: