NE-2747: Add external-dns-operator v1.3.6 bundle to all FBC catalogs

[alebedev87]

Summary

• Add external-dns-operator.v1.3.6 bundle entry to all FBC catalog-template.yaml files (v4.12-v4.22) using registry.redhat.io
• Add v1.3.6 to stable-v1 and stable-v1.3 channel entries (replaces v1.3.5)
• Regenerate all catalog.yaml files with make generate-catalog OCP_VERSION=4.X

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR rolls out external-dns-operator.v1.3.6 through OLM catalog versions v4.12 to v4.22. For each version, the template is updated to add the new bundle to stable-v1 and stable-v1.3 with replaces: external-dns-operator.v1.3.5 and skipRange: <1.3.6, plus a new bundle image reference. The generated catalogs are updated to match those channel entries, refresh related bundle image references where needed, and replace or append the full olm.bundle metadata for version v1.3.6 with updated CSV properties and related image digests.

Possibly related PRs

• openshift/external-dns-operator#453: Earlier catalog rollout advancing from v1.3.3 to v1.3.4 using the same template and catalog update pattern.
• openshift/external-dns-operator#467: Catalog rollout advancing from v1.3.4 to v1.3.5 with the same OLM channel and bundle update structure.

Suggested reviewers

• davidesalerno
• gcs278

🚥 Pre-merge checks | ✅ 5 | ❌ 10

❌ Failed checks (10 inconclusive)

