| #10 |
Managing Unique Names in ochami microservices |
update |
Becoming more relevant as SMD replacement is considered (inventory-service already in play). Fold into the new SMD replacement RFD (to be drafted). |
| #13 |
Standards for Headers in Ochami Microservices |
close |
Becoming less relevant as fabrica replaces hand-tooling — our standards have effectively become the fabrica defaults. Close with reference to fabrica. |
| #23 |
Introduce a simple node orchestration/federation API |
update |
Overlaps with #121 (node config), #91 (lifecycle), #122 (HW identification). Clarify scope vs. current direction. (No maintainer direction provided.) |
| #34 |
Developer Guidelines |
close |
Covered by Renovate automation + stronger CONTRIBUTING.md directives (via #131). Close. |
| #37 |
Secure Boot |
update |
Park — becomes more relevant once TPM enablement (#40) is done. Add maintainer note on dependency. |
| #40 |
TPM Enrollment and secure secret delivery |
update |
Prerequisite for #37 but distinct. Both need more detail before they can land. |
| #41 |
Federation/Orchestration for Cell-Based deployment |
update |
Needs an update from CSCS about how they want meta-services to work. Author engagement required. |
| #48 |
Interopreability |
close |
Confirmed close. |
| #54 |
Power Control |
close |
Point to #64 (Support for Power Management) and close. |
| #64 |
Support for Power Management |
update |
14 comments. Active topic; drive to a decision. (No maintainer direction provided.) |
| #65 |
Discfull Boot for Compute Nodes |
update |
Real ask from SC24 BoF, 3 comments. Scope and either commit or defer. (No maintainer direction provided.) |
| #66 |
Export Prometheus metrics for all microservices |
close |
Move to the fabrica repo — Prometheus is being built into fabrica. Close this RFD in roadmap with a pointer. |
| #67 |
Remote Console Service |
close |
Point to remote-console (built) and close. |
| #68 |
ClusterAPI Provider for OpenCHAMI |
close |
Close unless someone wants to own it at the meeting. |
| #72 |
Virtual Test Development System (vTDS) |
update |
vTDS exists but how to use it is still unclear. Delegate to HPE with hope of close. |
| #73 |
Support BOS-style boot sessions |
update |
13 comments, active discussion. Needs a small scoping decision to move forward. (No maintainer direction provided.) |
| #76 |
Distributed Management Zones and Failure Domain Architecture |
update |
Architectural anchor with related sub-RFDs (#41, #90). Drive alignment. (No maintainer direction provided.) |
| #79 |
API Tagging |
update |
API standards cluster. Consider rolling up under #107 — though see note: most of the cluster is being closed. (No maintainer direction provided specifically for #79.) |
| #80 |
Standard Query Parameters |
update |
API standards cluster. (No maintainer direction provided specifically for #80.) |
| #81 |
Results Filtering |
close |
Close. |
| #82 |
Pagination |
close |
Close. |
| #83 |
Asynchronous Operations |
close |
Close. |
| #84 |
Bulk Operations: Bulk path |
close |
Close. |
| #85 |
Bulk Operations: Bulk POST |
close |
Close. |
| #86 |
Bulk Operation: Bulk PATCH |
close |
Close. |
| #89 |
CLI and configuration consolidation |
close |
Point to ochami (the CLI) and close. |
| #90 |
Local Management Zone Device Manager |
update |
Sub of #76. Align with that discussion. (No maintainer direction provided.) |
| #91 |
Node Lifecycle State Machine |
update |
Wrap into the new SMD replacement RFD (to be drafted). |
| #102 |
Options for RPM Signing Approach |
close |
Point to existing gpg-signing-manager + github-actions signing pattern and close. |
| #105 |
FRU Functional Spec Proposal |
close |
Close, reference fru-tracker (implementation). |
| #107 |
REST API standards |
close |
Close. |
| #112 |
Hardware Inventory API and Data Model Proposal |
update |
Point to fru-tracker and the new SMD replacement RFD. 21 comments — most active on the board; needs the TSC push to land. |
| #113 |
choose HTTP API/client framework |
close |
Close with fabrica — chosen by adoption. |
| #114 |
Deprecate Mailerlite mailing list |
close |
Close with note about the new Linux Foundation mailing list (link to the LF list address when posting the close comment). |
| #117 |
Issue Creation Policy |
close |
Merge with / reference #131 and close. |
| #121 |
Profile-based Node Configuration and Node API Shim |
update |
Drive to decision; ties to #122 (HW identification) and #91 (lifecycle → SMD replacement). (No maintainer direction provided.) |
| #122 |
Flexible Hardware Identification and Hierarchy Linking |
update |
Foundational for FRU + inventory. (No maintainer direction provided.) |
| #123 |
Redfish Interface Strategy |
update |
Multi-vendor strategy needs broad agreement. (No maintainer direction provided.) |
| #124 |
Standardized OpenAPI Discovery Endpoint |
update |
Merge with #126 — include other standard endpoints (health, metrics, openapi discovery) — and implement in fabrica. |
| #126 |
standardize Schema API naming |
update |
Merge with #124 (see that row for the combined direction). |
| #128 |
BMC Credential Secret Management via Vault |
update |
Generalize: Vault as core component, with a library that allows local files for testing or when Vault is unavailable. |
| #129 |
Artifact Library / MinIO Integration |
close |
Likely close after some discussion with bmcdonald and HPE. Community-meeting outcome already captured in comments ("backend-agnostic"); just needs body update + close. |
| #130 |
recommended list of base docker images |
close |
Treat as a use case within #131. Close the standalone RFD; fold into the #131 discussion. |
Please share any additional details on this topic
Many of our RFDs hav gone stale or overcome by events. We need TSC cooperation to move them through the lifecycle. I'd like to approve as many of these changes as we can in about 20 minutes.
Detail what actions or feedback you would like from the TSC
Alex's proposal for next steps on each RFD
remote-console(built) and close.ochami(the CLI) and close.gpg-signing-manager+github-actionssigning pattern and close.fru-tracker(implementation).How much time do you need for this topic?
20 minutes