On Fri, Jan 12, 2024 at 3:59 PM Jeremy Spewock <jspew...@iol.unh.edu> wrote: > > > > On Fri, Jan 12, 2024 at 5:23 AM Juraj Linkeš <juraj.lin...@pantheon.tech> > wrote: >> >> > diff --git a/dts/.devcontainer/devcontainer.json >> > b/dts/.devcontainer/devcontainer.json >> > new file mode 100644 >> > index 0000000000..6313cd3ded >> > --- /dev/null >> > +++ b/dts/.devcontainer/devcontainer.json >> > @@ -0,0 +1,33 @@ >> > +// For format details, see https://aka.ms/devcontainer.json. For config >> > options, see the README at: >> > +// >> > https://github.com/microsoft/vscode-dev-containers/tree/v0.241.1/containers/docker-existing-dockerfile >> > +{ >> > + "name": "Existing Dockerfile", >> > + >> > + // Sets the run context to one level up instead of the >> > .devcontainer folder. >> > + "context": "..", >> > + >> > + // Update the 'dockerFile' property if you aren't using the >> > standard 'Dockerfile' filename. >> > + "dockerFile": "../Dockerfile", >> > + >> > + // Use 'forwardPorts' to make a list of ports inside the container >> > available locally. >> > + // "forwardPorts": [], >> > + >> > + // Uncomment the next line to run commands after the container is >> > created - for example installing curl. >> >> The next line is uncommented, we should update or remove the comment. > > > Good catch, I'll change this. > >> >> >> > + "postCreateCommand": "poetry install --no-root", >> > + >> > + "extensions": [ >> > + "ms-python.vscode-pylance", >> > + ] >> > + >> > + // Uncomment when using a ptrace-based debugger like C++, Go, and >> > Rust >> > + // "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", >> > "seccomp=unconfined" ], >> > + >> > + // Uncomment to use the Docker CLI from inside the container. See >> > https://aka.ms/vscode-remote/samples/docker-from-docker. >> > + // "mounts": [ >> > "source=/var/run/docker.sock,target=/var/run/docker.sock,type=bind" ], >> > + >> > + // Uncomment to mount your SSH keys into the devcontainer used by >> > vscode. >> > + // "mounts": >> > ["source=${localEnv:HOME}/.ssh,destination=/root/.ssh,type=bind,readonly"] >> >> Should this SSH key correspond to the user below? > > > On one hand I agree it would be better to unify the two options, but on the > other we don't make a remote user in the docker image so the option below > can't be used anyway. I would be more in favor of just removing the > remoteUser option and leaving this the way it is as that would line up better > with what you can actually do with the container image we provide. > > Leaving it as a stub for something that could be done isn't a bad either > though, or I could also add the remote user to the container, but I don't > really see the need for a non-root user for running DTS currently. >
Thanks for the explanation. As there is no need for it and adding things that could be done (in other tools) seems out of scope to me, let's remove it. >> >> >> > + >> > + // Uncomment to connect as a non-root user if you've added one. >> > See https://aka.ms/vscode-remote/containers/non-root. >> > + // "remoteUser": "vscode" >> > +} >> >> <snip> >> >> > diff --git a/dts/README.md b/dts/README.md >> > new file mode 100644 >> > index 0000000000..dc88ec585e >> > --- /dev/null >> > +++ b/dts/README.md >> > @@ -0,0 +1,70 @@ >> <snip> >> > +#### Start docker container with SSH keys >> > + >> > +```shell >> > +docker build --target dev -t dpdk-dts . >> > +docker run -v $(pwd)/..:/dpdk -v /home/dtsuser/.ssh:/root/.ssh:ro -it >> > dpdk-dts bash >> >> We talked about possibly baking the key into the image, but this seems >> safer and pretty easy to use. >> I understand this is tailored to the lab and I'm thinking about other >> possible use cases, but it seems there would only be convoluted ones >> (possibly with some extra security considerations, which is generally >> not needed for testing purposes) where this doesn't do what we want it >> to. I'd say this is good enough. >> >> >> > +$ poetry install >> > +$ poetry shell >> > +``` >> > +
