## Description
This is a follow-up to #76 which introduced a failure:
```
provisioner: ./setup.sh: line 117: NAT_INTERFACE: unbound variable
```
## Why is this needed
Unbreak `setup.sh` when used by Vagrant
Fixes#77
## How Has This Been Tested?
I used the following simple test case. It works now that the variable is declared first, but still breaks as reported without the fix.
```bash
#!/bin/bash
set -eu
NAT_INTERFACE=""
if [ -r .nat_interface ]; then
NAT_INTERFACE=$(cat .nat_interface)
fi
if [ -n "$NAT_INTERFACE" ] && ip addr show "$NAT_INTERFACE" &>/dev/null; then
echo "$NAT_INTERFACE"
fi
```
## How are existing users impacted? What migration steps/scripts do we need?
Vagrant users are currently broken as reported in the community Slack.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
## Description
The NAT setup commands assume that the interface is named eth1, when clearly from the [documentation](https://github.com/tinkerbell/tinkerbell-docs/blame/master/docs/setup/equinix-metal-terraform.md#L118) it is named `enp1s0f1`. This commit fixes the NAT setup commands accordingly.
## Why is this needed
NAT doesn't work by default on Equinix Metal when following the documentation
## How Has This Been Tested?
- [x] Tested with Terraform in Equinix Metal
## How are existing users impacted? What migration steps/scripts do we need?
Existing sandboxes (that are broken) should either be rebuilt, or can run the commands manually to enable NAT
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
Signed-off-by: Nahum Shalman <nshalman@equinix.com>
## Description
Add `jq` to the nix-shell environment
## Why is this needed
There are bits of documentation that use the sandbox and reference using `jq` from the command line.
This makes them work nicely.
## How Has This Been Tested?
On NixOS running `nix-shell` now has `jq` in the PATH.
## How are existing users impacted? What migration steps/scripts do we need?
N/A
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
## Description
This change causes Nix to pull in Terraform v0.14 rather than v0.12 when users run `nix-shell`
## Why is this needed
Without this change I get this error on both Mac and NixOS:
```
[nix-shell:~/sandbox/deploy/terraform]$ terraform init --upgrade
Warning: Provider source not supported in Terraform v0.12
on main.tf line 4, in terraform:
4: metal = {
5: source = "equinix/metal"
6: version = "1.0.0"
7: }
A source was declared for provider metal. Terraform v0.12 does not support the
provider source attribute. It will be ignored.
(and 2 more similar warnings elsewhere)
Error: Unsupported Terraform Core version
This configuration does not support Terraform version 0.12.30. To proceed,
either choose another supported Terraform version or update the root module's
version constraint. Version constraints are normally set for good reason, so
updating the constraint may lead to other errors or unexpected behavior.
```
## How Has This Been Tested?
I used this on both a Mac and a NixOS machine using `nix-shell`
## How are existing users impacted? What migration steps/scripts do we need?
Running `nix-shell` on existing checkouts will now pull down a newer version of Terraform.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
As I explained here
https://github.com/tinkerbell/sandbox/pull/66#issuecomment-803009169 the
current OSIE on master broke how tink-worker gets installed in sandbox.
For a series of bad habits, the PR got merged even if e2e tests are
broken leaving sandbox/master to a not working state
This commit reverts OSIE back to a fully operational version
## Description
Allows for deploying the vagrant/libvirt setup without NAT and with multiple workers, which enables testing with cluster-api-provider-tink
## Why is this needed
Helps with testing CAPT
## How Has This Been Tested?
Currently testing at the moment, but all testing will consist of manual testing with vagrant/libvirt
## How are existing users impacted? What migration steps/scripts do we need?
This could affect existing vagrant/libvirt users if they have an existing worker running when they update, not sure if there is a good way to avoid that, though.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
## 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
## Description
Mounting the `current_versions.sh` file to the target provisioner when installing TinkerBell on Equinix using terraform
<!--- Please describe what this PR is going to change -->
## Why is this needed
Because the `generate-envrc.sh` will fail and no TinkerBell env will be created.
<!--- Link to issue you have raised -->
Fixes: #60
## 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. -->
Simply ran the provisioner on Equinix and the env file was created with all the needed info.
## How are existing users impacted? What migration steps/scripts do we need?
None
<!--- 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
I am not sure when it happens, it can be when we removed the NGINX_IP,
or when we checked that every services were using ports OR network_mode
but we exposed nginx and boots over the same port.
This commit fixes that.
… container definition
## Description
Resolves#53
## Why is this needed
This conflict causes container creation to fail.
Fixes: #
## How Has This Been Tested?
I ran the setup and was able to run a workflow and deployment without issue.
## How are existing users impacted? What migration steps/scripts do we need?
No impact.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
## Description
Updates [Packet Terraform](https://docs.tinkerbell.org/setup/packet-terraform/) plan to use the Equinix Metal provider.
## Why is this needed
Consistent with rebranding efforts across the organization.
Fixes: #
## How Has This Been Tested?
This plan validates, and applies as expected (and has previously) with the renamed resources, and updates outputs.
## How are existing users impacted? What migration steps/scripts do we need?
Existing users may need to reinitialize their Terraform environment, but existing resources in state can be imported.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
This PR contains a provisioning mechanism for the Vagrant boxes we ship
as part of Sandbox.
In order to self contain and distribute the required dependencies for Tinkerbell
and Sandbox without having to download all of them runtime we decided to use
[Packer.io](https://packer.io) to build boxes that you can use when provisioning
Tinkerbell on Vagrant.
Currently the generated boxes are available via [Vagrant
Cloud](https://app.vagrantup.com/tinkerbelloss).
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
Signed-off-by: Michael Richard <michael.richard.ing@gmail.com>
## Description
This configures NGINX to listen on port 8080 and lets go the need to configure a second IP address on the host dedicated to NGINX.
## Why is this needed
Setting up a second IP address to host NGINX on the same host is not always easy, especially when running tinkerbell on network devices like switches. The second IP address adds a useless level of complexity. In the future, all the code required to identify the host operating system and configure the IP address could even be removed and left as a prerequisite, since the host is likely to have an IP address already configured.
## How Has This Been Tested?
The untouched vagrant_test.go test ran sucessfully.
## How are existing users impacted? What migration steps/scripts do we need?
Simply re-applying the docker-compose.yml should be sufficient (untested).
Additional firewall rules to allow traffic on port 8080 could be required depending on user's network configuration.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
## Description
Fixes the vagrant configuration when using libvirt
## Why is this needed
Without this issue the vagrant provisioner fails when using libvirt with the following error:
```sh
Error occurred while creating new network: {:iface_type=>:private_network, :netmask=>"255.255.255.0", :dhcp_enabled=>false, :forward_mode=>"none", :virtualbox__intnet=>"tink_network", :libvirt__dhcp_enabled=>false, :libvirt__forward_mode=>"none", :auto_config=>false, :protocol=>"tcp", :id=>"18e6fc6d-41b8-40c9-814d-ffc476bfd920"}.
```
## How Has This Been Tested?
Reran vagrant up after making the changes and the provisioner machine successfully was created
## How are existing users impacted? What migration steps/scripts do we need?
Should not affect existing users unless they were trying to use vagrant/libvirt and were unsuccessful before.
No migration should be needed.
Commit b504810 introduced a NAT to make worker capable of reaching the
public internet via the provisioner.
But it also introduced a bug, it only works for the Vagrant setup as
Manny pointed out:
https://github.com/tinkerbell/sandbox/pull/33#issuecomment-759651035
This is an attempt to fix it
@mmlb I would like to avoid additional conditions as part of the
setup.sh, we have already too many of them and they are not even easy to
dsicover. We have different entrypoint for those environment let's use them.
## Description
Update boots version.
## Why is this needed
This will get us proper binaries in the releases but also 64bit boots
for 64bit x86 machines!
## How Has This Been Tested?
Boots has been tested on EM hw.
## Description
Renames binaries to be more consistent in and of itself and also compared to other Go projects that provide multi-arch binaries.
## Why is this needed
@gianarb asked me to rename the binaries in https://github.com/tinkerbell/boots/pull/122 to match this scheme, but I think that this PR is the better directon.
## Description
Documentation
## Why is this needed
This statement is confusing, I needed to log into the community slack to get clarification.
Fixes: #
## How Has This Been Tested?
This is a documentation change and thus will not impact any software in this project.
## How are existing users impacted? What migration steps/scripts do we need?
They are not, newer users may find this a little easier to digest.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
The go program we use to get binaries from a docker image was unpacking
only the last layer. This is not required and in order to have a more
generic approach and fewest requirement the program now unpack all the
image
Tinkerbell is made of different components as we all know at this point.
Sandbox had those versions all over the places. This PR moves them as
part of the `envrc` file.
As it is today this PR requires an additional flag for the `docker-compose` command as described here #6
