module-migrate

Name: module-migrate
Author: opendatahub-io

36stars74forks

How to install module-migrate?

opendatahub-io/ai-helpers/module-migrate

$npx -y skills add opendatahub-io/ai-helpers --skill module-migrate

Installs into the current project.

Summary

Read existing in-tree ODH operator component code and produce a step-by-step extraction checklist for migrating it to a standalone module. Analyzes controller logic, webhooks, RBAC, embedded manifests, and DSC field mappings. Use when extracting a component from the monolithic op

Files · 1

View on GitHub

SKILL.md

1	# ODH Module Migration
2
3	Analyze an in-tree ODH operator component and generate a migration checklist
4	for extracting it into a standalone module operator.
5
6	## Prerequisites
7
8	The user must have the `opendatahub-io/opendatahub-operator` repository (or a
9	fork) checked out locally. This skill reads that codebase to analyze the
10	component.
11
12	## Step 1: Identify the component
13
14	Extract the component name from `$ARGUMENTS`. If not provided, ask the user.
15
16	Search for the component in these locations within the operator repo:
17
18	- `internal/controller/components/<name>/` (component controllers)
19	- `internal/controller/services/<name>/` (service controllers)
20	- `api/components/v1alpha1/<name>_types.go` (component CRD types)
21	- `api/services/v1alpha1/<name>_types.go` (service CRD types)
22
23	If the component is found under `components/`, the target API group is
24	`components.platform.opendatahub.io`. If under `services/`, use
25	`services.platform.opendatahub.io`.
26
27	## Step 2: Analyze controller logic
28
29	Read all files in the component's controller directory. Document:
30
31	1. Handler implementation -- the file implementing the handler interface
32	(ComponentHandler or ServiceHandler). Note which interface methods are
33	implemented.
34	2. Controller setup -- how the reconciler is registered. Note if it uses
35	the builder pattern or a legacy pattern.
36	3. Action functions -- list each action (render, deploy, gc, custom) and
37	what it does.
38	4. Resources managed -- grep for resource kinds the controller
39	creates/updates (Deployments, Services, ConfigMaps, Routes, etc.).
40	5. Embedded manifests -- look for `go:embed` directives, template files,
41	or inline YAML strings. Note their locations.
42	6. Platform dependencies -- grep for references to DSCI, DSC, or other
43	platform CRs within the controller logic.
44
45	## Step 3: Analyze CRD types
46
47	Read the component's CRD types file. Document:
48
49	1. Spec fields -- list all spec fields. Identify which are user-facing
50	(belong in CommonSpec) vs operator-written (stay in Spec only).
51	2. Status fields -- check if it already implements PlatformObject or uses
52	a different status pattern.
53	3. Platform-managed fields -- fields populated by the orchestrator (auth,
54	certs, monitoring config).
55	4. Validation -- CEL rules, webhook validations, enum constraints.
56
57	## Step 4: Analyze webhooks
58
59	Search for webhook registrations related to the component using the Grep
60	tool:
61
62	- Search for `"webhook"` in `internal/controller/components/<name>/`
63	- Search for `"webhook"` in `internal/controller/services/<name>/`
64	- Search for `"<ComponentKind>"` in `internal/webhook/`
65
66	Document each webhook: type (validating/mutating), what it validates, where
67	the handler code lives.
68
69	## Step 5: Analyze RBAC
70
71	Find RBAC requirements for the component:
72
73	1. Check for `+kubebuilder:rbac:` markers in the controller files.
74	2. Check top-level controller RBAC files that may cover this component's
75	operations (e.g., `internal/controller/datasciencecluster/kubebuilder_rbac.go`).
76	3. List each RBAC rule: apiGroup, resource, verbs.
77	4. Separate rules into:
78	- Module-side -- rules the standalone module controller needs
79	- Orchestrator-side -- rules the orchestrator needs to manage the module
80
81	## Step 6: Analyze DSC/DSCI field mappings
82
83	Find how the component's configuration flows from DSC to the component:
84
85	1. Grep for `spec.components.<name>` or the component's stanza name in the
86	DSC types.
87	2. Read the DSC-to-component mapping code. Note which DSC fields map to which
88	component spec fields.
89	3. Identify platform-wide settings from DSCI (auth, certs, monitoring) that
90	are injected into the component.
91
92	## Step 7: Map import paths
93
94	Using `${CLAUDE_SKILL_DIR}/references/import-mappings.md`, identify all
95	imports from the operator's internal packages and map them to their
96	`odh-platform-utilities` equivalents.
97
98	Use the Grep tool to find imports that need remapping:
99
100	- Search for `"opendatahub-operator"` in `internal/` and `api/`
101	- Search for `"openshift/api"` in `internal/` and `api/`
102
103	For each import, note the old path, the new path, and any API changes
104	(e.g., `WithReleases` is now part of PlatformObject).
105
106	## Step 8: Generate migration checklist
107
108	Write the checklist to `migration-checklist-<component>.md` in the current
109	directory. Use this structure:
110
111	```markdown
112	# Migration Checklist: <Component> Module
113
114	Generated from opendatahub

People who liked this also viewed

6 picks

Type

module-migrate

36stars74forks

View on GitHub

How to install module-migrate?

opendatahub-io/ai-helpers/module-migrate

$npx -y skills add opendatahub-io/ai-helpers --skill module-migrate

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ODH Module Migration
2
3	Analyze an in-tree ODH operator component and generate a migration checklist
4	for extracting it into a standalone module operator.
5
6	## Prerequisites
7
8	The user must have the `opendatahub-io/opendatahub-operator` repository (or a
9	fork) checked out locally. This skill reads that codebase to analyze the
10	component.
11
12	## Step 1: Identify the component
13
14	Extract the component name from `$ARGUMENTS`. If not provided, ask the user.
15
16	Search for the component in these locations within the operator repo:
17
18	- `internal/controller/components/<name>/` (component controllers)
19	- `internal/controller/services/<name>/` (service controllers)
20	- `api/components/v1alpha1/<name>_types.go` (component CRD types)
21	- `api/services/v1alpha1/<name>_types.go` (service CRD types)
22
23	If the component is found under `components/`, the target API group is
24	`components.platform.opendatahub.io`. If under `services/`, use
25	`services.platform.opendatahub.io`.
26
27	## Step 2: Analyze controller logic
28
29	Read all files in the component's controller directory. Document:
30
31	1. Handler implementation -- the file implementing the handler interface
32	(ComponentHandler or ServiceHandler). Note which interface methods are
33	implemented.
34	2. Controller setup -- how the reconciler is registered. Note if it uses
35	the builder pattern or a legacy pattern.
36	3. Action functions -- list each action (render, deploy, gc, custom) and
37	what it does.
38	4. Resources managed -- grep for resource kinds the controller
39	creates/updates (Deployments, Services, ConfigMaps, Routes, etc.).
40	5. Embedded manifests -- look for `go:embed` directives, template files,
41	or inline YAML strings. Note their locations.
42	6. Platform dependencies -- grep for references to DSCI, DSC, or other
43	platform CRs within the controller logic.
44
45	## Step 3: Analyze CRD types
46
47	Read the component's CRD types file. Document:
48
49	1. Spec fields -- list all spec fields. Identify which are user-facing
50	(belong in CommonSpec) vs operator-written (stay in Spec only).
51	2. Status fields -- check if it already implements PlatformObject or uses
52	a different status pattern.
53	3. Platform-managed fields -- fields populated by the orchestrator (auth,
54	certs, monitoring config).
55	4. Validation -- CEL rules, webhook validations, enum constraints.
56
57	## Step 4: Analyze webhooks
58
59	Search for webhook registrations related to the component using the Grep
60	tool:
61
62	- Search for `"webhook"` in `internal/controller/components/<name>/`
63	- Search for `"webhook"` in `internal/controller/services/<name>/`
64	- Search for `"<ComponentKind>"` in `internal/webhook/`
65
66	Document each webhook: type (validating/mutating), what it validates, where
67	the handler code lives.
68
69	## Step 5: Analyze RBAC
70
71	Find RBAC requirements for the component:
72
73	1. Check for `+kubebuilder:rbac:` markers in the controller files.
74	2. Check top-level controller RBAC files that may cover this component's
75	operations (e.g., `internal/controller/datasciencecluster/kubebuilder_rbac.go`).
76	3. List each RBAC rule: apiGroup, resource, verbs.
77	4. Separate rules into:
78	- Module-side -- rules the standalone module controller needs
79	- Orchestrator-side -- rules the orchestrator needs to manage the module
80
81	## Step 6: Analyze DSC/DSCI field mappings
82
83	Find how the component's configuration flows from DSC to the component:
84
85	1. Grep for `spec.components.<name>` or the component's stanza name in the
86	DSC types.
87	2. Read the DSC-to-component mapping code. Note which DSC fields map to which
88	component spec fields.
89	3. Identify platform-wide settings from DSCI (auth, certs, monitoring) that
90	are injected into the component.
91
92	## Step 7: Map import paths
93
94	Using `${CLAUDE_SKILL_DIR}/references/import-mappings.md`, identify all
95	imports from the operator's internal packages and map them to their
96	`odh-platform-utilities` equivalents.
97
98	Use the Grep tool to find imports that need remapping:
99
100	- Search for `"opendatahub-operator"` in `internal/` and `api/`
101	- Search for `"openshift/api"` in `internal/` and `api/`
102
103	For each import, note the old path, the new path, and any API changes
104	(e.g., `WithReleases` is now part of PlatformObject).
105
106	## Step 8: Generate migration checklist
107
108	Write the checklist to `migration-checklist-<component>.md` in the current
109	directory. Use this structure:
110
111	```markdown
112	# Migration Checklist: <Component> Module
113
114	Generated from opendatahub

People who liked this also viewed

6 picks

Type