Error: Variables not allowed #143
Comments
|
Hi @outbackdingo, you just need to
For (1) proxmox setup see: http://thomasgrant.net/2024/06/16/deploying-proxmox-with-opentofu-part-i/ ...where I'm in the progress of creating a PR for enhancing the README which helps newbies -- I'm in the same boat as you, though 4 weeks ahead. HTH -- Sebastian Edit: Edit 2: Added |
|
I had previously done all of step 1. when i deployed "c0depool-iac" which worked. Im now moving to try homelab as it has more features. |
|
You need to provide the Sorry for the oversight, I've copy-pasted my |
|
@outbackdingo , the next error you will run into is the one I've stumbled over and which is documented with a workaround in #106 |
|
Let me paste my current revised version of the README (which is also giving hints on creating the sealed secrets key as part of the bootstrapping). Please note that you also need to change the cd tofu/kubernetes # if not there already
mkdir bootstrap/sealed-secrets/certificate
openssl req -x509 -days 365 -nodes -newkey rsa:4096 -keyout bootstrap/sealed-secrets/certificate/sealed-secrets.key -out bootstrap/sealed-secrets/certificate/sealed-secrets.cert -subj "/CN=sealed-secret/O=sealed-secret"
vi credentials.auto.tfvars
tofu init
tofu apply -target=module.talos.talos_image_factory_schematic.this
tofu apply
talosctl config merge output/talos-config.yaml
CLUSTER="talos"; kubectl config delete-context admin@$CLUSTER; kubectl config delete-user admin@$CLUSTER; kubectl config delete-cluster $CLUSTER
cp ~/.kube/config ~/.kube/config.bak && KUBECONFIG="~/.kube/config:output/kube-config.yaml" kubectl config view --flatten > /tmp/config && mv /tmp/config ~/.kube/configAfter the cluster is bootstrapped, you would also need to adapt the K8S code to your environment
|
|
and next.... yeah after your comments and help above i started poking around the tree, and it appears quite proprietary to his environment/needs, which some what also fulfil my needs short of a few things added i dont need, im thinking to fork it and make it less proprietary, as in dns names can be vars and such. id like to see it working first though so i know what im dealing with. Changes to Outputs:
Do you want to perform these actions? Enter a value: yes module.talos.proxmox_virtual_environment_download_file.this["abel_dcac6b92c17d1d8947a0cee5e0e6b6904089aa878c70d66196bb1138dbd05d1a_v1.8.1"]: Creating... |
I feel proprietary is too harsh, but I understand what you mean. I only have a limited time to work on this as a hobby, though I like to think I'm doing incremental improvements.
That would be very welcome! I've been thinking about a template similar to onedr0p's cluster template, but I've prioritised features instead. A system similar to Spring Initializr, but with more templating would be awesome. Maybe a mega Helm chart? The biggest hurdle would be customisability though... Nothing wrong with some copy, paste and edit though. |
|
@outbackdingo, I think I know what you mean, though I see it differently. I was also wondering that the nodes definition is hard-coded in @vehagn, you've used variables before according to a code/commit comment, I remember; how comes you've changed that? I was also disappointed about the need to change every domain and IP reference (and the other things mentioned above). I liked the possibility of e.g. defining the domain for all kubernetes manifests in an environment variable like done in https://k3s.rocks/install-setup/. However, that approach doesn't scale well (you would need to have a dedicated variable for each and every IP) and it won't work with CI/CD tools like Flux/ArgoCD (where the command line tool @outbackdingo, how would you implement a more flexible k8s cluster using variables? I also think that in the end a global search-and-replace in a forked repo works well because it's a simple editor change. Of course, any adaptations in the code will create some challenges in merging upstream code into. I therefore decided to go the See a PoC example for my homelab/k8s/apps/dev/whoami app. The I have to admit that this approach has some complexity, though. However, it allows the definition of a common base and then put one's environment-specific adapations on-top. Normally, that overlay approach is used for different environments (e.g. dev, staging, prod), typically. I've liked the approach of using vegard's homelab code)as a base and then put my adaptions on-top -- and of course for having different environments for trial-and-error on my route to evolving a prod k8s cluster (and for test rebuilds). @vehagn, I know onedr0p's cluster template. How would you allow the user to gain from any code changes from upstream that happen after template instantiation? FYI kustomize example for
|
|
@vehagn your docs are awesome, almost TL;DR.. but you have definatly helped me comprehend a lot of what you did
I started with c0depool/c0depool-iac.git which also uses sops and after some tweaks had it spun up in a day, caveat to that it had no argo, and some manual requirements like adding cilium and things. And was pretty clear cut in explaining how to get it spun up, basically step by step, which in my opinion simply makes it easier for those wanting to learn, Im simply trying to get to a point where i have the added features wanted, like auth and security, and since im on a static ip at home, its in my "lab". I understand your fitting the needs to your environment, like cloudflare tunnels and multimedia things, where i dont require them. so im looking to minimize whats deployed. |
That's for my own convenience. I could alternatively separate it into two variable files, one with public information I can check into the repo and another with private information, but I've been lazy.
That's a neat approach! I haven't dug into the details yet, but I think I get the gist of it. I've been planning to replace some of the Argo CD Application resources with ApplicationSets following this article by The Norwegian Mapping Authority. I think that could allow for a more centralised config.
I would have to dogfood the template myself then.
Thanks! I do have a habit of over-explaining, but that's mostly for myself when I have to understand what I did before. At the time being this is just a hobby — so time is limited, though I do feel the urge to make it more accessible. |
|
@vehagn i think if i could integrate your mini-lab into my deployment i would be there, my overall issue is theres a ton to change to simply get a cluster up as our environments are a bit different, im on a single DELL R640 in my Home Office/Den on a public IP, behind a opnsense firewall. Simply put your ArgoCD apps deployment, cilium, gateway, cert-manager, sealed secrets, keycloak, dns, without the cloudflared bits and maybe proxmox-csi are mosly what i need to add/integrate to get my lab up, i took down the c0depool deployment, but can easily spin that back up, i think id get stuck at adding the argocd and the missing apps to it. |
kubernetes git:(main) tofu plan
var.proxmox
Enter a value:
╷
│ Error: Variables not allowed
│
│ on line 1:
│ (source code not available)
│
│ Variables may not be used here.
╵
╷
│ Error: No value for required variable
│
│ on variables.tf line 1:
│ 1: variable "proxmox" {
│
│ The root module input variable "proxmox" is not set, and has no default value. Use a -var or -var-file command line argument to provide a value for this variable.
The text was updated successfully, but these errors were encountered: