On Fri, Jan 12, 2024 at 5:23 AM Juraj Linkeš <juraj.linkes@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.


>
> > +
> > +       // 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
> > +```
> > +
>