@skyhook-io/radar-app 1.10.0 → 1.11.0

package/src/components/resources/renderers/CNPGImageCatalogRenderer.tsx

@@ -0,0 +1,123 @@
+import { Boxes } from 'lucide-react'
+import { CNPGImageCatalogRenderer as BaseImageCatalog } from '@skyhook-io/k8s-ui/components/resources/renderers/CNPGDeclarativeRenderer'
+import { Section, RelationshipGroup } from '@skyhook-io/k8s-ui'
+import { LookupFailureNote } from '@skyhook-io/k8s-ui/components/resources/renderers/LookupFailureNote'
+import { getCNPGImageCatalogEntries } from '../resource-utils-cnpg'
+import type { ResourceRef } from '@skyhook-io/k8s-ui'
+import { useCNPGCatalogUsers } from '../../../api/policy'
+
+const CNPG_GROUP = 'postgresql.cnpg.io'
+
+/**
+ * Host wrapper adding the reverse lookup: which clusters are pinned to this
+ * catalog.
+ *
+ * This is the diagnosis path. A cluster that references a catalog lacking its
+ * major version reports "incomplete or invalid image catalog" and stops; the
+ * catalog is where you check what it offers, and from here you need to see who
+ * depends on it before changing anything.
+ */
+export function CNPGImageCatalogRenderer({
+  data,
+  onNavigate,
+}: {
+  data: any
+  onNavigate?: (ref: ResourceRef) => void
+}) {
+  const kind = data?.kind
+  const name = data?.metadata?.name ?? ''
+  const namespace = data?.metadata?.namespace ?? ''
+  // A ClusterImageCatalog is cluster-scoped and referenceable from any namespace,
+  // so the answer's scope is not this resource's. Read server-side rather than
+  // filtering a client-side list: omitting the namespace there means "the
+  // caller's namespace view filter", which would answer a question about the
+  // whole cluster from whichever namespaces they happen to be showing.
+  const scoped = kind === 'ImageCatalog'
+  const clusters = useCNPGCatalogUsers(name, scoped ? namespace : '', !!name)
+
+  const users = clusters.data?.clusters ?? []
+
+  // A cluster asking for a major this catalog does not carry is the failure the
+  // catalog page exists to explain, and it is invisible from the cluster side —
+  // there the reference looks fine.
+  const majors = new Set(getCNPGImageCatalogEntries(data).map((e) => e.major))
+  const unmet = users.filter((c) => !majors.has(c.major as number))
+  const met = users.filter((c) => majors.has(c.major as number))
+
+  const toRef = (c: { namespace: string; name: string }) => ({
+    kind: 'Cluster',
+    namespace: c.namespace,
+    name: c.name,
+    group: CNPG_GROUP,
+  })
+
+  return (
+    <BaseImageCatalog
+      data={data}
+      usedBy={
+        <Section title="Used By" icon={Boxes} defaultExpanded>
+          {clusters.isLoading ? (
+            <div className="text-sm text-theme-text-tertiary">Looking for clusters…</div>
+          ) : users.length === 0 ? (
+            clusters.error ? (
+              <LookupFailureNote
+                errors={[clusters.error]}
+                what="which clusters use this catalog"
+              />
+            ) : (
+              <div className="text-sm text-theme-text-tertiary">
+                {/* "Changing it affects nothing" is a claim about the cluster,
+                    and this search does not cover one. A ClusterImageCatalog is
+                    referenced from any namespace, but the lookup that answers
+                    this falls back to the reader's namespace view filter, so a
+                    filtered reader is told an edit is safe on the strength of
+                    the namespaces they happen to be looking at. The namespaced
+                    ImageCatalog has no such gap — its users can only be in its
+                    own namespace, which is exactly what was searched. */}
+                {scoped
+                  ? 'No cluster in this namespace is pinned to this catalog. Changing it affects nothing here today.'
+                  : 'No cluster in view is pinned to this catalog. Clusters in namespaces you are not currently showing are not covered by this check.'}
+              </div>
+            )
+          ) : (
+            <div className="space-y-3">
+              {met.length > 0 && (
+                <RelationshipGroup label="Clusters" refs={met.map(toRef)} onNavigate={onNavigate} />
+              )}
+              {unmet.length > 0 && (
+                <div className="space-y-1.5">
+                  <RelationshipGroup
+                    label="Pinned to a version this catalog does not list"
+                    refs={unmet.map(toRef)}
+                    onNavigate={onNavigate}
+                  />
+                  {unmet.some((c) => !!c.image) && (
+                    <div className="text-xs text-theme-text-secondary">
+                      {`Running now: ${unmet
+                        .filter((c) => !!c.image)
+                        .map((c) => `${c.name} on ${c.image}`)
+                        .join(', ')}`}
+                    </div>
+                  )}
+                  <div className="text-xs text-warning-text">
+                    {/* What the catalog can prove, and no further. A cluster
+                        that already resolved an image keeps running on it, so
+                        "will not start" sends a responder hunting for
+                        crash-looping pods that are not there — the failure is
+                        the NEXT time an image has to be resolved. The named
+                        form only when there is a major to name: a reference
+                        missing one lands here too, and "asks for PostgreSQL
+                        undefined" would be worse than the general sentence. */}
+                    {unmet.length === 1 && typeof unmet[0]?.major === 'number'
+                      ? `${unmet[0]?.name} asks for PostgreSQL ${unmet[0].major}, which this catalog does not list. Whatever image it is running now, the next time it has to resolve one it will fail.`
+                      : 'These clusters ask for a major version this catalog does not list. Whatever image they are running now, the next time they have to resolve one they will fail.'}
+                  </div>
+                </div>
+              )}
+            </div>
+          )}
+        </Section>
+      }
+    />
+  )
+}

