Add `bcvk up`, inspired by Vagrant

[sysvion]

The run-ssh command from either the ephemeral as the libvirt subcommand currently works nicely. And it would be nice if those commands can also build the image from a Dockerfile. So that the user can run one command when they want to test something.

For creating this feature. I think making images build command first. Would be a great step. And then use the same approach for the ephemeral libvirt commands

[cgwalters]

Hi, thanks for your interest in the project!

Offhand this seems like something that could be wrapped up in e.g. a Justfile or slightly higher level tool. Conceptually today the bootc project is (mostly) independent of how an OCI image is built (which could include systems not from Dockerfile/Containerfile too). And also this project (bcvk) is scoped currently to just being a bridge between vitualization and bootc.

i.e.

$ cat Justfile
build:
    podman build -t localhost/someimage .

build-run: build
    bcvk ephemeral run-ssh localhost/someimage

right?

[gbraad]

I made Machinefile for this a while back. I use it to build vm images from a container file, see https://github.com/machinefile. Would consider this outside the scope of bootc, as it results in a derived approach.

[sysvion]

The use of external tools like just or a bash script works, but it is cumbersome when changing the parameters that going to be passed to bcvk. Like placing the vm to a more realistic network environment.

It is also nice when starting a project that there is one command to start a local server without a lot of configuration. And later when the new project has something. Then they can learn more of how the build process works when they try to make the first bootable usb/cd.

I have tested some things of how i can make spawning a virt friendlier as a starting project context. But there are a few that really works. And if one works. Then it is running a command that the user has provided.

Sample code:

use crate::libvirt::run;

#[derive(Debug, Parser)]
pub struct LibvirtBuildRunOpts {
    #[clap(flatten)]
    pub run_opts: run::LibvirtRunOpts,

    pub command: String,
    pub command_argv: Vec<String>
}

pub fn run(opts: LibvirtBuildRunOpts) ->  Result<()> {
    [...]
    hostexec::command(opts.command, None)
        .args(opts.command_argv)
        .run();
     [...]
     // check if there is a new image
     [...]
    return run::run_vm_impl(opts.run_opts)
}

Ideal parameter format

$ bcvk libvirt build-run --network=bridged=br0 -- ./buildImage.sh
$ bcvk libvirt build-run -- podman build

Do you know someone else that is going to use this? Because one polished path is better than a lot of unpolished ones.

Thanks for all the work put in this project.
--- Sysvion (Aron)

Context of my project

My student association is trying to host a website in our building with a spotty internet connection. (Thanks built heritage conservation)

This project going to be build and maintained by students. And we have the pleasure of almost constantly having multiple computer science majors.

I'm member of the commission building the first implementation.

[cgwalters]

I made Machinefile for this a while back. I use it to build vm images from a container file, see https://github.com/machinefile.

Right...pretty high overlap there with the bootc world as well as other things. I think the biggest thing here is that bootc's build process is a container build process which ensures that e.g. things like autogenerated host SSH keys, your bash history and logs don't leak into disk images.

It is also nice when starting a project that there is one command to start a local server without a lot of configuration.

Right. So...one thing I could imagine doing is having bcvk libvirt up which takes a page from Vagrant and operates on a virtual machine scoped to the project, using some basic config?
Obviously a huge difference vs Vagrant is that instead of using prebuilt disks we'd operate on a locally built container first, but it could have some extra sugar for injecting non-container content dynamically? Like test scripts or whatever?

---

Initial design: new bcvk project verb

• bcvk project up is a lot like bcvk libvirt run - except it automatically names and labels the VM based on the working dir name (and possibly git origin?). It won't recreate if one exists.
• Defaults to --bind-storage-ro
• Defaults to also --bind-ro $(pwd):/run/src
• Defaults --lifecycle-bind-parent (new feature! In this, we detect when the parent process exits, and when it does we automatically shut down the VM. This makes the feature Just Work if you run this from an IDE for example and then switch projects in the IDE, as your shell exits)

Configuration

Supports .bcvk dir which accepts a default .bcvk/config.toml file:

# Configure the launched image by default
image = "localhost/my-bootc-image"

Customizing images for development

Let's take a page from devcontainers...we want for a project to separate its default build from "stuff injected for development". A nice way to do this I think is to add even more sugar for injecting systemd units, one can add a .bcvk/units/foo.service which does whatever you want. Underneath this gets injected via SMBIOS credentials.

Other verbs

• bcvk project ssh is just wrapping bcvk libvirt ssh <name> (btw we should make this auto-start the VM if it's stopped)
• bcvk project down to explicitly shut down

[cgwalters]

OK put up #86 for this