The Wombelix Post - Terraform

New release of sr.ht go lib and terraform provider to fix update repo bug

2025-07-28T00:00:00+02:00

Today I released new versions of terraform-provider-sourcehut (v0.2.1) and the related Go library sourcehut-go (v0.1.1). This is a bugfix release to address an issue when updating a repository description.

End of last year, I published the initial version of the provider and library and started using it for my OpenTofu based management of my git repositories. When I tried to update the description of an existing repository, the provider failed with a very generic error:

Multiple API errors occured

This wasn't very helpful, so I started to dig into the code to find the root cause.

The issue was in the sourcehut-go library itself. The error handling for multiple errors was just returning a static string instead of the actual error details from the API. I improved the error handling to be more specific:

--- a/errors.go
+++ b/errors.go
@@ -4,6 +4,8 @@

 package sourcehut

+import "strings"
+
 // Ensure that the build fails if Error and Errors don't implement error.
 var _, _ error = (*Error)(nil), (*Errors)(nil)

@@ -34,7 +36,18 @@ type Errors []Error

 // Error satisfies the error interface for Errors.
 func (err Errors) Error() string {
-       return "Multiple API errors occured"
+       if len(err) == 0 {
+               return "[WARN] Errors.Error() triggered with err length 0"
+       }
+       if len(err) == 1 {
+               return err[0].Error()
+       }
+
+       var details []string
+       for _, e := range err {
+               details = append(details, e.Reason)
+       }
+       return strings.Join(details, "; ")
 }

 // StatusCode returns the HTTP status code of the request that unmarshaled this

With this change in place, the error message became much more useful:

A repository with this name already exists.; validation failed

This new error pointed me in the right direction. I checked the git.sr.ht legacy API documentation and found the problem. The API endpoint for updating a repository treats the name field as optional. If you provide a name that is different from the current one, it triggers a rename and a redirect. If you provide the same name, it fails because a repository with that name already exists.

To fix this, I changed the UpdateRepo function to only include the name in the payload if it's actually different from the old name.

