Creating dns records for apex / root domains #449

soosap · 2018-01-26T12:56:30Z

Not sure if this is a bug or just not possible by design or other limitations.

I am trying to automatically create a dns record for the apex / root domain. Unfortunately, those records are not being created. Manually, it's possible to point the apex to a AWS ELB. I also do not get any feedback from the ExternalDNS pod except: time="2018-01-26T09:07:31Z" level=info msg="All records are already up to date".

Can you clarify how I could achieve this? I also have not seen any examples where the apex is being set through ExternalDNS.

The text was updated successfully, but these errors were encountered:

phyllisstein · 2018-01-31T00:11:14Z

I'm seeing something similar with the CloudFlare provider. I have an ingress defined with two rule sets, like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: ignota.media
  name: rupertsberg
  namespace: prod-green
spec:
  rules:
    - host: ignota.media
      http:
        paths:
          - backend:
              serviceName: rupertsberg
              servicePort: http
    - host: www.ignota.media
      http:
        paths:
          - backend:
              serviceName: rupertsberg
              servicePort: http
  tls:
    - secretName: ignota-media-ssl
      hosts:
        - ignota.media
        - www.ignota.media

...and it looks like the External DNS watcher detects them both, based on a dry debug run:

/ # external-dns --source=ingress --provider=cloudflare --cloudflare-proxied --once --dry-run --metrics-address=:9797 --log-level=debug
INFO[0000] config: &{Master: KubeConfig: Sources:[ingress] Namespace: AnnotationFilter: FQDNTemplate: Compatibility: PublishInternal:false Provider:cloudflare GoogleProject: DomainFilter:[] AWSZoneType: AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup: CloudflareProxied:true InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true InMemoryZones:[] Policy:sync Registry:txt TXTOwnerID:default TXTPrefix: Interval:1m0s Once:true DryRun:true LogFormat:text MetricsAddress::9797 LogLevel:debug}
INFO[0000] running in dry-run mode. No changes to DNS records will be made.
INFO[0000] Connected to cluster at https://100.64.0.1:443
DEBU[0002] Endpoints generated from ingress: prod-green/rupertsberg: [ignota.media 0 IN CNAME af9f52be105f911e89e8306637a410d9-1940002126.us-east-1.elb.amazonaws.com www.ignota.media 0 IN CNAME af9f52be105f911e89e8306637a410d9-1940002126.us-east-1.elb.amazonaws.com]

In CloudFlare, however, only the www subdomain shows up.

Adding the apex domain manually isn't the worst thing, but it'd be great if you folks had any suggestions! 😬

The-Loeki · 2018-04-13T22:40:45Z

With SimpleDNS we register .mydomain.example.com. which creates, but somehow cant update. This seems more related to the driver itself though, or it's a fluke it works at all :)

time="2018-04-13T22:40:26Z" level=debug msg="Endpoints generated from service: example/example-ing-public-traefik: [.exampleapp.nl 60 IN A 1.2.3.4]" 
time="2018-04-13T22:40:26Z" level=debug msg="No endpoints could be generated from service example/webapp" 
time="2018-04-13T22:40:26Z" level=debug msg="No endpoints could be generated from service example/zipkin" 
time="2018-04-13T22:40:26Z" level=debug msg="No endpoints could be generated from ingress example/public" 
time="2018-04-13T22:40:26Z" level=info msg="Changing records: UPDATE {0  0 A .exampleapp.nl 1.2.3.4 0 0 false []  } in zone: exampleapp.nl" 
time="2018-04-13T22:40:27Z" level=error msg="PATCH https://api.dnsimple.com/v2/123456/zones/exampleapp.nl/records/123456123456: 400 System records cannot be updated"

mandrean · 2018-05-08T21:22:34Z

GKE k8s v1.9.6-gke.1
nginx-ingress v0.14.0
cert-manager v0.2.5
external-dns v0.5.0

Noticed the same in Google CloudDNS! Apex domains are not auto set up.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/acme-challenge-type: dns01
    certmanager.k8s.io/acme-dns01-provider: clouddns
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
  labels:
    app: website
    chart: static-website-0.1.0
    heritage: Tiller
    release: website
  name: website
  namespace: default