Check name	Status	Explanation	Resolution
Stable And Deterministic Test Names	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Test Structure And Quality	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Microshift Test Compatibility	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Single Node Openshift (Sno) Test Compatibility	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Topology-Aware Scheduling Compatibility	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Ote Binary Stdout Contract	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Ipv6 And Disconnected Network Test Compatibility	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
No-Weak-Crypto	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
Container-Privileges	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.
No-Sensitive-Data-In-Logs	❓ Inconclusive	Repository clone failed, so this custom check could not run with code access.	Retry the review run. If this persists, inspect pre-merge custom-check logs for infrastructure or agent runtime failures.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The description is directly related to the changeset, providing a structured summary of what was added and the process followed (template updates, channel entries, and catalog regeneration).
Title check	✅ Passed	The title clearly and specifically describes the primary change: adding external-dns-operator v1.3.6 bundle to FBC catalogs across OpenShift versions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 9

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@catalog/v4.12/catalog.yaml`:
- Line 1098: The ClusterRoleBinding at line 1098 currently grants the
external-dns ClusterRole to groups (system:serviceaccounts:external-dns and
system:serviceaccounts:external-dns-operator) that include all service accounts
in those namespaces, violating the least privilege principle. Replace these
group-based subjects with specific ServiceAccount subjects pointing to the
individual service accounts that actually need the external-dns cluster
permissions. Change each group subject to a ServiceAccount subject with the
appropriate kind ("ServiceAccount"), name (the actual service account name), and
namespace values.
- Line 1080: The base64-encoded CSV data at line 1080 contains deployment
manifests that lack required pod runtime controls. Instead of directly patching
the encoded payload, locate the source CSV or deployment manifests in the
operator's repository (particularly the deployment specs for the
external-dns-operator and kube-rbac-proxy containers), then add resource limits
(cpu, memory) to every container, define liveness probes alongside the existing
readiness probes, and add readOnlyRootFilesystem: true to the securityContext of
each container. After making these changes to the source manifests, regenerate
and rebuild the catalog bundle to update this encoded data rather than modifying
it directly.

In `@catalog/v4.13/catalog.yaml`:
- Around line 1076-1110: Locate the source ClusterServiceVersion manifest file
(not the base64-encoded version in catalog.yaml) and apply the following
security hardening fixes: For the external-dns-operator container in the
deployment spec, add `readOnlyRootFilesystem: true` to the securityContext, add
resource limits (matching the pattern shown for kube-rbac-proxy with cpu and
memory requests), and add a livenessProbe (referencing the existing health-check
port and /livez or similar path). For the kube-rbac-proxy container, add
`readOnlyRootFilesystem: true` to its securityContext, add resource limits, and
add both readinessProbe and livenessProbe (using the https port and /livez type
paths). Additionally, create a new NetworkPolicy manifest in the bundle
directory following Kubernetes security best practices to restrict traffic to
the operator namespace and related services. After making these changes to the
source manifests, regenerate the catalog using your build tooling to produce the
updated base64-encoded bundle, rather than manually editing the encoded payload.

In `@catalog/v4.14/catalog.yaml`:
- Around line 1078-1080: The operator deployment specification is missing
critical security and reliability configurations. Locate the source
ClusterServiceVersion (CSV) manifest that defines the deployment for
external-dns-operator (not the generated catalog.yaml), and update both the
external-dns-operator and kube-rbac-proxy container specifications to add
resource.limits (matching or exceeding the requests of 100m cpu/30Mi memory for
the operator and 100m cpu/20Mi memory for the proxy), add livenessProbe to both
containers with appropriate endpoint paths and timing parameters, ensure
readinessProbe is present on both containers, and add
securityContext.readOnlyRootFilesystem: true to all containers. After making
these changes to the source CSV manifest, regenerate the catalog bundle/OLM data
to reflect the updated deployment specification.

In `@catalog/v4.15/catalog.yaml`:
- Line 1077: The ClusterRole RBAC objects at lines 1092-1095 are granting
permissions to the wrong API group and resource names compared to the CRD
defined at line 1077. The CRD serves
`externaldnses.externaldns.olm.openshift.io`, but the RBAC viewer and editor
roles are granting access to `externaldns` resource with incorrect API groups
(including references to `operator.openshift.io`). Regenerate the encoded RBAC
ClusterRoles to properly reference the correct API group
`externaldns.olm.openshift.io` and the correct resource name `externaldnses` so
that role bindings will authorize access to the actual ExternalDNS resources
defined by the CRD.
- Line 1080: The base64-encoded cluster service version manifest in the catalog
file is missing required pod hardening configuration. Decode the base64 data in
the `alm-examples` annotation to locate the Deployment specification for the
external-dns-operator and kube-rbac-proxy containers. Add the missing pod
hardening fields: include `readOnlyRootFilesystem: true` in the securityContext
for both containers, add `resources.limits` for CPU and memory on every
container (not just requests), add liveness probes to the external-dns-operator
container, and add a readiness probe to the kube-rbac-proxy container. After
making these updates to the source manifests, re-encode the updated manifest
back to base64 and replace the existing base64-encoded data in the catalog YAML
file.

In `@catalog/v4.16/catalog.yaml`:
- Line 1080: The catalog entry contains a base64-encoded CSV with an embedded
deployment that is missing required liveness and readiness probes. Locate the
source operator bundle/CSV file (not this generated catalog file) and add a
liveness probe to the external-dns-operator container (which currently has only
a readiness probe) and add both liveness and readiness probes to the
kube-rbac-proxy sidecar container (which currently has no probes). After making
these changes to the source bundle/CSV manifest, regenerate the catalog YAML
file to update the base64-encoded data field at this location with the new probe
definitions.
- Line 1080: The CSV data in the catalog file contains deployment specifications
for two containers (external-dns-operator and kube-rbac-proxy) that currently
have only resources.requests defined but lack resources.limits. Decode the
base64-encoded data field at line 1080, locate the spec.install.spec.deployments
array, and add calibrated resources.limits (CPU and memory) to both container
specifications alongside their existing resources.requests. Set appropriate
limits such as 500m CPU and 150Mi memory for external-dns-operator, and 200m CPU
and 100Mi memory for kube-rbac-proxy. After adding the limits, re-encode the
modified manifest back to base64 and update the data field with the new encoded
value to ensure Kubernetes resource governance is properly enforced.
- Line 1080: The base64-encoded data field at line 1080 contains an embedded
ClusterServiceVersion manifest with a deployment specification. The deployment
has two containers named "external-dns-operator" and "kube-rbac-proxy", each
with a securityContext that omits readOnlyRootFilesystem. Update the source CSV
file in the bundle to add readOnlyRootFilesystem: true to both container
security contexts (alongside the existing allowPrivilegeEscalation: false,
runAsNonRoot: true, and capabilities settings), then regenerate the catalog from
that updated source so the encoded manifest in this field reflects the hardened
configuration.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 928915ec-e463-4d1e-95ff-1fc9701d8c6d

📥 Commits

Reviewing files that changed from the base of the PR and between 08ec426 and 4a32dd8.

📒 Files selected for processing (22)

• catalog/v4.12/catalog-template.yaml
• catalog/v4.12/catalog.yaml
• catalog/v4.13/catalog-template.yaml
• catalog/v4.13/catalog.yaml
• catalog/v4.14/catalog-template.yaml
• catalog/v4.14/catalog.yaml
• catalog/v4.15/catalog-template.yaml
• catalog/v4.15/catalog.yaml
• catalog/v4.16/catalog-template.yaml
• catalog/v4.16/catalog.yaml
• catalog/v4.17/catalog-template.yaml
• catalog/v4.17/catalog.yaml
• catalog/v4.18/catalog-template.yaml
• catalog/v4.18/catalog.yaml
• catalog/v4.19/catalog-template.yaml
• catalog/v4.19/catalog.yaml
• catalog/v4.20/catalog-template.yaml
• catalog/v4.20/catalog.yaml
• catalog/v4.21/catalog-template.yaml
• catalog/v4.21/catalog.yaml
• catalog/v4.22/catalog-template.yaml
• catalog/v4.22/catalog.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Regenerate the bundle with the required pod runtime controls.

Line 1080’s decoded CSV installs containers with only resource requests, missing liveness probes, and no readOnlyRootFilesystem: true. Fix the source CSV/deployment manifests and regenerate the catalog rather than patching this encoded payload directly.

As per coding guidelines, Resource limits (cpu, memory) on every container, Liveness + readiness probes defined, and securityContext: runAsNonRoot, readOnlyRootFilesystem are required.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@catalog/v4.12/catalog.yaml` at line 1080, The base64-encoded CSV data at line
1080 contains deployment manifests that lack required pod runtime controls.
Instead of directly patching the encoded payload, locate the source CSV or
deployment manifests in the operator's repository (particularly the deployment
specs for the external-dns-operator and kube-rbac-proxy containers), then add
resource limits (cpu, memory) to every container, define liveness probes
alongside the existing readiness probes, and add readOnlyRootFilesystem: true to
the securityContext of each container. After making these changes to the source
manifests, regenerate and rebuild the catalog bundle to update this encoded data
rather than modifying it directly.