package/src/components/resources/renderers/CNPGObjectStoreRenderer.tsx

@@ -0,0 +1,152 @@
+import { Database } from 'lucide-react'
+import { CNPGObjectStoreRenderer as BaseCNPGObjectStoreRenderer } from '@skyhook-io/k8s-ui/components/resources/renderers/CNPGObjectStoreRenderer'
+import { Section, RelationshipGroup, CNPG_BARMAN_PLUGIN_NAME } from '@skyhook-io/k8s-ui'
+import { LookupFailureNote } from '@skyhook-io/k8s-ui/components/resources/renderers/LookupFailureNote'
+import type { ResourceRef } from '@skyhook-io/k8s-ui'
+import { useResources } from '../../../api/client'
+
+/**
+ * Host wrapper adding the reverse lookup the package renderer cannot do: which
+ * CNPG Clusters back up into this store.
+ *
+ * The Cluster page already links forward to its ObjectStore. Without this the
+ * relationship is one-way, so an operator reading a recovery window keyed by
+ * server name has no route to the cluster behind it.
+ */
+export function CNPGObjectStoreRenderer({
+  data,
+  onNavigate,
+}: {
+  data: any
+  onNavigate?: (ref: ResourceRef) => void
+}) {
+  const namespace = data?.metadata?.namespace ?? ''
+  const storeName = data?.metadata?.name ?? ''
+
+  // Clusters reference their store by name within their own namespace, so the
+  // search is namespace-scoped rather than cluster-wide.
+  const clusters = useResources<any>('clusters', namespace, 'postgresql.cnpg.io', {
+    enabled: !!storeName && !!namespace,
+  })
+
+  // Servers the store holds data for, from its own status. Deliberately a
+  // separate question from the one below.
+  const servers: string[] = Object.keys(data?.status?.serverRecoveryWindow ?? {})
+
+  const users = (clusters.data ?? []).filter((c: any) => {
+    const plugins = c?.spec?.plugins
+    if (!Array.isArray(plugins)) return false
+    return plugins.some(
+      (p: any) =>
+        p?.name === CNPG_BARMAN_PLUGIN_NAME &&
+        p?.enabled !== false &&
+        p?.parameters?.barmanObjectName === storeName,
+    )
+  })
+
+  // A recovery window is keyed by the archive's server name, which defaults to
+  // the cluster's name and is overridden by the plugin's own `serverName`
+  // parameter — the ObjectStore rejects the field outright ("use the
+  // 'serverName' plugin parameter in the Cluster resource"), so the Cluster is
+  // the only place it can come from. Matching keys against cluster names alone
+  // reports a cluster that renamed its archive as a stranger.
+  const clusterForServer = new Map<string, string>()
+  for (const c of users) {
+    const plugin = (c?.spec?.plugins ?? []).find(
+      (p: any) => p?.name === CNPG_BARMAN_PLUGIN_NAME && p?.parameters?.barmanObjectName === storeName,
+    )
+    const server = plugin?.parameters?.serverName || c?.metadata?.name
+    if (server && c?.metadata?.name) clusterForServer.set(server, c.metadata.name)
+  }
+
+  // A recovery window is only advancing while WAL archiving works. The Cluster
+  // owns that condition, and the ObjectStore's own status cannot see it — so a
+  // server whose archiving has stopped reports its last successful backup and
+  // reads as green here while the recovery point is frozen. The page whose job is
+  // "how far back can I restore" is the last place that should have to be
+  // cross-checked against another screen.
+  const archivingFailing = new Set<string>()
+  for (const c of users) {
+    const stalled = (c?.status?.conditions ?? []).some(
+      (cond: any) => cond?.type === 'ContinuousArchiving' && cond?.status === 'False',
+    )
+    if (!stalled) continue
+    const plugin = (c?.spec?.plugins ?? []).find(
+      (p: any) => p?.name === CNPG_BARMAN_PLUGIN_NAME && p?.parameters?.barmanObjectName === storeName,
+    )
+    const server = plugin?.parameters?.serverName || c?.metadata?.name
+    if (server) archivingFailing.add(server)
+  }
+
+  // Named in the window, traceable to none of the clusters above — the gap the
+  // note explains.
+  const unlisted = servers.filter((s) => !clusterForServer.has(s))
+
+  return (
+    <>
+      <BaseCNPGObjectStoreRenderer
+        data={data}
+        onNavigate={onNavigate}
+        // Server key -> the Cluster that archives under it. Built from the
+        // plugin parameters rather than by name, so a cluster that renamed its
+        // archive still resolves. Undefined while the lookup is unresolved.
+        clusterForServer={clusters.isLoading || clusters.error ? undefined : clusterForServer}
+        archivingFailing={clusters.isLoading || clusters.error ? undefined : archivingFailing}
+      />
+      <Section title="Used By" icon={Database} defaultExpanded>
+        {clusters.isLoading ? (
+          <div className="text-sm text-theme-text-tertiary">Looking for clusters…</div>
+        ) : users.length === 0 ? (
+          // Not the same as "nothing uses it" — the caller may not be able to
+          // list Clusters here, and a store with no users is worth noticing.
+          clusters.error ? (
+            <LookupFailureNote
+              errors={[clusters.error]}
+              what="which clusters use this store"
+            />
+          ) : (
+            <div className="text-sm text-theme-text-tertiary">
+              No cluster in this namespace backs up to this store.
+            </div>
+          )
+        ) : (
+          // The house pattern for "these other resources relate to this one":
+          // labelled group with a count, ref badges, truncate-then-expand.
+          <RelationshipGroup
+            label="Archiving here through the plugin"
+            refs={users.map((c: any) => ({
+              kind: 'Cluster',
+              namespace: c.metadata?.namespace ?? '',
+              name: c.metadata?.name ?? '',
+              group: 'postgresql.cnpg.io',
+            }))}
+            onNavigate={onNavigate}
+          />
+        )}
+        {/* This lookup can only see `spec.plugins`. A cluster still on the
+            deprecated in-tree `spec.backup.barmanObjectStore` names a
+            destination path and never references this CR, so it CANNOT appear
+            above however much data it has here. Read as blast radius — "who
+            breaks if I rotate these credentials" — the list would silently omit
+            every legacy-path cluster, which mid-migration is most of a fleet.
+            The recovery window is the other half of the answer. */}
+        {/* Only once the plugin lookup has actually answered. Derived while the
+            list is still loading — or after it failed — every server in the
+            window looks like an in-tree cluster, which is a claim about their
+            configuration made from having no data. */}
+        {!clusters.isLoading && !clusters.error && unlisted.length > 0 && (
+          <div className="mt-2 pt-2 border-t border-theme-border text-xs text-theme-text-secondary">
+            {/* Two causes reach this note and the screen cannot tell them
+                apart, so it names both rather than asserting the one that is
+                usually true: a cluster on the older in-tree settings never
+                references this record, and a cluster that renamed its archive
+                leaves the data it already wrote under the previous name. */}
+            {`${unlisted.join(', ')} ${unlisted.length === 1 ? 'has' : 'have'} data here but ${
+              unlisted.length === 1 ? 'is' : 'are'
+            } not listed above. This finds clusters through the barman-cloud plugin, so an archive written by a cluster on the older in-tree backup settings — or under a server name it has since changed — is not traced back to one.`}
+          </div>
+        )}
+      </Section>
+    </>
+  )
+}

