►
From YouTube: SIG Docs meeting for 20210629
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
folks,
it's
the
29th
of
june
2021,
and
this
is
the
weekly
meeting
of
the
documentation
special
interest
group
for
kubernetes.
I'm
tim
I'll
be
running
this
meeting
and
the
agenda,
let
me
grab
the
link
and
put
it
in
the
chat
is
going
to
appear
in
the
chat
when
I
paste
it
in
so.
If
you've
got
access
to
that,
google
doc,
you
can
access
it.
If
you
haven't
got
access,
let
us
know,
and
we
can,
we
can
sort
something
out:
cool
new
contributors.
A
I
don't
think
anyone's
new
to
their
weekly
meeting,
not
at
all
cool
next
week's
this
week's
pr
wrangler.
That
is
sf
tim.
That's
me!
Yes,
I'm
aware
that
I
am
me
and
next
week's
pr
angler
is
a
us
holiday.
So
it's
best
effort,
anyone
who's,
an
approver
or
a
viewer.
Please
feel
free
to
review
and
approve
everyone
else.
We
will
be
back
with
you
shortly:
okay,
let's
go
on
to
the
1.22
release,
documentation.
B
I
would
hello
so
currently
as
it
stands,
we
have
a
lot
of
enhancements
that
basically
need
docs
for
requests.
The
problem
is
that
there
are
a
lot
of
them
are
at
risk,
so
there's
not
much
that
we
can
do
enhancements,
has
pinked
people
about
this,
and
we
also
our
our
sig
release.
Team
lead
has
also
sent
two
emails
in
the
last
two
weeks
of
reminding
people
about
the
the
upcoming
code
freeze
and
also
the
deadline
for
for
the
pr
for
the
docs.
B
C
B
B
Some
of
them
were
marked
at
risk
because
the
the
enhancement
owner
did
not
reply
in
time.
So
I
I
expect
some
of
them
to
really
just
be
kind
of
false,
false
positives,
let's
say
or
false,
at
risk
status,
and
once
that
once
that
is
solved,
basically
we
will.
We
will
have
a
better
picture
once
enhancements,
get,
gets
the
details
back
and
starts
putting
everything.
As
tracked,
we
will
know
exactly
which
ones
you
know
are
truly
at
risk
and
which
ones
are
not.
A
I
I
got
a
follow-on
question.
I
guess
it
makes
sense
that
enhancements
are
at
risk,
we
add
a
hold
label
to
them.
Does
that
feel
reasonable.
B
Yes,
so
that's
something
that
I
noticed
with
the
pr
that
I
already
merged.
I
personally
know
the
person
I
work
with
them
in
red
hat,
so
I
kind
of
I
have
an
idea
that
the
the
pull
request
does
not
need
any
more
kk
code,
so
it's
already
merged.
I
wanted
to
ask
at
worst
case
scenario
if
there
isn't
some
other
code,
that
is
needed,
and
this
is
still
at
risk
or
it
doesn't
make
it
is
it
okay
to
simply
just
do
an
interactive,
rebase
and
delete
that
commit
from
dev122?
B
A
C
Not
necessarily
the
specific
use
case,
but
if
we're
just
doing
like
a
revert
commit
on
the
dev
122
branch,
I
don't
see
a
major
impact
because
it
would
still
write
a
new
one
in
history.
If
we
were
to
do
any
sort
of
funky,
you
know
rebasing.
Potentially
we
shouldn't
have
any
issues
with
the
master
branch
or
the
the
main
branch,
but
long
story
short.
I
think
we
should
be
able
to
do
a
revert
commit
on
the
dev
122
branch.
A
I
am
minded
to
say
the
same
thing:
open
a
new
merge
request
that
either
is
a
you
know.
What
git
thinks
is
a
revert,
commit
or
is
a
commit
that
reverts
the
change,
but
isn't
what
git
thinks
is
a
reversion
either
of
those
merge
that
in-
and
I
don't
my
expectation
is
that
it
wouldn't
force,
it
wouldn't
drive
the
one
two
two,
the
dev
122
branch
to
be
unmergeable.
A
If
we
get
into
a
pickle,
then
we
can
look
at
doing
funky
things
with
re-racing
and
chat
or
cherry
picking,
which
is
kind
of
the
same
thing
but
but
backwards.
Let's
do
the
simple
thing
if
we
can
absolutely
thank
you
and
I
I'm
sorry
go
ahead.
A
The
other
thing
is
like
I
mean
the
website.
Repo
is
chunky.
You
know
it's
a
bigger
repo
than
one
than
most
of
the
ones
I
usually
work
with,
but
it's
a
simple
enough
branching
strategy
that
you
know
we
can.
We
can
do
funky
things
off
the
side
on
the
dev
122
ranch
leave.
The
main
branch
is
pretty
much
kind
of
straightforward,
I
would
say,
and
I'm
okay
like
we'll,
we'll
only
ever
have
one
release
per
one
upcoming
release
branch
open,
we'll,
never
do
anything
more
complicated.
So
I
think
we
have
that
simplicity
on
our
side.
B
Perfect,
thank
you.
I
know
that
one
of
the
golden
rules
in
in
the
handbook
was
not
to
have
any
kind
of
you
know
revert
commits.
That's
why
I
was
suggesting
this
interactive,
rebase
and
delete,
but
if
this
works
then
then
it's
okay,
that
is
the
only
one,
I'm
quite
confident
that
it
will
be
fine
though,
but
let's
see
I
just
asked
in
case
this.
This
scenario
actually
comes
to
fruition.
B
Yeah
at
this
point,
I'm
not
sure
what
else
we
can
do.
We
will
try
to
remind
enhancement
owners
this
week
that
there
is
an
upcoming
deadline
for
the
pr,
but
outside
of
that,
my
personal
expectation
is
that
there
will
be
a
lot
of
them
either.
B
B
I
don't
know
if
it
makes
sense
to
kick
out.
You
know
to
kick
out
features
that
people
have
worked
on,
but
it
really
depends.
I
mean
if
a
feature
is
not
documented.
For
me
it
means
it
doesn't
exist
and
putting
something
out
like
that.
You
know,
I
don't
know
it
doesn't
make
sense,
but
we'll
see.
Hopefully
you
know
we
don't
get
there
and
yeah
we'll
see
how
that
goes.
C
Every
release
cycle
is
that
docs
as
a
subset
of
the
release
team,
does
hold
sole
authority
to
block
a
release,
and
so
another
alternative
option
as
well,
and
it
hasn't
came
up
yet
it's
one
of
those
things
where
I
I
like
to
remind
folks
that
that
exists
at
least
from
a
authoritative
structure,
but
one
thing
I
think
of
is
if
there
isn't
docs
and
we're
coming
up
across
deadlines,
potentially
pushing
the
release
out
further
based
on
the
lack
of
docs
as
a
somewhat
of
a
solution
or
something
if
we
didn't
have
a
official
exception
in
place
today.
C
A
Yeah,
I
would
expect
to
see
if
something
is
going
to
go
in
without
without
docs
and
move
forward.
I
would
expect
to
see
an
item
on
the
sig
docs
agenda.
You
know
requesting
a
formal
exemption
as
a
minimum.
Okay,
we
haven't
got
a
process,
but
that's
the
sort
of
minimum
I'd
expect
to
see.
A
Cool
one
bit
of
context
as
well:
victor
about
that
golden
rule.
We
used
to
have
squash
as
our
default
strategy
for
handling
pull
requests
and
in
those
days
you
know
of
of
using
squash,
I
think
revert
commits
would
have
been
a
pain.
We've
moved
using
merge
by
default
squash
optionally,
and
I
I
think
that
that
is
grounds
to
remove
that
golden
rule.
So
you
could
propose
that
change,
and
I
I
I
recommend
that
you
do.
C
Yes,
it's
a
strong,
strong
plus
one.
I
just
was
saying
great
point
tim.
I
was
thinking
where
would
that?
Where
did
that
golden
rule
come
from
and
you're
absolutely
right,
we
ran
into
so
much
pain
and
so
many
issues
when
we
were
having
that
that
auto
squash
happening
and
now
with
the
merge
strategy
that
shouldn't
be
the
case,
so
strong
strongpost
wanted
that,
thanks
for
the
context.
A
Cool
happy:
is
everyone
happy
to
wrap
up
the
release,
discussion
and
take
more
stuff?
Just
like
okay,
I'm
seeing
nothing?
Okay.
Next
one
is
issues
and
pr's.
There's
one
issue:
it's
from
me.
I've
raised
this
before
I
want
to.
What
I
want
to
get
is
that
I
want
to
get
consensus
about
what
we're
doing
with
this
issue
about
generating
feature
gauge
lists
from
data.
A
There's
two
parts
there's
a
pull
request,
which
is
you
know,
a
mechanism
to
to
address
the
issue
and
then
there's
the
issue
which
is,
should
we
generate
feature
gates,
lists
from
data
and
the
reason
I'm
raising.
This
is
because
the
pr
discussion
is
kind
of
mingling,
two
things
one
is:
should
we
do
it
and
the
other
one
is,
should
we
do
it
this
way?
A
I
want
to
get
the
should
we
do
it
question
settled
one
way
or
another
so
that
we
can
move
on,
and
then
you
know
if
the
peer?
If
we
accept
it,
then
then
then
the
question
is:
is
this
the
right
way
to
do
it,
but
I
want
to
I
I
want
to
get
the
the
question
of.
Should
we
do
it
off
the
table,
one
more
on
the
other?
So
I
appreciate
folks
taking
a
look
at
that
issue
and
putting
in
comments
about
their
view.
A
Victor
there
was
an
action
on
release.
Sig,
doc's
release
or
sig
release
dark
team
to
to
get
feedback
on
that
from
sig
release.
Yeah
apologies.
I
didn't
get
to
that.
B
A
B
Don't
I
don't
see
that
they
will
do
that,
they
will
say
no
and
to
touch
on
your
point.
If
we
should
do
it,
I
definitely
think
we
should
do
it.
I
I
looked
at
the
discussion
and
I
saw
that
it
was
kind
of
dragging
on
if
on
the
y,
a
lot-
I
don't
know
what
other
you
know,
what
other
arguments
I
can
bring,
but
basically
it's
a
lot
of
pr's
right
now.
Teaming
has
opened
a
huge
pr
to
fix
the
exactly
this
and,
as
you
can
see
like
he
already
based
it
twice.
B
A
Well,
I'd
really
like
to
build
a
clear
thought
out
consensus
about
the
way
forward
here.
You
know
I
I've
obviously
proposing
it.
So
I've
got
a
viewpoint,
but
I
want
to
make
sure
that
whatever
we
pick
represents
a
genuine
consensus
of
the
sick,
not
just
my
view.
A
We
can
talk
more
about
that,
but
rat
was
really
a
call
for
discussion.
You
know
via
the
github
issue
and
not
here,
but
any
questions
since
I
am
like
right
on
this
call
right
now,
yeah
feel
free
to
ask.
C
I'm
definitely
strongly
in
favor
of
going
to
a
more
systematic
data-driven
way
to
do
feature
gates.
My
concern
might
be
that
being
in
the
middle
of
the
release
cycle,
some
of
the
docs
in
flight,
some
of
the
enhancement
pieces,
definitely
syncing
with
the
release
team
would
be
good.
Potentially,
this
might
be
a
fast
follow
after
the
release
like
this
is
immediately
for
the
next
release
cycle.
That
would
be
the
best
case.
In
my
my
scenario,
that's.
A
When
I
want
the
pr
to
land
I'd
love
to
have
a
you
know,
a
ready-to-go
pr
like
with
the
wrong
data
in
it
and
then
land
it
at
the
point
that
we've
just
merged,
like
literally
we've,
maybe
just
unfrozen
the
repo,
and
that
one
goes
in
or
something
you
know
that
that
would
be
ideal.
That
is,
I
think,
a
slightly
different
question,
but
it
definitely
related
topic.
I'll,
put
a
note
in
the
in
the
agenda
and
slash
minutes.
A
Okay,
I'm
going
to
move
on
to
and
another
thing:
that's
actually
my
name
on
it
as
well
that
I've
brought
up,
which
is
an
article
about
deprecations.
A
So
this
release
and
if
this
happens
every
so
often
deprecates,
quite
a
few
bits
of
kubernetes
api.
So,
first
of
all,
before
we
have
talk
about
the
discussion,
do
people
know
what
I
mean
by
api
applications.
Any
questions
about
that.
D
Yeah,
I
have
a
question:
is
there
a
distinction?
Deprecations
is
basically
saying
it
will
not
be
supported
in
the
future.
What
do
you
call
it
when
you're
saying
it
is
now
out
of
the
code?
It
will
not
work
anymore.
Is
there
a
different
name
for
that,
because
it
seems
I've
getting
blurry
kind
of
understanding
of
that.
A
A
So,
let's
say
pod
security
policy,
which
is
also
also
also
very
much
relevant,
so
put
security
policy
is
is
is
in
is
in,
is,
is
up
for
two
reasons:
the
whole
pod
security
policy
concept
is
going,
we
don't
like
it,
it
tried
and
we're
not
doing
it.
It
wasn't
good
enough.
A
A
A
A
Let
me
pick
topology
manager,
the
topology
manager
feature
that
is
enabled
by
default
because
it's
beta,
but
if
you
don't
want
that
beta
feature
in
your
cluster
because
it
doesn't
do
what
you
want
it
to
do,
then
you
can
launch
the
cluster
components
and
not
have
that
feature
gate,
and
if
we
decided
that
that
feature
gate
was
no
good
and
like
we
weren't
going
to
keep
it,
we
would
deprecate
it
and
an
example
of
one
that
we've
deprecated
would
be
dynamic
auditing.
A
You
used
to
be
able
to
configure
the
auditing
configuration
of
kubernetes
at
runtime
and
talk
to
the
api
server
and
say
you
were
doing
auditing
like
this.
I
now
want
you
to
do
auditing
like
that.
Well,
you
can't
do
that
anymore,
because
that's
a
deprecated
feature,
but
what
deprecated
means
there
is
removed,
and
I
think
this
is
where
you
were
confused
chris,
and
I
think
it
was
a
good
question.
D
Yeah
I
haven't
been
confused
at
other
companies
where
I
had
this.
I've
been
confused
in
terms
of
kubernetes
because
we
had
it
unsupported
or
or
removed
from
the
software
a
way
of
saying
those
things.
So
so
I
didn't
know
that
they
made
that
distinction
here.
It
sounds
like
we
haven't
been
for
kubernetes
and
that's
what
a
lot
of
people
will
care
about.
They
care
about
they're
caring
about
when
their
code
will
actually
break.
D
A
week
before
that
say,
hey
this
is
about
to
be
dropped,
so
if
you
upgrade
you're
going
to
be
in
trouble,
if
you're
still
using
it.
F
A
And
so
what
we're
talking
about
for
this
v122
release
is
really
it's
not
about
api
deprecations,
because
the
api
is
being
removed
like,
for
example,
the
beta
versions
of
roll
binding
and
cluster
roll,
binding
and
cluster
role
and
role
and
the
beta
version
of
customer
resource
definition.
It's
a
specific
version,
but
it's
not
being
deprecated.
It
is
deprecated
already
it
went
ga
and
that
meant
that
the
beta
version
was
deprec
became
deprecated.
A
A
Should
we
have
a
blog
article,
every
release,
whether
where
there
are
removals,
should
we
have
a
you
know,
an
ongoing
process
for
always
making
that
blog
article
writing
be
part
of
the
release
for
like
the
docs
release
team
and
then.
Secondly,
what
should
we
do
for
this
release,
which
is
you
know,
creeping
up
on
us.
D
C
I
I
feel
like
this,
and
we
had
this
conversation
earlier
this
year.
I
think
it
was.
I
think
the
problem
is
fundamentally
a
communication
issue
and
the
hard
part
is
is
it's
kind
of
like
the
leading
the
horse
to
the
water
like?
Yes,
we
can
do
a
blog
post.
You
know
other
companies
might
do
their
own
posts.
You
know
a
lot
of
folks
when
the
release
comes
out.
They
create
their
own
released
blog
post.
C
I
know
that
jordan
liggett
has
started
in
a
doc
forum
that
covers
some
of
the
deprecation,
so
I'll
link
that
in
chat
here.
It
really
talks
about
some
of
the
upcoming
deprecations
that
are
that
are
kind
of
in
flight
or
underway.
So,
like
that's
a
good
spot
to
definitely
link
in
a
blog
post,
and
then
you
know,
this
is
not
just
a
problem
for
docs
but
for
cluster
operators,
owners,
admins
and
so
there's
other
folks
in
the
kubernetes
community
that
are
building
tooling
around
finding
deprecated
apis.
So
I
just
linked
to
chat
there.
C
A
a
deprecation,
checker
called
cube,
pug
and
cube
pug
was
built
by
one
of
our
community
members.
I
believe
ricardo
wrote
that
yeah
ricardo
cats
wrote
that,
and
what
this
does
is.
This
will
actually
take
a
look
at
the
swagger
api
of
what
has
been
changed
or
deprecated
and
spit
out
that
one
just
comment
that
I
feel
like
I
have
to
say,
even
though
it's
not
quite
relevant
to
the
topic
is
there's
something
that
goes.
C
That's
a
little
tricky
that
I
think
is
not
widely
known
in
kubernetes
is
that
the
lcd
server
will
always
store
the
manifest
with
the
preferred
version
and
why
this
is
tricky
is
the
fact
that
if
I
were
to
apply
a
kubernetes
manifest
on
a
115
cluster
and
upgrade
it
over
and
over
and
over
again
until
it
gets
to
be
to
122,
it's
very
likely
that
that
application
will
not
break,
and
it
won't
be
until
I
redeploy
and
hit
the
api
where
it
has
to
do
the
validating
web
hook
to
get
to
the
sdd
persisting
in
storage
and
the
reason
I
bring
that
up
is
you
know
you
run
like
cube
cuddle
out
yaml
or
you
dump
some
of
the
ammo
data
from
your
running
cluster.
C
You
can
say:
oh
I'm,
not
using
a
deprecated
api
version
and
that's
fundamentally
false,
and
so
on
top
of
the
communication
problem
on
top
of
the
technology
problem.
On
top
of
the
various
other
solutions
in
place,
I
feel
like
I'm
100,
on
board
with
over
communication
on
the
deprecations,
but
it
is
a
very
a
very
hairy
topic
to
tackle
so
strong,
plus
one
for
a
blog
post,
strong
first
one
to
talk
about
deprecations,
the
impact
of
folks.
C
I
think,
further
than
that,
we
need
to
talk
about
how
how
folks
can
be
proactive
and
solve
it
and
really
put
themselves
in
the
posture
where
we're
not
waiting
for
a
blog
release
on
release
day
for
the
deprecations
and
into
chris's
point
you
know
before
before
you
get
bit,
let's
tell
them
what's
going
to
bite
them,
which
I
think
is
the
spirit
of
the
deprecation
api
migration
guide
that
I
linked
in
chat.
But
once
again
it's
who
knows
that
that
document
is
out
there
and
who's
looking
for
it.
You
know.
D
Are
you
saying
maybe
someone
should
go
in
the
main
dock
set,
so
hey
prepare
for
deprecations
prepare
for
and
then
you
know
say
I
didn't
know
half
that
stuff.
You
just
said
so
I
mean
that
it's
all
kind
of
going
on
and
if
they
know
it's
there
they
can
go,
look
in
those
other
places
and
and
then
maybe
have
a
blog
that
points
back
to
that.
At
some
point
you
know
it's
a
less
of
an
effort
that
way.
C
Yeah
I
100
agree,
I
think,
like
a
source
of
truth
and
then
some
of
those
like
lesser
known
findings,
that
you
know
I
don't
think
early
on,
especially
in
my
kubernetes
journey.
It's
like
I'm,
barely
cracking
a
hello
world
app
and
I'm
I'm
deployed
I'm
not
worried
about
how
ncd
handles
you
know,
versions
or
preferred
versions,
and
and
how
do
we
distill
that
information
into
an
actionable
way
and
like
you're
saying
chris,
maybe
part
of
that
is
just
pointing
to
a
central
spot
and
widely
advertising
that
spot.
C
As
you
know,
before
you're
upgrading
this
is
somewhere,
you
should
check
and
here's
where
everything's
gonna
go,
here's
a
source
of
truth
and
kind
of
make
that
the
end
all
be
all.
B
I
just
wanted
to
mention
one
thing
about
this.
Well,
maybe
it's
not
that
important,
but
there
there
might
be
some
clash
with
the
release
notes
for
each
version
that
we
do
a
release
on,
because
each
version
also
has
some
some,
for
example,
urgent,
upgrade
notes.
No
really,
you
must
read
this
before
you
upgrade,
so
it's
kind
of
kind
of
covers
stuff
that
you
should
really
watch
out
for
before
you
before
you
do
the
actual
upgrade
and
also
I
see
it,
has
some
deprecation
section
as
well.
So
I
can
actually
copy
paste
this.
B
So
you
know,
maybe
maybe
we
should
try
not
to
duplicate
this
or
maybe
we
should
link
to
it
directly.
Probably.
C
That
makes
sense,
yep,
yes,
strong,
plus
one
and
your
spot
on
there,
it's
either
potentially
making
that
the
source
of
truth
or
potentially,
including
some
of
those
links
that
I
was
sharing
as
far
as
proactively.
You
know
preparing
people
in
the
future
and
that
would
be
coordination
with
sig
release
and
the
release
notes
team
alongside
docs.
A
The
thought
I
have
about
that
blog
article
is
that
if
we
could
get
liaison
and
say,
let's
agree
the
wording
for
these,
these
breaking
changes
say
you
know
three
weeks
after
the
least
released
two
weeks
out
from
the
release
whatever
earlier.
Ideally,
if
we,
you
know
for
the
long
term
process
and
say
this
like,
we
know
that
customer
resource
definition
is
going
to
be
v1
only
and
earlier
versions
of
the
custom
resource
definition,
api
and
we've
known
that
for
a
long
time.
A
So
we've
had
a
long
time
where
we
could
have
come
up
with
the
release.
Note
for
that
and
said:
okay,
no
really,
you
must
read
this
video
europe
before
you
upgrade
could
have
written
that
last
year
and
in
that
time
period
in
that
nine
or
twelve
months
that
we've
got
when
we
know
what's
coming
up,
we
could
be
drafting
a
really
good
release,
note
and
a
blog
article
and
have
a
con
strategy.
A
D
B
Just
wanted
to
mention
one
thing,
usually
what
I
came
across,
I'm
not
sure
if
in
our
docs
is
usually
it's
something
like
has
been
deprecated
and
removed,
so
it's
you
know
accompanied
by
and
removed.
So
you
know
that
the
current
version
doesn't
have
it
whatsoever.
C
And
one
other
thing
too,
as
I've
seen,
I
think
jordan
liggett
was
leading
this
effort
for
sig
cli
cube
cuddle
will
also
mention
things
that
are
being
deprecated
in
the
future.
So
if
you
were
to
apply
an
ingress
using
the
beta
version,
that
is
not
quite
deprecating
the
release
you
have,
they
will
still
apply
it
with
a
warning
saying:
hey
just
a
heads
up.
This
is
going
to
be
deprecated
in
one
two,
two
for
example,
and
I
think
that
those
are
also
incredibly
helpful
as
well.
A
Yeah
that
definitely
ties
in
with
the
subtlety
point,
because
if
you're,
for
example,
you're
using
a
current
coupe
curtail
your
cluster's
reasonably
clean,
you
could
have
a
v1
1.21
cluster
and
a
current
cube
curl
and
your
ci
system
goes
ahead
and
applies
that
v
v,
one
beta
one
ingress
resource
and
if
you
go
and
use
kubectl
to
check
all
your
ingresses
yeah
there.
You
are
v1
ingresses,
because
that's
how
kubernetes
works.
E
Oh,
this
was
just
talking
about
differentiating
between
the
two
terms,
deprecated
and
removing
it
like.
I
noticed
something
in
the
deprecation
guide
that
jim
linked
thing
will
no
longer
serve
the
following.
Deprecated
versions,
which
I
assume
just
is
the
deprecation,
but
we
were
talking
about
saying,
removed
so
we'll
remove
the
following
deprecated
api
versions,
because
they
were
deprecated
and
now
they're
being
removed.
A
Not
common,
consistent,
okay,
so
what
you're
saying
if
I've
understood
that
right
is
that
we
should
you
know
we
should
update
this.
The
way
that
we
should
make
sure
we
communicate.
This
clearly
is
by
change
to
the
style
guide.
That
says
this
is
how
you
describe
something:
that's
deprecated
and
still
there.
A
This
is
how
you
describe
something:
that's
deprecated
removed
and
basically
cover
all
of
the
cases
that,
where
different
ways
for
things
to
be
removed
from
kubernetes
great
so
chris
and
shannon
you
you've
you've
kind
of
made
the
point
there
would
one
of
you
to
be
willing
to
open
the
issue
about
that
and
then
and
log
that
okay
you're
both
nodding.
You
can
log
two
issues,
but
I'm
not
one
of
them
as
stupid
as
a
duplicate
go
ahead
and
take.
A
It's
yours,
you
got
it
cool,
that's
quite
a
bit
of
conversation
on
on
the
deprecation
blog
article
there
is
more
to
have.
I
think
we
should
move
this
to
slack
and
it's
coming
up
to
the
hour.
So,
let's
move
on
to
the
next
thing
about
readers
versus
mongodb.
It's
not
got
a
name
on
it.
So
who?
Whose
item
is
this
that.
C
Is
mine-
and
I
really
just
wanted
to
bring
this
up
for
for
context
and
have
a
chance
to
talk
about
this
overall
on
the
same
page,
I
went
kind
of
down
this
redis
mongodb
rabbit
hole
over
the
past
two
weeks
or
so,
and
I
wanted
to
summarize
here
with
some
context,
and
so
originally
kubernetes
has.
There
is
the
k,
slash,
k,
examples
which
are
used
for
end-to-end
testing
of
application,
yaml
and
then
there's
also
k-slash
website.
C
Our
main
kubernetes
website
repository
also
containing
similar
examples,
if
not
one-to-one,
matching
examples
that
are
used
more
for
the
end
user,
the
consumer
to
follow
like
a
tutorial.
Here's
how
you
deploy
a
guestbook
application
kind
of
the
hello
world
experience
that
y'all
would
expect
to
get
from
documentation.
C
C
The
second
piece
is
redis
was
referring
to
some
inappropriate
terminology
and
part
of
our
working
group
naming
improvements
that
we
were
doing.
We
were
changing
the
words
from
master
and
slave
to
leader
follower
and
some
of
the
more
accepted
terminology
around
some
of
these
deployments.
C
So
with
that
context
we
had
a
user
come
out
and
and
submit
a
pr
that
had.
Let
me
let
me
take
a
step
back.
Originally,
these
examples
were
leveraging
mongodb
or
no
they're,
originally
leveraging
redis
they're,
originally
leveraging
redis
a
pr
came
to
fix,
and
instead
of
changing
the
inappropriate
terminology
on
is
switching
to
leader
follower.
The
user
said
hey,
it
would
be
a
lot
easier
if
we
just
use
mongodb
and
I'm
going
to
create
this
pr
and
we
all
said
great
look.
We
got
rid
of
the
inappropriate
terminology
we're
using
mongodb.
C
That
is
a
fine
solution
and
we
definitely
value
prs
and
action
over.
You
know
open
issues
and
lack
of
action
so
with
that
there
is
not
a
ton
of
bike
shedding,
or
at
least
there's
a
little
bit
of
like.
Do
we
really
want
to
switch
from
redis
to
you
know,
is
this
a
it
gives
it
more
of
a
vendoring
discussion
here,
which
I
don't
think
we
have
any
interest
in
and
ultimately
it
was
okay.
This
pr
is
done,
it
works
it's
technically
functional,
there's,
no
inappropriate
terminology
or
language.
C
What
just
so
happens
to
also
have
fixed
their
example
with
the
inappropriate
terminology
so
for
those
that
are
keeping
up
with
this,
it
turns
out
that
we
were
actually
try
sourcing
the
content
and
taking
it
from
this
google
gcp
document,
and
now
we
got
into
this
fractured
state
of
there
is
the
source
of
truth
from
google
around
this
guestbook
hello
world
example,
and
now
there's
this
fragmented
one
that
is
no
longer
leveraging
the
same
backend
database
and
that's
merged
in
the
kubernetes
website,
and
one
thing
that
we
try
to
avoid
in
sig
docs
is
technical
debt
and
I
guess
additional
maintenance
that
is
unneeded.
C
So,
ultimately,
I
created
a
pr
to
revert
the
mongodb
example
to
use
redis
following
the
google
gcp
documentation,
and
I
have
a
follow-up
pr
to
then
change
the
kubernetes
kubernetes
examples
to
also
match
that
same
mongodb
or
to
match
the
redis
that
we
are
now
synchronized.
Part
of
the
effort
was
also
adding
in
comments
saying,
hey
look.
C
The
source
of
this
documentation
is
not
here,
it
is
actually
you
know
the
the
drones
you're
looking
for
are
in
the
gcp
documentation
and
the
reason
I
bring
all
this
up
is
in
the
issue
I
linked
here
was
there
was
another
pr
that
I
believe
got
merged
are
still
open
right
now,
so
this
one
that's
open
is
updating
the
mongodb
and
some
technical
challenges
there
and
I
really
feel
like
we
should
just
stick
with
the
source
content
in
gcp
and
we
really
shouldn't
deviate
from
that,
especially
if
it
avoids
technical
overhead,
it's
a
single
source
of
of
technical
debt
from
the
gcp
side,
and
this
is
a
very
long-winded
way
of
saying
we
got
into
this
mess
because
we
didn't
really
have
an
opinion,
and
I
think
it's
time
that
we
have
an
opinion
to
single
source,
the
content
and
go
from
there
and
I'm
just
trying
to
put
this
all
out
there.
C
D
So
you're
talking
about
taking
that
code
out
of
kubernetes
code
and
just
pointing
back
to
the
google
site
to
get
it
or
I
don't
think
you
want
to
do
that
right,
correct.
C
It's
really
if
the
source
of
truth
is
in
the
google
repo,
let's
just
use
that
until
proven
otherwise,
and
if
we
want
to
run
our
own
example,
I'm
fine
with
that
too.
But,
let's
not
you,
know,
create
multiple
sources
and
fragment
this
way
much
further
than
we
already
have.
C
A
A
Well,
I'm
seeing
in
the
in
the
chat,
comments,
shannon's
56,
single
sourcing
ray
is
for
reducing
technical
debt,
I'm
also
the
technical
debt.
Anyone
in
favor
of
technical
debt,
I
know
hands
up
now,
it's
a
very
biased
way
of
framing
it.
Is
there
anyone
who
who
disagrees
with
jim's
thesis
there
or
has
questions?
In
fact,
okay,
I
mean
this
yeah,
I'm
happy
to
to
say
to
go
with
the
single
sourcing
approach
and
I
think
your
explanation
for
why
jim
was
very
thorough.
A
D
Chris
weekly
blog
meetings
yeah,
I
tried
to
put
it.
I
don't
have
edit
permission
here
by
the
way,
so
I
requested
it,
but
yeah.
D
I
won't
you're
breaking
up
really
pretty
badly.
It
was
bi-weekly
a
good
cadence
for
this
does
somebody
else
want
to
run
it
or
do
you
want
me?
I
don't
mind.
Waking
it
back
up.
Yeah.
A
Okay,
I'm
gonna
give
chris
a
moment
to
okay
all
right.
I
think
the
the
the
gods
of
the
internet
have
not
been
kind
to
chris
there.
I'm
gonna
suggest
we
put
on
the
next
agenda.
A
It's
something
I
want
to
see
picked
up.
I
would
love
to
see
help
on
on
that.
One
of
the
challenges
that
I
have
seen-
and
I
will
say
this
for
the
record-
is
that
the
time
clashes
with
this
meeting,
so
that's
not
very
effective
for
people
who
want
to
join
both
things.
I
don't
know
what
the
answer
is.
I,
like
lots
of
times,
clash
with
lots
of
things,
but
I
personally
don't
think
I
could
join
in.
I
would
pick
this
meeting
over
the
over
the
the
blog
meeting.
F
B
A
That's
about
an
hour
ago
in
in
in
the
summer
and
the
same
time
in
the
winter.
C
My
opinion
would
be
moving
it
to
a
different
day
and
keep
at
the
same
time
if
it
worked
for
most
folks
all
right.
I
think
this
has
came
up
in
the
past
before
and
it
was.
It
was
scheduled
for
the
current
time,
based
on
preference,
I'm
not
sure
how
they
wound
up
conflicting.
I
don't
think
they
always
conflicted,
but
yeah.
I
think,
given
the
smaller
team
and
a
smaller
group
for
the
blog,
there
should
be
no
problem
changing
it.
A
E
Would
that
be
fortnightly
at
the
same
time
as
before,
like
one
an
hour
ago?
Basically,
at
any
time,.
A
A
Right,
I
think
we
should
park
this.
I
think
we
should
come
back
to
this
next
week.
Please
feel
free
to
discuss
weekly
meetings
on
slack
and
so
on.
I
will
try
to
make
time
to
organize
stuff.
A
Oh,
come
on.
Let's
see:
okay
thanks,
shannon
yeah,
I'm
gonna
wrap
things
up
last
chance
to
tell
me
that
we
should
discuss
something
else.
Five,
four,
three,
two
one
we're
we're
done
thanks!
Everyone
awesome
see
you
next
week.