Source: Coding guidelines

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Bind cluster permissions to concrete service accounts.

Line 1098’s decoded ClusterRoleBinding grants the external-dns ClusterRole to system:serviceaccounts:external-dns and system:serviceaccounts:external-dns-operator, which covers every service account in those namespaces. Bind only the operator/operand service accounts that need these cluster-scoped reads.

As per coding guidelines, RBAC: least privilege; no cluster-admin for workloads is required.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@catalog/v4.12/catalog.yaml` at line 1098, The ClusterRoleBinding at line 1098
currently grants the external-dns ClusterRole to groups
(system:serviceaccounts:external-dns and
system:serviceaccounts:external-dns-operator) that include all service accounts
in those namespaces, violating the least privilege principle. Replace these
group-based subjects with specific ServiceAccount subjects pointing to the
individual service accounts that actually need the external-dns cluster
permissions. Change each group subject to a ServiceAccount subject with the
appropriate kind ("ServiceAccount"), name (the actual service account name), and
namespace values.

Source: Coding guidelines

[alebedev87]

/retest-required

[alebedev87]

4.22 deploy pipeline has the right kube-rbac-proxy:

$ oras pull quay.io/redhat-user-workloads/external-dns-operator-tenant/ext-dns-optr-fbc-v4-22/external-dns-fbc-container-ext-dns-optr-fbc-v4-22:4a32dd8ad25d7e655e48a4b01ae196d9908d39f2-8bc4e2d5-d7ae-43b0-a382-2e0f1741f570

konflux-artifacts$ ag -A15 'relatedImages' clusterserviceversions.json | grep kube-rbac-proxy
484-                        "image": "registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9@sha256:0fc6a16b71e2719d9d01d6dfeb83077c38562c08d628d1f1ae03fabe3a5b9a91",
485-                        "name": "kube-rbac-proxy"
1152-                        "image": "registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9@sha256:0fc6a16b71e2719d9d01d6dfeb83077c38562c08d628d1f1ae03fabe3a5b9a91",
1153-                        "name": "kube-rbac-proxy"

[melvinjoseph86]

/lgtm

[Thealisyed]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Thealisyed

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Thealisyed]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[alebedev87]

/hold

[alebedev87]

/unhold

[openshift-ci-robot]

@alebedev87: This pull request references NE-2747 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

• Add external-dns-operator.v1.3.6 bundle entry to all FBC catalog-template.yaml files (v4.12-v4.22) using registry.redhat.io
• Add v1.3.6 to stable-v1 and stable-v1.3 channel entries (replaces v1.3.5)
• Regenerate all catalog.yaml files with make generate-catalog OCP_VERSION=4.X

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@catalog/v4.13/catalog-template.yaml`:
- Around line 156-158: The external-dns-operator.v1.3.6 bundle image reference
uses the production registry registry.redhat.io instead of the stage registry
required for this PR's rollout. In the bundle entry for
external-dns-operator.v1.3.6, update the image field to replace
registry.redhat.io with registry.stage.redhat.io to ensure the catalog can
properly resolve and promote stage-hosted artifacts. Keep the remaining image
digest and path structure intact.