package/src/components/resources/renderers/KyvernoPolicyCoverage.tsx

@@ -0,0 +1,65 @@
+import { useState } from 'react'
+import { useLocation } from 'react-router-dom'
+import { PolicyCoverageSection } from '@skyhook-io/k8s-ui/components/resources/renderers/PolicyCoverageSection'
+import type { PolicyCoverageSubject, ResourceRef } from '@skyhook-io/k8s-ui'
+import { usePolicyCoverage } from '../../../api/policy'
+
+/** Mirrors maxPolicyCoverageSubjectsHard in internal/server/policy_handlers.go —
+ *  asking for more than the server will send just returns the same list. */
+const COVERAGE_MAX_SUBJECTS = 5000
+
+/**
+ * Host wrapper for the policy coverage section — the inverse lookup that answers
+ * "which resources does this policy pass and fail".
+ *
+ * The package renderers take it as a slot rather than fetching it themselves, so
+ * a library consumer that does not wire this endpoint keeps the original policy
+ * drawer and nothing breaks.
+ */
+export function KyvernoPolicyCoverage({
+  data,
+  onNavigate,
+}: {
+  data: any
+  onNavigate?: (ref: ResourceRef) => void
+}) {
+  const name = data?.metadata?.name ?? ''
+  // A namespaced Kyverno Policy reports as "namespace/name"; the server tries
+  // both shapes, so the namespace is passed through whenever the policy has one.
+  const namespace = data?.metadata?.namespace ?? ''
+  // The server bounds each rule's subject list so an ordinary drawer open stays
+  // small. Asking for the rest raises that bound once, up to the server's own
+  // ceiling — past which the response says what it could not send.
+  const [limit, setLimit] = useState<number | undefined>(undefined)
+
+  // The header's namespace filter is applied SERVER-side from session state, so
+  // the same URL returns a different body once it changes and nothing in the
+  // request distinguishes the two. Without it in the cache key, a policy opened
+  // under "All namespaces" keeps serving that body after the filter narrows —
+  // the view then shows other people's namespaces under your scope, and which
+  // behaviour you get depends on where you navigated from.
+  const viewFilter = useLocation().search
+  const query = usePolicyCoverage(name, namespace || undefined, !!name, limit, viewFilter)
+
+  return (
+    <PolicyCoverageSection
+      resource={data}
+      data={query.data ?? null}
+      loading={query.isLoading}
+      error={query.error as Error | null}
+      onLoadMore={limit ? undefined : () => setLimit(COVERAGE_MAX_SUBJECTS)}
+      loadingMore={query.isFetching}
+      onSelectSubject={
+        onNavigate
+          ? (subject: PolicyCoverageSubject) =>
+              onNavigate({
+                kind: subject.kind,
+                namespace: subject.namespace ?? '',
+                name: subject.name,
+                group: subject.group,
+              })
+          : undefined
+      }
+    />
+  )
+}

