Flavours

A Flavour is a kind of way of running the Driver.

This enables you to use the best tool to run your test-script, without changing the composition itself.

Building a composition with a Flavour will create its Composition file in build/[composition_name]::[flavour_name].

Note

A composition’s Flavour can be changed any time: when you build your composition with a Flavour, it will store the result for that specific Flavour. You can have multiple built compositions stored under the build directory.

Once built, you can deploy the composition with this Flavour whenever.

Warning

When it comes to the Deploy phase, you first need to have your composition built with the Flavour you are trying to use!

Nix

A Flavour is also defined within the Nix code, under flavours. It constructs an output specific to the Flavour you requested.

Image type

You can specify the kind of output Nix produces in the flavour-type (defined in nix/flavours.json, nixos_compose/models/flavour.py & your Nix implementation nix/flavours/[...].nix).

Note

This Image type is quite central to evaluating the Nix output, it is used to evaluate flavoured_all.

Development specifications

A Flavour inherits the FlavourABC type.

Depending on your implementation & behaviours, you can inherit other types (such as LaunchableABC, CanStartAllABC & others…). Those enable a more precise implementation of some features.

Flavour-specific build process

You can override the build function to define your own behaviour after building the Nix flavour output.

Note

An example of this can be found within G5kImageScriptFlavour.

It contains a function that runs the script produced by Nix to generate the tarball to deploy.

Generating Deployment info

The Flavour is responsible with generating the Deployment info by overriding generate_deployment_info.

At this point, the Flavour should retrieve & prepare all required data for creating the deployment info.

Driver initialization

The function driver_initialize defines behaviour for initializing the Driver & its Machines.

Note

It is very common for Flavours to have their own inherited Machine type (such as Grid5000Machine) to hook some test_script/repl calls.

Driver initialization is where you would inject your own, when instantiating your Machines.

Clean up

In case you have any permanent resources you used temporarily & want to clean-up, you should use the cleanup function.

Warning

Although it may looks like it, it is possible for this function to NOT get called (it could get skipped if NixOS-Compose gets killed while still running). Manual clean-up methods should be ready just in case.

LaunchableABC

When Starting with a LaunchableABC Flavour, an additionnal process will be applied to the environment for this Flavour.

Currently quite hard-coded to Grid5000 behaviour, it does:

• Generating KExec script, if supported
• Pushing kernel, initrd & kexec script to another machine, if necessary.
• Start HTTPD for Kernel param retrievial
• Call launch

Launch

Launch is a special process that is called designed to overtake the Driver system, starting the experiment its own way.

Its behaviour is very Flavour dependent. The Starting process will exit(0) after completion.

CanStartAllABC

When the test_script (or repl) calls the start_all function, you can override the default behaviour by inheriting CanStartAllABC.

The process you defined with this override will take precedence over the standard NixOS-test-driver behaviour.