spec:
  rules:
  - host: 0x.se
    http:
      paths:
      - backend:
          serviceName: website
          servicePort: 80
        path: /
  - host: www.0x.se
    http:
      paths:
      - backend:
          serviceName: website
          servicePort: 80
        path: /
  tls:
  - hosts:
    - 0x.se
    - www.0x.se
    secretName: website-prod

$ kubectl logs -l app=external-dns -n kube-system

time="2018-05-08T21:04:53Z" level=info msg="All records are already up to date"
time="2018-05-08T21:05:54Z" level=info msg="Change zone: default-zone-0xse"
time="2018-05-08T21:05:54Z" level=info msg="Add records: www.0x.se. A [35.195.241.48] 300"
time="2018-05-08T21:05:54Z" level=info msg="Add records: www.0x.se. TXT [\"heritage=external-dns,external-dns/owner=extdns-main-cluster,external-dns/resource=ingress/default/website\"] 300"
time="2018-05-08T21:06:55Z" level=info msg="All records are already up to date"

:(

joekohlsdorf · 2018-05-15T16:06:33Z

Same on AWS with v0.5.0, maybe caused by the APEX having NS and SOA records set?
Weird that debug doesn't say anything about it though.

phyllisstein · 2018-05-17T15:38:05Z

On a whim, I tried setting the external-dns.alpha.kubernetes.io/hostname annotation to @ (which CloudFlare uses to signify the apex domain), but no dice.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    # No bueno.
    external-dns.alpha.kubernetes.io/hostname: '@'

ZigZagT · 2018-08-07T15:45:44Z

ran into the same issue. with the log entries:

time="2018-08-07T15:39:09Z" level=debug msg="Endpoints generated from ingress: default/xxx: [my.domain 0 IN A xxx.xxx.xxx.xxx my.domain 0 IN A xxx.xxx.xxx.xxx]"
time="2018-08-07T15:39:09Z" level=debug msg="Removing duplicate endpoint my.domain 0 IN A xxx.xxx.xxx.xxx"
time="2018-08-07T15:39:09Z" level=debug msg="Skipping endpoint my.domain 0 IN A xxx.xxx.xxx.xxx because owner id does not match, found: \"\", required: \"default\""
time="2018-08-07T15:39:09Z" level=debug msg="Skipping endpoint my.domain 0 IN TXT \"google-site-verification=abcde\" because owner id does not match, found: \"\", required: \"default\""
time="2018-08-07T15:39:09Z" level=info msg="All records are already up to date"

env:

GKE 1.10.5-gke.3
nginx-ingress 0.23.0(chart) 0.15.0(app)
external-dns 0.7.1(chart) v0.5.4(app)

JannikZed · 2018-11-05T20:46:54Z

I have the same issue - trying to write to my root domain pfefferundfrost.com with DNSimple provider -resulting in a strange error:
External-dns is writing the A record for pfefferundfrost.com.pfefferundfrost.com and complaining later:

time="2018-11-05T20:44:44Z" level=info msg="Changing records: CREATE {0 0 A pfefferundfrost.com 176.9.XXX.XXX 3600 0 false [] } in zone: pfefferundfrost.com"
5.11.2018 21:44:44 time="2018-11-05T20:44:44Z" level=error msg="POST https://api.dnsimple.com/v2/71763/zones/pfefferundfrost.com/records: 400 Zone record already exists"

How to fix this?

phyllisstein · 2018-12-03T04:14:06Z

Not sure when this landed---there's nothing of note in the CHANGELOG---but this appears to be fixed as of v0.5.9-15-gf25f90db (which I'm pulling into my cluster from the latest tag).

An ingress that looks like this will now correctly assign a record to the apex in CloudFlare:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: site
spec:
  rules:
    - host: site.tld
      http:
        paths:
          - backend:
              serviceName: site
              servicePort: http
    - host: www.site.tld
      http:
        paths:
          - backend:
              serviceName: site
              servicePort: http

sylver · 2018-12-12T15:32:07Z

It is indeed fixed as @phyllisstein said but it raises another issue : apex are usually associated with a lot of TXT records (google verification, spf, and other stuff) which seem to prevent external-dns to create its own entries :

