Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
178 changes: 2 additions & 176 deletions search-state.json
Original file line number Diff line number Diff line change
@@ -1,179 +1,5 @@
{
"version": 1,
"lastUpdated": "2026-03-02T19:43:54.021Z",
"projects": {
"strimzi/strimzi-kafka-operator": {
"github-issues": {
"lastSearched": "2026-03-02T19:37:57.626Z",
"processedIds": [
"gh:strimzi/strimzi-kafka-operator#9857",
"gh:strimzi/strimzi-kafka-operator#11210",
"gh:strimzi/strimzi-kafka-operator#9153",
"gh:strimzi/strimzi-kafka-operator#6180"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:00.103Z",
"processedIds": [],
"cursor": "Y3Vyc29yOnYyOpK0MjAyNS0wMS0wOFQxMzo1MDozMVrOAHb6Yg=="
}
},
"thanos-io/thanos": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:20.706Z",
"processedIds": [
"gh:thanos-io/thanos#8110",
"gh:thanos-io/thanos#1952",
"gh:thanos-io/thanos#1906",
"gh:thanos-io/thanos#4141",
"gh:thanos-io/thanos#1268",
"gh:thanos-io/thanos#6816",
"gh:thanos-io/thanos#4292",
"gh:thanos-io/thanos#5408",
"gh:thanos-io/thanos#2138",
"gh:thanos-io/thanos#3166",
"gh:thanos-io/thanos#4934",
"gh:thanos-io/thanos#656"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:22.613Z",
"processedIds": [],
"cursor": "Y3Vyc29yOnYyOpK0MjAyMi0wOC0wMVQyMDoyMToxN1rOAECSiQ=="
}
},
"volcano-sh/volcano": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:30.647Z",
"processedIds": [
"gh:volcano-sh/volcano#2203",
"gh:volcano-sh/volcano#4581",
"gh:volcano-sh/volcano#683",
"gh:volcano-sh/volcano#4767",
"gh:volcano-sh/volcano#4273",
"gh:volcano-sh/volcano#4782",
"gh:volcano-sh/volcano#687"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:31.039Z",
"processedIds": [],
"cursor": null
}
},
"wasmCloud/wasmCloud": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:32.108Z",
"processedIds": [],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:33.860Z",
"processedIds": [],
"cursor": null
}
},
"aeraki-mesh/aeraki": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:34.763Z",
"processedIds": [],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:35.478Z",
"processedIds": [],
"cursor": null
}
},
"project-akri/akri": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:37.552Z",
"processedIds": [
"gh:project-akri/akri#346"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:38.401Z",
"processedIds": [],
"cursor": null
}
},
"antrea-io/antrea": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:44.867Z",
"processedIds": [
"gh:antrea-io/antrea#2121",
"gh:antrea-io/antrea#1196",
"gh:antrea-io/antrea#5483"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:45.587Z",
"processedIds": [],
"cursor": null
}
},
"armadaproject/armada": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:47.507Z",
"processedIds": [
"gh:armadaproject/armada#2111"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:48.217Z",
"processedIds": [],
"cursor": null
}
},
"AthenZ/athenz": {
"github-issues": {
"lastSearched": "2026-03-02T19:38:49.392Z",
"processedIds": [],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:38:50.883Z",
"processedIds": [],
"cursor": null
}
},
"runatlantis/atlantis": {
"github-issues": {
"lastSearched": "2026-03-02T19:39:15.224Z",
"processedIds": [
"gh:runatlantis/atlantis#3607",
"gh:runatlantis/atlantis#1392",
"gh:runatlantis/atlantis#4114",
"gh:runatlantis/atlantis#4193",
"gh:runatlantis/atlantis#4499",
"gh:runatlantis/atlantis#3269",
"gh:runatlantis/atlantis#2261",
"gh:runatlantis/atlantis#1352",
"gh:runatlantis/atlantis#4001",
"gh:runatlantis/atlantis#4978",
"gh:runatlantis/atlantis#5940",
"gh:runatlantis/atlantis#2002",
"gh:runatlantis/atlantis#4229",
"gh:runatlantis/atlantis#3086",
"gh:runatlantis/atlantis#2507",
"gh:runatlantis/atlantis#2055",
"gh:runatlantis/atlantis#4275",
"gh:runatlantis/atlantis#3287"
],
"cursor": null
},
"github-discussions": {
"lastSearched": "2026-03-02T19:39:16.796Z",
"processedIds": [],
"cursor": "Y3Vyc29yOnYyOpK0MjAyMi0xMC0xMFQxNTo0MDoyMFrOAEQKfQ=="
}
}
}
"lastUpdated": "2026-03-09T06:53:25.696Z",
"projects": {}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
{
"version": "kc-mission-v1",
"name": "caddy-6862-caddytls-encrypted-clienthello-ech",
"missionClass": "solution",
"author": "KubeStellar Bot",
"authorGithub": "kubestellar",
"mission": {
"title": "caddy: caddytls: Encrypted ClientHello (ECH)",
"description": "This is the initial implementation for Encrypted ClientHello (ECH).\n\nI have verified during testing with Firefox + Wireshark that only the outer name(s) appear on the wire in plaintext; the actual server names do not. (Firefox requires DoH enabled.)\n\nCurrent features:\n\n- Adds a DNS provider configurable for the entire TLS app that acts as a default when a DNS module is needed, since most people use a single DNS provider; this can reduce redundancy in configs.\n- Generates an ECH config given only",
"type": "troubleshoot",
"status": "completed",
"steps": [
{
"title": "Understand the problem",
"description": "This is the initial implementation for Encrypted ClientHello (ECH).\n\nI have verified during testing with Firefox + Wireshark that only the outer name(s) appear on the wire in plaintext; the actual ser"
},
{
"title": "Adding support for the upstream `libdns` [`Priority`, `Weight`, and `Target` ...",
"description": "Adding support for the upstream `libdns` [`Priority`, `Weight`, and `Target` struct fields](https://pkg.go.dev/github.com/libdns/libdns#Record)."
},
{
"title": "Changing the semantics of `SetRecords` and `AppendRecords` to align with thos...",
"description": "Changing the semantics of `SetRecords` and `AppendRecords` to align with those discussed in libdns/libdns#145."
},
{
"title": "Apply the configuration",
"description": "Apply the following configuration to your cluster:\n```yaml\n(Be sure to replace with your actual values.)\r\n\r\nThis minimal, opinionated tells Caddy to serve your site, `example.com`, as usual (with automatic HTTPS, a certificate, the whole bit), but to also manage a certain for `ech.example.net`. This config is opinionated because it is so minimal, in that it enables ECH for all sites, protecting them behind the domain listed in the `ech` global option. (Each outer name correlates to an ECH config.) It also publishes all ECH configs (one in this case) to \n```"
},
{
"title": "Review the fix",
"description": "The fix was implemented in https://github.com/libdns/rfc2136/pull/8. Review the changes to understand the solution."
},
{
"title": "Verify the fix",
"description": "Confirm that the issue is resolved in your environment by testing the affected functionality."
}
],
"resolution": {
"summary": "Caddy [recently added ECH support](https://github.com/caddyserver/caddy/releases/tag/v2.10.0-beta.1), but [the `rfc2136` provider doesn't work properly with it](https://github.com/caddyserver/caddy/pull/6862#issuecomment-2692164710). This PR modifies the `rfc2136` module so that setting the ECH records works properly. I've tested these patches on my own server, and everything seems to work as expected now.\n\nThe two main changes that I had to make were:\n\n1. Adding support for the upstream `libdns` [`Priority`, `Weight`, and `Target` struct fields](https://pkg.go.dev/github.com/libdns/libdns#Record).\n\n2. Changing the semantics of `SetRecords` and `AppendRecords` to align with those discussed in libdns/libdns#145.\n\nI don't have much Go experience, so please let me know if you want me to make any changes. Thanks!",
"codeSnippets": [
"(Be sure to replace with your actual values.)\r\n\r\nThis minimal, opinionated tells Caddy to serve your site, `example.com`, as usual (with automatic HTTPS, a certificate, the whole bit), but to also manage a certain for `ech.example.net`. This config is opinionated because it is so minimal, in that it enables ECH for all sites, protecting them behind the domain listed in the `ech` global option. (Each outer name correlates to an ECH config.) It also publishes all ECH configs (one in this case) to",
"(Be sure to replace with your actual values.)\r\n\r\nThis minimal, opinionated tells Caddy to serve your site, `example.com`, as usual (with automatic HTTPS, a certificate, the whole bit), but to also manage a certain for `ech.example.net`. This config is opinionated because it is so minimal, in that it enables ECH for all sites, protecting them behind the domain listed in the `ech` global option. (Each outer name correlates to an ECH config.) It also publishes all ECH configs (one in this case) to all publishers (one DNS publisher, in this case).\r\n\r\n(The new `dns` global option specifies a DNS provider to use if none other is specified but one is needed. It does _not_ enable the ACME DNS challenge in the way the `acme_dns` global option does.)\r\n\r\nSimilarly, here's a sample JSON config with debug logs enabled; be sure to fill out your actual domain names (both inner and outer) and set your DNS provider accordingly. I have a Cloudflare one here since I used it for testing.",
"This tells Caddy to serve a site (`example.com`) over HTTPS with auto-managing certificates, as usual, and the TLS app has ECH enabled, so it will use the global DNS module (`cloudflare`) to publish the config for the outer name (`ech.example.net`).\r\n\r\nTo test this, open Firefox and ensure DNS-over-HTTPS is enabled. Then go to **about:networking#dns** and \"Clear DNS cache\" to ensure your test has a clean slate.\r\n\r\nWhen you run this config, wait about 1-2 seconds or for a cert to be provisioned, then, assuming an empty DNS cache, when you load your site (`example.com`) in Firefox, it will find the HTTPS-type DNS record and use that to employ ECH for the connection. Verify with Wireshark.\r\n\r\nYou can compile with this patch and a DNS plugin like so:",
"(The commented-out SVCB RRs would behave the same as the HTTPS RRs if they were valid.)\r\n\r\nAnyways, I'd suggest Caddyfile syntax something like the following",
"that behaves something like"
]
}
},
"metadata": {
"tags": [
"caddy",
"community",
"web-server",
"troubleshoot",
"feature--gear-"
],
"cncfProjects": [
"caddy"
],
"targetResourceKinds": [],
"difficulty": "beginner",
"issueTypes": [
"troubleshoot"
],
"maturity": "community",
"sourceUrls": {
"issue": "https://github.com/caddyserver/caddy/pull/6862",
"repo": "https://github.com/caddyserver/caddy",
"pr": "https://github.com/libdns/rfc2136/pull/8"
},
"reactions": 17,
"comments": 12,
"synthesizedBy": "regex",
"qualityScore": 65
},
"prerequisites": {
"kubernetes": ">=1.24",
"tools": [
"kubectl"
],
"description": "A running Kubernetes cluster with caddy installed or the issue environment reproducible."
},
"security": {
"scannedAt": "2026-03-09T06:51:06.597Z",
"scannerVersion": "cncf-gen-2.0.0",
"sanitized": true,
"findings": []
}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
{
"version": "kc-mission-v1",
"name": "clickhouse-38667-inverted-indices-implementation",
"missionClass": "solution",
"author": "KubeStellar Bot",
"authorGithub": "kubestellar",
"mission": {
"title": "clickhouse: Inverted Indices Implementation",
"description": "Resoves #19970\n\nA (generalized) inverted index for ClickHouse developed by @HarryLeeIBM and @larryluogit\n\nThis inverted index is implemented as a new type of skipping index. The implementation is well-aligned with ClickHouse's secondary/skipping index architecture, including index creation/alter/drop syntax, block stream piping, expression (RPN) evaluation, etc.\n\nTo define a GIN index:\n```sql\nCREATE TABLE my_table1 (k UInt64,s String,INDEX my_gin_index(s) TYPE inverted(0) GRANULARITY 1) Engine=",
"type": "troubleshoot",
"status": "completed",
"steps": [
{
"title": "Understand the problem",
"description": "Resoves #19970\n\nA (generalized) inverted index for ClickHouse developed by @HarryLeeIBM and @larryluogit\n\nThis inverted index is implemented as a new type of skipping index. The implementation is well"
},
{
"title": "Apply the configuration",
"description": "Apply the following configuration to your cluster:\n```yaml\n`gin()` (or `gin(0)`) set the tokenizer to \"tokens\", whereas `gin(n)` with `n` between `2` and `8` sets \"ngrams(n)” as tokenizer.\r\n\r\nMain implementation techniques include, Roaring Bitmap(for postings lists) and FST(for term dictionaries), see the following references:\r\n1. Single-pass index construction with segmentation, see Heinz, Steffen, and Justin Zobel. 2003. [Efficient single-pass index construction for text databases](https://doi.org/10.1002/asi.10268). JASIST 54(8):713–729.\r\n2. Roaring \n```"
},
{
"title": "Verify the fix",
"description": "Confirm that the issue is resolved in your environment by testing the affected functionality."
}
],
"resolution": {
"summary": "Failures in stress test after restart look unrelated.\n\nRestarted functional tests did unfortunately not run due to a recent change in the CI infrastructure (`clickhouse-test: error: unrecognized arguments: --report-logs-stats`, e.g. [here](https://s3.amazonaws.com/clickhouse-test-reports/38667/e7add8218fe121cd4df73301a2b526bb7f9a5e6b/stateless_tests__release_/test_result.txt)). This error can only be resolved by merging the latest master into this PR. The \"merge\" button is greyed out for me because these tests did not finish.\n\n@larryluogit @HarryLeeIBM Would you like to merge master again? (as far as I remember, functional tests were green in previous runs, so I don't expect new problems to pop up). Thanks!",
"codeSnippets": [
"`gin()` (or `gin(0)`) set the tokenizer to \"tokens\", whereas `gin(n)` with `n` between `2` and `8` sets \"ngrams(n)” as tokenizer.\r\n\r\nMain implementation techniques include, Roaring Bitmap(for postings lists) and FST(for term dictionaries), see the following references:\r\n1. Single-pass index construction with segmentation, see Heinz, Steffen, and Justin Zobel. 2003. [Efficient single-pass index construction for text databases](https://doi.org/10.1002/asi.10268). JASIST 54(8):713–729.\r\n2. Roaring",
"`gin()` (or `gin(0)`) set the tokenizer to \"tokens\", whereas `gin(n)` with `n` between `2` and `8` sets \"ngrams(n)” as tokenizer.\r\n\r\nMain implementation techniques include, Roaring Bitmap(for postings lists) and FST(for term dictionaries), see the following references:\r\n1. Single-pass index construction with segmentation, see Heinz, Steffen, and Justin Zobel. 2003. [Efficient single-pass index construction for text databases](https://doi.org/10.1002/asi.10268). JASIST 54(8):713–729.\r\n2. Roaring Bitmaps, see https://github.com/RoaringBitmap/RoaringBitmap\r\n3. Finite State Transducer (FST) Minimization, see Mihov, S., Maurel, D. (2001). [Direct Construction of Minimal Acyclic Subsequential Transducers](https://doi.org/10.1007/3-540-44674-5_18). In: Yu, S., Păun, A. (eds) Implementation and Application of Automata. CIAA 2000. Lecture Notes in Computer Science, vol 2088. Springer, Berlin, Heidelberg. \r\n\r\nA merge tree setting exists to control the maximum size of data digestion during indexing: `max_digestion_size_per_segment` (default is 256M).\r\n\r\nThe following steps demonstrate the inverted index feature using hackernews dataset.\r\n1. Create and load hackernews table",
"2. Create hackernews_gin3 table, which has the same column definitions as hackernews but with an inverted index.",
"3. Populate hackernews_gin3 table by copying the same data from hackernews table",
"4. Run query against hackernews and hackernews_gin3 for comparison"
]
}
},
"metadata": {
"tags": [
"clickhouse",
"community",
"analytics-db",
"troubleshoot",
"pr-feature",
"can-be-tested"
],
"cncfProjects": [
"clickhouse"
],
"targetResourceKinds": [
"Job"
],
"difficulty": "advanced",
"issueTypes": [
"troubleshoot"
],
"maturity": "community",
"sourceUrls": {
"issue": "https://github.com/ClickHouse/ClickHouse/pull/38667",
"repo": "https://github.com/ClickHouse/ClickHouse"
},
"reactions": 45,
"comments": 55,
"synthesizedBy": "regex",
"qualityScore": 65
},
"prerequisites": {
"kubernetes": ">=1.24",
"tools": [
"kubectl"
],
"description": "A running Kubernetes cluster with clickhouse installed or the issue environment reproducible."
},
"security": {
"scannedAt": "2026-03-09T06:45:58.429Z",
"scannerVersion": "cncf-gen-2.0.0",
"sanitized": true,
"findings": []
}
}
Loading