Good First Issues in Hcl

Area Provider compatibility Relevant reference versions.tf, the root README, and the five shipped examples in v0.2.0-beta.1. Expected behaviour Every bpg/proxmox release accepted by the module constraint should contain and validate the SDN resources used by the module. Observed behaviour The repository currently advertises bpg/proxmox >= 0.50.0. Provider v0.83.0 and earlier do not contain the VNet and subnet resources used in main.tf. Those resources first appear in v0.84.0, but the current module fails terraform validate against that release with: Error: Invalid Subnet Could not parse subnet: invalid CIDR address: The upstream interpolation fix was included after v0.84.0 in bpg/terraform-provider-proxmox#2204. An exact v0.85.0 provider selection validates successfully. The current main test suite passes with 26 tests, and the head of PR #64 passes with 35 tests. Steps to reproduce Select bpg/proxmox = 0.84.0. Run terraform init -backend=false -input=false. Run terraform validate. O

Area Module inputs or validation Problem The VLAN zone resource fixes mtu at 1500. Operators using jumbo frames or a smaller underlay MTU must fork the module to change one supported provider setting. Proposed change Add a zone_mtu input with a default of 1500, pass it to the VLAN zone resource, and document it in the input table and examples. Validate the value as a whole number within the range supported by Proxmox. Acceptance criteria Existing callers continue to plan with MTU 1500. A caller can set a different supported MTU without editing the module. Invalid values fail during validation. Mocked Terraform tests cover the default, an override, and invalid input. terraform fmt -check -recursive, terraform validate, and terraform test -no-color pass.

Area Proxmox SDN objects Relevant reference v0.2.0-beta.1, vnets.description, main.tf Expected behaviour The description supplied for each VNet should appear on the corresponding Proxmox SDN object. Observed behaviour description is required by the module input, but the VNet resource only sets id, zone, and tag. The provider exposes this field as alias, so the submitted description is currently discarded. Steps to reproduce Set a VNet description in any shipped example. Run terraform plan. Inspect proxmox_virtual_environment_sdn_vnet.vnet and note that no alias is planned. Environment Terraform 1.13.4, bpg/proxmox 0.111.1, module v0.2.0-beta.1. Scope Map each.value.description to the provider's VNet alias field and add a mocked assertion that proves the value reaches the planned resource. Existing examples should continue to validate.

Area Documentation Relevant reference v0.2.0-beta.1 README quickstart https://github.com/hybridops-tech/terraform-proxmox-sdn/tree/v0.2.0-beta.1/examples/api-only-edge-routed https://developer.hashicorp.com/terraform/language/expressions/version-constraints#specify-a-prerelease-version Expected behaviour The API-only quickstart should select a module release that supports enable_host_orchestration. A copied example should validate before any provider operation is attempted. Observed behaviour The quickstart uses: version = "~> 0.1.6" enable_host_orchestration = false That constraint selects the stable 0.1.x line. The v0.1.6 module requires proxmox_host and does not define enable_host_orchestration. terraform validate returns: Error: Missing required argument The argument "proxmox_host" is required, but no definition was found. Error: Unsupported argument An argument named "enable_host_orchestration" is not expected here. The GitHub release text uses version = "= 0.2.0-beta.1". Terraf

Overview Tool: Pulumi Category: Infrastructure as Code (IaC) Priority: Medium (per ROADMAP.md) Pulumi is an IaC tool that lets you define cloud infrastructure using general-purpose programming languages (TypeScript, Python, Go, etc.) instead of a DSL — a different approach from the Terraform/OpenTofu content already in this repo. Official docs: https://www.pulumi.com/docs/ What to add Follow the existing topic structure — see topics/grafana as a reference: topics/pulumi/README.md — sections: What is Pulumi?, Prerequisites, Installation, Basics of Pulumi, Beyond the Basics, More topics/pulumi/basics/ — a runnable example (e.g. a minimal Pulumi program provisioning one cloud resource, e.g. an S3 bucket) topics/pulumi/practice/README.md — at least one practice exercise See CONTRIBUTING.md for the contribution flow. Why Listed as Medium priority in the roadmap's Upcoming Topics table — a good complement to the repo's existing Terraform/OpenTofu content, and the roadmap alr

