►
From YouTube: Deep Dive on Ignition Andrew Jeddeloh & Brian Redbeard Harrington Red Hat OpenShift Commons Briefing
Description
Deep Dive on Ignition
Andrew Jeddeloh and Brian Redbread Harrington (Red Hat)
August 28, 2019 - OpenShift Commons Briefing
Ignition is a low-level system configuration utility. The Ignition executable is part of the temporary initial root filesystem, the initramfs. When Ignition runs, it finds configuration data in a named location for a given environment, such as a file or URL, and applies it to the machine before switch_root is called to pivot to the machine’s root filesystem.
Ignition is used by CoreOS to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration. https://github.com/coreos/ignition/
August 28 2019
OpenShift Commons Briefing
A
B
C
B
So
you
know
kind
of
jumping
into
this
year.
We're
gonna
go
over
a
whole
bunch
of
stuff
kind
of
talking
about
what
it
is
why
it's
interesting,
why
we
built
it
at
core
OS
and
kind
of
get
into
the
the
meat
of
how
you
actually
need
to
utilize
it
to
get
things
done.
One
of
the
things
that
you
know,
I
guess
is
a
great
spot
to
start
on
here
and
talking
about
what
is
ignition
and
what
it
is.
B
What
ignition
is
not
you
know
so,
ignition,
first
and
foremost,
you
know
we're
gonna
be
talking
about
it
exclusively
here
we're
not
going
to
be
talking
about
it
exclusively
in
the
context
of
open
shift.
You
know
it's
a
enabling
technology
within
rel
core,
oh
s,
open
shift,
manages
indirectly
a
series
of
kind
of
ignition
configs
and
that's
kind
of
why
this
becomes
important.
At
the
same
time,
this
is
going
to
be
generally
useful
to
folks
who
become
interested
in
Fedora
core
OS,
and
you
know
other
kind
of
distros
should
they
choose
to
adopt
ignition.
B
So
what
it
is
primarily
is
it's
designed
for
the
bring
up
of
a
host
and
it
executes
on
the
first
boot.
You
know
for
a
lot
of
users
who
come
from
the
cloud
config
world,
you
know
working
on
various
public
cloud
providers.
You
know
you're
used
to
you
put
in
a
configuration
and
it
kind
of
will
reacts
acute
every
single
time.
You
load
the
host
based
on
the
contents
of
the
user
metadata
and
the
ignition
does
not
work
that
way.
It
is
really
just
there
as
a
first
boot
tool
and
it
is
destroyed
Gnostic.
B
B
You
know
there
is
the
ability
to
put
things
in
there
that
are
much
more
nuanced
and
we'll
dive
into
some
of
those
details
here
in
a
little
bit,
but
suffice
it
to
say
that
you
know
all
of
these
initiatives
is
something
that
evolved
over
time
through
first-hand
learned
experience
of
running
lots
of
rel
and
Debian
and
container
Linux
systems
and
then
figuring
out
how
we
wanted
to
proceed
from
there.
You
know
it's
intended
as
a
declarative
mechanism.
B
B
It's,
not
a
turing-complete
mechanism,
so
you're
not
going
to
use
this
and
like
write
programs
or
have
loops
or
anything
in
it.
You
know
it
is
just
a
figuration
syntax
and
it's
intentionally
not
turn
complete
to
avoid
lots
of
Lang,
SEC
type
bugs
and
things
like
that,
and
it
operates
at
a
low
level.
You
know
there
are
just
the
primitives
there
to
get
things
done
and
then
you
know
we
have.
We
acquire
OS
and
Red.
B
B
C
Guess:
okay,
and
as
a
note
on
that,
the
one
of
like
ignitions
mantras
is:
it
should
give
you
the
system
that
you
asked
for,
or
it
should
give
you
nothing
at
all.
It
should
never
give
you
a
like
partially
configured
system.
So
if
your
system
comes
up,
you
know
that
it
has
the
state
that
you
described
yep.
B
So
ignition
is
not
a
configuration
management
system,
it's
not
chef
or
puppet
or
ansible.
It
is
just
there
to
bootstrap
the
host,
so
you're,
not
going
to
you
know,
decide
that
you
need
to
change
the
configuration
later
after.
The
host
has
been
up
for
three
weeks.
You
know
if
you
need
to
make
mutations
to
the
host,
then
go
make
the
mutations
of
the
host,
but
ignition
has
nothing
to
do
with
that,
and
it
is
not
an
installer
like
anaconda.
You
can
use
it
to
build
an
installer.
B
You
know
you
could
have
anaconda
do
something
where
it
rendered.
Your
I
should
say
the
front-end
anaconda
rendered
an
ignition
sequence
and
then
executed
it,
but
we
didn't
want.
We
explicitly
didn't
want
it
to
be
something
where
we
were
shipping
an
installer
on
every
single
host.
You
know
we
wanted
it
to
be
something
that
was
a
very
basic
mechanism
for
bootstrapping
and
kind
of
building
the
distributed
systems
that
you
were
trying
to
get
to
so
at
core
OS.
It
was
specifically
started
by
two
gentlemen,
a
guy
named
Vito,
Caputo
and
Alex
Crawford.
B
It's
now
is
maintained
by
the
platform
engineering
team,
specifically
the
core
OS
tools,
team
at
Red
Hat.
So
in
the
context
of
what
it
can
do,
it
is
all
of
the
basic
things
that
you
would
need
to
kind
of
bring
up
and
I
understand
that
I
keep
saying
the
the
phrase
like
use
it
to
bring
up
a
host
or
bootstrap
a
host.
But
when
you
think
about
the
opinionated
way
that
core
OS
has
done
things,
you
know
for
anybody,
who's
used,
OpenShift
v4.
B
B
We
felt
that
we
wanted
to
have
the
mechanism
that
could
do
all
of
that
setup,
but
also
was
free
enough
to
kind
of
configure
anything
else.
So
you
know,
hypothetically
being
able
to
use
the
same
configuration
mechanism
to
bootstrap
kubernetes
as
well
as
bootstrapping
hosts
for
running
Apache,
asos
or
running
OpenStack.
You
know
it's
it's
kind
of
intended
to
be
very
generic
in
what
it
can
do.
So
you.
B
That's
the
set
up
of
disks,
you
know
wiping
partition
tables
or
kind
of
making
new
file
systems
kind
of
handling,
the
basic
user
and
group
creation
laying
down
files
on
the
file
system.
You
know
these
are
all
things
that
were
first
order
kind
of
very
important
components
to
be
included
where
it
begins
to
differ.
A
little
bit,
though,
is
that
it
understands
how
to
both
do
the
normal
things
of
like
loading,
its
configuration
from
disk
or
from
cloud
metadata,
but
in
the
case
of
specific
hypervisors
like
vmware,
you
know
qemu,
etc.
B
Another
kind
of
key
decision
that
we
ran
into
after
working
with
the
immutability
of
auto-scaling
groups
on
AWS
was
that
we
wanted
to
make
sure
that
you
could
chain
load
and
merge
other
ignition
configs.
So
you
can
take
a
data
URI.
You
know
of
either
kind
of
embedding
data
in
line
to
include
more
ignition
content,
to
be
able
to
merge
that
in
or
being
able
to
reference
a
different
network
endpoint
to
be
able
to
load
the
config.
B
So
you
could
imagine
you
know
having
a
stub
config
in
stop
ignition
config
that
you
boot
cloud
provider
hosts
from
that
then
chain
loads
across
to
your
configuration
servers
so
that
you
could
endow
identity
over
time
as
you
recycle
those
hosts,
etc,
and
it
can
even
kind
of
handle
varying
versions
of
ignition
configs
kind
of
including
pulling
in
newer
versions
and
I'll.
Let
Andrew
speech
of
that
yeah.
B
C
B
So
getting
into
the
question
of
why
it
exists,
you
know,
I
can
tell
you
that
the
second
week
that
I
worked
at
core
OS.
You
know
all
of
us
went
out
to
Lake,
Tahoe
and
locked
ourselves
in
a
cabin
for
a
week
to
push
out
the
the
first
major
set
of
improvements
to
core
OS,
which
later
became
container
Linux
and
I
was
standing
on
a
table
yelling
about
how
I
didn't
want
to
have
different
configuration.
B
Domain-Specific
languages
for
cloud
for
physical
machines
or
machines
running
on
a
cloud
provider
like
I
was
tired
of
it.
I
didn't
want
to
have
to
deal
with
like
kickstart
files
and
cloud
configs.
I
only
wanted
one
thing,
and
so
the
first
thing
that
we
did
at
core
OS
was.
We
wrote.
We
really
wrote
cloud
in
it,
which
is
the
thing
that
runs
cloud
configs
on
OpenStack
and
you
know
a
number
of
cloud
providers.
B
B
B
Why
are
you
using
your
bootstrapping
mechanism
as
configuration
management,
so
we
decided
that
you
know
we
had
to
start
over
from
scratch
and
we
needed
to
be
able
to
support
the
sorts
of
things
that
anaconda
did
and
the
sorts
of
things
that
cloud
and
it
did,
but
on
clouds
and
physical
machines.
That
was,
you
know,
still
one
of
the
guiding
principles.
So
you
know
that's
why
we
kind
of
really
envisioned
a
cloud
in
it
as
ignition
and
kind
of
started
from
there
with
this
configuration
mechanism,
so
ignition
config
are
versioned.
B
B
Configs
and
we
also
needed
to
have
a
validator,
so
you
know
we
wanted
them
to
be
versioned
so
that
we
would
be
able
to
improve
and
extend
it
over
time
while
being
much
more
clear
around
what
the
contract
was
with
backwards,
compatibility
and
then
having
the
versioning
there
with
the
validator
then
allows
us
to
actually
lint
those
link,
the
spec
and
everything
else,
much
much
much
easier,
so
I
think
at
this
point.
This
is
a
good
opportunity
to
hand
things
across
to
Andrew,
to
let
him
talk
more
about
the
configs
and
take
it
from
there.
B
C
So
the
first
thing
that
you
should
know
about
writing
ignition
configs
that
you
shouldn't
write
them.
You
should
let
other
tools
write
them
for
you.
The
configs
themselves
are
Jason,
which
was
already
kind
of
a
pain
to
write.
Things
like
inline
files
need
to
be
URL,
encoded
or
sometimes
basically,
4
encoded
things
like
system
D
units
need
new
lines
escaped,
and
it's
generally
not
a
great
experience.
So
openshift
will
generate
them
for
rel
core
OS
for
container
Linux.
We
had
a
tool
called
the
container
Linux
config
transpiler
that
generated
them.
C
That
would
take
a
document
that
was
a
yellow
specification
and
then
translate
it
to
a
ignition
config,
and
that
also
allows
us
to
keep
ignition
still
low
level
only
primitives,
but
also
add
sugar
for
things
like
common
tasks
like
configuring,
at
CD,
for
Fedora,
core
OS,
we're
rebuilding
the
CL
CT,
but
for
fedora
core
OS
and
that's
the
FCC
T
and
the
exact
same
idea.
It's
also
a
camel
document.
C
So
this
is
just
a
outline
of
what
the
spec
looks
like
just
the
high
level
parts.
There
is
a
top
level
ignition
section.
This
is
where
we
specify
what
version
the
config
is
the
config
section
there
is,
where
you'd
specify
either.
If
you
want
to
replace
the
config
that
you're,
using
with
one
that
you'll
fetch
over
the
network
or
merge
in
additional
key
things,
there's
a
section
for
time
outs
for
if
you
want
to
change
like
the
HTTP
timeouts
for
fetching
things,
there's
a
section
for
adding
additional
certificate
authorities,
and
this
is
used
by
ignition.
C
So
if
you
need
to
fetch
a
resource
over
HTTP,
but
the
search
for
that
is
like
custom
to
your
organization,
you
can
specify
it
there.
The
storage
section
is
relatively
straightforward:
there's
a
section
for
doing
things
with
disks
like
partitioning
them:
creating
file
systems,
creating
raid
bring
files,
links
and
directories.
All
those
are
pretty
straightforward.
Systemd
units
have
their
own
section,
because
we
also
allow
special
things
for
like
enabling
or
masking
system
D
units
and
then
finally,
there's
the
password
section
for
creating
users
and
groups.
C
One
note
about
that
ignition
section
everything
there
is
just
for
ignition.
It
does
not
actually
affect
these
system
that
you're
configuring
at
all.
So
if
you
want,
if
you
need
to
add
a
CA
cert
there,
and
you
want
it
also
on
the
host
after
you're
done
configuring
it
you
need
to
specify
the
sort
in
the
ignition
section
and
also
write
out
the
cert
in
a
file
section.
A
C
Each
other
they're,
both
December,
so
there's
two
main
versions
of
ignition:
there's
the
zero
dot
X
series
and
the
2.0
series.
The
zero
dot.
X
theory
supports
the
older
specs,
which
go
from
V
1
up
to
V
two
for
experimental
and
the
new
ignition
B
2
supports
the
new
spec
V
3
and
newer
versions.
You'll
note
that
there
is
no
ignition
v1
and
that
doesn't
exist
because
of
go
semantic
imports
where
it'll
treat
V,
0
and
V
1
is
the
same
import
path.
So
you
can't
import
the
same
UK.
C
C
C
One
big
note
is
the
older
configs,
the
v1
through
v4
experimental
and
the
new,
the
3
configs
are
not
compatible.
There
were
some
bugs
in
the
configure
specification
that
were
not
fixable
without
a
compatibility
break
so
right
now,
rel,
core
OS
and
OpenShift
use
the
old
version,
but
those
will
move
to
v2,
v3
and
Fedora
core
or
less
started
off
with.
B
V3
and
that's
actually
a
good
area
to
just
kind
of
reinforce
what
Andrew
mentioned
earlier
is
that
you
know.
That's
also
why
we
wrote
the
tools
like
CL,
CT
and
FC
CT,
because
they
are
intended
to
kind
of
mask
some
of
these
annoyances
to
make
it
so
that
you
don't
get
caught
up
as
much
in
like
the
nuances
of
a
giant
blob
of
metadata
sitting
in
a
JSON
file.
C
The
container
linux
configs
are
mostly
additive
on
the
ignition
config
just
in
yeah
Mille,
so
this
yeah
Moe,
you
can
imagine,
could
be
transcribed
into
equivalent
JSON
and
all
this
does
is
add
an
SSH
key
for
the
core
user
and
adds
a
user
the
Herrington
and
has
an
SSH
key
for
them
as
well,
and
one
thing
you'll
notice
is
missing
from
this
container.
Linux.
Config
is
a
variant.
So
since
this
is
just
using
the
ignition
parts,
this
is
actually
relatively
portable.
C
You
could
use
it
for
our
cost
or
container
linux,
but
if
you
specify
this
variant
in
version,
that
doesn't
actually
mean
anything.
It
has
no
concept
of
a
variant
and
the
only
supported
version
is
version
zero,
and
we
just
put
that
in
there
as
a
way
to
reserve
the
keyword
to
make
sure
people
weren't
using
it-
and
this
was
largely
a
mistake-
see
you
do
that
with
container
Linux
configs
so
now
show
you
a
brief
demo.
C
C
So
I'm
in
the
400s
SDK
here
and
I'm,
going
to
use
this
tool
called
Cola
and
cool,
is
our
testing
tool
for
the
various
courses
and
it
has
a
sub-grant
spawn
and
what
this
is
doing
is
generating
an
SSH
key
pair
and
generating
an
ignition
config
that
adds
the
public
key
to
the
authorized
keys
file
and
then
logs
in
over
SSH
with
it,
and
if
I
go
and
look
at
the
ignition
config
it
used.
I
need
to
look
at
it.
C
C
C
So
as
another
example,
this
is
for
Fedora
core
OS.
This
is
a
fedora
core,
OS
config
you'll
notice
that
there
is
the
variant
end
version
this
time
we
did
not
make
the
same
mistake
twice
and
I'll
dive
into
exactly
what
this
config
does
in
a
sec
thought
to
look
at
what
this
would
be
rendered
into.
You
run
it
through
FC
CT.
You
get
an
equivalent
blob
of
JSON,
so
this
is
pretty
much
the
same.
C
It's
not
that's
not
always
the
case
because
I
see
CC
FCC's
can
add
sugar
for
things
and
you'll
know.
Also.
The
version
is
not
the
same.
If
I
go
back.
You'll
know
this
is
version
1.
This
is
version
3
they're,
not
the
same,
but
every
FCC
version
maps
to
a
mission
version,
so
it'll
always
deterministically,
give
you
the
same
config
and
so
every
FCC,
that's
version.
1
will
always
generate
a
version.
3
config.
C
If
we
dive
into
what
exactly
that
looks
like
there's
really
three
parts,
there's
a
part
here
where
we
are
saying
the
device
dev
vda
should
have
a
partition,
number
5,
the
label
VAR
and
the
certain
size
r0,
and
these
are
actually
special
values.
Start
zero
means
find
the
start
of
the
largest
block
of
available
space
on
disk
and
size.
Zero
means
use
as
much
as
possible,
so
this
just
creates
the
largest
partition
possible
on
a
disk.
Now.
B
C
V3
actually
only
supports
the
lining
on
megabytes,
so
everything
is
aligned
automatically,
and
you
also
don't
need
to
specify
like
partitions
that
are
already
there
you're
just
specifying
like
what
you
want
on
the
system.
So
next
there's
we
say
that
there
should
be
a
file
system
should
be
XFS.
It
should
be
on
that
partition.
We
just
created.
C
B
C
So
if
I
run
this,
it's
gonna
take
it
home
and
and
this
is
actually
running
in
a
container
as
well.
So
if
you
notice
I
passed
in
the
ignition
config
as
/sr
v,
/
demo
dognition,
because
that's
where
it's
getting
mounted
into
the
container.
So
now
we're
going
through
the
boot
process-
and
this
is
just
on
the
console
and.
C
C
There
you
can
see,
it's
got
a
bunch
of
other
stuff,
we
didn't
specify
as
well,
so
it
has
everything
we
specified
like
the
the
disk
with
the
partition,
but
it
also
has
this
these
other
files
and
the
data
URIs,
which
are
one
of
the
things
that
we
mentioned
in
the
beginning,
yeah.
So
this
writing
to
the
bachelor,
see
we're
appending
this
and
we
didn't
don't
know
what
this
is,
because
this
is
a
basic
ste,
4
encoded.
Look
at
that.
C
If
we
wanted,
but
what's
actually
happening
here,
is
when
I
ran
that
when
I
ran
this
the
tool
is
using
to
run
it
actually
embeds
the
config
that
you've
specified
as
a
merged
config
into
a
base.
Config
that
does
things
like
turns
on
some
things,
for
your
terminal
set
some
auto
log-in
like
that's
what
this
is
here,
all
the
things
that
you
need
specifically
to
do:
development
for
yes,
the
operating
system
and
I
can
actually
look
at
the.
C
And
so,
if
we
look
at
what
we
actually
did
here,
so
this
is
mostly
a
normal
Linux
boot
process.
Where
you
have
you
know
your
firmware
load,
your
bootloader,
this
might
be
yes,
the
efi
or
bios
or
device
tree
blob,
and
then
that
loads,
the
kernel
and
in
it
our
amethyst
and
that
might
be
grub,
might
be
your
bootloader
I.
B
Mean
to
also
to
clarify
on
that
you
know
everything
that
we
are
working
on
is
all
focused
around
grub.
You
know
the
the
you
boot
and
mentions
of
device
tree
blob
are
there,
you
know
talking
more
aspirationally
around
you
know
showing
how
other
distros
or
other
chip
architectures
could
utilize
this
in
a
very
similar
way,
because,
ultimately,
that's
all
the
set
up
before
we
get
to
the
things
that
ignition
really
cares
about.
Yeah.
C
And
then
kernel
will
unpack
the
Rama
fests,
and
this
will
run
the
init
program
from
the
integrand
fest
if
you're
not
familiar
with
init
Rama,
fesses
they're,
basically
a
root
filesystem
that
gets
bundled
with
your
kernel
that
is
used
typically
to
find
the
device
and
set
up
the
device
that
contains
the
root
of
s.
So
that
can
be
mounted.
And
then
you
switch
root
into
your
real
root
on
disk.
C
Theft
that
mounts
the
real
root
to
slash
this
route
and
then
switches
route
in
there.
And
when
you
do
that
switch
route,
you
exec
your
real
init
program
and
that's
just
a
regular
exact,
not
a
fork
and
exec,
and
so
you're.
A
real
roots
in
a
program
replaces
the
inner
program,
I'm
from
the
integrand
fess
and
so.
B
C
And
we
actually
have
the
ignition
specific
bracket
modules
for
pulling
the
ignition
into
your
inner
grandma
fests,
if
you're
using
bracket
split
out
from
the
elec
fedora
for
less
specific
ones.
So
you
can
pull
in
ignition
that
way,
there
might
be
some
work.
You
need
to
do
to
get
it
like
working
with
your
specific
distro
button,
and
if
we
dive
into
more
how
ignition
works,
it
has
two
main
stages.
The
first
one
is
disks,
and
this
is
everything
that
needs
to
happen
before
you
mount
the
root
of
s.
C
A
C
Root
of
s
and
optionally
other
file
systems
you've
specified,
and
this
is
where
we
do
things
like:
create
users
and
groups,
create
files
system,
D
units,
etc
and
then
new
with
ignition,
the
tubes
or
the
v3
spec.
There's
also,
these
two
stages
mount
and
unmount
the
mount
stage
it
bounced
all
of
those
file
systems
you
specified.
So
in
our
example,
we
had
the
VAR
file
system.
C
So
that's
where
that
gets
mounted
and
then
afterwards,
after
the
file
stage,
runs,
we
actually
unmount
it
and
that's
really
important,
because
we
want
to
make
sure
the
first
boot
doesn't
succeed
just
because
ignition
Ram.
We
want
to
ensure
that
the
first
boot
is
representative
of
all
of
the
subsequent
boots.
You
don't
get
a
system
that
worked
on
first
boot
and
then
you
go
to
reboot
and
then
it
fails.
C
C
A
B
You
know
I
think
that
right
now,
especially
since
they're
still
kind
of
getting
OS
p16
ready,
which
is
gonna,
be
the
next
LTS
release,
they're,
probably
which
I
remember
correctly-
shipping
early
next
year,
they're,
probably
still
in
flight
with
all
of
their
existing
processes.
I
think
more
interesting
to
that
is
when
ignition
was
going
to
be
available.
If
it
was
going
to
be
available
in
one
of
the
rel
like.
C
Rel
classic
yeah
I,
don't
know
about
that,
but
with
regard
to
OpenStack
ignition
already
supports
OpenStack.
If
use
OpenStack
like
a
cloud
and
so
OpenStack
is
like
two
main
ways
of
passing
in
a
config,
you
can
either
do
it
over
network
or
via
a
virtual
disk
device,
and
ignition
actually
supports
both
so
yeah.
Oh
all,
a
like
cloud
provider
or
hypervisor,
or
anything
like
that
needs
to
support
ignition
is
just
a
way
of
handing
us
the
config
there's,
there's
no
other
interaction
between
the
cloud
or
hypervisor
and
ignition
yeah.
C
B
A
All
right,
I,
think
that's
that
was
part
of
the
question
was
the
role
ignition
would
play
and
when
and
so
I
think
you've
answered
that
quite
nicely.
So
another
win
question
that
I
have
and
I
don't
know
if
you
have
any
insights
in
it,
but
what
timeline
will
open
shift
be
moving
to
v3
of
the
ignition?
Do
you
have
any
ideas
or
thoughts
about
that?
I.
A
Okay,
but
it
is
in
the
timeline-
and
it's
probably
sitting
somewhere
in
some
Trello
roadmap
document
that
we
can
dig
out
here
somewhere,
yeah,
okay,
I,
didn't
I
knew
that
I'd
heard
it,
and
you
know
it
came
out
as
part
of
the
conversations
around
ok,
d44
Oh
as
well.
So
that's
it
so
I'm.
Looking
looking
in
the
chat
now,
there's
a
whole
bunch
of
you
on
there
being
very
quiet.
A
C
Container
linux
support
it
like
the
only
way
to
configure
you're,
not
working
on
container
or
linux
was
via
network
D
and,
as
ignition
initially
started
out
for
container
Linux,
we
had
special
keywords
to
support
that
with
Fedora
core
OS.
We
actually
removed
that
because
a
fedora,
four
or
less
does
not
support
network
D.
Instead,
you
should
be
using
network
manager
and
also
everything
that
the
network
D
section
was
doing
was
just
writing
files
that
can
be
done
in
the
file
section.
C
B
I
mean
I
would
say
there
is
not
the
differences
between
the
configs
and
the
config.
Syntax
is
far
far
far
outweighed
by
the
similarities.
You
know,
I
can
say.
I
mostly
got
hung
up
in
some
of
the
early
archives
testing,
because
I
was
able
to
just
literally
take
vanilla,
ancient
ancient
container,
Linux
configs
and
run
them
through
a
validator,
and
they
would
work
now.
B
Ultimately,
then,
what
happened
was
having
the
kind
of
very
basic
configs
that
I
wanted
to
use
and
running
those
through
the
updated
config
transpilers
took
care
of
the
lion's
share
of
what
I
needed,
and
you
know,
even
when
I
then
had
my
our
cause
configs,
that
I
started
using
with
Fedora
core
OS.
You
know
which
used
a
different
version.
It
was
mainly
okay,
just
take
it.
I
have
to
go,
grab,
FCC
tea
and
then
run
it
through
FCC
tea,
and
it
warns
me:
hey
I
see
a
couple
issues.
B
You
know
you're,
obviously
trying
to
do
this
other
thing,
and
you
intend
to
do
this
so
tweak
X,
Y,
&
Z,
and
that
was
the
kind
of
sugar
or
part
of
the
sugar
that
Andrew
was
talking
about
earlier,
because
having
the
config
transpilers
made
that
transition
much
much
easier.
So
you
know,
while
it's
going
to
require
testing
on
our
part,
and
it's
going
to
require
new
effort
from
the
core
OS
engineering
team.
C
To
add
on
to
that,
most
of
the
issues
like
where
they
are
incompatible
are
from
places
where
people
are
doing
weird
things
with
ignition
configs
and
exploiting
the
the
like
bugs
in
the
spec.
So
ignition
like
we
say
that
the
ignition
config
should
be
declarative,
but
there's
parts
of
the
v2
config
that
are
not
declarative,
like
it's
possible
to
specify
that
something
should
be
both
a
file
like
a
passion,
be
both
a
file
in
a
directory,
and
what
actually
happens
there
is
that's
the
the
behavior.
C
There
is
determined
by
the
fact
that
ignition
happens
to
create
directories
before
files,
and
then
the
file
can
overwrite
the
directory.
But
what
really
should
be
happening?
There
is
the
ignition
validator
or
your
FCC.
T
validator
should
be
yelling
at
you
saying
this
isn't
possible.
You
know
you're
you're,
doing
something,
you're
saying
that
one
thing
should
be
two
different
things:
I
can't
do
that.
A
That
sounds
like
it
answered
everybody's
questions
too.
So
it's
good
and
as
the
Chara
says,
he
doesn't
mind
doing
a
bit
of
hacking
early
on
and
I.
Think
all
of
us
expect
a
bit
of
that
I
had
a
question
and
I
don't
see
any
other
questions
in
the
chat,
so
I'm
doing
pretty
good,
but
I
had
one
more
question
for
you
guys
working
on
ignition.
You
keep
talking
about
it
being
done
by
all
the
work
being
done
by
the
core
OS
team.
Is
there
any
way
that
other
people
can
get
involved
and
working
on
this?
A
B
Thing
that
I
will
mention
is
you
know,
of
course,
Diane
we're
gonna
pass
the
slides
to
you
and
all
of
the
slides
there
on
that
question.
Section
have
links
to
the
upstream
repositories
and
the
validators
and
everything
else.
So
you
know
there
are
open
source
projects
and
you
know
we
love
to
have
a
contribution
from
the
community
I'll.
Let
Andrew
speak
more
specifics
and
tactical
portions,
so.
C
C
For
the
actual
ignition
binary,
which
is
github.com,
slash,
core
OS,
/,
ignition,
yep
and
I'll
be
linked
in
the
slides
when
we
send
this
out
and
then
the
other
is
ignition
bracket.
Github.Com
/,
coral
s,
/
ignition
bracket,
that's
where
we
keep
all
the
drackett
modules
that
support
ignition
being
able
to
run
in
the
intagram
of
s.
Both
of
those
also
have
two
branches.
C
The
master
branch
is
for
the
new
ignition
v
to
inspect
v3
and
then
there's
a
spec
2x
branch
for
the
older
version
and
the
older
spec,
because
those
are
maintained
both
for
our
costs
and
for
container
Linux.
So
if
you
go
check
them
out,
just
make
sure
that
you're
looking
at
the
right
branch
for
what
you
want
to
contribute
to
our.
A
C
So
that's
something
that
actually
should
live
in
the
Fedora
core
LS
config
transpiler,
because
that
is
distro
specific
and
it's
sugar,
because
ultimately,
what
you
do
to
configure
network
manager
is
write
files.
And
so
that's
something
where
the
Fedora
core
OS
config
transpiler,
should
support
a
easier
format
and
possibly
even
support
validating
that,
depending
on
technical
questions
there,
but
and
then
generate
those
network
manager.
Configs
for
you.
A
B
It's
something
that
actually
it's
kind
of
like
you
could
make
something
that
translated
an
ignition
sequence
into
kickstart,
but
not
really
going
the
other
way.
You
know
it's
largely
if
you
I,
guess
yeah
a
blog
post
makes
sense,
because
there's
certain
things
in
a
kickstart
file
that
you
would
just
go.
Okay,
you
don't
care
about
this,
ignore
it
other
things
that
you
know
make
sense
and
then
the
some
of
the
things
like
where
you
would
have
a
post
section.
B
So
you
would
be
able
to
say,
even
if
you
wanted
to
have
you
know
six
different
scripts,
but
all
running
in
a
specific
order
and
making
sure
that
you
know
they
come
up
after
a
specific,
you
know,
mount
point
has
happened
or
a
specific
socket
is
opened.
You
know
all
of
those
mechanisms
are
going
to
be
there
and
that's
again
kind
of
why
we
did
all
of
that
in
that
way,
but
yeah
it
looks
like
we're.
Gonna
have
to
draft
somebody
and
I'm
gonna
have
to
talk
to
Ben
about
making
that
happen.
Something.
C
That
as
well,
a
kickstart
supports
some
things
that,
like
ignition,
does
not
and
will
not
support
like
things
like
configuring,
boot,
loaders
or
things
like
that.
Ignition
is
very
much
designed
for
their
operating
systems
that
follow
a
similar
model
to
container
Linux
and
the
core.
Os
is
where
you
have
a
disk
image
and
that's
up
on
the
clouds.
As
you
know,
your
ear
am
eyes
or
GCE
images
or
whatever
and
on
bare
metal.
You
also
have
that
same
or
very
slightly
modified
disk
image
that
your
install
process
is
just
DD.
C
The
image
to
disk
verbatim
and
inject
your
config
into
the
boot
file
system,
so
ignition
can
find
it
and
that
that's
how
we
unify
both
the
cloud
and
the
physical
machine
scenarios.
But
that
also
means
that,
like
there's
parts
of
that
disk
that
you're
not
allowed
to
mess
with,
like
the
bootloader,
for
example-
and
so
it's
not
quite
a
one-to-one
replacement
for
kickstart,
yeah
I,
guess
that.
B
B
David
Michael
from
the
core
OS
team
definitely
did
that
and
it
was
amazing
to
see
and
so
did,
Jesper
Zell
but
like
it
was
that's
not
how
it
was
intended.
You
know,
and
we
always
said
you
know
if
you're
looking
for
a
general-purpose,
Linux,
distro,
Red,
Hat
and
fedora
and
Debian
and
others
are
out
there,
you
know,
go,
seek
them
out
and
that
kind
of
touches
on
like
ignition
10
do
things
like
lay
down
your
VMRC
and
create
all
of
your
users
and
stuff.
B
B
A
C
Right
well,
no
ignition
doesn't
prescribe
any
like
way
of
doing
things
on
your
own
gives
you
the
tools
to
do
things.
The
way
like
those
upstream
tools
are
designed
to
be
configured
so
in
most
cases,
that's
just
writing
out
a
config
file.
So
there's
nothing
special
about
like
ignition
writing
out
at
sea.
Hostname
like
you,
you
use
ignition
to
do
the
things
you'd
normally.
C
Do
you
don't
there's
no
ignition
specific
quirks
about
like
writing
out
specific
files
or
anything
like
that,
and
so
the
short
answer
is
yes,
just
right,
it's
the
hostname,
but
the
long
answer
is:
if
your
distro
wants
you
to
configure
the
hostname
in
a
specific
way,
you
should
use
ignition
to
do
it.
The
way
your
district
wants
you
to
do
it
yeah.
B
So
you
know
if
FCC
T
or
if
Fedora
wanted
you
to
specifically
kind
of
run
hostname
CTL.
Instead
of
running
that,
you
know,
that's
the
thing
that
FCC
T
should
be
doing
so
that
you
can
just
say
my
hostname
is
you
know,
fubar
and
then
FCC
T
will
generate
the
system
D
unit
to
kind
of
take
that
and
lay
it
down
or
put
the
config
file
in
place
or
whatever
else
needed
to
happen.
Yeah.
A
A
Chuck
is
asking
if
we
can
provide
links
to
FCC,
T
and
C
LLC
T
as
well.
So
if
you
guys
can
gather
those
up,
I
will
distribute
the
recording
it
takes
about
an
hour
or
two
for
it
to
process
and
then
I
get
to
download
it
and
upload
it
again
into
YouTube.
So
we
put
all
of
these
videos
on
as
you
some
of
you
know,
on
our
H
openshift
on
YouTube
and
put
them
up.
A
I'll,
send
them
out
on
to
the
the
mailing
list
for
the
ok
D
working
group
and
for
OpenShift
commons
and
tweet,
the
heck
out
of
it,
but
you'll
see
them
soon.
I
mean,
if
there's
other
mailing
lists.
You
want
me
to
post
them
to
please
let
me
do
or
just
post
them
yourselves
cool
and
we'll.
Have
you
guys
back
I'm
sure,
because
I
think
this
is
going
to
be
something
we
as
ignition
changes
and
grows
and
matures
and
those
other
things
we're
gonna
want
to
hear
more.