mini-ndn

Alexander Lane wrote:

we should either replace this with an up to date image hosted on a shared account for Mini-NDN developers rather than a personal one or remove the recommendation to use Vagrant when configuring a new VM for usage with Mini-NDN.

I'd normally advocate for the containerization approach. However, mini-ndn is special because it requires a privileged container, therefore losing all the isolation benefits. Personally I wouldn't run the mini-ndn container on my bare-metal machine, unless it's a dedicated machine for experimentation purposes. So in this particular case of mini-ndn, and assuming you'll want to run it in a VM anyway (for better isolation), it seems likely that a vagrant up would provide a simpler out-of-the-box experience compared to "set up VM + install docker + docker run".

if it's infrequent, we should likely just remove it and find a way to host VM images through a first party institution.

I'm not sure what you mean by this.

Also keep in mind that Vagrantfile != VM image (what they call "vagrant box"). E.g., we can just provide a Vagrantfile that starts with an ubuntuXX.YY image and installs mini-ndn as part of its provisioning script, similar to what a Dockerfile does for a Docker image. We don't have to provide/publish the final image ourselves if we don't want to maintain it over time. (Although, once we have the provisioning script, it should be straightforward to write a Github actions workflow that regenerates the image a few times a year and publishes it to https://portal.cloud.hashicorp.com/vagrant/discover).
The provisioning script itself could potentially be as simple as running the mini-ndn install script.

Davide Pesavento wrote in #note-2:

Also keep in mind that Vagrantfile != VM image (what they call "vagrant box"). E.g., we can just provide a Vagrantfile that starts with an ubuntuXX.YY image and installs mini-ndn as part of its provisioning script, similar to what a Dockerfile does for a Docker image. We don't have to provide/publish the final image ourselves if we don't want to maintain it over time. (Although, once we have the provisioning script, it should be straightforward to write a Github actions workflow that regenerates the image a few times a year and publishes it to https://portal.cloud.hashicorp.com/vagrant/discover).
The provisioning script itself could potentially be as simple as running the mini-ndn install script.

It's worth noting that Ubuntu is no longer supplying official Vagrant images after 22.04 LTS (https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890), which just kicks this issue down the road. I do not necessarily want to rely on third party base images, which would essentially mean that we would be building them ourselves after a point.
Additionally, the existing official Ubuntu images do not support ARM64 hosts, which is both an annoyance to me and likely to others on MacOS.

Davide Pesavento wrote in #note-1:

Alexander Lane wrote:

...we should likely just remove it and find a way to host VM images through a first party institution.

I'm not sure what you mean by this.

For example, the Mininet-Wifi project currently hosts a pre-made VirtualBox image. This is likely less elegant than hosting the image via Hashi's platform (and I'd prefer to do so via Memphis or someone else in the NDN project), but it would mean we're not reliant on a private platform or software that is no longer permissively licensed. The point about usage is mostly whether it's worth committing time to maintaining this going forward if it's not being used by others.

Per NDN call on 2/21, enough interest that it's likely worth pursuing. In particular, we should also focus on providing a VMWare Fusion image for users on ARM64 MacOS.

Alexander Lane wrote in #note-3:

It's worth noting that Ubuntu is no longer supplying official Vagrant images after 22.04 LTS (https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890), which just kicks this issue down the road. I do not necessarily want to rely on third party base images, which would essentially mean that we would be building them ourselves after a point.

Repeating here what I said at the call, FTR: in our jenkins setup we've actually always used third-party boxes for the ubuntu agents (see here) because the official Canonical-provided images were not usable out-of-the-box.

That being said, if third-party images are a concern, there is a tool (ubuntu-bartender) that can automate the process of creating our own base image.

For example, the Mininet-Wifi project currently hosts a pre-made VirtualBox image. This is likely less elegant than hosting the image via Hashi's platform (and I'd prefer to do so via Memphis or someone else in the NDN project), but it would mean we're not reliant on a private platform or software that is no longer permissively licensed.

I fully sympathize with the desire to only use (or strongly prefer) free software. However, the Mininet-Wifi image is not the best example given that it's hosted on Google Drive which is also a proprietary platform. And the vast majority of Docker images are hosted on DockerHub, GCR, or GHCR, none of which is "open". Personally, I believe we should be fine as long as our processes don't have a hard dependency on a specific closed/proprietary platform. Effectively, we're just using HashiCorp's vagrant registry and GitHub's container registry for hosting, it should be easy enough to switch platform or self-host if things change.

Alexander Lane wrote in #note-4:

we should also focus on providing a VMWare Fusion image for users on ARM64 MacOS.

That may be challenging to do on Github Actions. Last time I checked, the Github-hosted macOS/arm64 runners did not support nested virtualization. (EDIT: confirmed, it's explicitly listed as a limitation in Github's documentation)