In `@catalog/v4.13/catalog.yaml`:
- Line 1077: The externaldns-viewer ClusterRole in the encoded CRD data
currently uses the API group `operator.openshift.io` in its RBAC rules, but the
CRD itself is defined under the API group `externaldns.olm.openshift.io`. Decode
the base64-encoded data field at line 1077, locate the embedded ClusterRole
definition for externaldns-viewer, and update the apiGroup in the rules section
from `operator.openshift.io` to `externaldns.olm.openshift.io` to match the
CRD's actual API group. After making this correction, re-encode the updated YAML
back to base64 and replace the data field value.

In `@catalog/v4.16/catalog.yaml`:
- Around line 643-644: The external-dns-operator-bundle image reference is
pointing to registry.redhat.io/edo but should point to
registry.stage.redhat.io/edo for stage catalog releases. Update the image
registry URL from registry.redhat.io/edo to registry.stage.redhat.io/edo at line
643 and all other related operator bundle/operand image references throughout
the file (including lines 1057 and 1112-1119). Note that kube-rbac-proxy images
should remain on registry.redhat.io. After updating the source bundle/template,
regenerate the catalog so the encoded CSV reference at line 1080 is also
automatically updated to reflect the new registry URL.

In `@catalog/v4.19/catalog.yaml`:
- Line 5688: The external-dns-operator-bundle image reference at line 5688 is
pointing to the production registry (registry.redhat.io) but should use the
stage registry (registry.stage.redhat.io) for stage catalog entries. Replace
registry.redhat.io with registry.stage.redhat.io in the image field for the
external-dns-operator-bundle reference. Apply the same change to the other
external-dns-* image references mentioned at lines 6036 and 6098-6105, ensuring
that any kube-rbac-proxy or other supporting images remain on registry.redhat.io
as they should not be changed to the stage registry.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 36f654f5-3e37-458e-a731-6f144719255b

📥 Commits

Reviewing files that changed from the base of the PR and between 4a32dd8 and 8fa6ce3.

📒 Files selected for processing (22)

