►
From YouTube: KBE Insider (E8)
Description
KBE Insider is a new streaming show made specifically for the Kubernetes community. We interview all-star guests who shape and evolve Kubernetes on a daily basis. Keep up with this evolving technology and get insights to help you grow your knowledge and skills.
Stay tuned for our next KBE Insider guest(s)...
A
A
A
A
Oh,
yes,
sorry
yeah,
there's
only
one
place
in
the
world
which
is
boston,
which
is
where
I
live
so
yeah
on
the
campus
and
the
reason
I
bring
it
up
is
I'm
one
of
the
founders
of
the
conference.
We've
been
running
it.
I
think
this
will
be
its
fifth
year,
but
it's
also
on
campus
at
boston
university,
so
that
makes
it
more
fun
as
well.
So
we
strongly
encourage
you
to
submit
a
talk,
you
know
and
come.
A
If
you
can
it's
august,
I
think
18
through
20
this
year,
so
without
further
ado,
why
don't
we
get
a
little
bit
more
into
the
show
and
so,
like?
I
said,
we'd
like
to
welcome
peter
hunt
for
cryo
and
if
you
wanted
to
introduce
yourself
because
that's
my
long-running
joke
is
it's
impossible
to
remember
or
know
the
team
names
or
titles
at
red
hat
for
any
period
of
time
longer
than
like
three
months.
C
B
C
No,
it's
not
it's
not
one
of
the
buzz
words
that
come
up
very
much
and
that's
actually
partially
like
we.
We
kind
of
intend
that
the
idea
of
cryo
is
to
be
the
implementation
of
the
kubernetes
container
runtime
interface
or
the
cri
in
an
oci
open
container
initiative.
Implementation
of
that.
So
that's
where
the
name
comes
from
cri
o.
C
The
developers
of
the
qubit
wanted
a
way
to
kind
of
abstract
out
the
way
that
the
cubelet
asks
some
entity
to
create
the
containers,
pull
the
images
and
like
manage
the
pods,
and
so
they
created
the
cri,
which
is
a
protobuf
api
to
talk
to
some
server
and
do
those
things
for
the
cubelet
delegate
out
that
job.
So
cryo
is
an
implementation
of
the
cri
and
we
try
to
make
it
be
as
secure
performant
and
boring
as
possible.
C
A
C
Right,
yeah
and-
and
there
really
isn't
like
we
they're,
basically,
two
main
implementations
of
the
cri,
now
cryo
and
container
d
and
they're,
both
like
you
know,
kind
of
tested
in
upstream
cube
and
they're,
both
like
used
in
production
and
so
it
from
the
sig
node
perspective,
they're
treated.
You
know
generally
equally.
C
Yes,
so
sig
note
is
like
special
interest
group
node.
It
basically
is
responsible
largely
for
the
cubelet,
so
anything
once
the
api
server
asks
the
cuba
to
do
something.
It's
like
the
node
level,
like
okay
schedule,
this
pod
and
then
the
qubit
goes
and
delegates
that
work
to
the
cri
implementation
does
all
the
volume,
plugging
and
yeah.
C
A
Gotcha
did
you
you
know
you
kind
of
opened
the
the
can
of
worms
there,
which
we
know
is
a
a
hot
topic
in
kind
of
the
kubernetes
and
actually
a
containerization
community
in
general,
but
before
we
get
into
the
details
of
it
a
little
bit
the
you
know,
what
I'm
referencing,
of
course,
is
the
docker
shim.
What
I'm
curious
about
is,
can
you
explain
what
the
docker
shim
does
exactly.
C
Sure
so,
basically
the
docker
shim
is
a
is
like
a
you
know,
a
shim
between
the
cubelet
requesting
hey.
Can
you
create?
Can
you
pull
this
image
and
then
can
you
create
this
container,
and
can
you
create
this
pod
between
that
and
the
docker
api?
So
it's
the
way
that
the
cubelet
speaks
docker
and
the
way
that
kubernetes
used
to
run
because
everyone
used
to
speak
docker.
The
docker
api
was
the
way
that
containers
were
created.
A
Right
I
mean
I,
you
know,
I
think
it's
one
of
those
english
words
that
not
a
lot
of
people
are
familiar
with,
but
is
exactly
what
it
means
when
we
talk
about
it
in
tech.
Speak
right,
you
know,
is
a
shim
is
something
kind
of
like
you
shove
it
in
there
because
you
need
it
to.
You
know,
make
something
fit
right.
You
know,
and
you
know
so,
the
other
shim
that
I
I
find
kind
of
scary
is
the
boot.
A
You
know
on
the
boot
loader
with
linux,
for
example,
there's
also
a
shim,
but
so
okay,
so
the
docker
shim.
The
plan
is
to
remove
the
docker
shim
so
that
we
can
avoid
this
kind
of
indirection
or
this
you
know,
potentially
hacky
code
or
whatever,
and
so
and
then
replace
the
container
runtime
with
say
cryo,
for
example,.
C
Yeah,
so
the
once
once
the
docker
shim
is
removed,
I
mean
so.
For
many
years
the
cubelet
has
been
able
to
use
the
cri
to
create
containers
instead
of
the
docker
shim.
So
the
idea
of
removing
the
docker
shim
is
to
say
definitively.
The
cri
is
the
way
to
have
your
containers
be
created,
so
you
have
to
use
one
of
the
reference.
A
C
So
it
I
mean
so,
if
you're
building
your
own
home
cluster
or
you
know,
you're
running
your
stuff
in
production,
you'll
have
to
change
some
flags
in
the
cubelet.
Basically
say:
hey
talk
to
the
cri
instead
of
the
docker
shim
and
you'll
have
to
run
cryo
on
that
node.
That
should
be
most
of
the
work,
so
it
like,
we
hope,
like
obviously
crowd,
doesn't
speak.
The
docker
api
and
cryo
is
made
for
the
needs
of
the
cubits.
C
C
C
Openshift
is
using
cryo,
so
openshif
cryo
has
been
an
option
in
openshift
since
openshift
311
and
then
for
the
entire
four
series
it
has,
which
has
been
out
for
around
three
years
as
well.
It
has
been
cryo
so
there's
no
other
container
runtime
interface
implementation.
That's
been
supported
on
openshift.
C
B
C
B
C
So
we
think
that
a
container
the
container
engine,
like
the
high
level
container
runtime,
sometimes
called,
should
be.
If
it's
used
in
production,
it
should
be
hyper
focused
on
that
production
use
case.
So
cryo
is
able
to
make
some
dis,
like
you
know,
design
decisions,
because
it
knows
it's
only
tailored
for
the
needs
of
the
cubelet.
C
C
Yeah
so
container
d,
I
mean
they
call
themselves.
Like
the
you
know,
generic
container
runtime.
So
in
addition
to
tailoring
themselves
to
the
needs
of
the
cubelet,
they
also,
you
know,
have
to
support
docker
and
they
support.
You
know
a
you
know,
handful
of
other
clients,
so
the
code
base
is
larger
and
their
capabilities
are,
you
know
more
robust
for
sure,
but
you
know
we
don't
think
that
if
you're
running
containers
in
production
with
kubernetes,
you
need
that
robustness.
A
C
I
you
know
got
convinced
by
a
friend
that
it
would
be
easier
to
do
my
coursework
on
linux,
because
all
of
it
was
unix
space
and
I
was
using
windows
at
the
time
and
I
switched
over
and
I
never
looked
back
using
ubuntu
at
the
time
much
a
chagrin
of
some
of
my
interviewers,
but
so
I
spent
college
running
linux,
but
I
never
was
an
open
source
developer,
but
once
I
took
you
know
operating
systems
course,
and
I
liked
it.
I
you
know
figured
out
that
there
was
a
red
hat
office.
C
A
45
miles,
I
think,
from
actual
boston
where,
where
I
live
so,
but
now
there
is
the
downtown
boston
office.
So
there
is
an
actual
boston
office
as
far
as
I'm
concerned,
so,
okay,
so
that
got
you
kind
of
into
open
source
because
you
started
using
linux
or
whatever
and
as
a
contributor
you
got
pulled
in
because
you
started
to
get
interested
in
operating
systems.
Did
you
did
you
have
that
what
they
refer
to?
As
like
the
open
sour?
C
There
definitely
were
a
num
yeah
yeah
I
mean
not.
So
I
wasn't
great
about
you
know
contributing
things
upstream,
but
they're.
Definitely
it
was
very
special
to
be
able
to.
You
know,
dig
into
you
know
the
the
the
you
know,
display
manager
and
be
like.
I
want
it
to
look
like
this
or
I
want
to
do
this.
I
definitely
bricked
a
number
of
my
early
installations
trying
to
customize
it
too
much.
A
A
C
So
I
mostly
maintain
cry,
I
would
say
like
80
to
90
of
my
time
I
spend
thinking
about
the
crowd
code
base,
so
I
serve,
as
you
know,
one
of
the
primary
like
triagers
of
cryo
issues,
and
you
know
the
pushers
of
cryo
features.
You
know
there
are
plenty
of
like
features
that
this
sig
node
ends
up.
You
know
working
on
that.
You
know
both
of
the
cri
implementations
have
to
work
on,
and
so
I'll
often
find
myself.
C
You
know
working
on
those
and
then
I
spent
some
of
my
time
in
signode
thinking
about
developing.
You
know
moving
forward
the
kubernetes
ecosystem
with
the
features
in
the
cubelet
but
yeah
most
of
my
timeouts,
and
then
I
spend
a
little
bit
of
my
time,
maintaining
con
mon,
which
is
a
little
agent
that
each
container
runs
or
needs
to
run.
That
runs
each
container
and
pays
attention
to
its
logs
and
its
life
cycle.
So
I
also
maintain
that.
C
That
it
like
attaches
to
the
standard
out
of
that
process
and
forwards
the
logs
to
the
disk
so
that
the
cuba
can
read
them
and
then
also
like
watches
for
sig
child.
So
when
the
process
dies,
it
can
write
its
the
exit
code
to
a
file
that
cryo
then
reads
so
cryo
can
actually
shut
down
and
because
none
of
the
none
of
the
containers
are
actually
direct
children
of
cryo,
none
of
the
containers
die,
crowd
can
shut
down.
A
configuration
can
change.
C
A
A
The
reason
I
mention
it
right
is,
I
think
developers
in
general
probably
have
more
experience
with
with
being
that
close
to
your
virtual
machines,
whereas
you
know
with
the
containers,
I
think
it's
it's
less
common,
but
that's
why
you
know,
I
would
say
it's
comparable.
Sorry,
josh
did
you
have
something
you
wanted
to
ask.
B
Oh
well,
you're
mentioning
and
working
on
some
features
and
that
sort
of
thing
so
she's
talking
about
cry
the
job
of
cryos
to
be
boring
and
that
sort
of
thing.
But
I
seem
to
remember
from
kubecon
that
you
are
actually
working
on
adding
some
new
things
to
cryo
things
that
actually
might
not
have
been
available
via
docker.
C
Well,
yeah,
so
you
know
we
we
we
tout
the
boringness
of
it,
but
you
know
still
at
the
end
of
the
day,
people
want
to
get
work
done
and
often
this
work
ends
up
being
interesting
and
novel,
and
so
we
there
are
situations
in
which
we
add
you
know,
we
do
add,
features
to
cryo.
So
some
of
the
things
that
we're
working
on
yeah.
C
C
Basically
does
this
like
list
watch
loop,
where
you
know,
because
before
in
docker
it
basically
was
just
like
hey
what
are
containers.
I
had
what
were
your
containers?
What
are
your
containers?
What
are
your
containers
on
a
loop
to
actually
get
the
state
of
the
node
because
it
was
like
kind
of
a
hacky?
You
know
shim,
as
we
were
talking
about
so
now
we're
kind
of
imagining
what
the
future
could
look
like
and
thinking
about
like
okay,
can
we
wire
up?
C
You
know,
events
in
you
know
the
cubelet
so
that
it
can
listen
to
events
and
reduce
the
like
runtime
cpu
usage
and
then
following
a
couple
of
caps
upstream
we're
working
on
reworking
the
way
that
stats
are
gathered.
So
I'm
sure
that
this
will
come
as
a
shock,
but
the
way
that
stats
are
gathered
in
kubernetes
is
also
kind
of
hacky,
where
it
used
to
be
that
c
advisor
would
monitor
the
behavior
of
the
docker
containers
by
you
know:
eye
notifying
on
c
group's
hierarchy.
C
A
Gotcha,
that
makes
a
lot
of
sense.
It's
so
kind
of
expanding
on
that,
though
you
know,
if
you,
if
you
were
in
charge
of
the
world,
what
would
you
you
know?
What
would
you
like
to
see
next
like
what
is
what
are
the
things
that
you
know
like,
I
said:
infinite
time:
infinite
money?
What
would
what
would
you
think
that
the
right
you
know
direction
in
a
sense
for
kubernetes
or
even
cryo,
or
you
know
any
part
in
the
middle.
C
C
So,
basically
like
the
cri
piece
would
be
much
thinner
and
much
smaller
so
that
the
runtime
cpu
you
know
there
wouldn't
be
all
this
listing
there
wouldn't
be
all
this
like
process
just
waiting
for
stuff
to
do,
but
rather
it
would.
You
know
it
like.
The
all
of
the
little
processes
would
be
responsible
for
their
little
piece
of
work
per
pod,
which
would
allow
kubernetes
to
scale
up
and
scale
down.
You
know
much
better.
C
C
So
look
thinking
about
what
it
looks
like
for
a
tiny
little
server
to
run.
You
know
these
containers
and
you
know
how
you
know
what
what
the
memory
and
cpu
constraints
would
look
like.
It
would
be
great
if
it
was
more
flexible
and
not,
as
I
mean
it's
kind
of
like
wasteful
now,
if
being
frank,
but
so
it,
but
you
know.
Obviously
it's
worked
this
way
for
a
long
time
and
it
works
well.
So
it's
and
it's
hard
to
change
so
right.
C
Right
so,
like
my
hope
is
to
is
that
I
mean
we
haven't
yet
put
up
our
proposal,
but
we're
we're
currently
like
some
of
folks
on
my
team
at
red
hat
are
imagining
what
this
proposal
would
look
like
and
then
once
we
you
know
once
we
submit
that,
and
it
goes
through
a
couple
of
releases,
then
you
know
for
the
proposal
for
the
event
driven.
So
that's
like
the
first
step
and
then
once
we
have
event,
then
we
can
start
thinking
about
okay.
What
actually
does
cryo
need
to
do
all
the
time?
C
What
is
this
damon
that
we're
running?
Do
we
need
it
you
know
or
like?
How
can
we
pair
it
down
another?
You
know
thing
that
we're
working
that
I
forgot
to
mention
is
we're
rewriting
khan
mon.
We
mentioned
khan
man
earlier
the
container
agent,
we're
actually
rewriting
it
in
rust,
the
new
hot
language
that
everyone
loves
talking
about
and
we're
we're
changing
it
to
and
the
and
we're
we're
updating
it
to
a
per
pod
model,
rather
than
a
per
container
model.
C
Right
now,
for
every
new
container,
that's
created,
a
new
con
monitor
is
running
for
every
container
exec.
That
runs
a
con
mon
runs,
and
all
of
this
is
you
know,
more
processes
than
are
actually
needed
so
by
we're
updating
where
hopefully,
in
124,
we'll
have
a
a
preview
of
this.
You
know
con
mon
3.0,
which
is
you
know,
a
per
pod,
con
mon.
That
crowd
can
talk
through
through
an
a
you
know,
an
api,
and
you
know
so.
C
That
will
also
take
us
another
step
forward
to
this
world,
where
that
process
can
actually
be
responsible
for
calling
all
of
the
run.
You
know,
run
c,
create,
run
c,
exec,
run
c
kill,
and
then
eventually
you
know
we
can
start
paring
down
the
things
that
cryo
needs
to
do
and
have
that
have
it
just
be
as
focused
as
possible.
C
The
it
definitely
and
it's
you
know
it's
it's
kind
of
funny
you
mentioned
because
it's
as
if
kubernetes
needs
more
complexity
and
as
if
it
needs
you
know
to
have
more
processes
in
the
picture.
But
you
know
you
trade
offs
everywhere,
and
it
we'll
have
to
make
it
easy
to
debug.
You
know
common
three,
but.
C
A
C
C
You
know
new
agent
that
we're
making
so
there's
you
know
it
will
have
to
you
know,
think
about
how
best
to
see
into
the
world
of
con
mon
right
as
as
the
scope
of
con
mon
increases,
and
you
know
because,
like
I
imagine,
a
world
in
which
it
basically
cryo's
like
okay,
I
have
this
pod.
Well,
I
have
this
like.
I
need.
I
need
a
pod
with
this
specification
and
then
con
mon
does
the
you
know
name
space,
pinning
it
acts
as
pid
one
for
the
container.
C
If
for
the
pod,
if
the
pod
is
a
private
pod
level,
pid
name
space,
which
is
the
reason
for
the
pause
container,
which
you
mentioned
earlier,
so
we'd
not
need
the
pause
container
in
like
most
situations
and
it
and
then
it
like
sets
up.
Basically
the
all
of
the
containers
and
does
all
of
the
execs
can
stop
the
container
when
it's
asked
to
so
basically
yeah,
like
all
of
the
functions
that
cryo
is
kind
of
doing,
I'm
moving
it
down
to
the
pod
level.
One
day.
C
Usage
like
the
go,
runtime
is
very
heavy
and
the
garbage
collection
is
expensive,
especially
if
we're
trying
to
reduce
like
latent
cpu
usage,
so
kind
of
like
rust,
lived
in
this
world
where
it
was
like
it
could
be
performant
in
the
way.
That
c
is,
but
also
you
know,
is
a
more
high
level
language
easier
to
work
with
can
have
like
threading.
Very
simply
can
have
you
know
all
of
these.
You
know
nice
niceties
that
we're
used
to
in
you
know
now.
So
I.
A
C
The
whole
we're
going
to
see
it's
kind
of
go
yeah,
so
that
I
mean
we
it
was
yeah
like,
and
I
mean
it
has
been.
You
know
it
has
been
very
useful
being
in
c
because
it
you
know
it's
very
low.
You
know
very
low
memory,
even
for
per
container
process.
It's
like
you,
know
two
megs
per
container.
If
there's
like
you
know
a
a
couple
of
containers
per
pod,
that's
you
know
pretty
low
overhead
over
all,
but
yeah
yeah.
A
Right
right,
so
that
makes
that
makes
a
lot
more
sense.
I
mean
I
at
least
you
know
for
me
going
if
it
was
go
and
going
to
rust.
That's
a
much
harder
decision
given,
as
you
were,
kind
of
saying
right,
the
most
of
the
kubernetes
world
is
in
go,
but
I
think
if
you're
coming
from
c,
you
have
a
lot
more.
You
know
kind
of
options
there.
So
we.
A
C
Right
so
my
plan,
so
right
now
we
have
the
ability
to
toggle
between
runtime
types,
because
we
have.
We
have
support
for
kata,
which
is
a
runtime
type
of
vm,
so
you
have
to
kind
of
work
with
it
in
a
very
particular
way
and
then
the
runtime
type
oci,
which
is
just
like
a
kanban
base.
So
my
my
plan
for
this
would
be
introduce
a
third
runtime
type
of
which
has
yet
to
be
named
and
then
they
so
they
in
long
story
short.
C
They
would
be
coexisting
for
a
while,
as
we
work
out
any
issues
with
the
new
con
mon-
and
you
know
we
have
you
know
a
normal
because,
like
cryo
supports
the
three
quarities
releases
that
are
currently,
you
know
that
are
supported.
So
you
know
we
would
be
supporting
a
con
based
one
for
a
while
anyway,
so
where
it
will
we'll
safely
move
through
until
we're
ready
that
it's,
like
you
know
up
to
snuff
and
capable
of
handling
the
production
workloads
enough.
You
know
well.
C
B
A
B
C
So
I
mean
coop
vert,
I
like
you
know
cooperate
is
from
my
understanding
and
I
haven't
really
worked
a
ton
with
cooperate,
but
I've
done
I've
supported
a
bit
of
it
and
from
my
understanding
it's
basically
like
they
create
a
privileged
container
process
that
then
talks
to
libfar
directly
and
that
creates
a
vm,
the
so
the
can
the
vm
it
doesn't
really
live
in
the
container
to
root
as
mine,
or
maybe
it
does.
I
I'm
not
super
familiar
with
like
exactly.
C
Right
so
so,
theoretically,
I
mean
everything
that
you
can,
because
a
container
is
just
a
process
right,
yeah
the
host,
that's
in
a
root
environment,
so
anything
that,
like
that,
doesn't
change
very
much
really.
What
changes
is
like
the
way
that
we
look
at
the
into
those
processes
so
like
con
mon
is
the
thing
that's
like
listening
to
the
standard
out
and
running
it
to
disk,
and
you
know
monitoring
the
exit
code.
None
of
that.
C
You
know
changes
if
the
configuration
gets
a
little
bit
more
exotic
for
like
something
like
kata,
where
the
container
is
actually
a
vm
or
the
pod
is
actually
a
vm
and
inside
of
it
the
containers
are
running
inside
of
the
vm
that
we're
not
really
considering
within
scope
of
this
change,
because
you
know
the
kata
community
has
you
know
they
there's
a
very
particular
way
that
they
interface
with
cryo.
So
we're
not
we're
not
really
messing
with
that.
C
A
Gotcha
kind
of
you
know
you've
been
talking
a
lot
about
change
and
one
of
the
things
that's
been
coming
up
for
me
a
lot
as
a
as
a
faculty.
Member
now
right
is
where,
if,
if
somebody
wanted
to
get
involved
with
the
project,
you
know
either
cryo
or
con
mon
or
whatever.
I
would
imagine
that
there's
that
it's
kind
of
got
a
bunch
of
code.
That
is,
you,
know,
kind
of
small
in
the
sense
that
you
can
understand
a
small
amount
and
you
know
make
a
fix.
C
Yeah,
it's
a
great
question,
so
we
do
have
in
cryo.
We
have
like
a
couple
of
tags
like
good,
first
issue
and
help
wanted
so
those
kind
of
those
we
try
when
triaging
to
apply
if
they
seem
generally
pretty
small
in
scope
and
something
that
you
know
wouldn't
be
too
complicated.
But
we
ourselves
don't
really
have
time
for
so
yeah
and
I
mean
generally
we're
always
happy
to
help
people
find
work
that
they're
interested
in.
C
So
if
they
wanted
to
reach
out
to
any
of
the
crowd
developers,
we
largely
live
in
the
community
slack
in
pound
cryo,
so
wow.
If
people
wanted
to,
you
know,
wanted
to
learn
how
to
contribute
more
definitely
reach
out
to
any
of
us
and
we'd
be
happy
to
kind
of
direct
them.
We're
always
we're
always
looking
for
new
contributors.
C
C
Now
it's
still
like
we're
still
pretty
early
stage
like
we
have
we're
pretty
close
to
like
mvp,
but
where
you
know,
there's
still
a
number
of
steps
and
a
lot
of
us
keep
getting
distracted
so
that
lives
in
there's
it
and
you
can
talk
about
it
in
the
cryoslack
or
on
cryo,
and
you
know
what
the
the
repository
is.
Github
slash
containers
slash
con
mon
dash
rs,
all
right.
I
can
type
that
out,
but
so,
but
right
now
it's
it's
such
early
stage
that
we
haven't
really
started.
B
Was
just
thinking
because
a
lot
of
a
lot
of
particularly
young
developers,
who
are
just
leaving
college
right,
are
learning
rust
and
so
they're
going
to
be
interested
in
that?
I'm
just
like
you
know.
If
somebody
is
a
rust
developer
and
they
want
to
when
they
want
to
get
involved
with
con
man.
Where
would
they
go
right?.
A
Well,
the
reason
like
you
know,
like
a
kind
of
another
experience,
I
have
that
kind
of
reinforces
your
your
opinion.
In
my
mind,
right
is
we've
been
looking
at
in
the
university
right
at
you
know
needing
a
low-level
language
to
teach
low-level
classes
right
so
like
an
operating
systems
class.
This
was
specifically
in
the
data
science
space,
but
you
know
whatever,
and
you
know
to
try
to
get
away.
Maybe
from
c
and
c
plus
plus-
and
you
know-
and
it
looks
like
rust-
might
be.
A
You
know
kind
of
also
reinforces
that
opinion
right,
so
you
know,
but
I
think
one
of
the
really
nice
things
about
modern
development.
You
know
the
last
five
or
ten
years
you
know
with
the
popularity
of
containerization
and
all
that
jazz
is
you
can
choose
the
the
right
language
for
the
right
job
significantly
more
easily
than
you
ever
used
to
be
able
to.
So
you
know
just
because
you
have
you
know
one
thing
written
and
go
another
thing
written
in
russ
and
another
thing
written
in
c.
A
C
Well,
the
so
no,
the
last
couple
of
years
haven't
been
the
most
conducive
for
competitive
partner
dancing,
but
yeah
in
I
did
last
competitively
dance.
When
I
was
in
college,
I
was
a
competitive
ballroom
dancer
so,
but
I
have
I've
I've
kind
of
fallen
off
a
bit,
but
I
am
interested
as
it
becomes
safe
and
poking
back
into
the
world
at
least
casually.
I
don't
think
I'll
probably
remain
a
competitive
dancer
but
yeah.
I
definitely.
C
A
B
C
A
C
C
So
I
don't
know
like
for
a
lot
of
the
pieces
in
the
the
the
like
higher
level
kubernetes
ecosystem,
I'm
not
sure
if
it
makes
a
bunch
of
sense.
I
mean,
obviously
it's
very
modular.
So
if,
like
someone,
some
really
motivated
developer
wanted
to
go
and
write
rewrite
etcd
in
rust,
they
could
and
just
plug
it
in
and
it
would
work.
But
I
think
that
I
I
think
that
the
biggest
considerations
are
like
you
know
anything
underneath
the
cubelet.
C
So,
like
rewrite,
like
you
know,
there's
the
project
c
run
which
is
written
by
one
of
our
colleagues
at
red,
hat
and
giuseppe
stravano
and,
like
c
like
so
it's
run
c,
rewritten
in
c,
which
makes
sense
because
it's
you
know
nice
and
low
level.
And
you
know
you
need
access
to
a
lot
of
the
kernel
apis
and
there
actually
are
pieces
of
run
c
written
in
c
to
do
some
of
the
things
that
go
can't
so
thing
for
positions
like
that.
C
A
Gotcha
yeah,
I
mean,
I
think
I
I
think
that's
interesting.
You
know,
because
language
choice
can
can
make
a
big
difference
to
you
know
the
kind
of
situational
you
know
the
situation
or
whatever,
but
rust.
Really
it's
only
in
my
opinion
right.
It's
only
just
getting
to
the
point
where
it's
something
I
I
would
trust
at
that
kind
of
level.
You
know
you
know
it's
great
and
all,
and
you
know
people
can
really
like
it
and
all
that
jazz.
But
it's
like
if
I'm
going
to
run
something
in
production.
A
C
You
know
we
have
some
of
it,
some
of
that
model
within
c
plus
plus,
but
it's
not
mandated
like
in
the
way
that
it
is
in
russ,
so
I've
I've
found
it
hard
to
switch
over
from
go
to
rust,
and
I
can
definitely
see
that
being
just
a
general
barrier
of
entry
for
any
project.
Thinking
about
moving
over
to
rust.
B
B
You
look
at
the
programmers
who
are
new
right
and
I'm
seeing
a
lot
more
rust
adoption
and
among
new
programmers,
because
if
you
look
at
I
mean
you
still
look
at
the
go
documentation
it
starts
out
with
go
is
just
like
c,
except
for
these
things,
yeah,
which
is
great
if
you're
like
me
and
you've
already
programmed
in
c,
but
if
you're
getting
started
you're
crossing
over
from
java.
That's
not
helpful
at
all.
C
A
A
Oh,
I
was
gonna
say
somebody
asked
if
there
was
a
advice
on
learning
rust
and
at
least
for
me
I
you
know
when
I
started
to
take
a
look
at
it
and
I
did
not
get
very
far
because
you
know
work
kind
of
gotten
away,
but
the
the
rust
kind
of
website
is
pretty
good.
You
know
at
some
of
the
kind
of
documentation
tutorial
stuff,
but
I
was
wondering
if
you
know
either
of
you
have
you
know
anything
that
you've
heard
or
seen
or
experienced.
C
I
learned
in
a
very
kind
of
I
don't
know
I
I
don't
books,
don't
typically
work
for
me,
my
brain,
I
like
I
try
to
read
and
I
just
can't
get
hazy-
have
trouble
paying
attention
so
the
I
don't
have
any
suggestions
like
that.
What
I
do
is
I
look
at
code
that
other
people
have
written
in
rust
that
I
can.
C
I
trust
so,
like
you
know,
one
of
my
colleagues
sasha
grenade,
who
also
works
on
cryo
with
me,
he's
done
a
ton
of
writing
stuff
in
rust,
and
so
I
basically
look
at
his
code
and
then
see
how
it
looks
and
then
write
some
code
and
then
see
how
many
compile
errors
I
have
and
then
google
all
the
compile
errors
until
I
fix
them
and
eventually
iteratively
over
time.
I
start
getting
more
familiar
with
it,
but
I
don't
think
that
that's
actually
the
most
efficient
way
to
learn
a
language.
A
Yeah,
it's
funny.
I
actually
I'm
very
good
at
reading,
like
I
really
like,
reading
or
whatever,
but
not
to
do
something
like
learning
a
programming
language,
I
usually
find
the
best
way
for
me
to
do
it
is
I
try
to
go
build
something
right
and
you
know,
and
basically
you
know
stack
overflow
and
google
are
open
over
here
and
my
you
know,
text
editor
is
open
over
here
and
I
just
kind
of
keep
banging
at
it
until
until
it
works,
but
I
think
I
think
that's
you
know
there.
A
There
are
better
ways
to
to
do
these
things,
I'm
just
not
100
sure
what
they
are,
but
I
did
I
did
like.
Like
I
said
I
like
the
it's
rust.
I
can't
remember
the
website.
It's
like
rustashlang.org
yeah.
You
know
I
like
some
of
the
content
there.
I
thought
that
was
pretty
good
and
isn't
like
firefox
is
now
completely
rust
right
or
is
it
just
like
a
rust
engine,
but
I
mean
I
I
would
trust
that
code
as
a
as
an
exemplar.
A
C
C
A
B
A
B
A
A
C
Absolutely
I
100
recommend
I
find
you
know.
I
typically
dress
largely
masculine
and
I
find
a
lot
of
masculine
clothes.
Don't
have
a
lot
of
the
flair
that
I'm
looking
for,
so
I
shop
in
the
often
the
you
know
the
women's
section
in
thrift
stores
for
for
fun
plants.
I've
got
some.
I
don't
know
if
I
can
get
my
leg.
B
C
Right,
yeah,
no,
yes,
but
I
definitely
think
more
people
should
be
wearing
fun
pants.
I
kind
of
really
have
a
thing
against
jeans,
and
so
and
the
nice
thing
about
the
fun
pants
is
they're
all
comfortable,
which
is
a
big
thing
for
me
as
well.
So
definitely
more
flowers
and
more
places
is
is
my
is
my
review.
A
B
C
C
A
Nice,
nice
all
right
on
on
that
note,
which
you
know
thanks
so
much
for
coming
peter.
We
really
appreciate
it
and
you
know
we
love
talking
about.
You
know
the
low-level
things
that
are
going
on
kubernetes.
We
like
to
hear
you
know
from
engineers
who
are
kind
of
doing
the
work.
What
you
know
where
do
you
see
it
going?
That's
really
interesting
about
the
rust
choice.
A
You
know
interesting
about
how
you
know
you're
trying
to
get
more
of
a
an
event-driven
infrastructure,
even
at
the
kind
of
cryo
level,
which
I
think
is
is
also
interesting,
but
thanks
to
the
audience,
really
appreciate
you
sticking
around
for
this
and
please
definitely
join
us.
We
have,
we
already
have.
I
think
guests
lined
up
for
the
next
like
three
shows
four
shows
something
like
that.
So
keep
an
eye
out.
B
Yeah
next
month
is
going
to
be
a
couple
of
people
talking
about.
I
was
mentioning
more
exotic,
runtimes
like
cooper,
so
a
couple
of
people
talking
about
virtual
machines
in
in
a
container
infrastructure,
so
somebody
from
the
cooper
project,
as
well
as
somebody
who's,
worked
on
virtualization
in
the
linux
kernel
for
a
long
time.
So
right.