-
Notifications
You must be signed in to change notification settings - Fork 14
docs(skills): add skill for creating controlplane service components #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
cjeanner
wants to merge
1
commit into
main
Choose a base branch
from
skill/create-new-service-component
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+120
−0
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,116 @@ | ||
| # Add Controlplane Service Component | ||
|
|
||
| This skill creates a new service component for the OpenStack controlplane. | ||
|
|
||
| ## Purpose | ||
|
|
||
| Scaffolds the directory structure and boilerplate files needed to add a new OpenStack service to the controlplane components catalog. | ||
|
|
||
| ## Usage | ||
|
|
||
| When an AI agent or contributor needs to add a new service component to `/components/rhoso/controlplane/services/`, use this skill to ensure consistency with the repository's patterns. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| - Service name (kebab-case, e.g., `barbican`, `designate`, `octavia`) | ||
| - Understanding of the service's configuration requirements | ||
| - Red Hat OpenStack Services on OpenShift documentation link for the service (if available) | ||
|
|
||
| ## Steps | ||
|
|
||
| ### 1. Create Service Directory | ||
|
|
||
| ```bash | ||
| SERVICE_NAME="<service-name>" # e.g., barbican, designate, octavia | ||
| mkdir -p components/rhoso/controlplane/services/${SERVICE_NAME} | ||
| ``` | ||
|
|
||
| ### 2. Create `kustomization.yaml` | ||
|
|
||
| Create `components/rhoso/controlplane/services/${SERVICE_NAME}/kustomization.yaml`: | ||
|
|
||
| ```yaml | ||
| --- | ||
| apiVersion: kustomize.config.k8s.io/v1alpha1 | ||
| kind: Component | ||
|
|
||
|
oliashish marked this conversation as resolved.
|
||
| patches: | ||
| - path: service.yaml | ||
| target: | ||
| kind: OpenStackControlPlane | ||
| ``` | ||
|
|
||
| ### 3. Create `service.yaml` | ||
|
|
||
| Create `components/rhoso/controlplane/services/${SERVICE_NAME}/service.yaml`: | ||
|
|
||
| ```yaml | ||
| --- | ||
| # https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/... | ||
| # TODO: Replace with actual documentation link for this service | ||
| apiVersion: core.openstack.org/v1beta1 | ||
| kind: OpenStackControlPlane | ||
| metadata: | ||
| name: openstack-control-plane | ||
| spec: | ||
| <service-name>: | ||
| enabled: true | ||
| template: | ||
| # Service-specific configuration goes here | ||
| # Refer to the OpenStackControlPlane CRD and service operator documentation | ||
| ``` | ||
|
|
||
| **Important:** | ||
| - Replace `<service-name>` with the actual service name in camelCase (e.g., `barbican`, `octavia`, `designate`) | ||
| - Replace the documentation URL with the actual Red Hat documentation link | ||
| - Add service-specific template configuration based on the service operator's CRD | ||
|
|
||
| ### 4. Validate the Component | ||
|
|
||
| Run kustomize build to ensure the component is valid: | ||
|
|
||
| ```bash | ||
| kustomize build components/rhoso/controlplane/services/${SERVICE_NAME} | ||
| ``` | ||
|
|
||
| ### 5. Add to Examples (Optional but Recommended) | ||
|
|
||
| Consider adding an example that uses this service component in `/example` to demonstrate usage. | ||
|
|
||
| ### 6. Run CI Validation | ||
|
|
||
| Before committing, run the validation commands from `.github/workflows/` to ensure the component passes CI checks: | ||
|
|
||
| ```bash | ||
| # Check the .github/workflows/ directory for exact validation commands | ||
| # Typically includes: | ||
| # - YAML linting | ||
| # - Kustomize build tests | ||
| ``` | ||
|
|
||
| ## YAML Conventions | ||
|
|
||
| Ensure all files follow repository conventions: | ||
|
|
||
| - **Document header:** Every YAML file must start with `---` (comments may appear above it) | ||
| - **Documentation links:** Include Red Hat documentation URLs in comments | ||
| - **Indentation:** Use 2 spaces (consistent with existing files) | ||
| - **One object per file:** Unless the pattern clearly uses multi-document files | ||
|
|
||
| ## Reference Example | ||
|
|
||
| See `/components/rhoso/controlplane/services/watcher/` for a complete working example. | ||
|
|
||
| ## Related Documentation | ||
|
|
||
| - [Repository structure](../agents/repository.md) | ||
| - [YAML, Helm, and Kustomize conventions](../agents/yaml-helm-kustomize.md) | ||
| - [CI and validation](../agents/ci-and-validation.md) | ||
| - [OpenStackControlPlane CR reference](https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_red_hat_openstack_services_on_openshift/assembly_creating-the-control-plane#ref_example-OpenStackControlPlane-CR_controlplane) | ||
|
|
||
| ## Notes for AI Agents | ||
|
|
||
| - This is a **component catalog**, not a full cluster configuration | ||
| - Prefer conservative, backwards-compatible changes | ||
| - Do not open PRs without explicit human request | ||
| - Follow Conventional Commits with `AI-Tool` / `AI-Model` footers when contributing | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know these Openstack service names are single word, but it would be better if we have some better examples of kebab-case here. I not sure what exactly to be honest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so there's a side-project to extract names directly from the
openstack-operatordocumentation, and serve them via an MCP - that same MCP would also be able to extract the documentationsectionrelated to the service, to then create the needed bits.Unless we hardcode the whole list here in the skill (won't do), I don't see what could be improved. I'm of course open to suggestion - there are about 30 services to date[1], maybe there's a wiser choice?
[1] https://openstack-k8s-operators.github.io/openstack-operator/
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it isn't about which services to list, the three examples are fine as service list. The issue is that barbican, designate, octavia aren't kebab-case. AI might Hallucinate with requiring kebab-case and example not actually being kebab-case.
A better example would look like
barbican-apishowing kebab case, I knowbarbican-apiis not something used directly it would be barbican, but just giving an example just for AI to not hallucinate over this. The example currently in all fairness is lowercase not kebab-case.But you can choose to ignore it as
kebab-casethe word in skills file should be enough.