Skip to content

Introduction to Linchpin terminology

Jump to bottom
Samvaran Rallabandi edited this page Feb 28, 2020 · 1 revision

LINCHPIN

Linchpin is a highly extensible multi-cloud resource provisioner written in ansible.

Features

  • YAML based DSL
  • Cloud agnostic Ansible inventory generation using layouts
  • Pre, Post Provisioning tasks
  • Configurable local, remote Workspaces
  • Python API support
  • Transaction based Database records for history and re-runs
  • Dynamic Jinja template based files for adhoc provisioning
  • Asynchronous provisioning
  • Generates Multiple inventory formats based on layouts

LINCHPIN TERMINOLOGY

  • WORKSPACES
  • PINFILE
  • TOPOLOGY
  • LAYOUT
  • HOOKS

WORKSPACES

​​​​​Workspaces are a collection of Static and generated files that are responsible for the cloud resource provisioning activity.

There can be two types of workspaces

  • Local workspaces: Workspaces that exists on a local machine

  • ​Remote workspaces: Workspace folders hosted on external services like Github, HTTP file servers

  • Related Linchpin commands (refer linchpin command line):

    • linchpin fetch
    • ​linchpin init

  • Example workspace structure

.
├── credentials
├── hooks
├── inventories
├── layouts
│   └── dummy-layout.yml
├── linchpin.conf
├── linchpin.log
├── localhost
├── PinFile
└── topologies
    └── dummy-topology.yml

PINFILE

  • Pinfile is file consisting of structured format of pairs of topologies, layouts ( known as Targets) and optional hooks.

  • Pinfile acts as a entry point for any provisioning activity.

  • All targets in Pinfiles are provisioned Top-down manner.

  • A Workspace can contain multiple Pinfiles.

  • There are three types of Pinfiles

    • ​Relative path Pinfile

    • All-in-One Pinfile

    • Dynamic Pinfile

    • Scripted Pinfile

  • Related Commands

    • (refer linchpin command line):

    • ​linchpin up

    • linchpin destroy

LINCHPIN TOPOLOGY

  • Topology is well defined set of cloud resources in YAML format.

  • Topology can either be present in a Pinfile ( see All-in-One Pinfile ) or as a file in topologies folder of linchpin workspace

  • Each topology is validated against a set of resource schemas before it is provisioned

  • Each provision activity using topology is not Idempotent unless mentioned

  • A Pinfile can have multiple topologies

  • Each resource in topology validates against a specific schema

  • Topologies can also be dynamically rendered by passing jinja template variables

  • Refer linchpin cli examples

  • Related commands:

    • linchpin up

LINCHPIN TOPOLOGY STRUCTURE

  1. Topology

    • set of resource groups and vars

  2. Resource Group

    - set of resource definitions

  3. Resource Group Type

    • predefined set group types

  4. Resource Definition

    - the denotation of resource with its attributes

  5. Resource type

    - predefined cloud resource name

  6. Resource group vars

    - Metadata for the cloud resource

Linchpin topology structure

  • Example topology
---
topology_name: os-server-new
resource_groups:
  - resource_group_name: os-server-new
    resource_group_type: openstack
    resource_definitions:
      - name: "{{ distro | default('') }}database"
        role: os_server
        flavor: m1.small
        image: CentOS-7-x86_64-GenericCloud-1612
        count: 2
        keypair: ci-factory
        fip_pool: 10.8.240.0
        additional_volumes:
          - name: "hello"
            size: 1
            device_name: "/dev/vdb"
        networks:
          - e2e-openstack
    credentials:
      filename: clouds.yaml
      profile: ci-rhos

LAYOUTS

  • Inventory layouts act as a mapping between cloud servers provisioned and Ansible inventory groups.
  • Inventory layouts are cloud-agnostic i.e., A fixed inventory layout can generate both multi-cloud and single cloud Ansible inventories
  • One can reuse inventory layout against multiple topologies
  • refer: Linchpin Layouts page

HOOKS

  • In terms of Linchpin , A hook is considered as script or activity that takes place before or after a resource provisioning life cycle
  • When provisioning a instance , Linchpin switches from one state to another. Each state can trigger single/multiple scripts when the state is attained.
  • the Linchpin States are as follows:
    • Preup:
      • State attained by linchpin before provisioning a target
    • postup
      • State attained when the after provisioning a target
    • predestroy
      • State attained by linchpin before destroying a target
    • postdestroy
      • State attained by linchpin before destroying a target
  • Linchpin has a capability to run scripts, Ansible playbooks while when the state is switches
  • Refer Linchpin hooks page
Clone this wiki locally