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.
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
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
## 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.
This naming scheme seemed weird to me so I went looking around at other
Go projects. None of the projects that I found that had multi-arch
release binaries used this scheme, instead they just append the variant
to arch. Appending the variant to the arch also makes a lot of sense if
you think of the naming schme as $binary-$os-$cpu and
$cpu=$arch$variant. Keeping arch and variant together as $cpu is also
more consistent, and consitency is great :D.
Signed-off-by: Manuel Mendez <mmendez@equinix.com>
## 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
The go program we use to get binaries from a docker image was unpacking
only the last layer. This is not required and it order to have a more
generic approach and fewest requirement the program now unpack all the
image
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
The main reason for this bump is because we fixed multi arch support for
boots binaries. Before docker images were multi arch but boots was
always x86. This issue is not fixed.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
script/release-binaries.sh
When writing the release-binary bash script I didn't use the right
variables in current_versions.sh but I fixed those values as part of the
script itself.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
have a look at the README.md to see how it works.
Bootstrap a CLI program to copy binaries from multi arch images
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
