collection-scaleway
This site is the complete documentation for stephrobert.scaleway. Use it
to operate the collection, to understand how it is generated from Scaleway’s
versioned API contracts, and to contribute to the generator safely. Galaxy
remains the distribution channel; GitHub holds the code and the issues.
Two paths, and they do not need each other.
- Use the collection
Install it, authenticate, list your resources, run a Day-2 operation, and check that a second run reports no change. The task playbooks, the dynamic inventory and the module reference continue from there.
- Build the collection
The pipeline from contract to module, the runtime, the contracts and their measured limits, and the decisions that were taken with what each of them costs.
The boundary that settles every design ambiguity:
Terraform provisions resources. Ansible operates existing resources.
Note
This repository does not contain a hand-written Ansible collection: it contains the generator that writes it. We do not follow the API by hand, we measure it. Scaleway added 453 SDK methods and removed 26 in twelve months: a hand-written collection is stale before it is published.
Use the collection
- Try it without an account
- Using the collection
- Task playbooks
- Scheduling these runs
- The Scaleway dynamic inventory
- The configuration file
- Credentials
- Products
- Zones and regions
- Machine names
- Where Ansible reaches the machine
- Groups
- Filtering
- Cache
- Strict mode, and a trap that is not ours
- The variables set on each machine
- Chaining onto the collection’s modules
- Diagnosing
- How many API calls
- What this plugin does not do yet
Reference
Understand the project
- Generator architecture
- The collection runtime
- Clearing a field
- How the roles are split
- Decision 1: execute the contract’s method and path, over our own transport
- Decision 2: a single way to build the client
- Decision 3: validation depends on the target
- Decision 4: pagination goes all the way, and knows when to stop
- Decision 5: an error says what to diagnose, and nothing else
- Decision 6: a PUT receives everything you want to keep
- The three kinds of module, and what each one does
- What this runtime still does not carry
- The end-to-end proof
- The trap hit while writing all this
- The inventory engine, layer by layer
- The Scaleway contracts: the source, its limits, how it is watched
- Mesure
Decisions
- Architecture decision records
- ADR-001. No operation is UNKNOWN in silence
- ADR-002. Day-2 only: Terraform provisions, Ansible operates
- ADR-003. A managing module reads before it writes
- ADR-004. An
ansible-test sanitythat examined nothing is a failure - ADR-005. Generated documentation is refused, not reported
- ADR-006. The emulator is a proof, not the proof of the real cloud
- ADR-007. A measured number is derived, never typed
- ADR-008. A constraint is translated or named, never guessed and never silent
- ADR-009. How a managed field is compared, and who decides
- ADR-010. A write is checked, not announced
- ADR-011. A product is admitted, not merely added
- ADR-012. An explicit null is refused, never ignored
- ADR-013. When a module appeared is recorded, never computed
- ADR-014. The runtime owns its HTTP transport
- ADR-015. A claim about the real API is a recorded exchange, not a green assertion
- ADR-016. A clearable field is cleared with the empty value of its type, and an explicit null is refused
- ADR-017. The launcher removes what blocks its own destruction, once, and says so
- ADR-018. A retry policy belongs to the operation, and an action is never replayed
- ADR-019. An API name filter narrows a listing, it never selects a resource
- ADR-020. A plan describes the moment it was computed, and is never replayed
Generator internals
Project quality