time="2018-12-12T15:28:03Z" level=info msg="Change zone: REDACTED"
time="2018-12-12T15:28:03Z" level=info msg="Add records: REDACTED A [REDACTED] 300"
time="2018-12-12T15:28:03Z" level=info msg="Add records: REDACTED TXT [\"heritage=external-dns,external-dns/owner=REDACTED,external-dns/resource=ingress/REDACTED/REDACTED\"] 300"
time="2018-12-12T15:28:03Z" level=error msg="googleapi: Error 409: The resource 'entity.change.additions[1]' named 'REDACTED (TXT)' already exists, alreadyExists"

Related to #443 #692

JannikZed · 2018-12-12T20:34:02Z

It is working with www.domain.tld, but not with domain.tld .. Even with the newest version I still get something like A | domain.tld.domain.tld | 176.XX.XX.XX for DNSIMPLE.

bkleef · 2018-12-14T16:56:50Z

Same here for DNSimple with:

external-dns.alpha.kubernetes.io/hostname: .example.nl.,www.example.nl.,.example.be.,www.example.be.

sylver · 2019-01-14T10:02:52Z

Any update here ? This is really an issue to not being able to set our domain apex along with other entries because of TXT records.
Maybe there is a workaround I can't think of ?

Kind of really busy but if I can help on something to make this go forward, let me know.

joekohlsdorf · 2019-04-05T18:23:51Z

Tested this again today on Route53 using external-dns v0.5.12 and it works 🎉!

Edit: Only if there is no other TXT record on the apex domain (in my case I have some Google site verification records):
time="2019-04-05T18:27:27Z" level=error msg="InvalidChangeBatch: [Tried to create resource record set [name='domain.name.', type='TXT'] but it already exists]\n\tstatus code: 400, request id: 76e454b6-57d0-11e9-9d8e-19e9906e17ea"

echoboomer · 2019-04-09T01:06:14Z

Creation of records for root/apex works fine for us, but we're running into the same issue others are reporting re: managing TXT records. We manage our Route 53 records using Terraform, but that isn't working as we're starting to deploy stage/prod services to our new EKS clusters because the TXT record for the root zone already exists because of external-dns and the Terraform apply for other TXT records for root fails.

echoboomer · 2019-04-09T15:22:10Z

We solved our issue by using the prefix option. We added it to the values file of the Helm chart as such:
txtPrefix: "${prefixName}."

This would generate prefixName.foobar.com, for example.

elafarge · 2019-04-24T13:16:39Z

I'm still having the problem on v0.5.13. My zone has NS and SOA records pointing to example.com (redacted). www.example.com records are created with success but example.com records (part of the same Ingress rule) aren't. Here's the log I'm getting:

{"level":"debug","msg":"Skipping endpoint example.com 0 IN CNAME REDACTED.eu-west-3.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"k8s-prod-public\"","time":"2019-04-24T13:02:36Z"}

Any help would be highly appreciated :)

echoboomer · 2019-04-24T13:24:52Z

@elafarge that error happens when external-dns skips a record because there's no tag on it signifying that it should be managing it. It will always create a TXT record with a value similar to this:

"heritage=external-dns,external-dns/owner=kube-cluster-name,external-dns/resource=service/namespace/service-name"

If you look at one of the other records that external-dns is managing, you'll see a tag similar to that one, and you'll want the cluster name to match k8s-prod-public which is what it is looking for. You can get around this by manually tagging the records it's complaining about, but removing the existing records and letting it recreate them is also a viable option depending on environment and tolerance for that type of change.

Hopefully that made sense.

Evesy · 2019-07-05T13:23:26Z

