►
From YouTube: Kubernetes SIG Docs 20181009
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for DD Month YYYY.
https://github.com/kubernetes/website
A
A
C
A
The
other
pair
for
that
news
is
the
happy
news
that
Jennifer
Rondo
has
agreed
to
step
up
and
be
the
lead.
Our
third
lead
for
sig
docks
jennifer
has
been
doing
this
longer
than
I
have,
and
I
is
just
exceptionally
knowledgeable
in
both
kubernetes
and
in
the
community
itself,
and
we
are
very
honored
and
very
fortunate
that
Jennifer's
will
need
to
step
into
the
role
so
welcome.
Jennifer.
B
And
I
just
wanted
Jennifer
you've
been
amazing
and
you
know
on
this
team
and
keep
you
focused
on
content
and
I'm,
really
hurting
as
cats
and
running
several
Oxford's
and
just
encouraging
our
presence
right,
Doc's
events.
So
it
is
a
deep
honor
and
pleasure
of
having
you
as
a
chair
of
cigars.
So
thank
you.
Thank.
A
A
We
have
done
over
the
past
year.
We
have
done
some
really
amazing
things
with
Julie
and
we
have
done
some
really
amazing
things
with
automation
and
resolved
a
lot
of
technical
debt,
and
the
end
result
of
that
is
that
we
have
some
great
automation,
but
our
onboarding
Doc's
are
still
not
what
I
would
consider
adequate,
so
I'd
like
for
us
to
return
to
content
and
the
quality
of
content
as
our
principal
focus
and
a
conversation
earlier
this
week,
I
think
Jared
said
it
best.
Is
that
we're
out
on
that?
A
When
we
as
we
head
into
our
planning
session
in
December,
I'm,
going
to
well
I
and
I
hope,
all
of
us
will
take
a
on
our
onboarding
content
and
talk
about
how
our
what
specifically,
we
can
do
to
improve
that.
What
what
specific
improvements
in
projects
to
onboarding
that
we
can
make
and
how
to
iterate
that
properly
hello
Paris
and
to
focus
on
content.
A
First,
and
this
is
a
I'd
like
to
add
a
standing
weekly
item
to
content
so
that
we
can
talk
about
what
folks
are
doing
and,
as
we
start,
building
out
specific
projects
that
we
commit
to
in
our
planning
upcoming
planning
session,
that
we
have
a
chance
to
check
in
on
those
and
expose
the
visibility
of
content.
Provements
and
functionally
Lucas
running
a
really
hopping.
Sigdoc
stools
group.
A
So
for
discussions
like
automation
for
tooling,
and
things
like
that,
it
sounds
like
a
really
good
opportunity
to
defer
those
discussions
to
the
tooling
working
group
and
to
have
that
working
group
meet
and
then
have
time
to
report
back
into
this
weekly
meeting.
But
to
not
give
quite
so
much
time
and
effort
and
focus
on
tooling
discussions
in
the
weekly
meeting
itself,
so
Luke
does
that
sound
reasonable?
Does
that
sound
reasonable
to
add
a
weekly
standing
discussion
item
for
sig?
That's
tooling
every
week,
yeah.
F
For
sure
I
I
mean
I,
guess
that
in
my
mind,
that
was
that
was
kind
of
the
goal.
All
along
I
mean
I
mean
honestly,
like
the
two
things
to
just
note
that
you
just
noted.
First
of
all,
you
know
that
you
want
this
kind
of
like
Aria,
reassertion
of
an
emphasis
on
on
content
and
a
place
to
kind
of
you
know
brush
some
of
the
some
of
the
tooling
nitty-gritty
issues
aside
to
was
precisely
the
goal
on
my
side,
so
yeah
that
that
sounds
great
and
I'm.
F
Actually
just
now
editing
the
the
agenda
for
next
week
to
talk
about
some
of
the
the
logistics
around
the
the
tooling
working
group,
because
you
know
thus
far
we've
just
we
kind
of
chat
a
little
bit
in
slack
and
so
on
and
so
forth.
But
we
don't
have
any
process
or
anything
like
that.
So
that's
something
that
I'd
like
like
for
us
to
just
discuss
as
a
group.
A
B
I
think
I
think
that's
a
really
good
point.
As
the
team
grows
in
size,
we
might
want
to
consider
like
splitting
off
some
of
those
larger
chunks
into
into
into
groups.
As
that.
Welcome
to
this
meeting
so
I
know
Paris
says
a
lot
when
she
can
get
into
around
when
she
gets
into
like
how
she's
working
with
contributes
and
and.
H
B
I
think
you
might
my
Micah,
like
I
know
we
can
totally
talk
about
the
the
onboarding,
the
on
break
journey
and
I.
Think
that
there's
there's
some
specifics
here,
but
I
think
you
know
my
larger
concern
around
tooling
and
content
is
I
want
to
make
sure
a
lot
of
our
content
like
I,
ran
the
last
big
ox
meeting
after
sort
of
being
be
focused
on
a
lot
of
other
projects
on
our
team
for
the
past
six
months.
I
just
noticed,
I
know
that
see
if
you're
doing
a
lot
of
content,
work.
B
I
know
that
Andrews
doing
a
lot
of
content,
work
and
I
just
wanted
to
make
sure
that
those
projects
are
being
tracked
and
surfaced
in
the
meeting
just
because
we
we
spent
an
hour
talking
about
tooling
and
internationalization
kind
of
coda
through
these
other
projects
that
are
important,
but
I
also
wanted
to
make
sure
that
we're
tracking
those
the
concepts
rewrite
I
see
that
there's
some
content
that
should
probably
be
cut
from
tutorials
because
updated
to
set
up
guys
process.
Zach
is
talking
about
I.
B
H
Here's
the
reason
I
ask
is
that
I
think
there
are
three
things
that
we
tend
to
to
rally
around.
One
is
tooling
and
infrastructure.
The
other
is
getting
started,
content
that
includes
things
like
how
to
contribute
and
have
it
install
coop
control
and
then
the
third
might
be
intermediate
level
of
content
where
we
actually
write
concept,
pages
and
task
pages
in
the
occasional
tutorial.
I
think
it's
that
third
bucket
that's
been
the
most
neglected.
A
Think
there's
a
fairly
compelling
case
for
both
of
the
scenarios:
I,
don't
think
it
has
to
be
in
either/or,
let's
see
in
Paris,
hopefully
notes
you
can
do
all
of
the
above.
If
you
cut
it
out
by
sub
project
and
then
the
sub
projects
meet
so
basically
yeah
porque,
no
los
dos
y.
Why
can't
we
do
everything
if
we,
if
we
organize
it
well,
and
that
leads
nicely
into
a
segue
for
Paris
to
talk
about
how
we
can
actually
track
and
effectively
explos
and
and
communicate
about
the
work
that
we're
doing
so.
I
What
my
vision
here
is,
is
less
meetings
left
I'm
in
those
meetings
and
more
visibility
on
the
projects
that
we
work
on
and
then
ultimately
engage
these
meetings
in
more
of
like
a
stand-up,
even
with
volunteers
and
open-source
contributors,
I
think
that
can
still
flourish.
I
can
add,
but
let
me
add,
in
the
chat
or
actually
I
could
probably
just
share
my
screen
too.
I
We
have
created
a
project
board
and
the
project
board
is
actually
against
all
of
kubernetes
org
and
the
reason
why
we
did
that
is
because
we've
noticed
that
a
lot
of
the
issues
that
we
work
on
do
you
cross
cut
multiple
repos
and
not
just
the
community
repo
I'd.
Imagine
you
all
catch
some
stuff
in
other
repos,
outside
of
just
like
website,
for
instance.
So
this
might
be
something
that
you
will
want
to
consider
as
well,
and
then
you
can
give
people
access
to
put
things
on
the
board
and
whatnot
hold
on
one.
I
I
Obviously
you
all
might
have
a
different
methodology
than
we
have,
which
is
very
plausible,
but
I
was
noticing
that
one
of
the
problems
that
we
were
actually
solving
to
was
kind
of
like
the
perception
of
what
contributors
think
we
should
be
working
on
and
then
what
we
were
actually
working
on.
So
this
project
board
also
gives
that
kind
of
visible
two
contributors
and
also
makes
them
more,
will
makes
us
more
susceptible
to
closing
that
feedback
loop
with
contributors
as
far
as
what
they
think
we
should
be
working
on.
I
mean
I.
I
Did
this
I
do
this
through
surveys,
and
things
like
that
too?
But
I've
noticed
that
people
are
a
lot
more
open
and
communicative
with
us,
because
now
they
see
the
stuff
that
we
are
working
on
and
we'll
say,
like
hey,
I
think
this
is
another.
You
know
you
maybe
rethink
that
this
should
be
a
priority
when
it's
not
I
did
add
the
project
board
inside
of
there.
So
we
essentially
treat
right
now
our
meetings
as
sort
of
this
half
and
a
half.
We
do
a
one
hour
approach,
just
like
you
all
do
just
like.
I
Most
things
do
and
then
in
that
one
hour,
the
first
30
minutes
is
typically
a
stand-up.
So
we'll
go
through
this
project.
For
the
first
thing
we
obviously
talked
about
as
blockers.
Does
anybody
have
any
blockers
that
they
want
to
discuss,
and
then
this
is
sort
of
where
typically
in
the
past,
we
would
have
folks
just
kind
of
start
talking
about
stuff
that
either
it's
work.
They're
working
on
is
a
problem,
etc,
and
now,
when
I
hear
those
things
live,
I
say:
is
there
an
issue
for
this?
Do
you
have
an
issue?
I
Are
you
working
on
this
thing
because
that's
now
putting
the
onus
on
the
contributor
to
to
pretty
much
stand
up
and
and
then
now
we
can
track
that
and
then,
with
going
back
to
kind
of
Steve's
comment
about
well,
should
we
take
one-quarter
to
focus
on
this?
This
project
board
I
actually
did
a
column
called
future
cycles.
I
So
it's
kind
of
what
we're
doing
a
contributor
experience
and
we're
sort
of
chiseling
this
off
kind
of
layer
by
layer
and
trying
different
approaches
each
week.
But
right
now
the
current
state
of
affairs
as
we
go
through
the
project
board.
Do
the
blockers
do
the
backlog
and
then
we
do
the
and
then
the
in
progress.
If
you
have
a
card
in
progress,
you
stand
up
so,
for
instance,
this
week,
I'm
looking,
we
have
nine
in
progress
cards.
I
Some
of
these
people
are
multiple,
so
like
I'm,
looking
at
multiples,
George
multiples
of
Kristof
multiples
of
myself
and
then
we'll
each
just
stand
up.
So
in
this
case
I'll
say
Kristoff.
It
looks
like
you
have
four
four
cards:
do
you
want
to
stand
up
and
tell
us
what
what's
going
on
and
then
we
documented-
and
we
usually
end
our
meeting
so
in
30
minutes.
So
it's
wonderful.
So
we've
been
doing
this
for
about
20
minutes
in
the
meeting
and
then
the
rest
is
like
open
mic
discussion.
I
So
that's
the
that's
kind
of
our
goals
and
I
think
based
on
what
I
know
about
Docs.
You
all
probably
could
mold
yourself
into
this
in
some
aspects,
but
not
necessarily
all
but
I
think
it
will
least
save
your
save
kind
of
like
some
meeting
times,
and
things
like
that.
So
you
can
see
you
guys
can
get
to
work
and
gals
get
to
work.
B
I
We
brought
it
out
slowly,
like
I've.
I,
put
the
project
board
together
and
I.
Didn't
do
anything
with
it
at
all
for
about
two
weeks,
except
for
put
it
on
our
agenda
and
say
hey
what
do
y'all
think
about
this?
Like
does
this
look
right?
Does
this
look?
You
know
like
something
you
know
that
you
can
digest
as
far
as
like,
where
we
are
with
certain
things
and
I
didn't
get
too
much
feedback.
I
got
a
couple
bits
and
pieces
from
people,
all
of
which
was
very
constructive
and
fine.
I
Let's
talk
about
some
of
the
blockers
of
cards
that
I
see
there
that
we
see
on
here
and
then
it
kind
of
just
grew
into
what
we
have
now
so
kind
of
just
like
peeling
back
each
one
of
those
layers
of
the
banana
one
by
one
and
then
now
people
see
oh,
my
gosh.
We
have
30
minutes
of
our
life
back
and
we've
had
it
for
the
last
two
weeks
that
actually
allowed
to
for
a
couple
of
our
sub
projects
to
take
over
the
next
30
minutes.
I
I
If
you
want
and
then
everybody
else
hangs
up,
so
no
real
issues
today,
I
mean
it
guess
it
can
be
kind
of
perceived
as
pushy
if
we're
asking
people
to
stand
up
as
volunteers,
but
I
feel
like
if
we
put
it
in
a
in
a
light
of
how
can
we
help
you,
or
you
know
more,
like
a
helpful
stance,
then
a?
What
are
you
getting
this
done?
What
is
the
deadline?
Kind
of
take
that
would
probably
be
fine,
but
no
no
real
major
hurdles
or
challenges.
B
A
I
That's
our
next
goal.
Our
next
goal
is
that
medical
now
I
mean
now.
We
kind
of
see,
though,
like
what
is
in
progress
and
then
from
there
like
as
I'm
doing
the
pruning
for
the
meet
for
the
weekly
meeting.
I
see
like
do
I
kind
of
think
that
this
is
going
to
be
done
before
the
next
cycle
like
and
I
and
or
like
I.
Look
at
the
backlog
too
and
I
look
at
our
future
cycles
and
from
there
I
can
kind
of
determine
what
what
I
think
will
hit
for
the
release
milestone.
I
A
That
so,
it
seems
like
something
that
we
could
reasonably
do.
I
think
we'll
have
to
like
discuss
the
specifics
of
implementation
as
we
do
it,
because
I'm
just
looking
at
our
own
project
list
of
projects
for
the
repo
and
I'm,
seeing
three
different
projects
right
now,
one
for
ducks
prints,
which
I
think
we
might
be
able
to
to
take
out
of
projects
and
put
into
I
just
keep
it
cards,
but
I
see
two
separate
boards
for
Google
2018
q4
projects
and
then
one
for
duck
editing
projects
which
I
think
is
Steve.
A
That
looks
like
your
way
of
tracking
out
working
things
in
progress,
so
it
looks
like
we
might
have
multiple
iterations
of
project
boards,
and
so
do
we
have
a
canonical
board.
In
addition
to
all
of
these,
do
we?
How
do
we
talk
about
our
work
meaningfully
together?
I
guess
when
projects
are
already
being
deployed,
sort
of
for
larger
sub-collections,
okay,.
J
H
D
B
Have
parrots
you,
you
put
in
a
couple
for
like
really
large
projects
and
then
umbrella
issues
I
think
that's
a
good
breakdown
but
yeah.
Maybe
maybe
we
think
we
can
build
the
projects
within
our
own
area
that
coordinated
with
contrive
X
as
we
get
bigger?
Is
that
what
you're
suggesting
Paris
or
like
if
we
do
cross-functional
work,
yeah.
I
So
sorry,
someone
just
knocked
on
the
door.
I
apologize.
You
know
I'm
getting
kicked
out
at
the
typical
Google
way,
no
fur
so
for
umbrella
projects.
They
are,
they
hold
essentially
all
of
your
one
on
one
second
101
set.
They
hold
all
of
your
all
of
the
issues
that
relate
to
that
sub
project.
So,
for
instance,
we
have
contributor
documentation
as
a
sub
project
and
we
were
working
on
the
contributor
guide
and
multiple
issue.
I
And
then
now
we
have
a
couple
different
umbrella
issues
and
we're
thinking
about
spouting
those
off
into
their
own
sub
projects,
as
well,
just
just
for
the
same
reason
that
Jennifer
brought
up,
which
is
maybe
crud
SIG's,
will
see
that
and
want
to
and
want
to
like
cross,
communicate
with
us
and
also
put
stuff,
that's
related
on
our
board,
and
then
it
seemed
we
could
do
the
same
thing
with
box.
I
mean
obviously
we
cross
occasionally
and
contributor
experience.
So
we
could
just.
A
A
So,
and
that
was
sort
of
a
lot
to
take
in
about
a
proposed
way
to
do
to
cover
our
our
content
journey,
how
do
big,
just
by
a
quick
show
of
consensus
up
down
middle,
you
get
sure
we'll
do
up
down
middle.
How
do
folks
feel
about
practicing
or
using
sub
projects
like
this
to
track
to
track
our
work
and
just
get
it
expose?
What
we're
doing
more.
H
E
I
Can
always
change
your
cards?
You
can
always
change
your
label.
You
can
always
change
like
how
you
do
umbrella
if
you
do
umbrella
issues,
there's
tons
that
is
customizable
here,
so
I
would
not
think
you're
locking
into
anything
and
I
know.
Folks
in
our
group
definitely
do
not
like
the
word
project
management.
So
so
that's
why
it's
kind
of
like,
if
you
do
just
roll
this
out,
try
little
little
bite
sizes
and
see
if
it
works
for
you,
yeah.
B
And
full
disclosure
I've
definitely
been
like.
We
need
okay,
ours.
We
need
okay,
ours
and
like
sort
of
late
talking
to
some
of
the
folks
here
about
that,
and
you
know
Parris
thank
you
for
showing
me
a
little
way,
one
that
isn't
so
Google
centric
of
doing
some
longer-term
planning
to
get
to
that
right
place
so
yeah.
We
don't
need
to
do
it
Google's.
What
might
be
better
to
do
it?
A
a
more.
H
D
K
A
A
C
C
C
Today's
presentation
has
a
little
bit
of
interactivity,
so
please
don't
be
shy
when
I
ask
a
question
and
also
don't
be
shy
to
ask
questions
yourself
at
any
point
in
time.
So
today
we
want
to
start
with
a
replica
set,
and
can
anybody
here
describe
this
replica
set
for
me?
What
does
this
replica
set?
Actually
do?
Can
you
see
it?
Well,
maybe
I
need
a
scroll,
and
can
I
zoom
in
here.
E
You
really
want
what
it
does.
Please
should
I
volunteer
and
leave
the
team
okay.
So
so
this
is
Brad
and
when
I
look
at
this,
you
hit
the
top
of
it,
and
you
know
what
API
version
that
you're,
using
for
what's
in
the
amel
you've
got
a
kind
field
that
that
tells
you
what
kind
of
resource
that
you
have
you've
got
your
specification
for
for
that
and
it's
declaring
three
replicas
and
the
model
and
kubernetes
is
always
to
match
on
labels,
and
so
you'll
you'll
see
the
labels
twice.
E
You'll
see
it
as
part
of
the
replica
set
saying
hey
here:
are
the
labels
I'm
going
to
query
for
as
I
try
and
identify
the
pods
that
are
in
my
replica
set
and
then
you've
got
the
the
template
there
for
for
the
for?
What's
going
to
be
and
in
the
in
the
pods
or
what
have
you
for
the
replica
set?
And
wouldn't
you
be
surprised
that
well
there's
the
labels
and
the
same
labels
that
it's
going
to
try
and
match
on
or
the
labels
out
of
puts
in
the
template?
E
That's
always
good
news
and
then
you've
got
the
nested
specifications.
How
I
like
to
do
it,
because
the
replica
sets
not
only
describing
itself
as
a
controller
but
describing
in
some
ways
the
pods
that
it's
going
to
manage,
and
so,
if
you
look
in
that
nest,
it's
back
it's
saying:
hey!
Here's!
The
image!
I
want
you
to
use
for
your
pause.
It
happens
to
be
a
busy
box.
C
It's
actually
wrong.
That
is
not
what
this
specification
says.
As
you
already
described,
the
replica
set
controller
desired
state
specifies
nothing,
but
there
shall
be
three
part.
Each
part
shall
have
a
label
up
of
busybox
zero.
It
does
not
say
whatsoever
image.
That
container
should
be
an
instance
off,
and
this
is
not
readily
available.
C
On
the
surface
of
this
specification,
this
property
is
buried
in
the
implementation
of
the
replica
set
controller,
and
the
implementation
of
the
replica
set
controller
is
fairly
complex,
but
it
basically
can
be
formally
described
with
the
state
match
predicate
where
you
say
copy
this
down
here.
A
replica
set
is
a
representation
of
the
fact
that
kubernetes
current
state
matches
the
desired
state.
If
and
only
if
there
are
Specter
replicas
in
our
case
three
hot,
so
that
the
pods
namespace
matches
the
namespace
and
the
pods
Labour's
matches
the
selector.
C
The
pods
labels
are,
the
replica
sets
spec
templates
labels
and
the
pods
spec
would
be
the
replica
sets
spec
template
spec
or
it
could
be
a
delete
action
where
the
deleted
object
is
a
part
and
the
replica
sets
spec
selectors
matches
that
part
as
a
consequence.
The
replica
set
would
be
entirely
happy
if
I
created
three
parts
manually,
not
with
busybox
but,
for
example,
with
engines
and
then
I
create
the
replica
set.
If
the
labels
match
up
the
replica
sets,
state
predicates
will
match
up,
and
it's
entirely
happy
about
it.
C
If
I
kill
now
one
of
my
engines
containers
the
replica
sets
state
match,
predicates
will
not
match
up
anymore.
It
will
create
a
new
part,
but
now
with
the
correct
with
the
correct
image,
if
I
scale
it
back
the
replica
set
it,
the
state
match
doesn't
match
again.
It
needs
to
delete
one
of
the
pots
and
it
could
be
very
well
the
busy
box
port
leaving
us
with
two
engine
spots.
C
So
our
original
assumption
right,
let
me
get
three
parts
because
replicas
three,
we
get
three
parts
of
busybox
containers
we
get
three
containers
of
a
busy
box
actually
does
not
hold
true,
and
this
is
not
available.
This
information
is
not
available
or
derive
able
on
a
tight
level.
You
cannot
see
this
just
by
looking
at
the
kubernetes
object,
replica
set,
you
actually
have
to
loop
in
the
source
code
of
the
controller.
This
is
buried
in
the
code
of
the
controller
and
therefore
for
each
object
that
we
have
in
kubernetes.
C
H
C
Also,
the
the
description
around
most
of
kubernetes
behavior
when
saying
that
kubernetes
tries
to
converge,
the
current
state
to
the
desired
state
right
leaves
out
the
specification
of
what
the
desired
state
actually
is.
The
desired
state
is
not
three
three
parts
of
image:
busybox
the
desired
state
is
three
parts
with
a
specific
label.
That's
all
the
desired
stated
other
other
than
that
the
reticle
set
doesn't
carry
any
further.
H
C
C
Kubernetes
would
actually
happy
accept
that
and
after
that,
I
basically
effectively
DDoS
kubernetes
will
never
stop
to
create
pots,
because
the
labels
never
match,
so
it
will
always
create
new
pots.
However,
it
is.
This
is
guarded
at
the
API
server
validation
site,
but,
as
I
said,
it's
not
part
of
the
type
system
whatsoever.
So.
A
G
We're
gonna
be
as
part
of
this
project.
I'm
gonna
be
like
refactoring,
a
lot
of
the
the
concept
section
and
I
think
we
need
to
kind
of
come
up
with
a
standard
format
for
how
we
explain
how
you
know
these
different
controllers
and
services,
work
and
I
think
Dominic's
done
a
great
job
and
sort
of
like
surfacing
like
the
conceptual
like
underpinnings
of
it
and
what
we
need
to
convey
clearly
to
the
users.
So
we
can,
you
know
we
can
come
up
with.
Like
a
you
know,
a
doc
plan
and
kind
of
split
up.
G
D
A
G
So
there
will
be
diagrams
too.
So
when
explaining
like,
you
know
how
something
functions
like
you
know,
we'll
have
the
clear
definitions
and
the
diagrams
in
the
description
of
like
you
know
how
particular
system
works,
but
then
that's
just
to
understand
the
overall
architecture
and
the
general,
like
you
know,
patterns
of
like
how
turbinates
works,
but
then
for
the
specific,
like
controller
or
something
a
replica
set,
then
we
can
talk
about
the
you
know
the
specific,
mitigating
actions
it
has.
G
You
know
the
ability
to
do
so
so
there's
those
two
levels,
there's
sort
of
like
the
general.
How
does
communities
working
you
know
broadly,
but
then
for
a
specific
component?
We
can
say
these
are
the
things
that
you
can
do,
and
this
is
how
it
you
know,
determines
whether
it's
matching
the
desired
State
or
not
sure
that
would
be
like
this
would
be
very
difficult
to
render
visually
yeah.
A
C
And
if
you
don't
mind,
I
also
would
like
to
say:
I
am
I'm
taking
and
taking
requests
for
the
next
fun
with
modeling.
If
anybody
wants
to
request
anything,
I
have
a
few
proposals.
One
is
what
is
a
container
a
container
engine
in
the
container
orchestration
engine?
The
next
one
is
what
is
a
pod
and
the
third
one
is
what
does
kubernetes
have
in
terms
of
high
availability
with
one
one
of
my
favorites,
because
another
provocative
subtitled
next
to
absolutely
nothing.
A
A
Little
container
behavior
in
pot
behavior
are
weirdly
specific
and
it's
not
clear
so
right
now
the
option
default
inheritance
does
not
equate
to
the
default.
The
default
is
not
the
default
behavior,
but
it
looks
like
Steve
is
voting
for
high
availability.
Jennifer
is
plus
1000
into
high
availability,
so
looks
like
I
lose
I,
don't.
A
E
This
should
be
quick
and
easy
and
we'll
hopefully
get
some
time
back
so
I
know
Andrew
and
I
are
gonna,
be
in
Shanghai.
We
are
running
the
docs
branch
and
then
I
did
volunteer
to
break
out
and
go
do
as
requested.
The
20
minute
discussion
presentation
on
cig
docks
to
the
new
contributor
workshop,
which
I'm
more
than
happy
to
do
I
watched
you
do
it
last
time.
I
think
was
an
Austen
right,
no
prepping
in.
A
Well,
thank
you
for
being
like
thank
you
for
doing
that.
I
think
you're
for
stepping
up.
That
sounds
like
a
great
discussion
for
like
an
issue.
If
you
want
to
open
an
issue
specifically
to
that
topic
and
like
CC
and
stakeholders
for
that
that
sounds
like
okay,
we
could
have
a
lot
of
really
good
discussion.
I
will
be
in
Shanghai,
I'm,
happy,
I'm,
happy
to
collaborate
up
to
and
including
the
presentation
itself.
So
I
didn't
know.
You
were
going
to
Shanghai
yeah.
B
E
A
E
We'll
figure
it
out
but
I'm
happy
to
hear
that
you're
going
I
was
thinking
you
weren't
going
and
no
we
won't
be
able
to
get
Peking
duck
or
anything,
but
but
now
that
you're
going.
This
is
great.
All
right,
well
open
an
issue.
Well,
we'll
figure
it
out,
like
I,
said
that
I
would
they
put
on
Andrew.
Did
you
know
he
was
gone?
No.