# Moving a ConfigMap deployment to cluster objects

Until now the console edited zones and address redirects by writing two
ConfigMaps (`fancy-dns-zones`, `fancy-dns-rpz`) through the resolver's service
account, and the domains page rewrote the config file. Those mechanisms are gone.
Everything the console edits is now an object:

| Was | Is |
|---|---|
| `zone--<apex>.zone` keys in the `fancy-dns-zones` ConfigMap | `DNSZone` |
| `address-overrides.rpz` in the `fancy-dns-rpz` ConfigMap | `AddressOverride` (one per name) |
| `blocklist.allow_entries` / `block_entries` | `DomainRule` (`inline-allow`, `inline-block`) |
| `blocklist.lists` with a URL | `BlockList` |
| `acl.groups` | `ClientGroup` |
| listeners, upstreams, cache, `default_policy` | still the resolver's YAML |

The old resolver does not read the objects and the new one does not read the
ConfigMaps, so the order below matters: **create the objects while the old
resolver is still serving, switch, then delete the ConfigMaps.** Nothing here
deletes anything until the last step.

## 1. Install the definitions and permissions

```sh
kubectl apply -f deploy/k8s/crds/crds.yaml
kubectl apply -k deploy/k8s/crds            # lets the resolver's service account read the objects
kubectl apply -f deploy/k8s/console/console.yaml   # the console, which writes them (create its two Secrets first)
```

## 2. Convert what you have

The command reads the two ConfigMaps from the cluster and, if you give it the
resolver's `config.yaml`, its URL lists, inline entries and ACL groups. By
default it only **prints** manifests.

```sh
kubectl -n dns get cm fancy-dns-config -o jsonpath='{.data.config\.yaml}' > /tmp/config.yaml

FANCYDNS_API_KEY=unused \
fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml > migrated.yaml
```

(`FANCYDNS_API_KEY=unused`: the config expands `${VAR}` references and refuses an
unset one; the value is not used.) Read `migrated.yaml`, and read what the
command printed on stderr:

* `converted:` lines say what became an object and what to remove from the config.
* `NOT converted:` lines are things it could not represent faithfully (a zone
  with a record type the console does not write, a list that is a file on the
  pod, a name that is not a legal object name). Those stay where they are.

Commit `migrated.yaml` if you manage the cluster with GitOps, or apply it:

```sh
fancy-dns-console migrate -kube-namespace dns -config /tmp/config.yaml -apply
```

It is safe to run again: objects are created or updated, never duplicated.

## 3. Switch the resolver

* Start it with `-kube` (the StatefulSet in `deploy/k8s/10-deployment.yaml` does).
* In `config.yaml`, remove what moved: the `edge-router-x-address-overrides` list
  and any other list you converted, `acl.groups`, the inline entries,
  `blocklist.managed_zones` and the `fancy-dns-zones` glob in `local_zones`.
* Roll it out.

## 4. Check before you delete anything

```sh
kubectl -n dns get dnszones,addressoverrides,clientgroups,blocklists,domainrules
curl -s https://<console>/api/status      # components.degraded must not mention kubernetes
dig @<resolver> <a name from each zone and override>
```

A rejected object is not a silent failure: it is logged by the resolver, the
node reports "kubernetes: objects rejected" as degraded, and an object that was
valid before keeps its last good version.

## 5. Delete the old ConfigMaps

Only now:

```sh
kubectl -n dns delete cm fancy-dns-zones fancy-dns-rpz
```

If your GitOps tool prunes, remove them from the repository **after** step 4, not
before: they hold the only copy of the data until the objects exist.