| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Change-Id: I4d229d0f4a9142e3bd427a8e63733426f5ca5bd9
Reviewed-on: https://cl.fcuny.net/c/world/+/412
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
| |
We add a new argument to the CLI to collect the path where we want to
publish the firecracker metrics.
|
|
|
|
|
|
|
| |
To help working on this project in the future, let's try to install
dependencies and configurations with `make`. For now we know that we
need the firecracker binary, the CNI configuration and the CNI plugin
for TAP.
|
| |
|
|
|
|
|
|
|
| |
By specifying these options we can speed up the boot process from 0.9
second to 0.15 seconds. Without these options, the linux kernel spends a
few milliseconds probing the device, which is useless in our context
(see https://github.com/firecracker-microvm/firecracker/blob/main/docs/api_requests/actions.md#intel-and-amd-only-sendctrlaltdel)
|
| |
|
|
|
|
|
|
|
|
|
| |
The binary needs a few more arguments: the path to the firecracker
binary, the path to a linux kernel.
Using the image that was generated, we can now boot the VM with
firecracker. This will rely on a CNI configuration to create the
network, and will use the provided kernel to boot.
|
|
|
|
|
|
|
|
|
| |
Add a target to the Makefile to download a version of firecracker and
extract it under the repository hack/firecracker. We will then use this
binary for running the VM.
Add a CNI configuration under hack/cni. This configuration will need to
be copied to `/etc/cni/conf.d`.
|
| |
|
| |
|
|
|
|
|
| |
When reading the configuration for the container, if there's an error we
return the error to the caller.
|
|
|
|
| |
Add a workflows to perform some validation when pushing new commits.
|
|
|
|
|
|
|
|
|
| |
Once we will be ready to boot our VM, we will need an init script in
place. For this, we create a simple shell script which we populate using
the environment variables and command extracted from the container.
The init script is stored in /init.sh within the new image, and we will
configure the boot parameter to find it there.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create a loop device by pre-allocating space to a file on disk. This
file is then converted to an ext4 partition, which we mount to a
temporary path on the host.
Once this is done, we extract all the layers from the given container on
that mounted path. We also add a few extra files to the image
(`/etc/hosts` and `/etc/resolv.conf`).
When we're done extracting and writing, we run resize2fs in order to
resize the image to a more reasonable size.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will ensure that our container will not be deleted while we work on
it. In addition, a default expiry of 24 hours will be set on it once the
lease is released (once the program is completed).
See [1] for more details.
[1] https://github.com/containerd/containerd/blob/261c107ffc4ff681bc73988f64e3f60c32233b37/docs/garbage-collection.md
Signed-off-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pull an image provided as an argument to the program. We're only
interested in images for Linux/amd64 at the moment.
We setup a default namespace for containerd named `c2vm`. Images that
will be pulled by containerd will be stored inside that namespace.
Once the program is build it can be run like this:
```
; sudo ./c2vm -container docker.io/library/redis:latest
pulled docker.io/library/redis:latest (38667897 bytes)
```
And the image is indeed in the namespace:
```
; sudo ctr -n c2vm images ls -q
docker.io/library/redis:latest
```
|
| |
|
| |
|
|
|
|
| |
Change-Id: If26166f29f9b519b87e288b514d2c603ca9b4413
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The REPL reads the input, send it to the lexer, and prints the token to
STDOUT. For now nothing else is done since we still don't parse the
tokens.
|
|
|
|
|
|
|
|
|
| |
The tokens for equal (`==`) and not equal (`!=`) are composed of two
characters. We introduce a new helper (`peekChar`) that we use when we
encounter the token `=` or `!` to see if this is a token composed of two
characters.
Add some tests to ensure they are parsed correctly.
|
| |
|
|
|
|
|
| |
Ensure that the new keywords added (`if`, `else`, `true`, `false`,
`return`) are parsed correctly.
|
|
|
|
|
|
|
| |
Add support for a few more keywords (`true`, `false`, `if`, `else`,
`return`).
All keywords are grouped together in the constant declaration.
|
| |
|
|
|
|
|
|
|
| |
The test `TestNextTokenBasic` was not testing anything that
`TestNextTokenMonkey` was not already testing.
Rename `TestNextTokenMonkey` to `TestNextToken` for clarity.
|
|
|
|
| |
For now, automate running the tests.
|
|
|
|
|
| |
Support the operator tokens that were added to our tokenizer. This also
add a few more tests to ensure we handle them correctly.
|
|
|
|
|
|
| |
Support additional tokens for operators (`-`, `*`, etc). This change
only adds the tokens to the list of constants, and group all the tokens
related to operators together.
|
|
|
|
|
|
|
|
|
| |
The initial lexer for the monkey language. We only support a small
subset at this stage.
We have some simple tests to ensure that we can parse some small
snippet, and that the minimum number of tokens we need are also all
supported correctly.
|
|
|
|
|
|
|
|
|
|
|
| |
This is the initial tokenizer for the monkey language. For now we
recognize a limited number of tokens.
We only have two keywords at this stage: `fn` and `let`. `fn` is used to
create function, while `let` is used for assigning variables.
The other tokens are mostly to parse the source code, and recognize
things like brackets, parentheses, etc.
|
|
|
|
|
|
| |
The project is named monkey, we add a mod file to ensure that the
tooling / dependencies are set up correctly when we import various
modules in this project.
|
|
|