القائمة
Write an enhancement proposal for a new ORC feature. Use for significant new features, breaking changes, or cross-cutting architectural changes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Review ORC controller code for Kubernetes best practices and ORC conventions. Use after implementing or modifying a controller.
Add a dependency on another ORC resource to a controller. Use when a resource needs to reference or wait for another resource (e.g., Subnet depends on Network).
Create a new ORC controller for an OpenStack resource. Use when adding support for a new OpenStack resource type (e.g., LoadBalancer, FloatingIP).
Run ORC tests (unit tests, linting, and E2E tests). Use after making changes to verify correctness.
Update an existing ORC controller. Use when adding fields, making fields mutable, adding tag support, or improving error handling.
Draft release notes for a new ORC version. Use when preparing a release to generate changelog and GitHub release body from git history.
| name | proposal |
| description | Write an enhancement proposal for a new ORC feature. Use for significant new features, breaking changes, or cross-cutting architectural changes. |
| disable-model-invocation | true |
Guide for creating a proposal for a new feature or enhancement in ORC.
Write an enhancement proposal when you want to:
You do not need an enhancement for:
When in doubt, suggest opening a GitHub issue first to discuss whether an enhancement proposal is needed.
Enhancements move through the following statuses:
| Status | Description |
|---|---|
implementable | The enhancement has been approved and is ready for implementation |
implemented | The enhancement has been fully implemented and merged |
withdrawn | The enhancement is no longer being pursued |
Use the enhancement template at enhancements/TEMPLATE.md.
For full process details, see enhancements/README.md.
Simple enhancement (single file):
cp enhancements/TEMPLATE.md enhancements/your-feature-name.md
Enhancement with supporting files (images, diagrams):
mkdir enhancements/your-feature-name
cp enhancements/TEMPLATE.md enhancements/your-feature-name/your-feature-name.md
Before writing a proposal, ask the user about:
Feature Overview
Use Cases
Dependencies
Scope
Testing
Existing Infrastructure (for non-controller enhancements)
Before writing the proposal, research the relevant area:
Read the template at enhancements/TEMPLATE.md and fill in each section:
| Section | What to Include |
|---|---|
| Metadata table | Status (implementable), author, dates, tracking issue (TBD initially) |
| Summary | 1-2 paragraph overview of the enhancement |
| Motivation | Why this is needed, who benefits, links to issues |
| Goals | Specific, measurable objectives |
| Non-Goals | What's explicitly out of scope |
| Proposal | Detailed solution with API examples |
| Risks and Edge Cases | What could go wrong, mitigations (see risk checklist below) |
| Alternatives Considered | Other approaches and why rejected |
| Implementation History | Timeline of major milestones |
Note: New controllers following existing patterns typically don't need an enhancement proposal. Only write a proposal if the controller requires new patterns or architectural changes.
If a proposal is needed, in the Proposal section, include:
apiVersion: openstack.k-orc.cloud/v1alpha1
kind: ResourceName
metadata:
name: example
spec:
cloudCredentialsRef:
secretName: openstack-credentials
cloudName: openstack
resource:
# Required fields with descriptions
# Optional fields with descriptions
import:
filter:
# Filter fields
status:
id: "uuid"
conditions: [...]
resource:
# Observed state fields
Also describe:
Address each of these in the Risks and Edge Cases section:
| Risk Category | Questions to Answer |
|---|---|
| API compatibility | Will this break existing users? Are metric/label names stable? |
| Security | Are there security implications? (Often N/A for read-only features) |
| Performance | Could this impact controller performance at scale? |
| Error handling | What happens when things fail? |
| Upgrade/downgrade | How does this affect users upgrading or downgrading ORC? |
| OpenStack compatibility | Does this work across different OpenStack versions? (N/A for K8s-only) |
| Interaction with existing features | Could this conflict with existing behavior? |
Verify internal consistency (anything referenced in one section is defined elsewhere), technical accuracy (check against actual code), and that examples are complete.
Enhancement: Add support for feature Xenhancement and link in metadataenhancements/