►
From YouTube: Kubernetes Sig Docs 20180417
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 17 April 2018.
https://github.com/kubernetes/kubernetes.github.io
B
Gist
self
documenting
it's
fairly
self
documenting
the
biggest
thing
to
note
is
that
there's
been
more
PRS
recently
that
have
come
in
against
the
generated
content
so
having
to
make
some
explicit
mentions
to
them.
Hey,
don't
here,
go
upstream,
here's
where
to
go
in
a
couple
of
them:
I
tried
to
find
the
source
for
them
and
help
guide
them,
not
exactly
an
easy
process,
because
everywhere
seems
to
be
different,
but
more
of
that's
coming
in
so
just
be
aware
of
it
as
more
people
hit
hit
into
our
site
and
try
to
do
updates
awesome.
A
A
So
as
a
reminder,
our
first-ever
sigdoc
summit
is
coming
up
on
Wednesday,
May,
9th
in
Portland
and
may
9th
is
the
day.
It's
a
Wednesday
immediately
after
write.
The
docs
important
so
planned
this
in
mind
with
the
idea
that
folks
could
stick
around
an
extra
day
if
you're
coming
to
write,
the
docs
and
I
have
opened
an
issue
for
that
includes
our
tentative
agenda,
and
that
includes
map
links
for
both
where
the
summit
itself
will
be
held
and
for
where
we're
gonna
head
for
dinner
after
after
the
summit
stuff.
A
A
Work
of
making
sure
that
we
have
clarity
about
what
our
shared
goals
are
for
the
rest
of
the
year
and
one
of
the
last
things
that
we'll
do
at
the
summit
is
set
our
date
for
2019,
so
that
when
we
do
this
again
next
year,
we're
not
already
halfway
through
the
year.
So
any
questions
about
the
cig,
Knox
summit.
A
A
A
How
would
you
express
that
to
others
in
terms
of
the
most
valuable
work
that
we
do
and
think
about
that
and
come
in
with
that
in
mind,
all
right,
if
you
have
any
other
questions
about
the
sigdoc
summit,
please
leave
a
comment
to
the
issue
and
we
can
address
calm,
address
questions
and
concerns
there
all
right,
a
few
notes
from
the
Joe.
Do
you
want
to
say
more
about
the
PRQ
or
to
be
do
be
cover
what
you
wanted
to
cover
all
golden?
Okay?
Let's,
let's
move
on,
let's
see
alright!
A
Someone
within
the
sig
teeming
tank
who's
based
out
of
China
doesn't
regularly
attend
this
meeting
because
it's
a
terrible
time
for
him
was
able
to
figure
that
out.
But
it
was
a.
There
was
a
change
to
pod
security
policy
and
it
was
a
very
unexpected
change,
so
we
were
able
to
fix
it
and
that's
a
credit
to
key
being,
but
there's
an
open
question
about.
Why
did
this
break
and
why
did
we
discover
it
in
the
breaking
Jennifer?
Do
you
want
to
say
more
about
that?
Well,.
D
I
can
lead
the
discussion,
but
I
don't
know
that
all
of
the
technical
details,
so
pod
security
policy
changed
in
version
1.2
and
that's
well
documented
everywhere.
The
the
salient
piece
of
information
for
our
purposes
is
the
test
harness
that
the
net
worth
I
build
runs
well
the
tests
that
it
runs
that
that
whole
test
run
is
clearly
upgraded
to
1.10
overnight
the
night
that
that
break
happened
right.
D
So
the
issue
isn't
so
much
that
the
pod
security
policy
endpoint
changed
groups
in
the
API,
the
issue,
although
that
was
the
symptom
and
the
thing
that
we
needed
to
fix.
The
issue
is
that
the
test
harness
is
getting
version
updates
and
we're
not
in
the
loop
about
that.
So
if
we've
made
that
change
like
you
know,
if
we
thought
okay,
pod
security
policy
changed
with
one,
we
need
to
change
the
test.
Script
for
1.10
we'd
have
been
breaking
before
that.
If
you
see
what
I
mean
yes,.
D
We
need
is
information
about
the
testing
framework
upstream
and
when
it
changes
and
I
don't
know
whether
I
mean
I
took
a
look
at
the
Travis
error.
I
took
a
look
at
the
change
that
came
and
made.
I
took
a
look
at
a
couple
of
other
files
and
I'm
sorry.
It
was
last
week
and
that's
like
a
century
ago,
but
you
know
what
I
noticed
is
I,
don't
know
whether
we
can
like
put
variables
in
there
and
declare
the
dependencies
explicitly
I'm,
not
sure
how
we
would
fix
this
technically.
D
A
A
D
D
D
Well,
my
guess
is
that
upgrading
versions
is
something
that
they
rotate
through.
You
know
various
I'm,
not
sure
what
you
know
branches.
You
know
whatever
clusters,
you
know
on
a
regular
basis,
presumably
they're
providing
different
versions
as
versions
role.
Last
right,
you
know
that
I'm
making
lots
of
assumptions
here,
but
I
think
some
of
them
are
reasonably
valid
to
explore.
C
A
C
A
B
To
call
out
those
tests,
nobody
else
owns
them.
It's
us,
you
know
we
inherited
them.
Those
the
tests,
I
think
that's
the
fundamental
problem
and
something
that
those
tests
depended
on
upstream.
It's
what
change
I,
don't
know
if
we
supply
it,
I,
don't
I,
haven't,
read
them.
I,
cracked,
the
code
myself,
so
not
in
a
position
to
make
any
assertions
about
it,
but
I
think
that's
fundamentally
what
we
need
to
sort
out.
B
D
Did
take
a
look
at
the
paths
that
the
pod
security
policy
paths
in
the
tests?
Those
are
definitely
upstream
and
something
changed-
the
version
that's
getting
built
and
served
that
those
tests
are
calling
into.
Okay,
that's
what
I
meant
by
test
interest,
but
the
tests
are
running
against
live
kubernetes
api
server,
we
don't
own
or
control.
A
D
C
A
E
Thank
you,
Andrew.
Let's
bring
up
the
other
issue,
which
is
the
tests
themselves
and
because
that
that
is
sort
of
like
an
alien
artifact
because
it
had
been
inherited
and
then
whenever
it
would
break,
we
would
go
quite
an
engineer
to
like
make
changes
and
they
would
fix
it.
So
if
there's
no,
there
hasn't
been
a
consistent
owner
for
the
actual
test
and
we've
just
been
making
modifications
here
and
there.
But
no
excuse
me,
person
owns,
owns
the
tests
themselves.
D
At
the
risk
of
getting
voluntold
for
something
down,
the
road
seems
to
me
like
we
might,
instead
of
I
mean
yeah.
We
want
to
investigate
the
history
of
the
tests
that
we've
got,
but
when
I
was
looking
at
them,
they
and
I
sort
of
stuck
this
in
the
chat.
They
seemed
like
an
odd
sort
of
Brad
bag.
It's
like
okay
I
can
see
why
we're
testing
odd
security
policy.
But
why
aren't
we
testing
all
the
other
related
Cooper
Navy's
objects?
I
mean.
D
Maybe
there
are
reasons,
but
there's
no
indication
of
those
reasons
in
the
tests
and
I'm
wondering
just
tossing
out
an
idea
here
whether
it
would
be
useful
to
I
mean
yeah.
We
need
to
find
out
about
test
infirm
what's
going
on
right
now,
but
also
maybe
think
a
bit
about
what
we
think
optimal
tests
would
look
like
right
right.
What's
testing
requirements,
document
sure.
A
I
was
thinking
about
that.
It's
like
what.
What
particularly
do
we
need
to
test
for
documentation
that
differs
infinitely
from
from
other
from
other
repositories,
tests
from
other
sig
tests
and
I'm,
not
sure
that
I
can
articulate
what
about
our
special
sauce
other
than
you
know
other
than
our
CI
CD
stack
that
we
need
to
be
that
we
need
to
be
validating.
F
A
G
Occurs
to
me
that
the
types
of
things
that
we
would
need
to
test
for
our
docks
specifically
are
radically
different
from
the
types
of
things
that
would
be
tested
for
upstream
dependencies,
and
things
like
that,
like
the
problem
that
I'm
working
on
in
their
release,
110
branch
right
now
is
potentially
a
sort
of
thing
that
we
would
want
to
test
for
test.
The
docks
for
another
I
mean
some
of
those
things
we
test
using
Netta
five,
because
if
the
I
guess,
if
the
net
Lefou
build
fails,
then
we
know
there's
a
problem.
A
One
about
I
think
so:
I
see
two
discussions.
One
is
about
a
better
notification
of
changes
to
upstream
testing
framework
and
one
is
about
owning
our
own
tests.
Our
own
tests
that
are
specific
to
sig,
Docs
and
andrew
has
already
said
that
he'll
go
talk
to
upstream
awesome.
Thank
you
Andrew,
and
then
we
we
are.
A
We
need
to
have
the
conversation
about
owning
our
own
tests
and
about
making
sure
that
our
own
tests
stack
one
that
we
will
understand
it
and
two
that
the
test
that
we
have
makes
sense
because,
yes,
misty
the
the
thing
that
you
ran
into
with
with
conflict
markers
merged,
didn't
cause
metla
fight
to
fail.
But
it
is
certainly
made
a
giant
giant
mess.
C
A
G
A
I'm,
sorry,
mr.
to
interrupt
but
yeah
just
to
give
that
context.
I
went
in
as
part
of
the
as
part
of
being
the
1.11
release.
My
sister
went
to
merge
master
into
release,
one
about
ten
yesterday
and
discovered
a
whole
bunch
of
merge,
conflicts
and
Misty
is
delving
on
causes,
but
that
is
misty
summaries
correct
that
we
can't
really
proceed
with
adding
anything
into
release
on
bottom.
You
can
merge
master
into
released
one
by
ten
until
the
current
state
of
conflicts
is
resolved,
so
I'm
saying
either
up
mostly.
Please
continue
and.
G
We
have
multiple
ways
that
we
can
try
to
resolve
it.
My
inclination
is
to
try
to
resolve
at
the
quote,
unquote
right
way,
which
involves
fixing
that
bad
commit
and
which,
like
interact
effectively
interactive
rebasing,
starting
with
that
bad
commit.
But
there
are
592
commits
on
top
of
that
commit
which
not
all,
of
course,
have
new
conflicts
based
on
fixing
that
commit,
but
enough
of
them
have
small
little
conflicts
as
I'm,
going
that
I'm
having
to
walk
back
up
through
so
right
now,
I'm
on
317
out
of
593.
G
There's
an
Ulta
native
approach
that
I
have
not
tried
that
somebody
else
could
potentially
try
on
the
side,
which
is
to
look
at
all
the
commits
that
have
gone
into
master
since
the
1.10
release
and
figure
out
which
one's
of
those
commits
are
not
appropriate
to
be
in
110.
And
then
we
could
effectively
hard
reset
with
the
release,
110
branch
as
a
master
and
then
pick
out
those
commits
that
we
don't
want.
G
The
way
that
you
would
need
to
do
it
do
if
you
don't
necessarily
know
the
history
but
I'm
happy
for
somebody
else
to
try
that
at
the
same
time,
I'm
not
pushing
anywhere
when
I
get
this
branch
into
a
consistent
state,
I'm
going
to
push
it
up
into
my
fork
and
let
people
look
at
it,
we
could.
We
could
look
at
it,
making
a
PR
they
between
it
and
the
release,
110,
just
to
see
the
differences
to
make
sure
that
I
made
the
right
choices.
F
G
Yeah
I
just
didn't
want
to
to
propose
that
without
having
enough
information,
it's
it's
the
less
safe
way
to
do
it.
The
other
thing
that
we
could
do
is
we
could
Ted.
We
already
have
a
tag
that
Zack
made
I.
Think
Jennifer.
You
also
didn't
tag
or
didn't
push
the
tag
for
from
110.
That's
good,
so
Jared
made
one
yesterday,
Zack
made
one
yesterday,
but
it's
also
Bates
the
tag.
Shaw
is
the
one.
G
A
G
G
E
A
All
right,
let's
move
on
okay,
so
quick,
takeaways,
I'm!
Sorry
before
we
move
on
from
the
breaking
release,
110
I
think
it's
also
important
to
talk
a
little
bit
about
why
it
was
broken,
and
in
this
case
it
looked
particularly
broken.
I
think
miss
T,
correct
me
if
I'm
wrong,
but
because
there
were
unresolved
conflict
markers
that
had
been
merged
into
some
files
and
caused
a
great
deal
of
confusion.
I
mean
is
that
correct,
Missy
yeah.
G
That's
correct
my
my
supposition.
The
way
that
I
could
imagine
it
getting
into
this
state
just
from
a
technical
point
of
view,
is
that
somebody
had
a
situation
with
a
terrible
number
of
conflicts
that
needed
to
be
resolved
and
they
maybe
lost
their
place,
went
to
lunch,
or
maybe
they
kind
of
freaked
out,
and
they
did
a
get
ad
star
or
something
like
that,
and
just
added
all
the
conflicted
files
without
resolving
the
conflicts.
G
That
would
be
my
supposition
if
you
do
a
git
status
and
you
see
both
modified
or
anything
like
that
anything
other
than
just
your
straight
modified
things
that
you
expect
to
see.
That's
probably
not
something
that
you
should
do,
but
I
can
also
understand
that
if
somebody
was
in
the
heat
of
the
moment
and
they
were
in
a
hurry
or
they
lost
track
of
what
they
were
doing,
maybe
they
would
forget
where
they
were.
There
are
some
mitigation
strategies
that
we
can
put
in
place.
G
We
can
do
we
can
develop
some
pre
commit
hooks
to
try
to
prevent
this
sort
of
thing
from
happening.
Pre-Commit
hooks
around
the
client
side,
so
it's
incumbent
upon
the
person
to
install
them
into
their
local
repo.
It's
not
really
enforceable.
The
other
thing
we
can
do
is
I
have
some
helper
things:
environment
in
my
environment
that
I'm
happy
to
share
that
mean
that
I
don't
lose
my
place.
I've
got
some
things
like
I've
got
a
customized
prompt
and
some
other
stuff
like
that.
G
That
really
helps
me
not
to
get
lost
and
I'm
super
happy
to
share
that
stuff.
It's
a
little
bit
more
advanced
than
a
lot
of
people
who
want
to
get
to
it's,
probably
not
something
for
a
meeting
like
this.
It's
maybe
something
a
little
bit
more
for
a
tech
talk
or
maybe
something
at
in
Portland,
or
something
like
that
where
I
can
just
show
people
what
it
looks
like
and
how
it
benefits
me.
But
yeah.
A
G
Say
that
if
you're
confused
or
concerned
or
stressed
about
anything
in
the
state
of
thing
that
you're
working
on
in
my
experience,
it's
better
to
ask
for
help
because
with
git,
like
anything
that
you
do
this
on,
this
step
is
just
going
to
make
things
10
million
times
worse,
especially
if
you're
not
super
comfortable.
With
what
you're
doing
it's
super
easy
to
get
into
a
strangely
yep.
A
A
D
I
can
look
back
and
say:
okay,
I
could
have
asked.
The
different
group
of
people
or
I
could
have
asked
a
group
instead
of
an
individual
and
I
should
certainly
have
put
a
hold
on
the
tarp
until
I
was
satisfied
with
its
state,
because
I
recall
being
bewildered
by
it,
but
I
think
that
there's
a
bunch
of
things
that
we
can
try
to
document
for
helping
people
get
through
this.
In
addition
to
yes,
please
to
get
tick-tock.
D
Dam
just
to
take
this
as
an
opportunity
to
learn
lessons
because
they
were
always
get
lessons
to
be
learned.
But
the
thing
I'm
hearing
you
say,
misty
that
I
felt
sort
of
intuitively
during
my
tenure
as
Ducks
Meister
for
110,
was
that
there
was
a
quite
desperate
communication
confusion
around
a
merge,
workflow
versus
a
rebase
workflow,
also,
which
is
one
of
the
reasons
I,
was
so
grateful
that
you
brought
it
up
and
that
we
are
moving
toward
clarity
and
coherence
around
this
because
I
without
understanding.
D
A
Well,
it
sounds
like
having
a
good
Tech,
Talk
and
yeah,
having
having
better
understanding
overall
and
clearer
and
more
consistent
practices
is
going
to
help
a
lot
going
forward.
All
right.
Let's
move
on
to
external
content,
so
Raj
I
raised
in
the
channel
yesterday,
she
pointed
to
a
particular
article
that
she
found
helpful
and
asked
if
we
can
include
it
in
the
site
if
we
could
link
to
it,
and
that
I
think
is
a
great
question
to
talk
about,
is
what
do
we,
whether
what
what
should
we
do?
A
F
I
think
it's
fine
to
link
to
external
content
I,
we
do
a
fair
amount
of
it.
Already.
I
can't
get
off
the
top
of
my
head
point
to
it,
but
I
know
we
do
it
and
you
know
my
thought
is.
We
have
there's
way
more.
That
needs
to
be
said.
Then
we
have
time
to
say
so
we
should
make
use
of
whatever
we
find
out
there.
I.
D
Think
that
we
want
to
be
careful
about
how
we
incorporate
links
and
content,
though
like
linking
out
to
this
particular
topic,
seems
fine
I,
think
including
it
doesn't,
for
the
specific
reason
that
it
looks
more
like
an
implementation
of
one
of
those
infinite
number
of
kubernetes
things.
That's
so
flexible
that
you
have
to
go
figure
out
how
to
implement
it.
You
can't
just
use
it
out
of
the
box,
and
that's
good
I
mean
we
all.
D
You
know
everybody
needs
that
kind
of
content,
but
we've
had
conversations
in
the
past
about
keeping
the
docs
about
what
kubernetes
does
and
then
pointing
people
to
well.
Here's
where
you
go
to
figure
out
how
to
you
know
for
examples
of
you
know
a
B
or
C.
Did
that
make
sense.
If
I
recall
correctly,
this
one
was
about
ingress,
which
is
a
particularly
thorny
thing.
A
A
A
Would
like
to
avoid
any
any
content
strategy
that
incorporates
other
people
that
will
then
incorporates
external
content
in
a
way
where
we
have
to
maintain
it.
I
am
a
little
reluctant,
well
I'm,
fine,
to
link
out
to
other
content,
but
I
would
also
like
to
make
sure
that
we
have
some
way
of
verifying
that
external
links
well
or
whether
external
links
are
broken
and
having
a
way
to
verify
that
they're
still
good
and
if
not
give
give
content
owners
the
chance
to
update
or
remove
those
links.
B
Joe,
you
were
muted
yeah,
just
with
yeah,
not
anymore.
No
just
for
the
sake
of
the
record.
There
is
content
that
we
are,
including
on
our
site
from
an
external
site
today
that
has
proven
problematic
and
we've
done
our
best
resolve
it,
but
it
continues
to
lurk
out
there
and
that's
everything.
That's
going
on
with
the
katha
kaadu
toriel's,
it's
incredibly
useful,
so
I'm
not
saying
get
rid
of
it,
but
this
is
a
place
where
we've
definitely
seen
the
pain
of
including
external
site
into
our
content
and
not
having
a
very
clear
structure.
A
Yes
and
a
lot
of
the
content,
almost
all
of
the
content
in
the
getting
started
section
what's
currently
labeled
to
set
up
on
the
site
is
content
that
is
specific
to
external
providers
and
is
likewise
problematic.
So
Raji
I
suspect
that
we're
wandering
a
little
far
from
your
proposal,
which
is
what
do
we
do
with
helpful
content
and
I?
Don't
know
what
do
what
do
folks
think
of
the
idea
of
having.
A
C
A
G
F
C
I
think
that's
a
really
good
point
to
you
know,
maybe
back
to
your
point.
That
is
the
right
answer
and
to
see
if,
like
having
a
site,
I,
think
hey
here's,
some
really
good
articles
that
are
out
there
and
really
good
content.
I
still
struggle
with
what
belongs
on
a
blog
versus
what
belongs
in
in
our
cut
to
old
pet
Doc's
right
so
I
think
there
at
the
vision,
con
save
a.
A
Lot
of
this
sounds
like
it's
really
relevant
to
the
redesign
of
the
community.
Page
and
canoe
seat
contributes
and
Parris
Pittman
and
the
the
redesign
of
community
it's
more
of
a
contributor
portal,
so
I
think
that
there
are
options
for
linking
to
helpful
content
all
right
linking
to
external
content
from
kubernetes
that
I,
oh.
But
it
sounds
like
doing
that
from
the
documentation
is
not
the
best
choice.
A
F
That
that
was
not
my
suggestion.
My
suggestion
was:
let's
have
it
be
fine
to
link
you
know
from
where
Doc's,
even
from
individual
pages
to
external
content?
If
we
think
there's
value
there,
we
can,
we
can
improve
our
our
infrastructure
for
detecting
broken
links.
I
think,
that's
you
know.
The
other
half
of
the
story
is
that
those
links
will
break
so
we'll
have
to
keep
track
of
it.
Well,
anyway,
that's
my
my
view
is
I.
G
It
just
was
a
thing
that
happened,
and
it
came
to
our
VP
of
engineering
attention
from
an
external
person
who
reported
it,
and
there
was
all
of
yelling
and
gnashing
of
teeth
about
it
until
he
did
a
post-mortem
and
figured
out
what
had
happened
and
it
was
totally
out
of
our
control.
But
this
is
one
of
the
problems
to
linking
to
external
content.
Is
that
the
external
content
can
change
in
ways
that
you
don't
expect
I'm,
not
necessarily
saying?
G
B
B
But
yes,
that's
a
possibility
for
that,
as
we
had
done
that,
but
that's
also
a
much
richer
project
that
needs
to
be
kind
of
thought
through
and
thought
out
where
I
think
where
we
are
today
is
yeah:
let's
go
ahead
and
link
to
some
external
content,
but
let's
use
some
best
judgment
and
have
some
sort
of
means
of
saying
yeah.
That's
a
good
thing
to
do,
or
another
thing
to
do
that
we
start
to
develop
internally.
A
And
I
think
that's
a
conversation.
I
think
anything
to
do
with
community
redesign
is
really
sig.
Country
Beck's
is
domain.
That's
that's
their
work
in
their
choice.
It's
a
conversation
we
can
have
with
them,
but
yeah
I
agree
with
Jared
on
this
one,
but
let's
avoid
let's
avoid
taking
ownership,
even
if
inaccurate
of
external
content,
because
it's
I
would
argue
that
it's
not
related
to
our
primary
goal
and.
D
A
A
C
I
sort
of
place
a
question,
something
that
we
might
want
to
chat
about
in
on.
Our
upcoming
summit
feels
like
defining
our
content
strategy
really
clearly,
because
I
think
this
question
is
up
for
any
old
question
more
than
perennial
sort
of
like.
Where
is
the
boundary
of
gratis
in
the
outside
world?
Where
is
that?
Where
is
it
forests?
Where,
as
they're
very
like
that
with
the
violin.