Describe the solution you'd like:
We currently have a blank readme. We need to change this and provide information about the project and also how to contribute. We need to include badges like the codecov badge

Why do you want this feature:
The project needs to provider information to its users and be a good open source citizen

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Change the logging used from Zap to Logrus. This is because the Firecracker SDK only uses logrus.

Describe the solution you'd like:
Create the skeleton of the Firecracker microvm provider. The functions will be unimplemented and will be implemented over time.

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
When saving the microvm spec in the repo we need to check if there is actually an update to the spec or not. If nothing has changed, then we don't need to take any action.

Why do you want this feature:

If we currently try saving where there is no update then an error is returned.

Anything else you would like to add:

Easiest way is to SHA256 hash the content and compare it to the digest of the content in the containerd content store.

Describe the solution you'd like:
A "plan" is needed with associated steps to create a microvm from the spec.

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Starting the initial work on the firecracker plugin

Integrate CNI into flintlock so that the network interfaces on the host are created/configured via CNI. We need to expose this via the API and also provide a default config.

Describe the solution you'd like:
Change the CLI infra to use urfave/cli instead of cobra/viper.

Why do you want this feature:
This is to make the future deployment option of being combined with containerd easier.

Anything else you would like to add:

Describe the solution you'd like:
Validate the changes to the microvm spec.

Why do you want this feature:

To protect the system from invalid specs. And provide good feedback to the user.,

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Basic Firecracker API calls

deb/rpm/ pick your linux package manager.

Do we need to make sure dependencies are specified or is that manual via docs?

Describe the solution you'd like:
Change the project to use mage instead of make. As a Go project mage will be easier to use instead of make.

Why do you want this feature:
Ease of use for Go engineers.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
Investigate if there are any benefits to using gogo protobuf over the standard protobuf tooling for go.

https://github.com/gogo/protobuf

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
I want to be able to get details of an existing microvm and list all microvms via the API.

Why do you want this feature:

As a consumer i need to know which microvms are running on which nodes.

Anything else you would like to add:

There are empty functions currently for the query methods.

Describe the solution you'd like:
The event bus implementation should be the containerd event service.

Why do you want this feature:
Instead of using a separate event bus we should use the containerd event service as it will make it easier responding to existing containerd events and we already are using contaierd for a bunch of other things.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Implement the release process.

To generate the release notes we need to use the release-notes cli from the kubernetes project. An example of how to use can be found here:
https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/Makefile#L429

Describe the solution you'd like:

Now there is the protobuf definitions and service we can use the protobuf generate types for the repository. This will remove the need to do conversions between the 2 api types.

Why do you want this feature:
Simplifies the implementation and removes the need to keep 2 different apis in sync

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
I want to be able to track the change in test code coverage. We should also block PRs that cause the code coverage to drop below a certain threshold.

Why do you want this feature:
To ensure we have adequate test coverage.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
Consider splitting out the gRPC gateway into a separate executable or command so it can be deployed separately.

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:

There is some prior art around using controller-runtime outside of Kubernetes. Investigate whether this will help with the implementation of the reconciliation part of reignite

Why do you want this feature:

If its possible to reuse existign code then it may save us having to develop a control loop from scratch.

Anything else you would like to add:

See this as an example:
https://github.com/ibuildthecloud/gitbacked-controller

Describe the solution you'd like:
A microvm has an identity that is made up of a name and namespace. This should be implemeted as a specific type instead of passing strimgs around

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
When requesting that a microvm is deleted via the API the spec for the VM should be marked as deleted but the content should remain.

The reconciliation loop should do the ultimate delete after the microvm has been removed.

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Describe the solution you'd like:
Refactor the microvm provider interface to make it simpler. Removed the provider registry.

Why do you want this feature:
There are only going to be 1 or 2 providers so we can use a simpler provider interface and no need for a registry

Anything else you would like to add:

Describe the solution you'd like:

Change the plan/steps so that it's aware of any changes in the environment to ensure it can re-create the desired state. For example, it should be aware that the Firecracker process has dies and create/config a new one.

Bug for specified issue: #178

Describe the solution you'd like:
A "plan" is needed with associated steps to delete a microvm from the spec.

Why do you want this feature:

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]