Overview Tool: Dagger Category: CI/CD Priority: Medium (per ROADMAP.md) Dagger lets you write CI/CD pipelines as code in a real programming language, then run them identically on your laptop or any CI runner — portable, testable pipelines. Official docs: https://docs.dagger.io/ What to add Follow the existing topic structure — see topics/grafana as a reference: topics/dagger/README.md — sections: What is Dagger?, Prerequisites, Installation, Basics of Dagger, Beyond the Basics, More topics/dagger/basics/ — a runnable example (e.g. a minimal Dagger pipeline that builds and tests a small sample app) topics/dagger/practice/README.md — at least one practice exercise See CONTRIBUTING.md for the contribution flow. Why Listed as Medium priority in the roadmap's Upcoming Topics table — portable, code-first CI/CD pipelines are a growing alternative to YAML-only pipeline tools already covered in this repo.

Overview Tool: Crossplane Category: IaC / Platform Engineering Priority: High (per ROADMAP.md) Crossplane extends Kubernetes to manage cloud infrastructure (databases, networks, storage) as native Kubernetes resources — a key building block of modern platform engineering. Official docs: https://docs.crossplane.io/ What to add Follow the existing topic structure — see topics/grafana as a reference: topics/crossplane/README.md — sections: What is Crossplane?, Prerequisites, Installation, Basics of Crossplane, Beyond the Basics, More topics/crossplane/basics/ — a runnable example (e.g. install Crossplane on a local kind cluster and provision a simple managed resource via a Composition/Provider) topics/crossplane/practice/README.md — at least one practice exercise See CONTRIBUTING.md for the contribution flow. Why Listed as High priority in the roadmap's Upcoming Topics table — Kubernetes-native infrastructure management is central to the growing platform-engineering trend

Overview Tool: FluxCD Category: GitOps / CI-CD Priority: High (per ROADMAP.md) FluxCD is a CNCF-graduated GitOps engine that keeps Kubernetes clusters in sync with a Git repository — a natural complement to the existing ArgoCD topic. Official docs: https://fluxcd.io/docs/ What to add Follow the existing topic structure — see topics/grafana as a reference: topics/fluxcd/README.md — sections: What is FluxCD?, Prerequisites, Installation, Basics of FluxCD, Beyond the Basics, More topics/fluxcd/basics/ — a runnable example (e.g. bootstrap Flux against a local kind cluster and sync one manifest from a Git repo) topics/fluxcd/practice/README.md — at least one practice exercise See CONTRIBUTING.md for the contribution flow. Why Listed as High priority in the roadmap's Upcoming Topics table — CNCF-graduated, growing GitOps adoption, pairs naturally with the repo's existing ArgoCD content.

Area Host-side scripts Problem The roadmap describes the SDN recovery helper as optional, but every deployment with host orchestration enabled installs the watcher and its systemd units. An operator cannot keep host L3, SNAT, or DHCP while choosing not to run the watcher. Proposed change Add an explicit input for the recovery watcher. Keep the current behaviour as the default so existing deployments do not change unexpectedly. Acceptance criteria The default still installs and enables the current recovery components. Disabling the option leaves host L3, SNAT, DHCP, and static routes available without installing the watcher. Changing the option from enabled to disabled removes only the files and units owned by this module. API-only mode remains unchanged. Tests and the input documentation cover both settings.