• catalog/v4.12/catalog-template.yaml
• catalog/v4.12/catalog.yaml
• catalog/v4.13/catalog-template.yaml
• catalog/v4.13/catalog.yaml
• catalog/v4.14/catalog-template.yaml
• catalog/v4.14/catalog.yaml
• catalog/v4.15/catalog-template.yaml
• catalog/v4.15/catalog.yaml
• catalog/v4.16/catalog-template.yaml
• catalog/v4.16/catalog.yaml
• catalog/v4.17/catalog-template.yaml
• catalog/v4.17/catalog.yaml
• catalog/v4.18/catalog-template.yaml
• catalog/v4.18/catalog.yaml
• catalog/v4.19/catalog-template.yaml
• catalog/v4.19/catalog.yaml
• catalog/v4.20/catalog-template.yaml
• catalog/v4.20/catalog.yaml
• catalog/v4.21/catalog-template.yaml
• catalog/v4.21/catalog.yaml
• catalog/v4.22/catalog-template.yaml
• catalog/v4.22/catalog.yaml

✅ Files skipped from review due to trivial changes (1)

• catalog/v4.20/catalog-template.yaml

🚧 Files skipped from review as they are similar to previous changes (15)

• catalog/v4.16/catalog-template.yaml
• catalog/v4.17/catalog-template.yaml
• catalog/v4.14/catalog-template.yaml
• catalog/v4.22/catalog-template.yaml
• catalog/v4.15/catalog-template.yaml
• catalog/v4.12/catalog-template.yaml
• catalog/v4.18/catalog-template.yaml
• catalog/v4.15/catalog.yaml
• catalog/v4.21/catalog.yaml
• catalog/v4.21/catalog-template.yaml
• catalog/v4.22/catalog.yaml
• catalog/v4.17/catalog.yaml
• catalog/v4.20/catalog.yaml
• catalog/v4.18/catalog.yaml
• catalog/v4.19/catalog-template.yaml

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Description: Decode the v1.3.6 bundle RBAC objects and compare them to the CRD group/plural.
# Expect: externaldns-editor and externaldns-viewer should both grant
#         apiGroups=["externaldns.olm.openshift.io"] and resources including "externaldnses".

python - <<'PY'
import base64
import json
import pathlib
import re

path = pathlib.Path("catalog/v4.13/catalog.yaml")
text = path.read_text()

match = re.search(
    r"(?ms)^image: .*\nname: external-dns-operator\.v1\.3\.6\npackage: external-dns-operator\nproperties:\n.*?^schema: olm\.bundle",
    text,
)
if not match:
    raise SystemExit("external-dns-operator.v1.3.6 bundle block not found")

objects = [
    json.loads(base64.b64decode(m.group(1)))
    for m in re.finditer(r"^\s+data:\s*([A-Za-z0-9+/=]+)\s*$", match.group(0), re.MULTILINE)
]

crd = next(obj for obj in objects if obj.get("kind") == "CustomResourceDefinition")
print("CRD:", crd["spec"]["group"], crd["spec"]["names"]["plural"])

for obj in objects:
    if obj.get("kind") == "ClusterRole" and obj["metadata"]["name"] in {"externaldns-editor", "externaldns-viewer"}:
        print(obj["metadata"]["name"], obj["rules"])
PY

Repository: openshift/external-dns-operator

Length of output: 7638

---

Fix the externaldns-viewer ClusterRole to use the correct API group.

The CRD defines group externaldns.olm.openshift.io, but the decoded externaldns-viewer ClusterRole grants resources from operator.openshift.io. This mismatch will prevent the viewer role from authorizing access to ExternalDNS CRs. Update the source RBAC manifest and regenerate the catalog to use externaldns.olm.openshift.io in the viewer role rules.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@catalog/v4.13/catalog.yaml` at line 1077, The externaldns-viewer ClusterRole
in the encoded CRD data currently uses the API group `operator.openshift.io` in
its RBAC rules, but the CRD itself is defined under the API group
`externaldns.olm.openshift.io`. Decode the base64-encoded data field at line
1077, locate the embedded ClusterRole definition for externaldns-viewer, and
update the apiGroup in the rules section from `operator.openshift.io` to
`externaldns.olm.openshift.io` to match the CRD's actual API group. After making
this correction, re-encode the updated YAML back to base64 and replace the data
field value.

[melvinjoseph86]

/lgtm

[openshift-ci]

@alebedev87: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.