Update/streamline operations

[bxffour]

Addresses: #9

This commit refactors most of the codebase, isolation several core logic into their own packages. The init command was added to ensure all dependencies are available. The create command was added to create microvms and the run command was added to run microvms.

New commands

Init

This ensures all the dependencies are available

# spitfire init

output:

2023/08/12 17:06:27 INFO init binary is ready to go
2023/08/12 17:06:27 INFO vmlinux binary is ready to go
2023/08/12 17:06:27 INFO firectl binary is ready to go

Create

This command creates the microvm image from a container image

• To create just the rootfs

# spitfire create --image alpine:latest test

• To create the init drive to go alongside the rootfs

spitfire create --init --image alpine:latest test

Run

This command runs the microvm

# spitfire run <image name>

[Joe-Degs]

• might be wise not to tie the create command to only creating drives from OCI images. the constants are the fstype, size and name (or path to put it). whether we want an image burned into the loop drive should be optional

[bxffour]

Are you suggesting that we pull container images without making drives out of them?

[Joe-Degs]

• i don't think an init command should be downloading stuff from the internet. the name does not imply that, command should imply the action they perform, so pull/download will be better for things that pull from the internet. you know where my mind is at

[bxffour]

I agree. What name would you suggest though. The idea is that it's a command that makes sure that all dependencies are met

[Joe-Degs]

there is a utils.Exists function

[blackprince001]

LGTM. great work bro

[buabaj]

LGTM bro
however, it would be much better if you made smaller PRs to ensure effective reviews as large PRs are pretty clumsy and make thorough reviewing a pain.
Also, could you consider modularizing most of your code into reusable functions to prevent duplication and ensure consistency?
i also believe you can do more effective validation and error-handling for certain things like parsing in flag values, etc(make sure you don't get any expected behaviour if users don't parse flags you're expecting).
Logging and messaging also don't appear to be enough, it's fine if you want to do those later but please don't overlook it.

otherwise, everything else lgtm as I mentioned. you should as well look into Joe's comments. I think he makes a good argument about whether or not having an image burned on the drive is optional (unless I'm missing some context)