This is the Flux RFC project.
We collect specifications for APIs, file formats, wire protocols, and processes.
- 1/C4.1 - Collective Code Construction Contract
-
The Collective Code Construction Contract (C4.1) is an evolution of the github.com Fork + Pull Model, aimed at providing an optimal collaboration model for free software projects.
- 2/Flux Licensing and Collaboration Guidelines
-
The Flux framework is a family of projects used to build site-customized resource management systems for High Performance Computing (HPC) data centers. This document specifies licensing and collaboration guidelines for Flux projects.
- 3/CMB1 - Flux Comms Message Broker Protocol
-
This specification describes the format of communications message broker messages, Version 1, also referred to as CMB1.
- 4/Flux Resource Model
-
The Flux Resource Model describes the conceptual model used for resources within the Flux framework.
- 5/Flux Module Extension Protocol
-
This specification describes the format of messages used to load Flux dynamic shared object modules, and the symbols that such modules must define.
- 6/Flux Remote Procedure Call Protocol
-
This specification describes how Flux Remote Procedure Call (RPC) is built on top of CMB1 request and response messages.
- 7/Flux Coding Style Guide
-
This specification presents the recommended standards when contributing C code to the Flux code base.
- 8/Flux Task and Program Execution Services
-
A core service of Flux is to launch, monitor, and handle I/O for distributed sets of tasks in order to execute a parallel workload. A Flux workload can include further instances of Flux, to arbitrary recursive depth. The goal of this RFC is to specify in detail the services required to execute a Flux workload.
- 9/Distributed Communication and Synchronization Best Practices
-
Establishes best practices, preferred patterns and anti-patterns for distributed services in the flux framework.
- 10/Content Storage
-
This specification describes the Flux content storage service and the messages used to access it.
- 11/Key Value Store Tree Object Format v1
-
The Flux Key Value Store (KVS) implements hierarchical key namespaces layered atop the content storage service described in RFC 10. Namespaces are organized as hash trees of content-addressed tree objects and values. This specification defines the version 1 format of key value store tree objects.
- 12/Flux Security Architecture
-
This document describes the mechanisms used to secure Flux instances against unauthorized access and prevent privilege escalation and other attacks, while ensuring programs run with appropriate user credentials and are contained within their set of allocated resources.
- 13/Simple Process Manager Interface v1
-
The MPI process manager interface (PMI) version 1 is a de-facto standard API and wire protocol for communication between MPI runtimes and resource managers. It was added to the MPICH2 MPI-2 reference implementation in late 2001, and has since been widely implemented, but was not officially standardized by the MPI Forum and has been only lightly documented. This RFC is an attempt to document PMI-1 to guide developers of resource managers that must support current and legacy MPI implementations.
- 14/Canonical Job Specification
-
A domain specific language based on YAML is defined to express the resource requirements and other attributes of one or more programs submitted to a Flux instance for execution. This RFC describes the canonical form of the jobspec language, which represents a request to run exactly one program.
- 15/Independent Minister of Privilege for Flux: The Security IMP
-
This specification describes Flux Security IMP, a privileged service used by multi-user Flux instances to launch, monitor, and control processes running as users other than the instance owner.
- 16/KVS Job Schema
-
This specification describes the format of data stored in the KVS for Flux jobs.
The change process is C4.1 with a few modifications:
-
A specification is created and modified by pull requests according to C4.1.
-
Each specification has an editor who publishes the RFC to (website TBD) as needed.
-
Each specification has a status on that website: Raw, Draft, Stable, Legacy, Retired, Deleted.
-
Non-cosmetic changes are allowed only on Raw and Draft specifications.