Area CI or release workflow Problem Current validation with bpg/proxmox 0.111.1 reports deprecation warnings for the four SDN resources used by the module: proxmox_virtual_environment_sdn_zone_vlan proxmox_virtual_environment_sdn_vnet proxmox_virtual_environment_sdn_subnet proxmox_virtual_environment_sdn_applier The provider exposes replacement proxmox_sdn_* resource types and states that the older names will be removed in v1.0. The module currently allows every provider version from 0.50.0 upward. Proposed change Move the module to the replacement SDN resource types and define a state-safe upgrade path. Existing deployments must not be replaced solely because the Terraform resource type changed. Update tests and documentation where resource addresses are shown. If the migration cannot be completed safely in one change, add a temporary provider upper bound and record the remaining migration step. Acceptance criteria the supported migration path preserves existing SDN objects module

Area Outputs or downstream integration Problem The ipam_prefixes output is consumed by downstream inventory and NetBox workflows, but the mocked module tests do not assert its structure or effective DHCP values. A change to the output can currently pass terraform test while altering fields used by downstream consumers. Proposed change Add mocked Terraform test assertions for ipam_prefixes. Cover: site and status metadata VLAN ID, role, prefix, and gateway DHCP-enabled and DHCP-disabled subnets effective default and per-subnet DHCP values stable ordering when more than one subnet is present Keep the test independent of a live Proxmox endpoint. Acceptance criteria the public IPAM output shape is asserted both DHCP states are covered custom ipam_site and ipam_status values are covered terraform test -no-color passes without credentials

Area Module inputs or validation Problem When enable_snat = true and enable_host_l3 = false, the effective SNAT path is disabled internally. The plan does not currently tell the operator that the requested SNAT setting cannot be applied. This is easy to hit because SNAT defaults to enabled. Proposed change Add an input validation or lifecycle precondition that rejects SNAT unless host L3 is enabled. The error should name both settings and explain the valid combinations. Add focused module tests for the invalid combination and the two supported paths: host-managed L3 with SNAT enabled edge-routed mode with both host L3 and SNAT disabled Acceptance criteria enable_snat = true with enable_host_l3 = false fails during validation or plan the error identifies the conflicting settings the host-managed SNAT path still passes the API-only edge-routed path still passes existing examples continue to validate terraform test -no-color passes

Full Raw Package Name (e.g. anda-0.4.14-1.fcrawhide.x86_64) flutter-3.44.2-1.fc44.x86_64 Release Version f44 Describe the Bug When you run flutter in cli as a regular user it refuses to do it because permission denied To Reproduce dnf install flutter run flutter permission denied Expected Behavior You could run flutter under a regular user not just a privileged superuser Relevant Log Output flutter /usr/share/flutter/bin/internal/update_engine_version.sh: line 71: /usr/share/flutter/bin/cache/engine.stamp.tmp.131628: Permission denied /usr/share/flutter/bin/internal/update_engine_version.sh: line 78: /usr/share/flutter/bin/cache/engine.realm: Permission denied

Hashicorp strongly recommends adding version constraints to provider installs. We should do that, it'll also remove some lint warnings.

We should standardize where the provider declarations live sometimes it is in provider.tf and sometimes it is in versions.tf. Recommended to stick with provider.tf

Please leave a comment if you, your project, or company is using Terra! A short sentence or two of how Terra is useful for you would be appreciated as well. Of key interest: Distributions/Fedora downstreams Other open source projects Companies or individuals using Terra at their workplace Anything else, don't be shy! P.S. If you represent a company or project, and would like to open a direct line with us, feel free to join and let us know on our Discord or send an email to [email protected].

These packages being in a seperate repo are bad for UX, and some of our packages depend on some of these packages. Re-packaging these for ourselves will eliminate the need to pull in the adoptium repo when building Terra packages. java-8-openjdk java-8-openjdk-portable java-11-openjdk java-11-openjdk-portable java-17-openjdk java-17-openjdk-portable java-21-openjdk >= 44 java-21-openjdk-portable >= 44 I propose adding all of these to anda/langs/java/