package/src/components/resources/renderers/KyvernoPolicyQueued.render.test.tsx

@@ -0,0 +1,59 @@
+import { describe, expect, it, vi } from 'vitest'
+import { renderToString } from 'react-dom/server'
+
+// The denial is the state under test, so the fetch is stubbed rather than run.
+const forbidden = Object.assign(new Error('forbidden'), { status: 403 })
+let queuedResult: { data?: unknown; error?: unknown } = {}
+
+vi.mock('../../../api/policy', () => ({
+  usePolicyQueued: () => queuedResult,
+}))
+vi.mock('../../../api/client', () => ({
+  isForbiddenError: (e: any) => e?.status === 403,
+}))
+
+const { KyvernoPolicyQueued } = await import('./KyvernoPolicyQueued')
+
+const generating = {
+  kind: 'ClusterPolicy',
+  metadata: { name: 'gen-companion' },
+  spec: { rules: [{ name: 'g', generate: {} }] },
+}
+const validating = {
+  kind: 'ClusterPolicy',
+  metadata: { name: 'require-labels' },
+  spec: { rules: [{ name: 'v', validate: {} }] },
+}
+
+/**
+ * A denial here is cluster-static, so disclosing it everywhere would be noise on
+ * the majority of policies that only validate. Staying silent about it on a
+ * policy that DOES queue is worse: a stuck backlog then looks exactly like a
+ * healthy policy with nothing pending, on the page someone checks to find out.
+ */
+describe('KyvernoPolicyQueued — a denial you cannot see', () => {
+  it('says it cannot check when the policy actually queues work', () => {
+    queuedResult = { error: forbidden }
+    const html = renderToString(<KyvernoPolicyQueued data={generating} />)
+    expect(html).toContain('permission')
+    expect(html).toContain('Queued Work')
+  })
+
+  it('stays silent for a policy that never queues anything', () => {
+    queuedResult = { error: forbidden }
+    expect(renderToString(<KyvernoPolicyQueued data={validating} />)).toBe('')
+  })
+
+  it('stays silent when there is genuinely nothing queued', () => {
+    queuedResult = { data: { requests: 0 } }
+    expect(renderToString(<KyvernoPolicyQueued data={generating} />)).toBe('')
+  })
+
+  // A fault is not a denial: it is neither permanent nor beyond acting on, so it
+  // is loud regardless of what the policy does.
+  it('reports a genuine fault on any policy', () => {
+    queuedResult = { error: new Error('could not read queued work') }
+    const html = renderToString(<KyvernoPolicyQueued data={validating} />)
+    expect(html).toContain('could not read queued work')
+  })
+})

