Request For Comments (RFCs)
  • Request for comments (RFC)
  • RFC 001: Matcher architecture
  • RFC 002: Archival Storage Service
  • RFC 003: Asset Access
  • RFC 004: METS Adapter
  • RFC 005: Reporting Pipeline
  • RFC 006: Reindexer architecture
  • RFC 007: Goobi Upload
  • RFC 008: API Filtering
  • RFC 009: AWS account setup
  • RFC 010: Data model
  • RFC 011: Network Architecture
  • RFC 012: API Architecture
  • RFC 013: Release & Deployment tracking
    • Deployment example
    • Version 1
  • RFC 014: Born digital workflow
  • RFC 015: How we work
    • Code Reviews
    • Shared Libraries
  • RFC 016: Holdings service
  • URL Design
  • Pipeline Tracing
  • Platform Reliability
    • CI/CD
    • Observability
    • Reliability
  • RFC 020: Locations and requesting
  • RFC 021: Data science in the pipeline
  • RFC 022: Logging
    • Logging example
  • RFC 023: Images endpoint
  • RFC 024: Library management
  • RFC 025: Tagging our Terraform resources
  • RFC 026: Relevance reporting service
  • RFC 026: Relation Embedder
  • RFC 027: Pipeline Intermediate Storage
  • RFC 029: Work state modelling
  • Pipeline merging
  • RFC 031: Relation Batcher
  • RFC 032: Calm deletion watcher
  • RFC 033: Api internal model versioning
  • RFC 034: Modelling Locations in the Catalogue API
  • RFC 035: Modelling MARC 856 "web linking entry"
  • RFC 036: Modelling holdings records
  • API faceting principles & expectations
  • Matcher versioning
  • Requesting API design
  • TEI Adapter
  • Tracking changes to the Miro data
  • How do we tell users how to find stuff?
  • Removing deleted records from (re)indexes
  • RFC 044: Tracking Patron Deletions
  • Work relationships in Sierra, part 2
    • Work relationships in Sierra
  • Born Digital in IIIF
  • Transitive hierarchies in Sierra
  • RFC 047: Changing the structure of the Catalogue API index
  • RFC 048: Concepts work plan
  • RFC 049: Changing how aggregations are retrieved by the Catalogue API
  • RFC 050: Design considerations for the concepts API
  • RFC 051: Ingesting Library of Congress concepts
  • RFC: 052: The Concepts Pipeline - phase one
  • RFC 053: Logging in Lambdas
  • RFC 054: Authoritative ids with multiple Canonical ids.
  • RFC 055: Genres as Concepts
  • RFC 055: Content API
    • Content API: articles endpoint
    • Content API: Events endpoint
    • Content API: exhibitions endpoint
    • The future of this endpoint
  • RFC 056: Prismic to Elasticsearch ETL pipeline
  • RFC 57: Relevance testing
    • Examples of rank CLI usage
  • RFC 059: Splitting the catalogue pipeline Terraform
  • RFC 060: Service health-check principles
  • RFC 060: Offsite requesting
    • Sierra locations in the Catalogue API
  • Content-api: next steps
Powered by GitBook
On this page
  • Problem statement
  • Solution
  • Notes

RFC 025: Tagging our Terraform resources

Last updated: 29 May 2020.

Problem statement

We manage our infrastructure in Terraform, but our Terraform configurations are split:

  • Across many repositories

  • Across multiple directories within each repository

This keeps each configuration small, so it can be planned and applied faster. It also creates a hard gap between unrelated services -- for example, a change in the storage service shouldn't affect the catalogue pipeline.

However, this approach can make it hard to find the definition of any particular resource.

If you're looking at a resource in the console, you should be able to tell:

  • Is this resource managed in Terraform?

  • If so, where is the corresponding Terraform configuration?

Solution

We are going to tag resources in a Terraform configuration like so:

tags = {
  TerraformConfigurationURL = "https://github.com/wellcomecollection/:repo_name/:configuration_path"
}

The tag will point to a URL where you can find the Terraform configuration. Every resource in a configuration will have the same tag -- this is a clue, rather than an exact file reference.

Notes

  • We are going to tag as many resources as we can do quickly, but the goal is not 100%. Trying to tag every last resource could get very fiddly, and the added value drops off quickly.

  • Because we tend to put staging and production resource in separate configurations, these tags will start to give us a way to break down costs among services.

  • We are not going to tag resources with a named, responsible individual -- we all have collective responsibility for the platform. If there are resources that only person understands or can maintain, that is a problem we need to fix.

PreviousRFC 024: Library managementNextRFC 026: Relevance reporting service

Last updated 10 months ago