✨ Add schema CRD and platform CRs.#450
Conversation
Signed-off-by: Jeff Ortel <jortel@redhat.com>
WalkthroughThis update introduces a new "platform" addon component to the deployment process, including its image configuration, resource defaults, and Kubernetes manifests. It also adds a new "Schema" CRD and two initial schema custom resources. The release workflow, Helm values, RBAC, and operator metadata are updated accordingly, and the Operator SDK version is bumped to v1.35.0. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant AnsibleRole
participant KubernetesAPI
participant Operator
User->>AnsibleRole: Deploy stack
AnsibleRole->>KubernetesAPI: Create Platform Addon CR
AnsibleRole->>KubernetesAPI: Create Schema CRs
KubernetesAPI->>Operator: Notify of new CRs (Addon, Schema)
Operator->>KubernetesAPI: Manage Addon/Task and Schema resources
Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (4)
helm/templates/crds/tackle.konveyor.io_schemas.yaml (1)
17-84: Consider adding discoverability & usability metadata to the CRDThe structural schema is solid; however, without
shortNames,categories, or meaningfuladditionalPrinterColumns, users will find the newSchemaobjects hard to discover and inspect (kubectl get).Example enhancement:
names: kind: Schema listKind: SchemaList plural: schemas singular: schema + shortNames: + - sch + categories: + - konveyor + - tackle ... + additionalPrinterColumns: + - name: Domain + type: string + jsonPath: .spec.domain + - name: Subject + type: string + jsonPath: .spec.subject + - name: Variant + type: string + jsonPath: .spec.variantThese purely additive fields improve UX and do not affect the controller logic.
helm/values.yaml (1)
22-22: Pin a specific tag instead oflatestfor reproducible releasesUsing
latestcouples chart installs to whatever was pushed most recently, defeating repeatability and making rollbacks harder.
Prefer the semver ({{ .Chart.AppVersion }}) you release in the workflow.- addon_platform: quay.io/konveyor/tackle2-addon-platform:latest + addon_platform: quay.io/konveyor/tackle2-addon-platform:{{ .Chart.AppVersion }}roles/tackle/templates/customresource-addon-platform.yml.j2 (2)
1-70: Remove duplication by iterating in JinjaThe three Addon definitions are structurally identical aside from
{name, task}.
A small loop will cut ~60 lines, lower the maintenance burden, and eliminate drift.{% for comp in ['manifest', 'importer', 'generator'] %} --- kind: Addon apiVersion: tackle.konveyor.io/v1alpha1 metadata: name: {{ ('platform_' ~ comp) }} namespace: {{ app_namespace }} labels: app.kubernetes.io/name: {{ platform_service_name }} app.kubernetes.io/component: {{ platform_component_name }} app.kubernetes.io/part-of: {{ app_name }} spec: task: {{ ('platform_' ~ comp) }} container: name: {{ platform_component_name }} image: {{ platform_fqin }} imagePullPolicy: {{ image_pull_policy }} resources: limits: cpu: {{ platform_container_limits_cpu }} memory: {{ platform_container_limits_memory }} requests: cpu: {{ platform_container_requests_cpu }} memory: {{ platform_container_requests_memory }} {% endfor %}
14-23: Harden the container spec with asecurityContextThe addon pods currently run without explicit security settings.
Consider adding at least:securityContext: runAsNonRoot: true readOnlyRootFilesystem: true allowPrivilegeEscalation: falseHelps satisfy common hardening baselines (NSA, CIS) and avoids future audit findings.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/create-release.yml(1 hunks)helm/templates/crds/tackle.konveyor.io_schemas.yaml(1 hunks)helm/values.yaml(1 hunks)roles/tackle/defaults/main.yml(1 hunks)roles/tackle/templates/customresource-addon-platform.yml.j2(1 hunks)roles/tackle/templates/customresource-schema-cloudfoundry.yml.j2(1 hunks)
🔇 Additional comments (2)
.github/workflows/create-release.yml (1)
127-142: Bundle build steps still miss the new platform image – risk of broken CSVYou correctly release and wait for the image here, but
build-bundlelater passes explicit image arguments (lines 228-236).addon_platformis not among them, so the CSV will not get its digest substituted, leading to an unresolved image pull at install time.Action item: add the argument in the
make-bundlestep:addon_discovery: quay.io/konveyor/tackle2-addon-discovery:${{ inputs.version }} + addon_platform: quay.io/konveyor/tackle2-addon-platform:${{ inputs.version }}Validate that
make-bundletarget consumesaddon_platformsimilarly to the others.roles/tackle/templates/customresource-addon-platform.yml.j2 (1)
71-95: Confirm Taskactionvalues against the operator’s expectationsWe couldn’t find any local definitions or usages of
spec.actionin this repo, so please double-check that the valuesfetch,import, andgeneratematch what the Tackle Operator’s reconciliation logic actually supports. If these verbs aren’t recognized, your Tasks will be ignored and the Addon will stay inPending.Suggested verification steps:
- Clone the upstream operator and search its Go types and constants:
gh repo clone konveyor/tackle-operator rg -n "type TaskSpec" -A5 -B2 tackle-operator/ rg -n "Action" -A3 -B1 tackle-operator/- Alternatively, consult the operator’s documentation or CRD (
kubectl explain Task.spec.action) to see the list of valid action values.
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
Signed-off-by: Jeff Ortel <jortel@redhat.com>
3 participants
Add Schema CRD.
Add Cloud Foundry schemas.
Add platform tasks and addons. The addons share the same image.
Tasks:
Addons:
Schemas:
Summary by CodeRabbit
New Features
Improvements
Chores