djpbessems/Tinkerbell.Sandbox
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
86 Commits 12 Branches 6 Tags 336 KiB
Shell 47.3%
Go 38.7%
HCL 10.8%
Smarty 1.3%
Dockerfile 1%
Other 0.9%
6a954b6dcb
Go to file
mergify[bot] 6a954b6dcb
remove the metadata filter in the sandbox (#63) 
## Description
Using a custom endpoint instead of using the default endpoint that `hegel` adjusts 
<!--- Please describe what this PR is going to change -->

## Why is this needed
The reason behind that is, while using the sandbox in combination with tinkerbell's example [workflows](https://github.com/tinkerbell/workflows). The [functions.sh](https://github.com/tinkerbell/workflows/blob/master/ubuntu_18_04/00-base/functions.sh) will fail due to lack of information in the retrieved metadata from `hegel`. The default endpoint filters out all the needed metadata such as `plan_slug`. This PR removes that filtration criteria. 

Also I am not sure, I think we are safe to provide these info(the full hardware spec) to the worker while using the Sandbox setup, as this is mainly used as an example setup not as a production one.   
<!--- Link to issue you have raised -->

Fixes: #64 

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran to -->
<!--- see how your change affects other areas of the code, etc. -->
Yes, it was tested locally by setting the env var in the docker-compose.yml file and batch it in the sandbox setup. 

## How are existing users impacted? What migration steps/scripts do we need?

<!--- Fixes a bug, unblocks installation, removes a component of the stack etc -->
<!--- Requires a DB migration script, etc. -->


## Checklist:

I have:

- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
2021-03-18 14:35:33 +00:00
.github/workflows Run apt-update before installing package in the tag workflow 2020-11-24 19:52:15 +01:00
cmd New tool to bump current_versions.sh automatically 2021-02-12 14:47:46 +01:00
deploy remove the metadata filter in the sandbox 2021-03-16 19:36:40 +01:00
script Missed docker transport in release-binaries 2020-11-24 17:08:08 +01:00
test/_vagrant New tool to bump current_versions.sh automatically 2021-02-12 14:47:46 +01:00
.envrc Add shell.nix and .envrc for great good 2020-11-09 17:39:00 -05:00
.gitattributes Force Unix line endings for shell scripts 2020-12-07 23:31:00 +01:00
.gitignore Add .env to .gitignore 2020-12-07 23:31:00 +01:00
.mergify.yml Add mergify and license 2020-09-02 16:31:57 +02:00
CODEOWNERS initial commit 2020-08-20 13:53:27 +02:00
current_versions.sh New tool to bump current_versions.sh automatically 2021-02-12 14:47:46 +01:00
generate-envrc.sh Set NGINX to bind on TINKERBELL_HOST_IP:8080 2021-01-25 15:19:23 -05:00
go.mod New tool to bump current_versions.sh automatically 2021-02-12 14:47:46 +01:00
go.sum New tool to bump current_versions.sh automatically 2021-02-12 14:47:46 +01:00
LICENSE Add mergify and license 2020-09-02 16:31:57 +02:00
README.md Making statement on breaking changes clearer 2021-01-04 12:07:15 -08:00
setup.sh Set NGINX to bind on TINKERBELL_HOST_IP:8080 2021-01-25 15:19:23 -05:00
shell.nix Bootstrap Packer template for libvirt and Vbox 2021-02-04 10:27:19 +01:00

README.md

This repository is a quick way to get the Tinkerbell stack up and running.

Currently it supports:

  1. Vagrant with libvirt and VirtualBox
  2. Terraform on Packet

Tinkerbell is made of different components: osie, boots, tink-server, tink-worker and so on. Currently they are under heavy development and we are working around the release process for all the components.

We need a way to serve a version of Tinkerbell that you can use and we know what is running the hood. Sandbox runs a pinned version for all the components via commit sha. In this way as a user you won't be effected (ideally) from new code that will may change a bit how Tinkerbell works.

We are keeping the number of breaking changes as low as possible but in the current state they are expected.

Binary release

As part of a new release for sandbox we want to push binaries to GitHub Release in this way the community will be able to use them if needed.

We build Docker images across many architectures, each of them in its own repository: boots, hegel, tink and so on.

Sandbox is just a collection of those services and we follow the same pattern for getting binaries as well.

There is a go program available in ./cmd/getbinariesfromquay/main.go. You can run it with go run or build it with go build:

$ go run cmd/getbinariesfromquay/main.go -h
  -binary-to-copy string
        The location of the binary you want to copy from inside the image. (default "/usr/bin/hegel")
  -image string
        The image you want to download binaries from. It has to be a multi stage image. (default "docker://quay.io/tinkerbell/hegel")
  -out string
        The directory that will be used to store the release binaries (default "./out")
  -program string
        The name of the program you are extracing binaries for. (eg tink-worker, hegel, tink-server, tink, boots) (default "hegel")

By default it uses the image running on Quay for Hegel and it gets the binary /usr/bin/hegel from there. The directory ./out is used to store images and binaries inside ./out/releases.

To get the binaries for example for boots you can run:

$ go run cmd/getbinariesfromquay/main.go \
    -binary-to-copy /usr/bin/boots \
    -image docker://quay.io/tinkerbell/boots:sha-9625559b \
    -program boots

You will find them in ./out/release