@echoboomer We're probably going to do the same. Did you run into any gotcha's with having the TXT prefix being a subzone? (Right now it's just a prefix in the same zone). I can't think of anything that would be an issue but you never know

frittentheke · 2019-08-02T14:20:42Z

We ran into the issue @joekohlsdorf describes:

Having external-dns manage an apex record is no issue in itself. Just on AWS / Route53 you may not simply add another TXT record if one (like one for DKIM / SPF) exists, but apparently you have to "add" yourself to the existing record:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html#TXTFormat

fejta-bot · 2019-10-31T15:17:25Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

frittentheke · 2019-10-31T17:11:07Z

/remove-lifecycle stale

fejta-bot · 2020-01-30T00:35:17Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

frittentheke · 2020-02-14T06:16:45Z

/remove-lifecycle stale

b-dean · 2022-08-10T19:45:44Z

@mariusmarais,

have you had any luck with deleting records created this way? It's not finding the owner for me. I changed my prefix to not have anything resulting in a trailing dash like you had suggested.

--text-prefix="txt%{record_type}."

So for something like foo.example.com I'd end up with these TXT:

Name	Type	Value
foo.example.com	CNAME	something-else.example.com
txt.foo.example.com	TXT	"heritage=external-dns,external-dns/owner=example,external-dns/resource=crd/foo/example"
txtcname.foo.example.com	TXT	"heritage=external-dns,external-dns/owner=example,external-dns/resource=crd/foo/example"

but then when I delete the resource that caused these records to show up, the log on the delete says:

Skipping endpoint foo.example.com 300 IN CNAME  something-else.example.com [] because owner id does not match, found: "", required: "example"

Which makes me think it probably wouldn't update a record that change either.

I'm not sure this has anything to do with the apex stuff, just how it's finding the owner when you have a prefix.

mariusmarais · 2022-08-11T04:38:42Z

I hadn't noticed that, but we haven't deleted services in a long time. Would be a separate bug I suppose.

k8s-triage-robot · 2022-11-09T05:28:30Z

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot · 2022-12-09T05:52:21Z

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

DerEnderKeks · 2022-12-09T09:15:50Z

/remove-lifecycle rotten

cdenneen · 2023-01-11T21:22:20Z

If you specify the annotation for hostname and ingress-hostname-source you can avoid the APEX records trying to create:

external-dns.alpha.kubernetes.io/ingress-hostname-source: "annotation-only"

k8s-triage-robot · 2023-04-11T22:12:46Z

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

DerEnderKeks · 2023-04-12T06:34:16Z

/remove-lifecycle stale

k8s-triage-robot · 2023-07-13T11:58:12Z

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

mlazowik · 2023-07-13T13:52:50Z

/remove-lifecycle stale

benriou · 2023-08-22T12:32:18Z

So for something like foo.example.com I'd end up with these TXT:

Name Type Value
foo.example.com CNAME something-else.example.com
txt.foo.example.com TXT "heritage=external-dns,external-dns/owner=example,external-dns/resource=crd/foo/example"
txtcname.foo.example.com TXT "heritage=external-dns,external-dns/owner=example,external-dns/resource=crd/foo/example"
but then when I delete the resource that caused these records to show up, the log on the delete says:
Skipping endpoint foo.example.com 300 IN CNAME  something-else.example.com [] because owner id does not match, found: "", required: "example"
Which makes me think it probably wouldn't update a record that change either.

I'm not sure this has anything to do with the apex stuff, just how it's finding the owner when you have a prefix.

Hello,

Using the AWS/Route53 plugin, we're facing the same problem for APEX domains.
The current configuration it text-prefix ending by a dash.

Whatever we're trying to do, ExternalDNS keep complaining

time="2023-08-22T09:41:46Z" level=debug msg="Skipping endpoint ourdomain.com 0 IN CNAME  desired-value.elb.amazonaws.com [{alias true} {aws/evaluate-target-health true}] because owner
id does not match, found: \"\", required: \"eks-production\""
time="2023-08-22T09:41:46Z" level=debug msg="Skipping endpoint ourdomain.com 300 IN CNAME  current-value.eu-central-1.elb.amazonaws.com [{aws/evaluate-target-health false} {alias true}] 
ecause owner id does not match, found: \"\", required: \"eks-production\""

Our external DNS configuration is a follows :

  - args:
    - --metrics-address=:7979
    - --log-level=debug
    - --log-format=text
    - --namespace=production
    - --domain-filter=ourdomain.com
    - --policy=upsert-only
    - --provider=aws
    - --registry=txt
    - --interval=1m
    - --txt-owner-id=eks-production
    - --txt-prefix=external-dns-
    - --annotation-filter=external-dns.alpha.kubernetes.io/exclude notin (true)
    - --source=service
    - --source=ingress
    - --aws-api-retries=3
    - --aws-zone-type=
    - --aws-batch-change-size=1000

We tried to create the TXT records with the expected value as follows :

external-dns-.ourdomain.com
external-dns-cname-.ourdomain.com

Both resolves publicly correctly, with the expected TXT value, with no more success.

Is there a way to retrieve which DNS record is exactly requested by ExternalDNS ?

k8s-triage-robot · 2024-01-26T19:35:56Z

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue as fresh with /remove-lifecycle stale
Close this issue with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

morremeyer · 2024-01-26T19:36:35Z

/remove-lifecycle stale

richieganney · 2024-02-23T10:32:56Z

I am using helm to deploy external-dns and this did it for me:

fqdnTemplates:
  - "{{.Name}}.your-domain.com"
  - "your-domain.com"
domainFilters:
  - your-domain.com

yarashagarwal · 2024-03-05T13:59:02Z

We are using v0.13.4 with Azure DNS. We have existing TXT records for the apex and we still have the external-dns creating apex A record for our K8S ingress.

hjacobs mentioned this issue May 31, 2018

External DNS attempts to delete unrelated TXT records. #580

Closed

The-Loeki mentioned this issue Sep 12, 2018

TXT registry with apex records #692

Closed

PurpleBooth mentioned this issue Sep 18, 2018

Can't combine domains and subdomain hostnames #710

Closed

jbowes mentioned this issue Apr 27, 2019

DNSimple: Support apex records #1004

Merged

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 31, 2019

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 31, 2019

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 30, 2020

matmicro mentioned this issue Oct 6, 2022

Cert-manager DNS Webhook ovh/public-cloud-roadmap#311

Open

dpoetzsch mentioned this issue Oct 6, 2022

GKE & Cloud DNS "No matching zone warning for record" messages for all root/apex domains #2971

Closed

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 9, 2022

cuppett mentioned this issue Nov 27, 2022

TXT records with multiple targets are not handled properly #2762

Closed

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Dec 9, 2022

k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Dec 9, 2022

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 11, 2023

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 12, 2023

szuecs added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Apr 14, 2023

Sewci0 mentioned this issue Jun 27, 2023

[TXT Registry] Fix handling of records produced by toNewTXTName in toEndpoint #3724

Merged

1 task

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 13, 2023

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 13, 2023

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 26, 2024

k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 26, 2024

Creating dns records for apex / root domains #449

Creating dns records for apex / root domains #449

Comments

soosap commented Jan 26, 2018

phyllisstein commented Jan 31, 2018

The-Loeki commented Apr 13, 2018 • edited

mandrean commented May 8, 2018 • edited

joekohlsdorf commented May 15, 2018

phyllisstein commented May 17, 2018 • edited

ZigZagT commented Aug 7, 2018

env:

JannikZed commented Nov 5, 2018 • edited

phyllisstein commented Dec 3, 2018

sylver commented Dec 12, 2018 • edited

JannikZed commented Dec 12, 2018

bkleef commented Dec 14, 2018

sylver commented Jan 14, 2019

joekohlsdorf commented Apr 5, 2019 • edited

echoboomer commented Apr 9, 2019

echoboomer commented Apr 9, 2019

elafarge commented Apr 24, 2019

echoboomer commented Apr 24, 2019 • edited

Evesy commented Jul 5, 2019

frittentheke commented Aug 2, 2019 • edited

fejta-bot commented Oct 31, 2019

frittentheke commented Oct 31, 2019

fejta-bot commented Jan 30, 2020

frittentheke commented Feb 14, 2020

b-dean commented Aug 10, 2022 • edited

mariusmarais commented Aug 11, 2022

k8s-triage-robot commented Nov 9, 2022

k8s-triage-robot commented Dec 9, 2022

DerEnderKeks commented Dec 9, 2022

cdenneen commented Jan 11, 2023

k8s-triage-robot commented Apr 11, 2023

DerEnderKeks commented Apr 12, 2023

k8s-triage-robot commented Jul 13, 2023

mlazowik commented Jul 13, 2023

benriou commented Aug 22, 2023 • edited

k8s-triage-robot commented Jan 26, 2024

morremeyer commented Jan 26, 2024

richieganney commented Feb 23, 2024

yarashagarwal commented Mar 5, 2024

The-Loeki commented Apr 13, 2018 •

edited

mandrean commented May 8, 2018 •

edited

phyllisstein commented May 17, 2018 •

edited

JannikZed commented Nov 5, 2018 •

edited

sylver commented Dec 12, 2018 •

edited

joekohlsdorf commented Apr 5, 2019 •

edited

echoboomer commented Apr 24, 2019 •

edited

frittentheke commented Aug 2, 2019 •

edited

b-dean commented Aug 10, 2022 •

edited

benriou commented Aug 22, 2023 •

edited