►
From YouTube: Kubernetes Community Meeting 20210422
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
All
right,
we
are
officially
recording
welcome
to
the
new
monthly
kubernetes
contributor
community
meeting.
I
think
I
got
that
all
in
the
right
order.
I
just
want
to
remind
everybody
that
we
do
have
a
code
of
conduct,
so
please
be
aware
of
that,
be
excellent
to
one
another
and
we
will
get
started
as
a
courtesy.
Please
do
mute
when
you
are
not
speaking
that
way.
Everybody
is
sure
they
can
be
heard
and
but
you
feel
free
to
unmute.
A
If
you
would
like
to
be
part
of
the
discussion-
and
my
name
is
laura
santa
maria,
I
am
from
log
dna
and
I'm
also
part
of
sig
contributor
experience.
So
I'm
also
the
one
responsible
for
this
meeting
now
and
we're
trying
out
a
new
format.
So
we'll
see
how
this
goes.
I
I
don't
think
we
have
a
note
taker
yet
if
somebody
could
take
over
that,
that'd
be
great
and
thank
you
bob
for
dropping
that
in
the
zoom
chat.
A
All
right
well,
well,
somebody
is
thinking
about
becoming
the
note
taker.
I
will
take
it
just
couple
quick
announcements:
this
is
the
new,
updated
community
meeting
format
so
afterwards,
we'd
love
to
hear
your
thoughts
on
what
you
thought
about
the
whole
experience
feel
free
to
reach
out
to
me.
A
Laura.Santaria
logging.com
or
you
can
reach
out
to
us
on
slack
you'll,
be
able
to
find
me
there
and
yeah
that
doc's
overloaded,
so
we're
gonna,
just
keep
going
and
it'll
be
very
entertaining
as
we
go,
but
that's
the
only
really
big
announcement
that
I
have
in
terms
of
this
community
meeting
and
if
you
have
announcements
for
next
time,
please
do.
Let
me
know
a
couple
notes
about
release
updates.
So
1.21.0
was
first
released
earlier
this
month.
On
april,
8th,
congratulations
to
the
release
team.
A
The
retro
was
held
on
april
15th,
so
that
I
think
was
earlier
this
week
or
last
week
it
was
last
week.
I
know
what
day
it
is.
That's
perfectly
fine.
Some
patch
release
updates
for
you.
There
is
a
link
to
the
patch
releases
doc,
but
there's
some
upcoming
patches,
so
1.18.19
release
target
is
the
28th
of
april
1.19.11.
A
Cherry
pick
deadline
of
may
7th
release
target,
may
12
1.20.7
same
cherry
pick,
deadline
and
release
target
as
with
1.21.1,
and
there
were
some
patches
released
as
of
april
15th,
as
well
as
the
big
release
from
1.21.0
and
that's
1.18.18,
1.19.10
and
1.20.6.
A
So
that's
the
quick
update
on
the
releases
and
on
that
note
now
we
get
to
the
fun
part,
which
is
discussions
and
we're
going
to
be
starting
with
the
release.
Cadence
kep,
which
is
from
our
release
team,
and
we
have
jeremy
here
to
kind
of
be
my
be
my
expert,
because
I
don't
know
everything
about
this
kep,
no
matter
how
much
I
read
about
it.
Welcome
jeremy!
Thank
you!
So
much
for
being
with
us
today,
thanks.
B
For
having
me,
I'm
I'm
excited
to
talk
about
this
topic,
it's
near
and
dear
to
my
heart
for
the
last
few
weeks.
So
in.
B
In
essence,
what
this
this
change-
or
you
know,
kept
our
proposals
for
changing
kubernetes.
They
could
be
changing
kubernetes
in
terms
of
code,
so
it
could
be
a
new
feature,
we're
also
using
them
to
propose
policy
changes,
and
this
one
is
specifically
around
the
release
cadence
for
kubernetes.
B
So
in
2020,
due
to
the
the
many
things
that
happened
in
the
world,
you
know
we
slowed
the
119
release
down
and
extended
it
quite
a
bit
to
just
give
everybody
breathing
room,
just
kind
of
take
space
to
to
deal
with
all
the
events
that
were
unfolding.
B
What
that
ended
up
doing
was
leaving
not
enough
time
to
do
two
more
releases
in
in
the
rest
of
the
year,
so
we
ended
up
with
three
releases
in
2020
and
during
that
time
there
was
a
lot
of
discussion
in
various
places.
It's
hard
to
pull
all
the
threads
together
to
find
all
of
the
comments
and
all
the
discussion
that
has
happened,
but
going
forward.
We
thought
that
we
thought
sick
release
proposed
kind
of
adopting
that
formally.
B
So,
instead
of
the
four
releases
that
normally
would
have
happened
once
a
quarter
moving
to
a
cadence.
That's
three
releases:
there's
a
few.
You
know
a
few
reasons
that
we
thought
about
doing
this
one
it
it's
a
lot
of
overhead
to
build
the
releases
out,
maintain
the
various
branches,
and
this
will
give
us
a
little
bit
of
breathing
room
from
the
release
team's
perspective,
but
also
from
from
the
consumer's
perspective.
It's
really
hard
to
keep
up.
B
B
Things
stayed
in
support
for
a
little
bit
longer
and
we
just
kind
of
wanted
to
formalize
that
so
really
what
the
cap
at
a
really
high
level
is
proposing
is
some
rough
guidance
on
planning
release,
calendars
and
the
guidance
kind
of
breaks
down
into
a
few
things.
Three
real
bullet
points,
one
is
that
releases
should
be
around
15
weeks.
Previously
they
were
much
shorter
than
that
10
11
12
weeks,
depending
on
where
it
fell
on
the
calendar.
So
this
isn't
like
a
great
big
difference.
B
B
The
second
thing
is
that
it's
going
to
bake
in
a
little
bit
of
downtime
between
each
release
from
the
release
team's
perspective.
One
of
the
things
that's
great
about
cycle
to
cycle
is
that
we
onboard
a
whole
bunch
of
new
contributors,
some
experienced
contributors
to
the
release
team
as
shadows
to
learn
the
roles
and
help
with
staff
the
release
teams
going
forward,
and
it's
always
a
challenge
to
get
that
done,
especially
for
some
of
the
roles
like
enhancements
that
have
to
hit
the
ground
running.
Speaking
as
a
previous
enhancements
lead.
B
I
know
like
it's
really
hard
to
pick
the
shadows
in
time
to
get
them
really
really
engaged,
because
you
know
we
hit
the
ground
as
soon
as
the
release
officially
kicks
off,
trying
to
collect
all
of
the
the
caps
there
are
going
to
make
it
into
the
release
and
make
sure
the
authors
are
pushing
those
things
forward.
So
this
will
give
us
a
little
bit
more
time
to
do
that,
but
also
to
plan
the
you
know.
B
Schedule
firmed
out
and
and
not
rushed
to
make
sure
we
get
all
like
right.
Now,
the
the
122
schedule
is
being
discussed,
there's
a
pr,
that's
open
for
that
I
can,
after
I'm
done
talking.
I
can
go
grab
the
link
and
drop
it
into
into
the
notes,
but
essentially
you
know
there's
feedback
coming
in
and
when
we
have
less
time
to
get
that
finalized,
it
kind
of
rushes
that
process.
B
So
that's
the
second
bullet
point
two
weeks
of
downtime
and
then
the
third
thing
that
we
did
during
2020-
and
we
really
did
this
during
the
119
release
and
the
120
release
was
give
time
for
kubecon
to
occur.
Generally
kubecon
occurs
during
one
of
the
releases
or
by
two
of
the
releases
during
the
year
and
it's
you
know
in
person,
it's
really
really
hard
to
focus
on
any
of
the
release
team
activities.
B
When
things
are
online,
it's
still
difficult,
you're,
still
trying
to
focus
your
attention
on
kubecon
and
and
not
having
to
worry
about
getting
any
of
the
release
team
meetings.
Getting
reviews
done
no
deadlines
landing
in
that
week.
So
the
third
bullet
point
of
this
kind
of
rough
policy
is
that
we're
going
to
block
out
that
week
from
any
activities
occurring
from
the
release
team's
perspective.
B
There
won't
be
any
deadlines
that
week
we
won't
have
release
team
meetings,
we're
also
going
to
treat
the
week
before
and
after
kind
of
as
a
loose,
also
kind
of
blackout
period,
but
not
as
formal
as
that
one
week
period.
B
So
with
those
three
things
in
mind,
those
those
three
kind
of
release
planning
things
in
the
cap-
we've
we've
kind
of
spelled
out
what
2021
would
look
like
with
the
three
release
cadence
and
what
22
would
look
like
with
the
three
release
cadence
and
what
you
end
up
seeing
is
that
we
end
up
with
a
release
in
april.
We
really
end
up
with
a
release
in
august
and
we
end
up
with
a
release
in
december.
So
with
those
three
things,
it's
pretty
predictable
to
know.
B
You
know
when
this
release
is
going
to
happen
down
to
a
week
or
two.
You
know,
depending
on
how
things
shift
within
the
year,
the
cap
is
currently
approved
by
almost
everybody
that
needs
to
approve
it.
We're
still
waiting
for
sick
testing
to
weigh
in,
but
everybody
else
has
provided
such
great
feedback.
We've
had
a
lot
of
back
and
forth
a
lot
of
really
great,
intense
collaboration.
B
To
get
this
to
the
point
where
it's
ready
to
go,
I
would
invite
everybody
to
to
go
check
it
out,
but
at
a
high
level,
three
things
coming
15
week
releases
two
weeks
between
releases,
no
no
release
activities
during
kubecon
and
that
will
result
in
three
releases
per
year.
A
E
Do
you
wanna
also
talk
about
how
we're
going
to
it's
a
bit
tbd,
but
how
we're
going
to
evaluate
whether
or
not
this
change
is
successful?
Yeah.
B
Thanks
for
I
totally
spaced
on
that
one,
so
what
we're
gonna
do
is,
after
every
release,
we're
going
to
submit
a
survey
or
send
a
survey
out
to
community.
This
is
you're
really
going
to
target
end
users
and
contributors
to
get
feedback
on
how
this
is
going.
B
What
changes
do
we
need
to
make
to
the
process
going
forward?
And
after
we
do
three
of
these
releases,
we're
going
to
take
that
feedback
and
make
a
decision
about
whether
this
would
become
a
permanent
change
or
whether
we
should
either
revert
back
to
the
old
way
or
think
of
another?
Do
we
need
to
make
any
other
alterations
to
the
process,
so
420
122,
123
124,
we're
gonna,
try
to
collect
that
feedback
and
and
work
through
the
survey
results
which
is
still
tbd.
B
We
have
a
couple
of
in
the
in
the
cap
issue.
There's
a
couple
of
related
issues
to
to
kind
of
firm
that
stuff
up
during
the
122
time
frame.
Those
surveys
will
typically
go
out
at
the
end
of
the
release
and
then
we'll
catch
up.
You
know
in
the
subsequent
release
to
process
that
information
and
kind
of
roll
it
into
the
next.
So
then,
after
we
collect
those
three
release,
feedbacks
we
will
kind
of
synthesize
everything
together
and
then
revisit
this
topic
with
a
public
communication
via
the
mailing
list.
D
I'm
kind
of
curious
just
to
how
we're
going
about
deciding
what
counts
or
like
what
the
goal
is
for
a
new
release
and
like
is
this
exclusive
to
just
the
main
kubernetes
project?
Or
does
this
also
sync
up
with
kubernetes
groups.
B
That
is
a
super
good
question
and
that's
another
topic.
That's
in
under
a
lot
of
discussion
right
now.
What
you
know.
Typically,
the
releases
are
really
focused
on
things
that
are
in
the
kubernetes
kubernetes
repo.
We
do
track
things
that
are
out
of
the
repo,
but
there's
not
a
great
policy
or
really
definition
of
of
what
releases
look
like
for
things
that
are
outside
of
kk.
B
When
we
talk
about
the
release,
we're
talking
mostly
about
kk,
we
do
track
things,
and
sometimes
there
are
blog
posts
that
go
out
for
those
other
things,
but
typically
the
release
itself,
so
121
122
is
really
building
off
of
things
that
are
in
the
kubernetes
kubernetes
repo.
What
goes
into
those
releases
really
comes
down
to
what
the
sigs
want
to
deliver
in
that
upcoming
cycle.
The
way
that
a
change
goes
into
kubrick's
is
through
a
kubernetes
enhancement
proposal
or
a
cap.
B
Authors
are
responsible
for
writing
those
things.
The
sigs
are
responsible
for
approving
and
reviewing
those
things
and
then
really
figuring
out.
What
bandwidth
do
they
have
to
work
on
these
things
during
the
upcoming
release?
So
the
the
way
we've
kind
of
moved
toward
to
collect
those
things
for
the
release
is
that
sigs
are
opting
in
and
telling
us
the
release
team.
Hey
we
plan
on
delivering
these
things.
You
know
it
could
be
five
things.
It
could
be
two
things.
B
It
could
be
one
thing
it
could
be
zero
things
when
they
opt
in
and
say
they're
going
to
deliver
these
features,
or
these
you
know
graduate
this
thing
from
alpha
beta
or
beta
disable.
Each
one
of
those
things
comes
with
a
certain
number
of
requirements.
It
may
have
to
have
a
pr
production
readiness
review.
It
may
need
to
have
a
feature
flag
change.
B
It
may
need
to
have
additional
tests
or
conformance
tests
delivered
for
it
and
part
of
what
the
release
team
does
is
once
somebody
has
opted
in
and
said,
hey
we're
going
to
do
this
thing
for
the
release.
It
really
seems
really
helping
them
meet
those
milestones.
So
we,
you
know
we're
looking
to
say
your
your
cap
isn't
fully
complete.
It
has
to
be
an
implementable
state.
It
has
to
have
graduation
criteria
defined.
It
has
to
have
test
plans
to
find
that's
what
and
winds
up
with
something
we
call
enhancements.
B
Freeze,
then,
from
that
point
on
code
has
to
be
done,
and
that
has
to
be
done
by
the
code
freeze
period
of
the
release
and
again
these
things
are
enforced
for
the
kk
repo.
Obviously,
things
don't
have
to
land
by
code
freeze
because
we're
not
locking
down
other
repos
the
code.
B
Freeze
mechanism
comes
into
place
for
the
kk
repo,
so
the
the
release
team
is
is
again
like
checking
to
make
sure
that
all
pr's
that
are
necessary
for
that
work
are
done,
making
sure
that
we
know
about
all
the
pr's
that
are
necessary
for
that
work
to
be
done,
so
we
can
track
it
checking
to
see
if
any
bugs
have
been
opened,
watching
ci
signal
and
kind
of
relating
it
back
to
those
prs
and
just
kind
of
doing
the
mechanisms
of
making
sure
that
those
things
successfully
land
in
the
release.
B
But
what
goes
into
the
release
really
comes
down
to
the
six.
So
if
signod
wants
to
land
some
brand
new
feature,
signal's
really
responsible
for
that
feature,
landing
they're
responsible
for
hitting
those
deadlines,
they're
responsible
for
the
cap
shepherding
through
that
process,
with
support
from
the
release.
Does
that
answer
your
question.
D
B
And
in
general
sig's
own
code
right
so
like
the
sig
node
signate
owns
things
like
the
cubelet
and
they
own
pieces
of
the
kubernetes
kubernetes
kind
of
giant
repo
that
are
really
specific.
To
signal
same
thing
for
storage,
same
thing:
for
api
machinery,
there
are
owner's
files
that
land
in
various
places,
that
kind
of
correspond
to
the
sigs
and
they're
responsible
for
making
sure
that
those
things
get
the
proper
reviews
that
the
code
gets
done
and
then
there
are
other
reviews
that
have
to
happen
too,
like
outside
of
just
node-specific
code.
B
There
may
have
to
be
api
reviews
that
happen
and
those
are
a
different
set
of
people,
but
they're
really
responsible
for
ensuring
that
those
things
those
checkboxes
get
done
before
the
release
happens.
If
those
things
don't
happen
like
buy,
enhancements,
freeze
or
buy
code
freeze,
we
remove
them
from
the
release.
B
So
the
the
release
team
does
own
some
of
that,
but
we,
we
have
some
say
over
what
gets
in
and
we
have
some
mechanisms
for
kind
of
client
things
back,
but
you
know
it's
a
shared
responsibility
with
a
lot
of
responsibility
landing
on
the
sticks.
I
see.
A
A
A
A
A
E
A
G
You
should
be
good
thanks,
so
I'm
gonna
share
my
screen
just
because
josh
asked
me
to
show
some
codes,
but
I
will
not
show-
and
I
will
try
to
keep
in
my
five
minutes
yeah.
So
we
are
trying
to
normalize
this
code
from
cube
ctl
and
the
best
way.
I
think,
to
show
you.
The
problem
is
actually
show
me
showing
the
problem,
so
the
first
one
is
uploading
that
I
wrote
the
uploading
that.
G
That
is
it's
with.
Yes,
it
called
whatever
I
put
right.
So
if
I
put-
and
I
don't
know
what
is
the
actually
actually
the
exit
code
from
qctl
right,
the
second
one
is
one
that
we
got
from
cityoutif,
which
god
returns
to
us
an
air
code
of
one,
but
by
main
pages
from
diff.
One
is
if,
if
it's
different
to
is
if
in
trouble-
but
we
didn't
had
this
before
like
it-
was
returning
one
for
everything
and
we
have
a
bunch
of
of
our
codes
that
show
us.
G
G
Quick
yeah,
so
if
I
do
this
inside
I
get
an,
is
it
called
one?
So
I
guess
I've
shown
you
what's
what's
the
point
here
right?
The
problem
that
we
get
here
is
anything
that
you
run
inside,
cube.
Ctl,
you
get
you
get
an
error
code
which
doesn't
doesn't
symbolize
or
doesn't
represent
what
what
actually
happened?
You
don't
know
if
the
the
error
code,
what
is
from
the
client
side
or
from
the
server
side,
or
even
if
it's
from
an
external
command
like
from
diff.
You
cannot
delegate
that
for
diff
or
for
a
plugin.
G
If
a
plugin
wants
to
as
it
wants
to
return
a
different,
is
it
called
other
than
one
to
represent
things
we
just
we
we
just
don't
know
we
it
can.
It
can
use
the
the
our
code
from
from
the
plugin
and
simulate
that
something
correctly
or
clear
it,
but
it
doesn't
right.
So
the
main
points
points
of
attention
that
that
we
went
actually
the
first
one.
It's
hard
to
pragmatic
pragmatically
distinguish
errors
from
cuba,
city
or
commons.
We
we
don't
know
what
ever
happened
right.
G
We
don't
know
where
did
her
happen
if
they
ever
happened
in
the
client
side
or
in
or
if
it
happened
in
the
server
side
or
even
if
the
it
was
a
c
program,
different
error
code
and
what
we
want
with
this
cap
is
to
document
the
possible
cube,
ctrl
visit
codes,
so
the
same
way
that
we
have
in
other
unix
programs.
That
say
so.
G
If
you
got
this
error
code,
it
symbolizes
this
thing
or
if
you
get
the
this
other
code,
it
symbolizes
the
other
thing
right
and
also
to
allow
to
delegate
to
the
sub
commands
like
different
plugins
to
have
their
own
as
it
codes.
But
this
doesn't
this
as
this
should
not
impact
in
the
in
the
error
called
from
qctl,
and
we
want
to
gradually
implement
the
as
it
called
standardization
for
each
command.
G
So
we
still
need
to
resolve
how
we
are
going
to
do
that
because
we
can
standardize
at
once,
but
or
we
can
do
that
gradually.
But
this
this
this
might
get
some
impact
impacts
for
the
user.
And
why
are
we
bringing
this
here?
Because
we
have
two
possible
caveats
at
least
right.
So
the
first
one
is:
we
cannot
use
well
known
as
codes.
I
I
will
put
the
nodes
that
I'm
reading
here,
because
I
am
like
I
I
that
there
are.
G
There
are
some
links
here
and
the
other
one
and
the
mostly
notable
is
cis
or
users
that
already
relies
on
on
the
behavior
of
cube
ctrl
nowadays
right.
So
if
they
behaves
on
dsd
called
one-
and
we
say
oh
see
now
we
are
going
to
say
that
if
the
network
occurs
in
the
server
side,
we
are
going
to
use
the
other
code
65
to
70..
G
We
are
going
to
define
those
those
is,
it
called
range,
so
this
might
impact
in
some
ci
cd
or
even
in
users
relying
into
these
in
scripts,
and
we
have
some
unresolved
needs
and
things
that
needs
attention.
So
how?
How
is
this
behavior
going
to
happen
with
windows
users?
I
I
really
don't
know
about
that.
So
probably
we
we
should
bring
folks
using
cube
ctrl
in
windows
and
how
to
deal
with
what
specific
is
it
called
when
using
cube,
ctrl
run
or
cubicity
iosec,
and
this
is
something
that
we
are
we
are
still
discussing.
G
I
I
already
I
I
also
put
in
the
notes
some
code
navigation.
If
someone
wants
to
know
how
the
comments
they
they
happen,
inside
cube
cto
with
the
complete,
validate
and
run
it's
pretty
nice
and
what
how
how
the
error
they
are
delegated.
G
But
I
think
that
the
most
the
most
important
thing
here
is
that
we
need
the
feedback
from
the
community,
because
this
is
this
might
be
a
breaking
change
for
a
lot
of
ci
cd
providers
or
for
people
relying
on
on
different
as
it
codes.
So
please,
folks,
I
I
I
really
love
answering
comments
that
just
just
help
us
doing
that.
Okay-
and
I
guess
that's
how
I
don't
know
if
matcha
or
eddie,
they
want
to
say
something
else,.
F
No,
I
think
ricardo
presented
the
topic
very
well.
What
I
wanted,
probably
to
add,
is
have
a
look
at
the
cap.
I
linked
the
cap
ricardo
also
linked
in
the
notes
that
he
put
together
before
we
start
actually
writing
something.
F
We
would
love
to
get
as
much
feedback
as
possible,
since
this
will
be
a
bigger
change
that
will
be
with
us
for
probably
for
the
remaining
time
of
the
cube
cuddle
lifetime,
and
we
don't
expect
to
break
that.
After
this
happens,
the
actual
implementation
should
be
pretty
straightforward.
It
is
the
initial
discussion
and
the
feedback
that
we
want
to
gather
about.
The
shape
of
the
proposal
is
critical
to
kick
it
off,
so
we
won't
be
definitely
rushing
with
this.
F
F
A
C
I
I
mentioned
this
in
chat,
but
if
you
do
want
to
reach
out
to
some
end
users,
we
can
engage
directly
with
the
cncf
end
user
group
and
direct
them
to
provide
feedback
to
the
cap.
C
We've
done
that
before
mostly
for
surveys.
So
I
don't
know
if
you
want
to
just
have
them
comment
directly
on
the
cap
or
potentially
have
like
a
feedback
survey
or
something
like
that,
but
either
way
we
can
send
something
out
to
them.
B
G
C
E
Some
of
my
other
questions
here
is
going
to
be
what
plans
do
we
have
for
user
outreach,
because
I
actually
see
a
lot
more
potential
for
breakage.
E
You
know
with
people's
personal
bash
scripts
than
necessarily
with
actual
project
plumbing.
H
I
think
this
could
be
weaved
into
the
larger
discussion
around.
How
do
we
talk
about
changes
in
the
project
during
the
release
process?
It
sounds
like
something
that
would
be
feasible
to
have
as
a
pre-release
bloggy
thing
as
well
as
noted
in
and
in
the
release
notes,
and
I
guess
the
the
all
of
the
release
train
communication
that
we
do
once
the
release
actually
goes
out.
E
Yeah,
I
think
we
need
to
engage
the
you
know
contributor.
Well,
this
isn't
really
contributor
marketing,
although
they
probably
have
some
ideas,
because,
like
one
of
the
questions
I
have
up
in
the
air
that
I
really
have,
no,
I
don't
know
you
know
central
dilemma
is:
is
it
better
to
have
a
large
message
saying:
hey
here's,
the
things
we're
about
to
break
in
this
release,
which
would
actually
be
nice
to
have
in
general
versus
giving
out
messages
for
specific
issues?
E
Because
always
my
worry
about
a
roundup
message
is
that
people
won't
read
the
whole
thing
and
then
they'll
miss
the
issue.
That
really
applies
to
them.
H
So
I
so
we
were
yeah.
We
were
actually
discussing
some
of
this
in
sick
release
recently.
I
think
that,
as
part
of
the
as
part
of
any
cap
that
may
I
think
it's-
I
think
it's
worthwhile
to
more
visibly
note
when
a
cap
involves
a
deprecation,
and
I
think,
as
part
of
that
there
could
be
an
addition
to
the
release
team
checklist.
That
says,
like
hey,
is
your
thing.
H
A
deprecation
here
are
some
additional
things
that
you
should
do
to
make
sure
that
it's
it's
visible
to
people
who
might
be
consuming
this,
this
enhancement,
so
that
doesn't
exist
today,
but
I
agree
that
the
for
the
talking
about
wide
scale
changes
some
folks
mentioned
contributor
marketing.
I
think
it's
important
that
the
sig,
the
sig
sig
docs,
sig,
release
and
contributor
marketing
are
involved
in
whatever
that
communication
plan
is.
F
I
mean
for
this
particular
change,
and
I
I
think
that
could
easily
apply
to
similar
broader
changes
is
promoting
the
change
discussing
about
it
and
making
sure
that
it
is
not
on
by
default.
So
you
need
to
explicitly
set
some.
F
I
don't
know
flag
environment
variable
something
to
opt
in,
provide
the
feedback
and
in
the
early
stages
speak
up
about
it,
and
you
know
at
the
early
stage,
will
be
open
about
oh
yeah,
it
will
change,
but
you
can
already
provide
feedback
from
something
working
because
from
my
personal
experience,
I
know
that
there
are
people
more
willing
to
provide
feedback
when
they
could
give
it
a
try,
rather
than
here
at
his
eyes,
no
problem.
B
One
of
the
things
that
I
had
in
mind
too
was:
is
there
any
sort
of
mailing
list
or
circle
for
people
who
provide
manage
kubernetes
as
a
service
like
the
cloud
providers
and
some
of
the
other
sas
companies,
because
that's
a
great
way
to
get
folks
to
ask
their
customers
directly?
So
the
cncf
has
a
list
cool.
A
All
right,
so
we
did
this
reboot
with
only
30
minutes
on
the
clock,
so
we
are
at
time,
but
I
know
some
people
probably
really
want
to
keep
talking,
so
I
don't
think
we
can.
We
can
stop
if
folks
want
to
keep
talking
about
different
topics.
We're
welcome
to
stay
on.
A
I
do
want
to
just
take
a
quick
note
or
two
for
the
folks
who
do
need
to
hop
off.
There
are
like
4.5
chain
pages
of
shout
outs
that
I'm
not
going
to
read
out
like
I
normally
would
do
at
the
end
of
a
community
meeting.
Please
do
go
check
those
and
we
will
read
them
out
at
the
next
community
meeting,
but
shout
out
to
just
everybody
thanks
all
for
coming.
A
We
really
appreciate
you
joining
us
for
this
new
experiment
of
the
community
meeting
being
more
of
a
discussion
format
and
again,
if
you
have
any
feedback
on
that,
you're
welcome
to
reach
out
and
folks
can
stay
on
and
keep
talking.
But
I
wanted
to
make
sure
I
got
that
in
there
for
folks
who
have
to
jump
off.
H
I
have
a
quick
one
before
we
stop
the
recording
so
just
to
back
up
on
the
upcoming
patch
schedule.
What
we
were
discussing
within
what,
by
having
one
additional
118
release,
was
to
line
it
up
with
the
the
current
patch,
the
upcoming
patches,
so
the
release
date
for
apparently
can't
edit
the
working
dock,
but
the
release
date
for
118-19,
the
cherry
pick
deadline
is
may
7th
and
the
release
target
will
be
may
12th.
A
H
A
A
I
I
I
For
example,
if
you're
doing
a
some
kind
of
a
pull
image
or
run,
you
may
not
get
the
error,
you
would
get
if
you
read
the
entire
logs.
Well,
we
tried
over
here
we
tried
over
there.
You
know.
Sometimes
one
error
doesn't
really
explain
the
whole
thing,
so
it
just
just
adds
up.
We
we
can
help
at
the
cry
level.
H
A
Yeah
we
had
a
little
bit
of
an
issue
with
the
google
calendar,
so
short
versions
were
quite
large
as
a
group
and
apparently
that
causes
some
problems
for
our
community
calendar.
So
we're
going
to
be
working
on
that
eventually,
but
that
hopefully
might
explain
why
it
appeared
and
then
disappeared,
and
then
there
were
emails.
So
I
apologize
on
that
one
which
which
emails,
because
I
want
to
make
sure
I
get
that
into
the
notes.
It
was
sig
networking
and
what
was
the
other
one.
A
But
on
that
note,
I
think
we're
kind
of
hitting
the
end
of
the
conversation
today
so
again.
Thank
you
so
much
for
sticking
around
a
little
bit
longer
than
the
original
invite
that
disappeared.
That
reappeared,
that
disappeared
actually
had
on
the
calendar.
I
hope
you
all
found
something
very
interesting,
but
thank
you
all
for
coming.