►
From YouTube: Lightning Talk: CoreOS Layering Explained Colin Walters Red Hat OpenShift Commons 2022 Detroit
Description
Lightning Talk: CoreOS Layering Explained
Red Hat OpenShift Commons 2022 @ Kubecon/NA
Detroit, Michigan
October 25, 2022
Speaker: Colin Walters Red Hat
https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
https://commons.openshift.org/gatherings/kubecon-22-oct-25/
A
A
Fundamental
chain
for
what
we're
calling
for
for
about
core
OS,
so
I'm
going
to
go
fast,
but
hopefully
we'll
get
there
I'm
an
engineer
on
the
core
OS
team.
We've
been
working
on
this
for
a
number
of
years
and
I
like
to
start
every
talk
by
saying
why
I
do
what
we
do
like,
not
just
what
I'm
doing.
But
you
know
a
long
time
ago,
I
was
I
thought
technology
had
a
lot
of
promise.
A
It
was
going
to
change
the
world
in
a
lot
of
ways
and
it's
it's
happened
right
and
now
our
society
depends
on
computers
in
a
lot
of
ways.
As
you
all
know,
you
have
to
maintain
the
computers.
You
have
to
keep
them
up
to
date
and
secure,
and
that's
part
of
why
I'm
here
to
make
sure
that,
especially
with
free
and
open
source
software,
it
helps
make
sure
that
we
control
the
computers
they're,
not
controlling
us
or
being
used
against
us
so
yeah
to
understand
the
future.
A
You
know
we
kind
of
before
you
can
have
kubernetes.
You
need
a
Linux
right
and
we
we
took
a
lot
of
the
coreus
Technologies
and
we
built
all
this
stuff
up
on
it
and
I.
Think
largely
speaking,
it's
been
successful,
not
that
everything's
perfect,
but
we
made
it
work
and
you
know
I'm
very
proud
of
some
things.
You
know
how
we
use
ignition
and
I.
Think
it's
given
us
a
very
cross-cloud
experience
where
you
can
deploy
openshift
in
the
same
way
on
bare
metal
and
in
public
cloud
and
at
a
very
technical
level.
A
It
really
works
the
same
way.
So
we
can
support
it
the
same
way
and
of
course
we
created
the
openshift
machine
config
operator
and
for
those
of
you
who
are
maintaining
openshift,
especially
on
bare
metal
or
where
you
need
to
configure
things.
You've
encountered
this
right,
and
this
is
sort
of
a
key
aspect
of
everything
that
we've
built
up
for
openshift.
In
order
to
make
sure
that
you
can
click
that
cluster
upgrade
button
in
the
console
and
your
operating
system
will
be
reliably
updated.
But
it's
not
just
about
upgrades.
A
A
Just
the
VMware
Network
driver
and
made
it
a
lot
more
flaky
and
sorry
about
that
that
one
got
through
our
CCI
just
because
it
was
flaky,
it
didn't
totally
fail
and
that's
one
of
those
things
where
the
operating
system
can
feel
invisible
until
something
goes
wrong
like
that
and
takes
down
your
cluster
right
and
that's
where
you
need
to
be
in
control
and
I
like
to
talk
about
the
machine
config
operator,
oops
I
should
have
started
my
timer.
Someone
keep
me
on
track
on
time.
A
That's
where
you
need
to
be
able
to
take
control
right
and
I
like
to
think
of
the
machine
config
operator
as
and
the
autopilot
you
know,
on
an
airplane
or
a
car.
But
what
I'm
going
to
talk
about
is
how
you
can
turn
off
that
autopilot
when
you
need
to
so
yeah.
We
invented
a
lot
of
stuff,
and
one
of
the
things
that's
core
to
the
machine.
Config
operator
is
via
this
kubernetes
native,
a
crd.
A
You
can
change
your
kernel.
Arguments
with
Coupe
pedal
and
the
Machine
config
operator
takes
care
of
everything
else
right.
So,
for
example,
we
ship
with
hyper
threading
enabled
which
in
some
cases,
if
you
want
stronger
isolation,
you
do
need
to
turn
that
off
and
we
shipped
technology
such
that
you
can
change
your
kernel
arguments
with
Coupe
cuddle,
and
you
know
everything
the
machine
config
operator
will
handle
draining
and
everything
else
I
think
it's
cool
it's
working!
Well,
it
means
you
can
commit
that
crd
to
get.
You
can
do
git
Ops
for
your
operating
system.
A
In
the
same
way,
you
do
get
Ops
for
all
your
applications
right.
That
was
something
that
you
just
couldn't
really
do
in
the
openshift
three
days,
so
we've
been
successful
right,
there's
a
butt
here
and
and
I
love
to
reference
this
scene.
This
is
this
is
a
screenshot
from
the
movie
Jurassic
Park,
and
it
was
a
time
when
movies
in
the
movie
theater
were
real
movies
and
not
just
regurgitated
super
superhero
movies
in
this
scene.
She
sits
down
at
the
system
and
she
says
it's
a
Unix
system.
A
A
We've
built
up
a
lot
around
Unix
before
kubernetes
existed
right,
so
you
know
if
she'd
sat
down
then,
and
all
she
had
was
coup
cuddle
well,
the
Raptors
would
have
won
right
like
we
we've
yeah,
there's
so
much
knowledge
that
comes
from
that
Unix
base
layer
that
you
know
and,
let's
be
honest-
we
haven't
successfully
turned
that
all
into
a
high
level,
crd
that
you
can
configure
right
like
in
some
of
these
things.
You
just
need
to
manage
in
a
way
you
did
before
you
know.
A
For
example,
you
still
need
to
support
static.
Ip
addresses
if
you're
deploying
on
bare
metal.
That's
just
a
perfect
example
of
yeah
I've
seen
some
support.
People
say
you
shouldn't
touch
core
OS,
but
no
you
have
to
be
able
to
right.
You
need
to
be
able
to
configure
and
manage
your
operating
system,
because
it's
the
foundation
for
everything
else
right.
A
You
know
a
big
one
that
you
can
see
in
our
docs
and
and
from
the
support
team
is,
should
you
enable
SSH
or
not
right
and
I
I'm
suspecting
for
many
of
you,
you
in
this
room
that
may
be
a
dividing
line
right,
because
the
problem
is,
is
it
allows
uncontrolled
change
outside
of
the
kubernetes
space
outs?
That's
in
some
ways
invisible
to
everything
else.
A
It
means
admins
are
making
changes
that
aren't
necessarily
captured
in
your
git
Ops
flow
right,
but
but
we
have
so
much
built
up
on
that
right
like
if
you
can
SSH
to
it.
It's
a
Unix
system
right
now
there
are
people
out
there
that
are
doing
kubernetes,
os's
that
don't
have
SSH
and
to
me
this
is
a
very
interesting
topic,
but
you
know
we're
still
we're
still.
A
Unix
system
is
the
way
I
like
to
think
about
it,
and
we
have
a
lot
of
things
around.
A
A
lot
of
third
parties
have
made
the
transition
to
containerizing
their
agents,
so
you
can
deploy
them
as
privileged
demon
sets.
You
know:
security
scanners,
all
that
sort
of
stuff.
Some,
a
good
number
of
organizations
have
adapted
to
this
new
world,
but
the
way
I
like
to
think
of
it
technology
goes
in
layers
like
when
kubernetes
appeared.
It
didn't
change
the
whole
world
at
once.
Right,
there's
some
organizations
that
can
change
at
certain
speeds.
A
You
know
one
one
perfect
example
of
this:
is
the
openshift
sdn
team
really
pushed
hard
to
go
back
to
running
open,
V
switch
as
part
of
the
host,
because
that's
how
they'd
been
testing
it
in
other
cases,
and
we
really
wanted
to
be
a
demon
set.
You
know,
and
it
creates
there's
different
trade-offs
in
this
right.
A
It's
like
you
need
this
in
some
cases
before
kublet,
and
so
it
we
feel
this
tension
too
and
I'm
sure
many
of
you
who
are
administering
the
OS
on
the
openshift
have
have
encountered
this
yeah
and
obviously
still
today
like
for
a
lot
of
people
who
are
admitting
systems,
you
know
switching
from
the
sort
of
Docker
style
imperative
workflow
to
kubernetes.
Is
it's
still
a
big
leap?
A
So
here's
the
big
change-
and
this
was
a
big
change
in
the
412
development
cycle
so
far,
I
think
it's
gotten
threatened
to
be
reverted
four
times
because
we
broke
things
now
so
I
talked
about
how
a
release
image
and
the
openshift
CI
is
very
good.
You
know
we've
built
everything
out
around
it,
so
you
know
when
we
broke
things
it
was
caught,
but
it's
a
big
change
right.
It's!
This
is
sort
of
akin
to
retuning
the
jet
engine,
while
it's
running
so
so.
A
The
big
change
is
that
we're
rethinking
of
Rel
coros
as
a
container
base
image
Okay
so
and
what
you
see
here
is
a
Docker
file
right
and
so
we're
making
it
so
that
you,
as
a
systems
administrator
for
when
something
goes
wrong.
You
can
write
this
Docker
file,
which
you
already
know,
because
you've
already
seen
Docker
files
for
your
application
right.
You
can
write
this
and
build
a
container
that
derives
from
Rel,
coros
and
and
then
you
can
push
it
to
a
registry
right.
A
If
you're
using
hypershift,
you
can
deploy
it
to
multiple
clusters
right,
you
know
push
it
to
a
centralized
tree
like
Quay
mirror
it.
You
can
scan
it
in
the
same
way
you
scan
every
container
image,
but
the
thing
that's
new
is
that
you
can
boot
it
so
we've
taken,
you
know
the
OSG
stuff,
which
is
part
of
relcore
os,
we've
sort
of
retooled.
It
sort
of
natively,
understand,
container
images.
So
again
you
build
using
this
Docker
file
or
really
any
container
native
build
tooling,
and
this
is
turning
off
autopilot.
A
This
is
taking
control
of
the
OS
updates
and
the
state
of
the
node
root
file
system.
Is
this
container
image
you
built
so
this
example
wasn't
chosen
randomly
we
had
a
customer
that
had
a
big
outage
because
they
hit
a
bug
in
IP
tables
and
they
rolled
out
the
hotfix
not
perfectly,
and
it
caused
a
lot
of
confusion.
So
in
this
case
see
if
I
have
this
on
the
next
slide.
A
Yes,
so
here
I'll
just
skip
ahead
to
this
slide,
so
the
idea
is
once
you've
built
this
thing
we're
keeping
machine
config.
But
the
new
thing
is,
you
can
say
in
the
specification
boot
this
container
and
the
Machine
config
operator
will
do
the
same
thing.
It
does
for
the
regular
OS
updates,
it'll
roll
out
your
custom
override
to
the
node
root
file
system.
So
again,
this
is
in
scenarios
where
you
want.
A
A
What
doesn't
simply
change
how
you
do
OS
updates?
It's!
It's
been
a
big
change,
because
all
this
you
know
when
we
need
to
ship
a
kernel,
security
update.
It
needs
to
work
right
and-
and
we
take
this
very
seriously-
so
this
is
a
pretty
fundamental
change
in
how
we
ship
operating
system
updates
in
openshift.
But
now
the
yeah
again,
the
new
container
just
looks
like
a
native
a
native
container,
but
we
it's
a
seamless
upgrade
and
in
fact
it's
going
to
be
mandatory.
A
When
you
upgrade
to
412,
you
will,
if
you're
not
changing
anything,
all
your
machine
config
will
continue
to
apply
if
you've
added
static,
IP
addresses
through
custom
ignition.
All
that
will
continue
to
work.
We're
going
to
make
this
a
seamless
upgrade
right
because
again,
circling
back
to
why
I'm
here,
you
need
to
keep
your
computer
up
to
date
and
secure,
but
this
adds
a
powerful
new
flexibility
and
capability
in
customizing
and
controlling
the
Rel
core
OS
and
something
I've
been
saying.
A
lot
is
I
really
really
wish.
A
A
A
We
talked
about
that
so
yeah
we're
adding
a
lot
more
to
the
docs
on
this
and,
like
I,
said
this
almost
got
reverted
four
times,
so
it's
really
going
to
stick
in
412
and
we're
going
to
ship
it
and
we're
adding
a
lot
of
a
lot
more
built
up
on
this,
but
just
to
answer
a
couple
questions
in
advance.
First,
one
of
the
most
important
things
is
as
soon
as
you
do
this
again.
It's
turning
off
autopilot
you
own
updates
for
that
container
image.
A
When
we
ship
a
kernel
security
update,
you
need
to
rebuild
your
container
when
that
new
image,
ships,
okay
and
there's
a
lot
on
top
of
this,
but
it's
targeted
at
hot
fixes.
For
precisely
this
reason,
that's
in
the
case
where
there's
a
regression
in
the
kernel
Nick
driver
on
vsphere
I
want
to
go
back
to
the
earlier
kernel.
You
can
do
that.
You
can
do
that
by
writing
a
Docker
file
or
using
any
tool
that
looks.
A
Yeah,
looks
familiar
to
you
and
deploy
it,
but
a
cool
aspect
of
this
right
is
that
when
we
ship
the
fix-
and
you
want
to
go
back-
you
want
to
turn
back
on
autopilot.
You
just
delete
that
machine
config
and
the
cluster
will
roll
out
the
stock
OS
image
right.
You've
turned
back
on
autopilot.
Cluster
updates
are
now
life
again
life
cycle
bound
with
the
operating
system
and
yeah
again.
A
This
doesn't
require
you
to
change
anything
if
again,
if
you're,
using
it
custom
ignition,
if
you're
using
custom
machine
config,
all
of
that
continues
to
work,
we're
just
changing
how
we
do
things
and
adding
a
new
capability,
but
some
of
you
may
have
left
ahead
here
and
thought
well.
I
could
use
this
for
something
other
than
hotfixes.
I
could
use
this
to
deploy
custom,
node
agents.