| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The code is in https://github.com/fcuny/containerd-to-vm
|
|
|
|
| |
The notes are at https://github.com/fcuny/notes.fcuny.net
|
|
|
|
| |
The blog moved back to https://github.com/fcuny/fcuny.net
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Configure the way we import these packages the same way, that way it's
consistent and easy to use.
Change-Id: I0e218f8fe9dd4cd2045bfee11c80de84ff769fe1
Reviewed-on: https://cl.fcuny.net/c/world/+/703
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
|
|
|
|
|
|
| |
The pre-commit hook for new lines reported and correct a number of
issues, so let's commit them now and after that we ca enable the hook
for the repository.
Change-Id: I5bb882d3c2cca870ef94301303f029acfb308740
Reviewed-on: https://cl.fcuny.net/c/world/+/592
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
|
| |
We don't need namespaces, a better abstraction is to use different
buckets, as this provides a better abstraction to manage quotas and
permissions.
|
|
|
|
| |
There's no need to install the libpcap-dev package for this repo.
|
|
|
|
| |
There's no `cmd` directory in this repo.
|
|
|
|
|
| |
Let's ensure we test and build a binary when pushing to main and when we
create a pull-request.
|
|
|
|
|
|
|
|
|
| |
Add the stub commands for the binary. Each command will be in its own
file (with the exception of delete/un-delete). This will make it easier
to navigate the code.
We use `github/urfave/cli` for generating the sub commands, as the
module is well documented and easy to use.
|
| |
|
|
|
|
| |
This is a high level description of what buckit is and how it works.
|
| |
|
|
|
|
|
|
|
| |
Change-Id: Ifcd265c515b0fc5e1999eed0d7594475e84a346a
Reviewed-on: https://cl.fcuny.net/c/world/+/413
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
|
|
| |
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
```
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't need tags in this repository. There's no need to create them
after a deploy.
Before stopping the fly.io agent, checks that we're in the CI
environment.
Change-Id: I6208b70023c6ae74d58e535e24b44221956dbe63
Reviewed-on: https://cl.fcuny.net/c/world/+/408
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
|
|
|
| |
Change-Id: I0911c07d5ab0e17a09e587ba4507d0202f6c7ff3
Reviewed-on: https://cl.fcuny.net/c/world/+/364
Tested-by: CI
Reviewed-by: Franck Cuny <franck@fcuny.net>
|
|
|
|
| |
Change-Id: If26166f29f9b519b87e288b514d2c603ca9b4413
|
|\
| |
| |
| | |
Change-Id: I790690b0877ae309d1d5feb5150f136085e78206
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
|
|
|
|
|
| |
There's no need to have a flake.nix for the notes, we can use the same
mechanism as for the blog and resume.
Add a README so I remember how to use this in the future.
|
|
|
|
|
| |
This is needed in order to replace the flake.nix with a default.nix,
like I did for the blog earlier.
|
|
|
|
|
|
|
| |
Integrate the resume with the rest of the repository, as I did for the
blog in the previous commit.
Added a script to copy the resume in the static directory of the blog.
|
|
|
|
|
|
| |
There's no need to have multiple `flake.nix` in the repository. Make the
blog part of the flake configuration at the root level of the
repository, delete the one in the blog, and update the documentation.
|
|
|
|
|
| |
This is not going to work with the next change, so I'm just going to
drop it.
|
|
|
|
|
| |
I can now have a readme.org with instructions on how to generate the
resume (because I'll obviously forget again).
|
| |
|
|
|
|
|
| |
In a monorepo setup, the CI configuration is not used at this level of
the tree, and the gitignore/envrc are not relevant.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Running `nix build` is enough to generate the file `resume.html`. It
will be created in the `result` directory automatically.
The configuration for the build is also updated to run `nix build`
|
| | |
|
| |
|
|
|
|
|
| |
In a monorepo setup, the CI configuration is not used at this level of
the tree, and the gitignore/envrc are not relevant.
|
|\ |
|
| |
| |
| |
| | |
This is not needed anymore.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Instead of using the Makefile, move the content to a script. This will
be executed by drone later.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Separating the two sites so I can customize them differently.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Using Firefox' accessibility tool as a guide.
|
| | |
|
| |
| |
| |
| | |
These elements are unique on each page.
|
| | |
|
| |
| |
| |
| |
| | |
Depending on the size of the display, display the TOC either before the
article or on the right of the article and let's make it sticky.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a need for two TOCs in the layout: one for when the page is on
mobile; one for non mobile.
When we are on mobile, we display the first TOC, before the article.
When we're not on mobile, we hide that TOC and display one after the
document.
We restructure a bit the layout so that's it's a bit more readable too,
and close tags properly.
|
| | |
|
| |
| |
| |
| |
| | |
The div 'main' is not needed, we are creating an element named 'named'
in the main block.
|
| | |
|
| |
| |
| |
| | |
Use a light blue.
|
| |
| |
| |
| |
| | |
Otherwise it's the name of the site, which is not what I'm looking for
here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Specify the weight so that the items in the menu are listed in the order
I want.
|
| |
| |
| |
| |
| | |
Generate correctly the content of the RSS feed. I only want the blog
articles, not the notes.
|
| | |
|
| |
| |
| |
| | |
Add a "contact" header with my information under it.
|
| | |
|
| |
| |
| |
| | |
After a successful deploy, push all the branches / tags to origin.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
If we're not explicit, we're trying to run the image tagged `latest',
but there's no image with that tag.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We were evaluating the version of the app when the rule was evaluated,
while we need to get the version after we run `flyctl deploy`.
Since we're tagging a release, let's also annotate the tag.
Remove the `--build-arg` argument to `flyct deploy` since it's being
ignored (same with `docker build`).
Closes #1.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The last deploy was tagged v13, while the version deployed was 14. It's
possible that running `fly info` too quickly after a deploy returns the
incorrect version. Adding a `sleep 5` before running the command for git
tag.
|
| | |
|
| |
| |
| |
| | |
It's ugly.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add an element "article" to the single page template, and change the CSS
to use the decoration for headers only for that kind of content.
Having decoration for all headers is distracting, it's more suited for
actual content.
We also don't need decoration for h1, only smaller headers.
|
| | |
|
| |
| |
| |
| | |
Move the title to the left and the menu items to the right.
|
| |
| |
| |
| |
| |
| |
| |
| | |
If the deployment is successful, tag the repository with the version
being deployed on fly.io.
Don't deploy unless the repository is clean (this is done with the
target `worktree-clean`).
|
| |
| |
| |
| | |
This note captures things that are useful when working with go for me.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Roboto Slab font is hard to read (at least for me). Switch to Droid
Sans and make the text a bit smaller.
Change the background of the page to white (again), and change the
background color for the code snippets.
Add text decoration for headlines (similar to org-bullet).
|
| |
| |
| |
| |
| | |
If an entry has the parameter `#+toc` set to `t`, we will enable the
table of content in the page.
|
| |
| |
| |
| |
| | |
We will have more use of the tag `nav` and we will need different styles
for it.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Increase the font size and change some of the colors used for
highlighting code.
|
| | |
|
| | |
|
| |
| |
| |
| | |
See humanstxt.org for more information.
|
| |
| |
| |
| |
| | |
Now that we're using a more recent version of the Docker image for hugo
that comes with git, we can enable again git information.
|
| |
| |
| |
| |
| | |
Add a Makefile to take care of most common operations (build, deploy,
etc).
|
| |
| |
| |
| |
| |
| |
| |
| | |
The Dockerfile used by fly is relying on an older version of hugo ([1]).
We can use a newer version and provide our own setup, and configure with
the flags we want (e.g. promote to HTTS automatically).
[1] https://github.com/superfly/flyctl/blob/3eb204909fbecd5fd2b1ba4517cdbce2abd9f74a/internal/build/imgsrc/builtins/defaultbuiltins.go#L89
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The docker image used by fly.io to deploy a static website with hugo
does not come with git, which prevents us to use the option
`enableGitInfo`. This is not critical for now, so let's disable it so we
can deploy.
|
| | |
|
| |
| |
| |
| | |
Fix boot options
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I want to differentiate blog's entries from more general notes. For
this, we create two menu entries, and add a navbar at the top.
The nav bar let us select between the two kind of articles: blogs or
notes. For now we have a single blog entry, and no notes.
The page to list entries is simplified: we use the same layout for all
lists (tags, notes, blogs).
The CSS is updated to support the new nav bar.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
We want to have pages that list all the articles related to a given tag.
Update the configuration to add support for tags and the permalink
structure.
|
| |
| |
| |
| |
| |
| |
| | |
We want to show the tags and the published/updated date for the
articles.
Add to the CSS the classes for these new elements.
|
| |
| |
| |
| | |
Indent properly the CSS
|
| |
| |
| |
| | |
Indent properly the CSS for the `pre` tag.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Add a workflow configuration to publish to GitHub pages. This is using
the standard configuration from
https://gohugo.io/hosting-and-deployment/hosting-on-github/
|
|
|
|
|
|
|
|
|
| |
Start my website from scratch once more, using hugo to generate it. For
now the layout is pretty simple:
- an index page that will list future notes
- notes should be created under the "content" directory
The theme is custom and I'll try to keep this simple.
|
|
|
|
|
| |
In a monorepo setup, the CI configuration is not used at this level of
the tree, and the gitignore/envrc are not relevant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I ran into the following issue:
```
The agent failed to start with the following error log:
162022/05/11 02:38:11.375368 srv another instance of the agent is
already running
```
I'm not sure this is the right approach, but it's a start.
|
|
|
|
|
| |
This is not needed anymore, I'm not running it in a container, and the
build is done remotely by fly when I do a build.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Delete the workflow for GitHub actions.
|
| |
|
|
|
|
|
|
|
|
| |
Add a drone configuration to run the deploy on a push to the main
branch.
Cleanup the nix configuration to only keep support for `nix run` (which
will run the hugo server).
|
| |
|
|
|
|
| |
It's already in the footer.
|
| |
|
|
|
|
| |
They are at https://notes.fcuny.net now.
|
|
|
|
|
|
|
|
| |
Add a `flake.nix' configuration to pull the required dependencies and
run the server.
Remove a few targets from the Makefile and move the deployment part to a
script.
|
|
|
|
|
|
|
|
|
|
| |
The notes will be moved to a different site/repository, with their own
style.
Update the index page to make it more readable. Make the header more
visible with fewer links.
Add a footer, with links using SVG icons.
|
| |
|
| |
|
| |
|
|
|
|
| |
Using Firefox' accessibility tool as a guide.
|
| |
|
|
|
|
| |
These elements are unique on each page.
|
| |
|
|
|
|
|
| |
Depending on the size of the display, display the TOC either before the
article or on the right of the article and let's make it sticky.
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a need for two TOCs in the layout: one for when the page is on
mobile; one for non mobile.
When we are on mobile, we display the first TOC, before the article.
When we're not on mobile, we hide that TOC and display one after the
document.
We restructure a bit the layout so that's it's a bit more readable too,
and close tags properly.
|
| |
|
|
|
|
|
| |
The div 'main' is not needed, we are creating an element named 'named'
in the main block.
|
| |
|
|
|
|
| |
Use a light blue.
|
|
|
|
|
| |
Otherwise it's the name of the site, which is not what I'm looking for
here.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Specify the weight so that the items in the menu are listed in the order
I want.
|
|
|
|
|
| |
Generate correctly the content of the RSS feed. I only want the blog
articles, not the notes.
|
| |
|
|
|
|
| |
Add a "contact" header with my information under it.
|
| |
|
|
|
|
| |
After a successful deploy, push all the branches / tags to origin.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
If we're not explicit, we're trying to run the image tagged `latest',
but there's no image with that tag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were evaluating the version of the app when the rule was evaluated,
while we need to get the version after we run `flyctl deploy`.
Since we're tagging a release, let's also annotate the tag.
Remove the `--build-arg` argument to `flyct deploy` since it's being
ignored (same with `docker build`).
Closes #1.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The last deploy was tagged v13, while the version deployed was 14. It's
possible that running `fly info` too quickly after a deploy returns the
incorrect version. Adding a `sleep 5` before running the command for git
tag.
|
| |
|
|
|
|
| |
It's ugly.
|
|
|
|
|
|
|
|
|
|
| |
Add an element "article" to the single page template, and change the CSS
to use the decoration for headers only for that kind of content.
Having decoration for all headers is distracting, it's more suited for
actual content.
We also don't need decoration for h1, only smaller headers.
|
| |
|
|
|
|
| |
Move the title to the left and the menu items to the right.
|
|
|
|
|
|
|
|
| |
If the deployment is successful, tag the repository with the version
being deployed on fly.io.
Don't deploy unless the repository is clean (this is done with the
target `worktree-clean`).
|
|
|
|
| |
This note captures things that are useful when working with go for me.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The Roboto Slab font is hard to read (at least for me). Switch to Droid
Sans and make the text a bit smaller.
Change the background of the page to white (again), and change the
background color for the code snippets.
Add text decoration for headlines (similar to org-bullet).
|