package/src/components/resources/renderers/KyvernoPolicyQueued.test.ts

@@ -0,0 +1,99 @@
+import { describe, it, expect } from 'vitest'
+import { policyQueuesWork, queueBanner, requestBelongsTo } from './KyvernoPolicyQueued'
+
+/**
+ * Kyverno permits a namespaced Policy and a ClusterPolicy to share a name, and
+ * records the first qualified and the second bare. Accepting the bare form as a
+ * fallback for a namespaced policy shows it someone else's backlog — the same
+ * collision the coverage lookup refuses, reintroduced here once already.
+ */
+describe('requestBelongsTo', () => {
+  const req = (policy: string) => ({ spec: { policy } })
+
+  it('matches a cluster-scoped policy on the bare name only', () => {
+    expect(requestBelongsTo(req('require-labels'), 'require-labels', '')).toBe(true)
+    expect(requestBelongsTo(req('team-a/require-labels'), 'require-labels', '')).toBe(false)
+  })
+
+  it('matches a namespaced policy on the qualified name only', () => {
+    expect(requestBelongsTo(req('team-a/require-labels'), 'require-labels', 'team-a')).toBe(true)
+    // The bug: this is a ClusterPolicy's request and must not appear here.
+    expect(requestBelongsTo(req('require-labels'), 'require-labels', 'team-a')).toBe(false)
+  })
+
+  it('does not match another namespace', () => {
+    expect(requestBelongsTo(req('team-b/require-labels'), 'require-labels', 'team-a')).toBe(false)
+  })
+
+  it('matches nothing when either side is missing', () => {
+    expect(requestBelongsTo({}, 'require-labels', '')).toBe(false)
+    expect(requestBelongsTo(req('require-labels'), '', '')).toBe(false)
+  })
+})
+
+/**
+ * The banner is the only thing on this page that makes a claim rather than a
+ * count, so the claim has to be the one the numbers support.
+ */
+describe('queueBanner', () => {
+  it('says work stopped only when something has actually sat still', () => {
+    const b = queueBanner(3, 12, '12m')
+    expect(b?.title).toBe('Queued work has not moved for 12m')
+    expect(b?.message).toContain('cannot keep up')
+  })
+
+  // The bug: this branch fires when NOTHING is older than the stall threshold,
+  // which is the case most likely to be a burst draining normally. The body has
+  // to agree with the headline — diagnosing a stalled controller underneath a
+  // headline that only reports a size puts the claim straight back.
+  it('does not tell you a moving backlog is not being processed', () => {
+    const b = queueBanner(30, 1, '1m')
+    expect(b?.title).toBe('30 requests are queued')
+    expect(b?.title).not.toContain('not being processed')
+    expect(b?.message).toContain('may be a burst still draining')
+    expect(b?.message).not.toContain('cannot keep up')
+    expect(b?.message).not.toContain('grows rather than drains')
+  })
+
+  it('stays quiet for a queue doing what a queue does', () => {
+    expect(queueBanner(3, 1, '1m')).toBeNull()
+    expect(queueBanner(0, 0, '')).toBeNull()
+  })
+
+  it('prefers the measured stall over the size when both apply', () => {
+    expect(queueBanner(40, 30, '30m')?.title).toContain('has not moved')
+  })
+})
+
+/**
+ * A denial is only worth disclosing where it can cost something. Silence on a
+ * policy that queues nothing keeps the page clean; silence on one that DOES
+ * queue hides a backlog behind a page that looks healthy.
+ */
+describe('policyQueuesWork', () => {
+  it('is true for a policy that generates resources', () => {
+    expect(policyQueuesWork({ spec: { rules: [{ name: 'g', generate: {} }] } })).toBe(true)
+    expect(policyQueuesWork({ kind: 'GeneratingPolicy', spec: {} })).toBe(true)
+  })
+
+  it('is true for a policy that mutates resources which already exist', () => {
+    expect(policyQueuesWork({ spec: { rules: [{ mutate: { targets: [{ kind: 'Pod' }] } }] } })).toBe(true)
+    expect(policyQueuesWork({ spec: { evaluation: { mutateExisting: { enabled: true } } } })).toBe(true)
+  })
+
+  // The common case, and the reason a blanket note would be noise.
+  it('is false for a validate-only policy', () => {
+    expect(policyQueuesWork({ spec: { rules: [{ name: 'v', validate: {} }] } })).toBe(false)
+    expect(policyQueuesWork({ kind: 'ValidatingPolicy', spec: {} })).toBe(false)
+  })
+
+  // A mutate rule with no targets runs at admission only — nothing is queued.
+  it('is false for admission-time mutation', () => {
+    expect(policyQueuesWork({ spec: { rules: [{ mutate: { patchStrategicMerge: {} } }] } })).toBe(false)
+  })
+
+  it('handles a policy with no spec at all', () => {
+    expect(policyQueuesWork({})).toBe(false)
+    expect(policyQueuesWork(undefined)).toBe(false)
+  })
+})