--- a/git/git.go
+++ b/git/git.go
@@ -8,6 +8,7 @@ package git
 import (
        "bytes"
        "encoding/json"
+       "fmt"
        "io"
        "net/http"
        "net/url"
@@ -152,15 +153,25 @@ func (c *Client) NewRepo(name, description string, visibility RepoVisibility) (*
 // If repo.Name differs from oldName, a redirect from the old name to the new
 // name.
 func (c *Client) UpdateRepo(oldName string, repo *Repo) error {
-       jsonRepo, err := json.Marshal(struct {
-               Name string `json:"name"`
-               Desc string `json:"description"`
-               Visi string `json:"visibility"`
-       }{
-               Name: repo.Name,
-               Desc: repo.Description,
-               Visi: string(repo.Visibility),
-       })
+       updateData := make(map[string]interface{})
+
+       // Only include name if it's different from oldName (for renaming)
+       if repo.Name != "" && repo.Name != oldName {
+               updateData["name"] = repo.Name
+       }
+
+       // Always include description, allows empty as well
+       updateData["description"] = repo.Description
+
+       if repo.Visibility != "" {
+               // Validate visibility value
+               if repo.Visibility != VisibilityPublic && repo.Visibility != VisibilityUnlisted && repo.Visibility != VisibilityPrivate {
+                       return fmt.Errorf("invalid visibility: %s (must be public, unlisted, or private)", repo.Visibility)
+               }
+               updateData["visibility"] = string(repo.Visibility)
+       }
+
+       jsonRepo, err := json.Marshal(updateData)
        if err != nil {

I used the opportunity to refactor the code a bit and to add a value validation for the repo visibility.

With these two fixes, updating a repository description with my sourcehut terraform provider now works as expected.

The new versions are available in the OpenTofu and Terraform registry.

The OpenTofu Registry WebUI is often behind the API, even if it doesn't show v0.2.1 yet, it is already available. You can verify it by running curl https://registry.opentofu.org/v1/providers/wombelix/sourcehut/versions.

DNS management with OpenTofu and some AI assistance

2025-07-27T00:00:00+02:00

Today I migrated dozens of DNS records from manual to OpenTofu based management. My DNS provider allows downloading zone files in BIND format, but other information like record IDs needed for OpenTofu imports are buried in the HTML of their web interface.

Manual migration would have been time-consuming and error-prone. Perfect opportunity to test AI assistance. I'm not expecting magic, but to handle the repetitive parsing while I focus on validation and logic.

I used Google's Gemini Code Assistant for this experiment. Over the past months I've worked with Amazon Q Developer, GitHub Copilot, Cursor, and Roo Code with various models.

The key was, and in my experience always is, to provide specific context instead of vague requests. I had already built the OpenTofu modules and project structure to manage Domains and DNS records months ago. So, I knew exactly what I needed and how things should work. This allowed me to give precise guidance to the assistant without relying on it to figure out implementation details.

I provided the AI with full context: existing record files, OpenTofu module structure, and clear objectives. I essentially train the coding assistant on the patterns and conventions of my existing codebase. This doesn't mean hours of actual training, just a few well-crafted prompts.

For tasks like this (processing large amounts of data that humans can barely read, finding patterns, applying logic, and transforming data into different formats) LLMs are naturally a good fit.

For converting a BIND zone file, my instruction was:

Here is the BIND zone file for mycloudoffice.de. I need you to create
a records_mycloudoffice_de.tf file. Please follow the syntax and naming
conventions you see in my existing records_wombacher_cc.tf file, and be
sure to ignore irrelevant records like SOA and RRSIG or CAA that are handled
in a different place and are not in scope now.

Of course, I then pasted the complete BIND zone file content after this instruction as well. By providing both raw data and a clear example of desired output, the model understood the pattern, identified relevant records, and produced properly formatted OpenTofu code. The "Magic" here is that popular LLMs of course know what DNS records are and how BIND Zone files are structured. So, they don't need handholding to understand and parse them.

The next step was generating import commands. To get these resources into my OpenTofu state without destroying and recreating them, I needed tofu import commands for each record. The unique IDs are somewhere in the HTML code from my DNS provider's web interface.

My prompt was:

Now, I need you to generate the tofu import commands for the resources
you just created. Here is the raw HTML containing the record IDs. The
command format is "tofu import <resource_address> <domain>:<record_id>".

Again, I included the full HTML source after this instruction. A while later, I had a complete list of shell commands ready to execute. A task that would have involved manually matching dozens of records to their IDs was done in seconds without errors.

But this wasn't about blindly accepting AI responses. When we encountered a URL record type specific to my DNS provider, the AI's first attempt was based on its general knowledge of resource options. Since none of my shared examples contained details for this specific URL type, it made a reasonable but non-functional guess.

I researched the provider's documentation and fed that back to the model to get the right syntax. Even then, tofu plan revealed subtle drift that required my analysis and guidance to resolve. But two short iterations later, we had a working solution.

This collaboration - where AI handles repetitive tasks while I provide direction and validation - is practical and effective. It's not about replacing developers but freeing us from repetitive work so we can focus on architecture and problem-solving.

As models improve, we stay in the driver's seat, making decisions and reviewing results. Work quality depends on clear instructions and critical evaluation of results, not on expecting AI to solve everything automatically.

Personally, I never want to go back to do all this manually. It isn't fun to read through hundreds of lines of BIND zone files and HTML code to find the right IDs in a weirdly nested div tag.

If you are interested in the outcome, some of what Gemini came up with today made it into my OpenTofu based domain management.

Release: sourcehut (sr.ht) OpenTofu / Terraform provider and Go library

2024-12-28T00:00:00+01:00

Today I released terraform-provider-sourcehut and the related Go library sourcehut-go into the wild. The majority of code is licensed under BSD-2-Clause. The provider is available in the OpenTofu and Terraform registry. The online version of the Documentation can be found there as well.

sourcehut-go is a Go SDK for accessing the sourcehut legacy REST API with oauth personal access tokens created via meta.sr.ht/oauth.

Both projects are based on the work of Sam Whited who archived the former code base on August 22, 2022.

My motivation to improve and release it: I plan to move my git repository management to OpenTofu. Providers for my usual mirror targets GitHub, Gitlab and GitLab are available. But there was no functional and published provider for sourcehut (sr.ht). Which I use as my primary code hosting and build platform.

Now that the library and provider are in a working state, I can continue to work on the actual project :D

Uyuni Test Environment with sumaform on local libvirt host (openSUSE Tumbleweed)

2022-03-08T00:00:00+01:00

A convenient way to quickly setup a local Uyuni Instance inclusive Clients, either for Development or Testing, is sumaform. It supports different backends and provides a ton of options, check it out: https://github.com/uyuni-project/sumaform

I just want to run a Uyuni Server and a few Clients (openSUSE, EL, Debian) on my Laptop so I can verify reported bugs, try some configs as well as deploy and test changes during development, without investing much time.

Following a overview of the, in my case, relevant steps, examples of my config and some Ansible snippets.

Setup

sudo zypper addrepo http://download.opensuse.org/repositories/systemsmanagement:/sumaform/openSUSE_Tumbleweed/systemsmanagement:sumaform.repo
sudo zypper install git-core
sudo zypper install --from systemsmanagement_sumaform terraform terraform-provider-libvirt
git clone https://github.com/uyuni-project/sumaform.git

Follow the First-time configuration (libvirt) instructions in the README, but use the uyuni example file instead: copy main.tf.uyuni.example to main.tf

Config & Deployment

vim main.tf

terraform init
terraform validate
terraform apply

My terraform main.cf based on the uyuni example file

terraform {
 required_version = "1.0.10"
 required_providers {
   libvirt = {
     version = "0.6.3"
   }
 }
}
provider "libvirt" {
}
module "base" {
  cc_username = ""
  cc_password = ""
  images = ["centos7", "opensuse153o", "ubuntu1804"]
}
module "server" {
  base_configuration = module.base.configuration
  product_version = "uyuni-master"
  name = "server"
  image = "opensuse153o"
  use_os_released_updates = true
  create_first_user = false
  auto_accept = false
  skip_changelog_import = false
  mgr_sync_autologin = false
  create_sample_channel = false
  create_sample_activation_key = false
  create_sample_bootstrap_script = false
  publish_private_ssl_key = false
  java_debugging = true
  provider_settings = {
    memory = 8192
    vcpu = 4
  }
}
module "redhat-minion" {
  base_configuration = module.base.configuration
  product_version = "uyuni-master"
  name = "minion-centos7"
  image = "centos7"
  server_configuration = module.server.configuration
  provider_settings = {
    memory = 1024
  }
  auto_connect_to_master = true
}
module "debian-minion" {
  base_configuration = module.base.configuration
  product_version = "uyuni-master"
  name = "minion-ubuntu1804"
  image = "ubuntu1804"
  server_configuration = module.server.configuration
  provider_settings = {
    memory = 1024
  }
  auto_connect_to_master = true

}

Ansible Snippets for the Setup steps

- name: Import systemsmanagement:/sumaform RPM Key
  rpm_key:
    key: https://download.opensuse.org/repositories/systemsmanagement:/sumaform/openSUSE_Tumbleweed/repodata/repomd.xml.key
    state: present

- name: Add systemsmanagement:/sumaform RPM Repository
  community.general.zypper_repository:
    name: systemsmanagement_sumaform
    description: Using Terraform to create a SUSE Manager test environment (openSUSE_Tumbleweed)
    repo: https://download.opensuse.org/repositories/systemsmanagement:/sumaform/openSUSE_Tumbleweed/
    priority: 90
    state: present
  ignore_errors: true

- name: Package Installation (Uyuni Development - sumaform)
  community.general.zypper:
    name:
      - terraform
      - terraform-provider-libvirt
      - git-core
    allow_vendor_change: true
    force_resolution: true
    force: true
    state: latest