Significant updates to YAML examples to more fully
illustrate the proposed schema Remove notes.md and open issues for items that need continued collaboration Update readme with the proposed service modules for drydock
This commit is contained in:
Scott Hussey
parent
be87c3db15
commit
0085d4ca76
36
README.md
36
README.md
|
|
@ -1,2 +1,38 @@
|
|||
# drydock
|
||||
A python REST orchestrator to translate a YAML host topology to a provisioned set of hosts and provide a set of cloud-init post-provisioning instructions.
|
||||
|
||||
## Modular service
|
||||
|
||||
### Design Consumer ###
|
||||
|
||||
Pluggable service to ingest a inventory/design specification, convert it to a standard
|
||||
internal representaion, and persist it to the Design State API. Initial implementation
|
||||
is the consumer of AIC YAML schema.
|
||||
|
||||
### Design State API ###
|
||||
|
||||
API for querying and updating the current design specification and persisted orchestration status.
|
||||
CRUD support of CIs that are not bootstrap-related, but can be used by other automation.
|
||||
|
||||
### Control API ###
|
||||
|
||||
User-approachable API for initiating orchestration actions or accessing other internal
|
||||
APIs
|
||||
|
||||
### Infrastructure Orchestrator ###
|
||||
|
||||
Handle validation of complete design, ordering and managing downstream API calls for hardware
|
||||
provisioning/bootstrapping
|
||||
|
||||
### Server Driver ###
|
||||
|
||||
Pluggable provisioner for server bootstrapping. Initial implementation is MaaS client.
|
||||
|
||||
### Network Driver ###
|
||||
|
||||
Pluggable provisioner for network provisioning. Initial implementation is Noop.
|
||||
|
||||
### Introspection API ###
|
||||
|
||||
API for bootstrapping nodes to load self data. Possibly pluggable as this is basically an
|
||||
authenticated bridge to the Design State API
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
---
|
||||
#############################################################################################################################
|
||||
# name : Name of the hardware type. This name will be used in site_config.yaml to refer back; Example, hp-gen9, #
|
||||
# hp-gen8, dell-v3 ; Mandatory #
|
||||
# vendor : Name of the hardware vendor; Example, HP, Dell ; Mandatory #
|
||||
# generation : Generation of the hardware model; Example, 8, 9,10 ; Mandatory #
|
||||
# version : Version of the hardware model within a generation; Example, v2, v3, v4 ; Mandatory #
|
||||
# bios : Version of the bios in the hardware; Example, 2.2.3, 3.4 ; Mandatory #
|
||||
# boot_mode : Mode of the default boot of hardware; Example, bios, UEFI ; Mandatory #
|
||||
# boot_protocol : Protocol of boot of the hardware; Example, PXE, USB, HDD ; Mandatory #
|
||||
#############################################################################################################################
|
||||
hardware-definition:
|
||||
- name: HPGen8v3
|
||||
vendor: HP
|
||||
generation: 8
|
||||
version: 3
|
||||
bios: 2.2.3
|
||||
boot_mode: bios
|
||||
boot_protocol: PXE
|
||||
pxe_interface: 0
|
||||
device_aliases:
|
||||
pci:
|
||||
- address: pci@0000:00:03.0
|
||||
alias: prim_nic01
|
||||
# type could identify expected hardware - used for hardware manifest validation
|
||||
type: '82540EM Gigabit Ethernet Controller'
|
||||
- address: pci@0000:00:04.0
|
||||
alias: prim_nic02
|
||||
type: '82540EM Gigabit Ethernet Controller'
|
||||
scsi:
|
||||
address: scsi@2:0.0.0
|
||||
alias: primary_boot
|
||||
type: 'VBOX HARDDISK'
|
||||
- name: HPGen9v3
|
||||
vendor: HP
|
||||
generation: 9
|
||||
version: 3
|
||||
bios: 2.2.3
|
||||
boot_mode: bios
|
||||
boot_protocol: PXE
|
||||
pxe_interface: 0
|
||||
- name: HPGen9v4
|
||||
vendor: HP
|
||||
generation: 9
|
||||
version: 4
|
||||
bios: 2.2.3
|
||||
boot_mode: bios
|
||||
boot_protocol: PXE
|
||||
pxe_interface: 0
|
||||
- name: DellR720v2
|
||||
vendor: DELL
|
||||
generation: 9
|
||||
version: 3
|
||||
bios: 2.2.3
|
||||
boot_mode: bios
|
||||
boot_protocol: pxe
|
||||
pxe_interface: NIC.Integrated.1-1-1
|
||||
- name: DellR730v3
|
||||
vendor: DELL
|
||||
generation: 9
|
||||
version: 4
|
||||
bios: 2.2.3
|
||||
boot_mode: bios
|
||||
boot_protocol: pxe
|
||||
pxe_interface: NIC.Integrated.1-1-1
|
||||
|
|
@ -1,171 +0,0 @@
|
|||
---
|
||||
webvirt: 192.168.1.1
|
||||
site_name: sitename
|
||||
maas_api_key: consumerkey:tokenkey:tokensecret
|
||||
maas_uuid: nonce
|
||||
host_profiles:
|
||||
- name: k8-node
|
||||
hardware_profile: HPGen9v3
|
||||
interfaces:
|
||||
# Keyed on device_name
|
||||
# pxe is a special marker indicating which device should be used for pxe boot
|
||||
- device_name: pxe
|
||||
network_link: pxe
|
||||
slaves:
|
||||
- prim_nic01
|
||||
networks:
|
||||
- name: pxe
|
||||
- device_name: bond0
|
||||
network_link: gp
|
||||
slaves:
|
||||
- prim_nic01
|
||||
- prim_nic02
|
||||
networks:
|
||||
- name: mgmt
|
||||
- name: private
|
||||
oob:
|
||||
type: ipmi
|
||||
network: oob
|
||||
account: admin
|
||||
credential: admin
|
||||
storage:
|
||||
boot_drive:
|
||||
device: primary_boot
|
||||
bootsize: 2g
|
||||
rootsize: 50g
|
||||
platform:
|
||||
image: ubuntu_16.04_hwe
|
||||
kernel_params: default
|
||||
metadata:
|
||||
introspection_url: http://172.16.1.10:9090
|
||||
- name: k8-node-public
|
||||
host_profile: k8-node
|
||||
interfaces:
|
||||
- device_name: bond0
|
||||
networks:
|
||||
# This is additive, so adds a network to those defined in the inherited host_profile
|
||||
- name: public
|
||||
network:
|
||||
# Describe layer 1 attributes
|
||||
links:
|
||||
- name: pxe
|
||||
bonding:
|
||||
mode: none
|
||||
mtu: 1500
|
||||
linkspeed: auto
|
||||
# Is this link supporting multiple layer 2 networks?
|
||||
trunking:
|
||||
mode: none
|
||||
# use name, will translate to VLAN ID
|
||||
default_network: pxe
|
||||
- name: gp
|
||||
bonding:
|
||||
mode: 802.3ad
|
||||
hash: layer3+4
|
||||
peer_rate: slow
|
||||
mon_rate: default
|
||||
up_delay: default
|
||||
down_delay: default
|
||||
mtu: 9000
|
||||
linkspeed: auto
|
||||
# Is this link supporting multiple layer 2 networks?
|
||||
trunking:
|
||||
mode: tagged
|
||||
networks:
|
||||
- name: pxe
|
||||
vlan_id: 99
|
||||
# How are addresses assigned?
|
||||
allocation: dhcp
|
||||
# Allow MTU to be inherited from link the network rides on
|
||||
mtu: 1500
|
||||
cidr: 172.16.0.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: dhcp
|
||||
start: 172.16.0.5
|
||||
end: 172.16.0.254
|
||||
dns:
|
||||
domain:
|
||||
servers:
|
||||
- name: mgmt
|
||||
vlan_id: 100
|
||||
# How are addresses assigned?
|
||||
allocation: static
|
||||
# Allow MTU to be inherited from link the network rides on
|
||||
mtu: 1500
|
||||
cidr: 172.16.1.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.1.15
|
||||
end: 172.16.1.254
|
||||
routes:
|
||||
- subnet: 0.0.0.0/0
|
||||
gateway: 172.16.1.1
|
||||
weight: 10
|
||||
dns:
|
||||
domain: mgmt.sitename.example.com
|
||||
servers: 172.16.1.9,172.16.1.10
|
||||
- name: private
|
||||
vlan_id: 101
|
||||
# How are addresses assigned?
|
||||
allocation: static
|
||||
# Allow MTU to be inherited from link the network rides on
|
||||
mtu: 9000
|
||||
cidr: 172.16.2.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.2.15
|
||||
end: 172.16.2.254
|
||||
dns:
|
||||
domain: priv.sitename.example.com
|
||||
servers: 172.16.2.9,172.16.2.10
|
||||
- name: public
|
||||
vlan_id: 102
|
||||
# How are addresses assigned?
|
||||
allocation: static
|
||||
# Allow MTU to be inherited from link the network rides on
|
||||
mtu: 1500
|
||||
cidr: 172.16.3.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.3.15
|
||||
end: 172.16.3.254
|
||||
routes:
|
||||
- subnet: 0.0.0.0/0
|
||||
- gateway: 172.16.3.1
|
||||
- weight: 9
|
||||
dns:
|
||||
domain: sitename.example.com
|
||||
servers: 8.8.8.8
|
||||
storage:
|
||||
backend: ceph
|
||||
nodes:
|
||||
- host_profile: k8-node-public
|
||||
name: controller01
|
||||
interfaces:
|
||||
- device_name: bond0
|
||||
networks:
|
||||
# Remove network from interface
|
||||
- name: '!private'
|
||||
addressing:
|
||||
- network: pxe
|
||||
address: dhcp
|
||||
- network: mgmt
|
||||
address: 172.16.1.20
|
||||
- network: public
|
||||
address: 172.16.3.20
|
||||
metadata:
|
||||
roles: os_ctl
|
||||
rack: rack01
|
||||
- host_profile: k8-node
|
||||
name: compute01
|
||||
addressing:
|
||||
- network: pxe
|
||||
address: dhcp
|
||||
- network: mgmt
|
||||
address: 172.16.1.21
|
||||
- network: private
|
||||
address: 172.16.2.21
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
# BSD License
|
||||
#
|
||||
# Copyright (c) 2017, AT&T Intellectual Property. All other rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or
|
||||
# without modification, are permitted provided that the following
|
||||
# conditions are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above
|
||||
# copyright notice, this list of conditions and the following
|
||||
# disclaimer in the documentation and/or other materials provided
|
||||
# with the distribution.
|
||||
# 3. All advertising materials mentioning features or use of this
|
||||
# software must display the following acknowledgement: This
|
||||
# product includes software developed by the AT&T.
|
||||
# 4. Neither the name of AT&T nor the names of its contributors
|
||||
# may be used to endorse or promote products derived from this
|
||||
# software without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY AT&T INTELLECTUAL PROPERTY ''AS IS'' AND
|
||||
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AT&T INTELLECTUAL PROPERTY
|
||||
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
|
||||
# OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
||||
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
||||
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
||||
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
||||
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
||||
# THE POSSIBILITY OF SUCH DAMAGE.
|
||||
#############################################################################
|
||||
#
|
||||
# bootstrap_hwdefinition.yaml - Definitions of server hardware layout
|
||||
#
|
||||
#############################################################################
|
||||
hardware_definition:
|
||||
# Name of the hardware type. This name will be used in bootstrap.yaml to refer back
|
||||
- name: HPGen8v3
|
||||
# Vendor of the server chassis
|
||||
vendor: HP
|
||||
# Generation of the chassis model
|
||||
generation: 8
|
||||
# Version of the chassis model within its generation - not version of the hardware definition
|
||||
version: 3
|
||||
# The certified version of the chassis BIOS
|
||||
bios_version: 2.2.3
|
||||
# Mode of the default boot of hardware - bios, uefi
|
||||
boot_mode: bios
|
||||
# Protocol of boot of the hardware - pxe, usb, hdd
|
||||
bootstrap_protocol: pxe
|
||||
# Which interface to use for network booting within the OOB manager, not OS device
|
||||
pxe_interface: 0
|
||||
# Map hardware addresses to aliases/roles to allow a mix of hardware configs
|
||||
# in a site to result in a consistent configuration
|
||||
device_aliases:
|
||||
pci:
|
||||
- address: pci@0000:00:03.0
|
||||
alias: prim_nic01
|
||||
# type could identify expected hardware - used for hardware manifest validation
|
||||
type: '82540EM Gigabit Ethernet Controller'
|
||||
- address: pci@0000:00:04.0
|
||||
alias: prim_nic02
|
||||
type: '82540EM Gigabit Ethernet Controller'
|
||||
scsi:
|
||||
address: scsi@2:0.0.0
|
||||
alias: primary_boot
|
||||
type: 'VBOX HARDDISK'
|
||||
|
|
@ -0,0 +1,318 @@
|
|||
---
|
||||
# BSD License
|
||||
#
|
||||
# Copyright (c) 2017, AT&T Intellectual Property. All other rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or
|
||||
# without modification, are permitted provided that the following
|
||||
# conditions are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above
|
||||
# copyright notice, this list of conditions and the following
|
||||
# disclaimer in the documentation and/or other materials provided
|
||||
# with the distribution.
|
||||
# 3. All advertising materials mentioning features or use of this
|
||||
# software must display the following acknowledgement: This
|
||||
# product includes software developed by the AT&T.
|
||||
# 4. Neither the name of AT&T nor the names of its contributors
|
||||
# may be used to endorse or promote products derived from this
|
||||
# software without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY AT&T INTELLECTUAL PROPERTY ''AS IS'' AND
|
||||
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AT&T INTELLECTUAL PROPERTY
|
||||
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
|
||||
# OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
||||
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
||||
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
||||
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
||||
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
||||
# THE POSSIBILITY OF SUCH DAMAGE.
|
||||
####################
|
||||
#
|
||||
# bootstrap_seed.yaml - Site server design definition for physical layer
|
||||
#
|
||||
####################
|
||||
site_name: sitename
|
||||
network:
|
||||
# Describe layer 1 attributes. Primary key is 'name'. These settings will
|
||||
# generally be things the switch and server have to agree on
|
||||
links:
|
||||
- name: oob
|
||||
bonding:
|
||||
mode: none
|
||||
mtu: 1500
|
||||
linkspeed: 100full
|
||||
trunking:
|
||||
mode: none
|
||||
default_network: oob
|
||||
# pxe is a bit of 'magic' indicating the link config used when PXE booting
|
||||
# a node. All other links indicate network configs applied when the node
|
||||
# is deployed.
|
||||
- name: pxe
|
||||
bonding:
|
||||
mode: none
|
||||
mtu: 1500
|
||||
linkspeed: auto
|
||||
# Is this link supporting multiple layer 2 networks?
|
||||
# none is a port-based VLAN identified by default_network
|
||||
# tagged is is using 802.1q VLAN tagging. Untagged packets will default to default_netwokr
|
||||
trunking:
|
||||
mode: none
|
||||
# use name, will translate to VLAN ID
|
||||
default_network: pxe
|
||||
- name: gp
|
||||
# If this link is a bond of physical links, how is it configured
|
||||
# 802.3ad
|
||||
# active-backup
|
||||
# balance-rr
|
||||
# Can add support for others down the road
|
||||
bonding:
|
||||
mode: 802.3ad
|
||||
# For LACP (802.3ad) xmit hashing policy: layer2, layer2+3, layer3+4, encap3+4
|
||||
hash: layer3+4
|
||||
# 802.3ad specific options
|
||||
peer_rate: slow
|
||||
mon_rate: default
|
||||
up_delay: default
|
||||
down_delay: default
|
||||
mtu: 9000
|
||||
linkspeed: auto
|
||||
# Is this link supporting multiple layer 2 networks?
|
||||
trunking:
|
||||
mode: tagged
|
||||
default_network: mgmt
|
||||
# Describe layer 2/3 attributes. Primary key is 'name'
|
||||
networks:
|
||||
- name: oob
|
||||
allocation: static
|
||||
cidr: 172.16.100.0/24
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.100.15
|
||||
end: 172.16.100.254
|
||||
dns:
|
||||
domain: ilo.sitename.att.com
|
||||
servers:
|
||||
- name: pxe
|
||||
# Layer 2 VLAN segment id, could support other segmentations. Optional
|
||||
vlan_id: 99
|
||||
# How are addresses assigned?
|
||||
allocation: dhcp
|
||||
# MTU for this VLAN interface, if not specified it will be inherited from the link
|
||||
mtu: 1500
|
||||
# Network address
|
||||
cidr: 172.16.0.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: dhcp
|
||||
start: 172.16.0.5
|
||||
end: 172.16.0.254
|
||||
# DNS settings for this network
|
||||
dns:
|
||||
# Domain addresses on this network will be registered under
|
||||
domain:
|
||||
# DNS servers that a server using this network as its default gateway should use
|
||||
servers:
|
||||
- name: mgmt
|
||||
vlan_id: 100
|
||||
# How are addresses assigned?
|
||||
allocation: static
|
||||
# Allow MTU to be inherited from link the network rides on
|
||||
mtu: 1500
|
||||
# Network address
|
||||
cidr: 172.16.1.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.1.15
|
||||
end: 172.16.1.254
|
||||
# Static routes to be added for this network
|
||||
routes:
|
||||
- subnet: 0.0.0.0/0
|
||||
# A blank gateway would leave to a static route specifying
|
||||
# only the interface as a source
|
||||
gateway: 172.16.1.1
|
||||
weight: 10
|
||||
# DNS settings for this network
|
||||
dns:
|
||||
# Domain addresses on this network will be registered under
|
||||
domain: mgmt.sitename.example.com
|
||||
# DNS servers that a server using this network as its default gateway should use
|
||||
servers: 172.16.1.9,172.16.1.10
|
||||
- name: private
|
||||
vlan_id: 101
|
||||
allocation: static
|
||||
mtu: 9000
|
||||
cidr: 172.16.2.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
# Type can be reserved (not used for baremetal), static (all explicit
|
||||
# assignments should fall here), dhcp (will be used by a DHCP server on this network)
|
||||
- type: static
|
||||
start: 172.16.2.15
|
||||
end: 172.16.2.254
|
||||
dns:
|
||||
domain: priv.sitename.example.com
|
||||
servers: 172.16.2.9,172.16.2.10
|
||||
- name: public
|
||||
vlan_id: 102
|
||||
# How are addresses assigned?
|
||||
allocation: static
|
||||
# MTU size for the VLAN interface
|
||||
mtu: 1500
|
||||
cidr: 172.16.3.0/24
|
||||
# Desribe IP address ranges
|
||||
ranges:
|
||||
- type: static
|
||||
start: 172.16.3.15
|
||||
end: 172.16.3.254
|
||||
routes:
|
||||
- subnet: 0.0.0.0/0
|
||||
- gateway: 172.16.3.1
|
||||
- weight: 9
|
||||
dns:
|
||||
domain: sitename.example.com
|
||||
servers: 8.8.8.8
|
||||
host_profiles:
|
||||
# No magic to this host_profile, it just provides a way to specify
|
||||
# sitewide settings. If it is absent from a node's inheritance chain
|
||||
# then these values will NOT be applied
|
||||
- name: defaults
|
||||
# OOB (iLO, iDRAC, etc...) settings. Should prefer open standards such
|
||||
# as IPMI over vender-specific when possible.
|
||||
oob:
|
||||
type: ipmi
|
||||
# OOB networking should be preconfigured, but we can include a network
|
||||
# definition for validation or enhancement (DNS registration)
|
||||
network: oob
|
||||
account: admin
|
||||
credential: admin
|
||||
# Specify storage layout of base OS. Ceph out of scope
|
||||
storage:
|
||||
# How storage should be carved up: lvm (logical volumes), flat
|
||||
# (single partition)
|
||||
layout: lvm
|
||||
# Info specific to the boot and root disk/partitions
|
||||
bootdisk:
|
||||
# Device will specify an alias defined in hwdefinition.yaml
|
||||
device: primary_boot
|
||||
# For LVM, the size of the partition added to VG as a PV
|
||||
# For flat, the size of the partition formatted as ext4
|
||||
root_size: 50g
|
||||
# The /boot partition. If not specified, /boot will in root
|
||||
boot_size: 2g
|
||||
# Info for additional partitions. Need to balance between
|
||||
# flexibility and complexity
|
||||
partitions:
|
||||
- name: logs
|
||||
device: primary_boot
|
||||
# Partition uuid if needed
|
||||
part_uuid: 84db9664-f45e-11e6-823d-080027ef795a
|
||||
size: 10g
|
||||
# Optional, can carve up unformatted block devices
|
||||
mountpoint: /var/log
|
||||
fstype: ext4
|
||||
mount_options: defaults
|
||||
# Filesystem UUID or label can be specified. UUID recommended
|
||||
fs_uuid: cdb74f1c-9e50-4e51-be1d-068b0e9ff69e
|
||||
fs_label: logs
|
||||
# Platform (Operating System) settings
|
||||
platform:
|
||||
image: ubuntu_16.04_hwe
|
||||
kernel_params: default
|
||||
# Additional metadata to apply to a node
|
||||
metadata:
|
||||
# Base URL of the introspection service - may go in curtin data
|
||||
introspection_url: http://172.16.1.10:9090
|
||||
- name: k8-node
|
||||
# host_profile inheritance allows for deduplication of common CIs
|
||||
# Inheritance is additive for CIs that are lists of multiple items
|
||||
# To remove an inherited list member, prefix the primary key value
|
||||
# with '!'.
|
||||
host_profile: defaults
|
||||
# Hardware profile will map hardware specific details to the abstract
|
||||
# names uses in the host profile as well as specify hardware specific
|
||||
# configs. A viable model should be to build a host profile without a
|
||||
# hardware_profile and then for each node inherit the host profile and
|
||||
# specify a hardware_profile to map that node's hardware to the abstract
|
||||
# settings of the host_profile
|
||||
hardware_profile: HPGen9v3
|
||||
# Network interfaces.
|
||||
interfaces:
|
||||
# Keyed on device_name
|
||||
# pxe is a special marker indicating which device should be used for pxe boot
|
||||
- device_name: pxe
|
||||
# The network link attached to this
|
||||
network_link: pxe
|
||||
# Slaves will specify aliases from hwdefinition.yaml
|
||||
slaves:
|
||||
- prim_nic01
|
||||
# Which networks will be configured on this interface
|
||||
networks:
|
||||
- name: pxe
|
||||
- device_name: bond0
|
||||
network_link: gp
|
||||
# If multiple slaves are specified, but no bonding config
|
||||
# is applied to the link, design validation will fail
|
||||
slaves:
|
||||
- prim_nic01
|
||||
- prim_nic02
|
||||
# If multiple networks are specified, but no trunking
|
||||
# config is applied to the link, design validation will fail
|
||||
networks:
|
||||
- name: mgmt
|
||||
- name: private
|
||||
metadata:
|
||||
# Explicit tag assignment
|
||||
tags:
|
||||
- 'test'
|
||||
# MaaS supports key/value pairs. Not sure of the use yet
|
||||
owner_data:
|
||||
foo: bar
|
||||
- name: k8-node-public
|
||||
host_profile: k8-node
|
||||
interfaces:
|
||||
- device_name: bond0
|
||||
networks:
|
||||
# This is additive, so adds a network to those defined in the host_profile
|
||||
# inheritance chain
|
||||
- name: public
|
||||
# Nodes represent actual servers, not just config profiles
|
||||
nodes:
|
||||
- host_profile: k8-node-public
|
||||
# the hostname for a server, could be used in multiple DNS domains to
|
||||
# represent different interfaces
|
||||
name: controller01
|
||||
interfaces:
|
||||
- device_name: bond0
|
||||
networks:
|
||||
# '!' prefix for the value of the primary key indicates a record should be removed
|
||||
- name: '!private'
|
||||
# Addresses assigned to network interfaces
|
||||
addressing:
|
||||
# Which network the address applies to. If a network appears in addressing
|
||||
# that isn't assigned to an interface, design validation will fail
|
||||
- network: pxe
|
||||
# The address assigned. Either a explicit IPv4 or IPv6 address
|
||||
# or dhcp or slaac
|
||||
address: dhcp
|
||||
- network: mgmt
|
||||
address: 172.16.1.20
|
||||
- network: public
|
||||
address: 172.16.3.20
|
||||
metadata:
|
||||
roles: os_ctl
|
||||
rack: rack01
|
||||
- host_profile: k8-node
|
||||
name: compute01
|
||||
addressing:
|
||||
- network: pxe
|
||||
address: dhcp
|
||||
- network: mgmt
|
||||
address: 172.16.1.21
|
||||
- network: private
|
||||
address: 172.16.2.21
|
||||
127
notes.md
127
notes.md
|
|
@ -1,127 +0,0 @@
|
|||
# aic-kube MaaS Orchestration #
|
||||
|
||||
## Inventory/Design Schema ##
|
||||
|
||||
Would be nice to see this get out of Git-managed flat-files and into
|
||||
an API accessible datastore that allows more fine-grained queries
|
||||
and supports inheritance/composition natively
|
||||
|
||||
### Requirements ###
|
||||
|
||||
1. Use profile inheritance to minimize data repitition
|
||||
2. Future-proof to support configuration items (CIs) we consider static today
|
||||
3. Support composition to allow federated source of truth
|
||||
|
||||
### Components ###
|
||||
|
||||
#### bootstrap_seed.yaml ####
|
||||
|
||||
Probably needs renamed, but I see this as being the Formation data
|
||||
that specifies explicit values - hostnames, IP address assignments,
|
||||
VLAN IDs, etc...
|
||||
|
||||
#### bootstrap_hwdefinition.yaml ####
|
||||
|
||||
Looks to be mainly focused on initial OOB control and getting a server
|
||||
into PXE mode. Should be able to leave as-is and adopt existing
|
||||
Apollo logic for IPMI.
|
||||
|
||||
#### bootstrap_profiles.yaml ####
|
||||
|
||||
Currently doesn't exist, but I think it makes sense to separate the
|
||||
data that describes the design (like general profiles) from the data
|
||||
that ties the design to explicit assignments (i.e. Formation data)
|
||||
|
||||
### Questions/Issues ###
|
||||
|
||||
* Need DNS specs in YAML - where to include it, possibly per network
|
||||
making it effective when that network is chosen as "primary"
|
||||
* Can set comma-delimited list of DNS servers per subnet
|
||||
* Consider YAML pointers and anchors to diminish how much inheritance
|
||||
has to be calculated in code
|
||||
* Does not appear to support key subtraction
|
||||
* No way to merge hashes based on a 'primary' key
|
||||
* Scott thinks best to keep with managing inheritance in code. Can minimize
|
||||
magic via comments in YAML
|
||||
* Best way of specifying hardware paths (eth0 may not be consistent across boots)
|
||||
* PCI bus address
|
||||
* For NIC lshw should tie a PCI address to a MAC (serial number) and logical
|
||||
name (eth0)
|
||||
* MaaS API is keyed to logical name
|
||||
* SCSI bus address
|
||||
* How to specify custom hardware drivers
|
||||
* OOB config - /etc/maas/drivers.yaml specify the suite of drivers available
|
||||
to MaaS outside what is built into the streams. MaaS will automatically
|
||||
consume a driver when it detects hardware that needs it. This config is not
|
||||
API accessible.
|
||||
* Expound on storage, at least specifying primary boot drive
|
||||
|
||||
## Orchestrator Service Fabric ##
|
||||
|
||||
Consider Go over Python considering performance differences, concurrency support
|
||||
and ease of deploying static binaries.
|
||||
|
||||
### Requirements ###
|
||||
|
||||
1. Make interfaces at both ends pluggable
|
||||
2. Support metadata API for node introspection
|
||||
3. Support future addition of network and storage orchestration
|
||||
|
||||
### Services ###
|
||||
|
||||
#### Design Consumer ####
|
||||
|
||||
Pluggable service to ingest a inventory/design specification, convert it to a standard
|
||||
internal representaion, and persist it to the Design State API. Initial implementation
|
||||
is the consumer of AIC YAML schema.
|
||||
|
||||
#### Design State API ####
|
||||
|
||||
API for querying and updating the current design specification and persisted orchestration status.
|
||||
CRUD support of CIs that are not bootstrap-related, but can be used by other automation.
|
||||
|
||||
#### Control API ####
|
||||
|
||||
User-approachable API for initiating orchestration actions or accessing other internal
|
||||
APIs
|
||||
|
||||
#### Infrastructure Orchestrator ####
|
||||
|
||||
Handle validation of complete design, ordering and managing downstream API calls for hardware
|
||||
provisioning/bootstrapping
|
||||
|
||||
#### Server Driver ####
|
||||
|
||||
Pluggable provisioner for server bootstrapping. Initial implementation is MaaS client.
|
||||
|
||||
#### Network Driver ####
|
||||
|
||||
Pluggable provisioner for network provisioning. Initial implementation is Noop.
|
||||
|
||||
#### Introspection API ####
|
||||
|
||||
API for bootstrapping nodes to load self data. Possibly pluggable as this is basically an
|
||||
authenticated bridge to the Design State API
|
||||
|
||||
### Questions ###
|
||||
|
||||
1. Should this drive the MaaS configuration or only drive node deployment?
|
||||
2. What do we need commissioning scripts for?
|
||||
* Firmware updates
|
||||
* Hardware RAID configs
|
||||
* Hardware manifest validation (as designed/as built)
|
||||
3.
|
||||
|
||||
## Resources ##
|
||||
|
||||
* [MaaS Node Deployment](https://insights.ubuntu.com/2016/01/23/maas-setup-deploying-openstack-on-maas-1-9-with-juju/)
|
||||
* [MaaS Network Provisioning](https://insights.ubuntu.com/2016/01/31/nodes-networking-deploying-openstack-on-maas-1-9-with-juju/)
|
||||
* [Custom Curtin Scripts](http://caribou.kamikamamak.com/2015/06/26/custom-partitioning-with-maas-and-curtin-2/)
|
||||
* [curtin_userdata for bootstrapping K8](https://gist.github.com/aric49/4d424929346e7fbb3ddbd87c7a49ba67)
|
||||
* [YAML anchors and pointers](http://blog.daemonl.com/2016/02/yaml.html)
|
||||
* [YAML Wikipedia](https://en.wikipedia.org/wiki/YAML)
|
||||
* [MaaS 3rd Party Drivers](http://people.canonical.com/~jlane/third-party-drivers.html)
|
||||
* [MaaS API Spec](https://maas.ubuntu.com/docs2.0/api.html)
|
||||
* [VMware Go IPMI](https://github.com/vmware/goipmi)
|
||||
|
||||
|
||||
Loading…
Reference in New Issue