New pull requests are not being checked against the standard suite of go checks. This issue tracks the fix which ensures this occurs.

This issue tracks the use of the Unikraft Governance tool governctl to automatically synchronize labels within the KraftKit project.

A new GitHub actions pipeline should be created that is run when this file is updated.

This issue tracks the ability to toggle timestamps on the logger via the configuration option:

The adjusment should adopt the option design pattern.

This issue tracks the addition of https://github.com/juju/errors such that errors can be better understood. Based on the juju errors' README, we need to use the juju errors package to replace the internal package's definition of errors with juju's, i.e.:

index 8206a12..4d88304 100644
--- a/internal/errs/defs.go
+++ b/internal/errs/defs.go
@@ -4,7 +4,9 @@
 // You may not use this file expect in compliance with the License.
 package errs

-import "errors"
+import
+       "github.com/juju/errors"
+)

However, we actually do NOT need to replace the above, in fact, since internal/errs declares the same (subset) of errors, this can be removed since they will be duplicate. Only when we add new error types (which is possible), would we need to restore this package with custom definitions. Let's hold off for now and simply remove this package.

Instead, to continue this work, I would recommend going through the KraftKit source code and replacing all instances of return fmt.Errorf and errors.New with valid juju errors wrappers. This will allow us to a). classify each error into a category and b). allow us to unwrap each error nicely since the system will homogenise. The moment where errors are actually printed to the console occurs in cmdfactory.Main:

For the first iteration, this needs to be replace with juju errors' Unwrap or Trace method which will output the call stack or the list of errors which have occurred.

Finally, the code related to "user" look up can be removed entirely since this is out-of-scope of the project.

This issue tracks adding more helpful error messages when parsing a Kraftfile which is syntactically (or logically) in correct. The error message should attempt to point to where the error was encountered and suggest a remedy.

If the number of processes handled by the paraprocess package is greater than the size of the terminal window, the output is severely distorted.

This issue tracks better managing the output such that the render on the terminal is legible.

This issue tracks the parsing and injecting of all configuration options of KraftKit such that they become available as CLI arguments to any KraftKit program.

This change should replace the following in-line hacks:

• #29
• #17
• #18
• #19
• #20
• #22

This issue tracks the ability to have a "template" within the kraftfile, such that its contents is retrieved and applied as a base before the user's kraftfile is applied (in a additive fashion).

Templates offer a convenient way to using pre-configured Unikraft constructs as the basis for your application.

When initializing a new project to be built as Unikraft unikernel,

Examples

Example 1

The following template:

spec: 0.6
name: my-template
version: 0.0.1
unikraft: 0.9
libraries:
  - newlib: v123
targets:
  - arch: x86_64
    plat: kvm

when used:

spec: 0.6
name: my-app
version: 0.0.1
template: my-template:0.0.1

Results in:

  spec: 0.6
  name: my-app
  version: 0.0.1
- template: [email protected]
+ unikraft: 0.9
+ libraries:
+   - newlib: v123
+ targets:
+   - arch: x86_64
+     plat: kvm

Example 2

spec: 0.6
name: my-template
version: 0.0.1
unikraft: 0.9
libraries:
  - newlib: v123
targets:
  - arch: x86_64
    plat: kvm

Using the template:

spec: 0.6
name: my-app
version: 0.0.1
template: [email protected]
unikraft:
  version: 0.9
  kconig:
    - MYLIB=y

Results in:

  spec: 0.6
  name: my-app
  version: 0.0.1
- template: [email protected]
  unikraft:
    version: 0.9
    kconig:
      - MYLIB=y
+ libraries:
+   - newlib: v123
+ targets:
+   - arch: x86_64
+     plat: kvm

Implementation

1. Add a new optional directive to the kraft-spec.json so as to interpret a string or component by the name template.

2. Create a new a new unikraft package, unikraft/template with the following:

type TemplateConfig struct {
	configuration.ComponentConfig

	Type component.ComponentType `yaml:",omitempty" json:"type,omitempty"`
}

3. Add Template to ApplicationConfig:

type ApplicationConfig struct {
	component.ComponentConfig

	WorkingDir    string                `yaml:"-" json:"-"`
	Filename      string                `yaml:"-" json:"-"`
	OutDir        string                `yaml:",omitempty" json:"outdir,omitempty"`
+	Template      template.templateConfig   `yaml:",omitempty" json:"template,omitempty"`
	Unikraft      core.UnikraftConfig   `yaml:",omitempty" json:"unikraft,omitempty"`
	Libraries     lib.Libraries         `yaml:",omitempty" json:"libraries,omitempty"`

4. Introduce similar functionality to loadUnikraft but for a single template. Use WithType and set it to unikraft.ComponentTypeApp.

5. So far, the schema is a static declaration of the project which has not used for dynamic population, we must wait until the template can be fully rendered, i.e. just-in-time. Whilst it does have access to the package manager which does allow it to retrieve information, it has never been used so far to pull down components. This is largely because we also want to pass to a context.Context object just-in-time as well as additional things to the pulling mechanism (e.g. a progress bar function). The next step should be to simply add this new component to the list of known components to the application but this is faced with conflicting information "just-in-time" since the template will also need to provide to us new additional information, and therefore potentially new components. This means that during sequences such as this would not fully render by the intention of fulfilling the goals of a template. To mitigate against this, we must throw an if a). a template is being used and b). the template component returns false with IsUnpackedInProject. The use of a template should be conditional to it already existing and so we must then add pre-emptive code to retrieve it by modifying both kraft build and kraft pkg pull in order to retrieve it.

6. In kraft build, add new logic to find and pull [before the invocation of project.Components(). This is can be achieved by directly invoking the package manager if a template is set and pulling pre-emptively. Similar logic should appear in kraft pkg pull. Ultimately, this code (along with other similar sequences should be abstracted into internal/cmd/<similar sequence methods>.

7. Back inside of schema, the method created earlier and inside the Load method, since we now have access to the template data, we can re-populate the whole returning project. Override values from the template by calling NewApplicationFromOptions with the same options on the template. Start initially by loading the template, then override anything that is provided by the user.

8. Since we have now added potentially new configuration options which were not originally provided to us on an initial call of NewApplicationFromOptions, we must in fact change the way we are operating with regard to accessing these values. Unexport all ApplicationConfig attributes and migrate these to methods, e.g. Libraries becomes func (ac *AppplicationConfig) Libraries ([]*lib.LibraryConfig, error). The last error returns true if the template of the application is a). a set and non-empty and b). the template component returns false with IsUnpackedInProject. Update all references to make this change.

9. The above step guarantees access to the correct values at any moment of the use of the ApplicationConfig object, however, to initially populate these values, we must introduce options.go to the unikraft/app package. New options should be used during the creation of the ApplicationConfig, e.g. WithLibraries(libs ...*lib.LibraryConfig) (ApplicationConfigOption, error) which is able to add to the now private libraries attribute.

This issue tracks the addition of "buildenv"s which can be specified either within a Kraftfile:

  spec: v0.5
+ buildenv: kraftkit.sh:latest
  ...

Or as a CLI option i.e. ukbuild --build-env kraftkit.sh:latest ..

The build environment invokes the instantiation of a new container via containerd as the specified build environment, mounts the correct directories through host maps, and subsequently calls Unikraft's build system (via make).

The purpose of introducing such functionality is to abstract away the necessary dependencies for constructing a unikernel. By default, Unikraft requires a set of "build essential" tools. For language runtimes, such as Golang, python, etc., more bespoke tools are required to complete the build. Providing a suite of build environments aims to abstract these needs and additionally allow the developer to use kraftkit without needing to install any additional tools on their host other than kraftkit and containerd.

GitHub-Depends-On: #28

This issue tracks statically linking all binaries available in KraftKit.

The major overhead here is the use of github.com/libgit2/git2go which depends on libgit2-dev.

The reason for using this library is that it offers progress callback (so cloning a repo can be monitored). If native Go library which implements Git can offer the same, this should be used as an alternative. Otherwise, this issue also explores statically linking against the libgit2-dev shared library https://github.com/libgit2/libgit2

This issue tracks adding pipelines which are tagged as an official release.

The current pipeline is only for the staging branch and therefore pre-releases only.

See also:

• https://github.com/unikraft/kraftkit/blob/staging/.goreleaser-staging.yaml
• https://github.com/unikraft/kraftkit/blob/staging/.github/workflows/release-staging.yaml

This issue tracks the addition of two templates to be used to guide users reporting issues and contributing:

• #24
• #25

This issue tracks a series of support files which represent a shell script which is served at https://get.kraftkit.sh. The script should will be retrievable via:

curl --proto '=https' --tlsv1.2 -sSf https://get.kraftkit.sh | sh

The script should detect the host OS, (linux distribution if applicable), and provide a guided installation which offers to install KraftKit using either the native package manager or by downloading the latest binary. Checksumming should be embedded in the script.

The structure of the addition should resemble something like:

