Fixes improvements for docker compose and terraform quickstarts

douglaswainer commented 1 year ago

Description

The primary purpose of this PR is to make the docker-compose quickstart easier to get working out of the box for people trying to run it on bare metal machines with NVME drives. It also addresses the some issues I encountered when testing these changes with the other docker-compose based quickstart guides.

Docker-compose (on bare metal)
Terraform Equinix metal
Vagrant (with USE_HELM=false

Plus some cleanup to remove some code/files that I believe are legacy and no longer used.

Why is this needed

This is my attempt to address 172 and 173.

How Has This Been Tested?

I've tested by running through the quickstart documentation for all compose based quickstarts:

Docker-compose (On bare metal Lenovo Thinkcenter Tiny M900 machines, with NVME drives)
Terraform
Vagrant/Libvirt with USE_HELM=true
Vagrant/Libvirt with USE_HELM=false

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

All statements like {{ index .Hardware.Disks 0 }} in the deploy/stack/compose/manifests/template.yaml have been replaced with environment variables (set in the .env file) that get substituted by the manifest-update container task. This should make it more likely to work for new users, but might confuse users that add their own manifest files.

Checklist:

I have:

[x] updated the documentation and/or roadmap (if required)
[x] added unit or e2e tests
[x] provided instructions on how to upgrade

douglaswainer commented 1 year ago

I've been looking into the hardware types and I can see how I could have used the MetadataInstanceStorageMount, which I believe could be substituted more naturally (or more inline with Tinkerbell templates) with:

{{ (index .Hardware.Metadata.Instance.Storage.Filesystems 0).Mount.Device }}

Provided the hardware.yaml provides this metadata. I might be wrong, I'm not very familiar with Golang templates so I'll need to test.

I'm happy to close this and go and rework/retest my changes and then reopen again at a later stage, if that is preferable?

jacobweinstock commented 1 year ago

I've been looking into the hardware types and I can see how I could have used the MetadataInstanceStorageMount, which I believe could be substituted more naturally (or more inline with Tinkerbell templates) with:
{{ (index .Hardware.Metadata.Instance.Storage.Filesystems 0).Mount.Device }}
Provided the hardware.yaml provides this metadata. I might be wrong, I'm not very familiar with Golang templates so I'll need to test.

I'm happy to close this and go and rework/retest my changes and then reopen again at a later stage, if that is preferable?

Hey @douglaswainer, at the moment only the disks (hardware.Spec.Disks) are available for use like this. This was deliberate on our part so that we could evolve this functionality with purpose as use-cases arise. So no need to rework this. Thanks though!

douglaswainer commented 1 year ago

Hey @douglaswainer, at the moment only the disks (hardware.Spec.Disks) are available for use like this. This was deliberate on our part so that we could evolve this functionality with purpose as use-cases arise. So no need to rework this. Thanks though!

Oh interesting, I assumed the whole hardware data json could be referenced. Thank you for clarifying!

tinkerbell / playground