support/webinstall
├── Dockerfile  # Build environment
├── go.mod      # This is a small Go program HTTP server that dynamically injects relevant information into install.sh
├── install.sh  # The actuall installation script which is served
├── main.go     # The Go HTTP server
└── Makefile    # Build instructions

This issue tracks adding better explanations to each command and subcommand such that the help menu provides the user with excellent usage guidance.

This issue tracks adding support for compiling KraftKit for darwin (macOS) arm64.

This issue tracks the addition of a general installation screen when any of the kraftkit programs is used for the first time. The purpose of this screen is to help guide users with a mini-tutorial but also help customize their installation, e.g. with configuration options.

This issue tracks migrating the Dockerfile.gcc file to this repository. At the same time, having multiple versions of GCC would be nice and bring it up-to-date. The migration should also introduce a GitHub action's pipeline which builds the dockerfile.

Currently, if a channel name is used to retrieve a manifest package, the channel name is saved in the source cache. E.g. pulling unikraft:staging results in:

tree -a -L 2 ~/.local/share/kraftkit/
.
|-- manifests/
|   `-- ...
|-- plugins/
`-- sources/
    |-- apps/
    |-- libs/
    `-- unikraft-staging.tar.gz # <- channel name used here, not version

This will result in not being able to identify stale sources.

This issue tracks fixing this such that the version is used in the filename and the additional logic used to determine if the cache can indeed be used at that version given a channel name. This requires looking up the latest version in a given channel.

This issue tracks migrating the Dockerfile.qemu file to this repository. At the same time, having multiple versions of QEMU would be nice and bring it up-to-date. The migration should also introduce a GitHub action's pipeline which builds the dockerfile.

Providing a wrong argument to ukpkg source leads to a runtime error.

• #28
• #9
• #10
• #11
• #12
• #13
• #14
• #79
• #80

This issue tracks adding a configurable output format engine within KraftKit and related commands which produce an informational output, for example kraft pkg ls or kraft pkg info.

Task list:

• Investigate how kubectl get -o's output formatter works, it is quite configurable, e.g.:

  -o, --output='': Output format. One of:
      json|yaml|wide|name|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...
  

• The implementation should migrate the use of the existing tool tableprinter and use instead a more relevant library for outputting formatted data.

• A global option should be introduced into kraftkit.sh/config (Output) such that the format can be switched;

• Log output format be adjusted to the desired format when its set to json, overriding log.type.

• All tabular data should use a common interface such that its visible output can be adjusted dynamically and without requiring each instance to be reworked.

This issue tracks the ability to modify the pulled build environment image and inject necessary build tools as an OCI layer into the container filesystem either as the first layer (pre) or the last layer (post).

The functionality should be specified as CLI argument, i.e.:

• ukbuild --build-env python:3 --pre-glue-tools
• ukbuild --build-env python:3 --post-glue-tools

The injection will need to install a series of "build essentials" required by Unikraft's build system (e.g. make, gcc, wget, etc.). A simple layer can simply add these binaries to /usr/bin (or /usr/local/unikraft/bin?) and modify the PATH environmental variable. Statically compiling these tools/binaries such that no additional shared objects are necessary will make the injection distribution agnostic.

An investigation needs to occur to determine whether pre or post (likely post) is the better default operation.

GitHub-Depends-On: #49

This issue tracks the ability to simultaenously output logs via bubbletea's Printf method such that if an error occurs it is retrievable through the user's terminal. For now, the user interface hides this by truncating the build log and this is not helpful if a larger error occurs. To mitigate against this, simultaneously outputing this way (which would be hidden via bubbletea's UI window mechanism) so we can have the progress bar print still at the top.

This issue tracks this implementation fix.

This issue tracks the ability to add command line argument groups. This is useful to help displaly information on any invocation of the --help flag and to show flags which are part of either a common area, subsystem or category.

For example, all configuration options for KraftKit should be grouped together (see #35) as "global options".

This issue tracks the ability to simply check if there is a new release of this toolsuite. The check should simply probe Github's releases page and check whether the current version of any of the provided programs is less than the available program. The check should happen in the background in a separate thread to prevent disruption to the user's flow.

• #6
• #7

This issue tracks adding a pipeline step which uploads the .deb and .yum artifacts from goreleaser.

See:

• https://gemfury.com/help/apt-repository
• https://gemfury.com/help/yum-repository

An additional secret GF_TOKEN needs to be used in the pipeline to enable authentication.

Upon a successful ukbuild invocation, information about the constructed unikernels and pontential next steps (e.g. using ukrun) should be output. We can derive the paths of the unikernels and display this.

This issue tracks outputting such information.