►
Description
When Slack seems like it’s going too fast, and you just need a quick answer from a human...
Meet Our Contributors gives you a monthly one-hour opportunity to ask questions about our upstream community, watch interviews with our contributors, and participate in peer code reviews.
Check out this page for more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
Mentoring
on
demand
these
fine
folks
who
are
upstream
kubernetes
men
upstream
kubernetes
contributors
dedicated
the
next
hour
to
helping
you
with
your
upstream
adventure,
so
whether
you're,
new
or
current,
we're
here
to
help
whether
you're,
an
early
contributor
or
you're
just
now,
starting
either
way
we're
here
to
help
we
get
all
kinds
of
questions,
and
so
that
brings
that
brings
me
to
my
next
thing
with.
Where
can
you
go
to
ask
those
questions?
That's
slack!
A
If
you
are
not
on
the
kubernetes
slack
channel,
I,
definitely
recommend
it
slack
Kade
CIO
the
channel
is
meet
our
contributors
and
you
can
ask
there
or
if
you'd
like
to
ask
anonymously,
you
can
DM
me
there
on
slack
again.
My
name
is
Paris
its
that
matches
the
way
you
see
on
YouTube
right
now,
and
you
can
also
tweet
at
us
whatever
get
it
to
us,
and
that
brings
my
bring
me
to
my
last
item
that
I
need
to
talk
about
which
is
code
of
conduct.
A
We
do
abide
by
one,
that's
under
the
colonnade
of
computation,
the
TLDR.
There
is
the
excellent
to
each
other
like
we
are
every
day
and
everything
would
be
awesome
that
includes
like
Twitter.
That
includes
our
slack
space
wherever
we're
talking
and
panelists.
This
also
goes
for
you
so
also
feel
free
to
ask
each
other
questions.
A
I'm,
not
sure
if
you
know
each
other
we're
about
to
find
out
in
the
introductions,
but
you
are
allowed
to
be
mentored
like
anyone
else
and
feel
free
to
ask
you
two
other
questions,
so
we
have
three
panelists
with
us
today.
We
also
Jorge
from
VMware
who
is
helping
us
with
VJ
duties
to
YouTube
so
wave
the
Jorge
everybody.
If
you
get
here
us
on,
if
you
can
hear
us
on
YouTube
and
then
let's
go
right
into
intros
Andy
you're.
First
thanks.
B
Paris
I'm
Andy
Goldstein
I
currently
work
at
VMware
with
George
and
some
background
on
me.
I've
been
working
kubernetes
for
yes
about
the
past
five
years
now,
I
started
when
I
was
at
Red.
Hat
I
actually
worked
on
open
shift,
which
was
a
version
of
open
shift
for
kubernetes
existed
and
then
I
helped
with
the
the
core
OpenShift
team
get
open
shift
3
out
the
door.
I
worked
a
lot
on
the
image
registry
aspect
of
open
shift.
3
I
also
wrote
cute
control,
exec
attached
important
forward.
B
So
if
you've
ever
used,
those
the
initial
implementations
came
for
me
and
after
leaving
Red
Hat
in
2017,
I
went
to
hep,
do
startup
from
Joe
Beda
and
Craig
McKee,
two
of
the
cofounders
of
kubernetes
and
I
took
a
little
bit
of
a
break
from
working
on
kubernetes
itself
and
I
was
the
team
lead
for
arc,
which
is
now
bolero,
which
is
the
backup
and
recovery
tool
that
we've
been
working
on
for
the
past
couple
of
years?
That's
open
source
we're
trying
to
build
a
community
around
that
right
now
the
team
lead
is
steve
chris.
B
So
that's
in
other
people's
hands.
Right
now,
I
miss
it
a
little
bit,
but
what
I'm
currently
working
on
is
cluster
API,
which
is
part
of
state
cluster
lifecycle,
and
the
goal
that
we
have
with
cluster
API
is
to
try
and
provide
the
same
sort
of
declarative
style,
api's
that
you're
familiar
with
for
pods
and
deployments
and
all
the
other
typical
kubernetes
primitives
that
you're
used
to.
We
want
to
have
that
same
style,
but
use
it
to
manage
your
clusters
and
your
machines.
B
So
how
can
I
start
from
basically
nothing
and
end
up
with
one
or
more
clusters
with
as
many
nodes
as
you
can
imagine
and
have
capacity?
For
so
that's
what
we're
working
on
with
cluster
API
and
I
guess
a
couple
other
things
I'm
on
the
East
Coast
I'm
in
Rockville,
Maryland,
so
close
to
Baltimore
for
Paris
and
I,
have
I've,
got
a
kids
and
a
couple
cats,
and
that's
about
it
for
right
now.
I
guess.
A
C
C
So
right
now
we're
kind
of
in
the
middle
of
these
two
systems
and
we're
trying
to
shim
everything
to
the
new
system
with
no
user
disruption.
So
that's
what
I'm
working
on
right
now,
besides
that
pretty
much
yeah
I
work
at
Google.
If
that
wasn't
clear
from
before-
and
this
is
actually
my
first
job
out
of
college,
so
I've
been
here
for
two
years
and
before
that
I
was
at
Carnegie
Mellon
very.
D
Everyone
I'm
tall
I'm,
a
Google,
was
a
bit
I
joined,
so
kubernetes
is
also
my
first
job
after
graduate
I
started
around
2015
a
pro.
So
it's
my
four
year
anniversary
with
kubernetes
I
have
been
working
on
the
API
machinery
stuff
since
I
joined
I.
Think
my
main
contributions
includes
at
a
garbage
collector
the
client
goal,
library,
I
and
the
entire
stage
in
all
the
three
idea.
I
have
you,
like
you,
hated
also
the
admission
webhook
and
currently
I'm,
focusing
on
safely
how
to
safely
upgrade
downgrade
kubernetes
clusters
and
specifically,
I'm
working
on
the
storage.
D
A
B
A
B
I
kind
of
bounced
around
through
several
different
technologies
and
products
or
projects
over
the
past
several
years,
so
I
spent
a
lot
of
time.
Writing
Java,
back-end
stuff,
so
spring
EJ
B's
running
on
JBoss-
and
this
was
before
I
worked
at
Red
Hat,
as
well
as
after
I
also
had
a
lot
of
experience,
doing
messaging
systems
with
Apache,
Cupid
and
then
and
I
mean
it
was
just
sort
of
when
I
was
consulting.
B
It
was
whatever
the
client
needed,
and
so
as
I
got
to
the
point
where
I
decided
I
don't
want
to
travel
so
much
as
the
consultant
anymore,
I
started.
Looking
at
what
seemed
to
be
interesting
to
me
in
in
Red
Hat's
portfolio
and
OpenShift
too
at
the
time
was,
was
really
intriguing,
with
the
ability
to
just
take
your
source
code
or
bring
your
source
code,
and
let
openshift
worry
about
everything
else.
B
Think
I
like
the
platform
I
like
the
way
it's
constructed,
I
really
love
the
people.
We
have
a
great
community
here.
I've
made
a
lot
of
great
friends
over
the
past
several
years,
both
virtually
and
in
person
going
to
cube
cons.
So
I'd
say
that's
why
I'm
sticking
with
it?
It's
just
all
of
that
together.
C
Yeah
I
could
come
at
it
from
a
slightly
different
perspective,
like
from
a
personal
goals
or
impact
kind
of
perspective.
I
guess
why
I
choose
kubernetes
as
opposed
to
working
on
something
else.
C
In
this
case
kubernetes
and
you
know,
you're
saving
like
man-hours
man
days,
man
or
person
years.
You
know
with
your
changes
and
your
and
your
efforts,
I'm
so
kind
of
like
the
multiplicative
effect
of
the
changes
that
we
make
to
kubernetes
and
how
they
affect
the
industry
as
a
whole.
The
tech
industry
as
a
whole
and
how
that
in
turn
will
affect
kind
of
the
world
as
a
whole.
So
I
find
that
really
interesting.
D
So
for
me,
yeah
I,
like
David
I,
always
I
when
I
was
in
the
graduate
school
I
want
to
work
on
infrastructure.
I
always
worked
would
like
to
work
on
the
back
end,
not
the
front
end,
and
when
I
got
my
Google
offer,
I
need
to
choose
a
team
and
I
think
the
option.
My
god
back
then
was
between
an
internal
Google
system
called
a
bog
and
the
kubernetes
team.
D
So
I
think
they
are
they're
very
similar
to
each
other
and
article
a
kubernetes
team
have
a
lot
of
so
I
asked
my
friends
in
the
industry.
They
say
they
do.
They
have
already
heard
about
kubernetes
I,
think
that's
still
pre
the
GA
of
kubernetes
kubernetes
is
already
gathering
a
lot
of
attention
and
I
was
thinking.
D
Organ
kubernetes
they're
working
on
similar
problems
and
kubernetes,
is
open
source.
So
it's
cool.
Everyone
can
see
your
contribution
and
and
Google
is
willing
to
pay
me
to
work
on
open
source.
Why
not?
It's
a
obvious
decision
for
me
and
I
really
enjoyed
my
time
at
kubernetes.
So
I
stayed
here
for
four
years
so
far.
B
A
B
B
So
for
our
end,
users,
who
are
interested
in
being
able
to
execute
commands
in
containers
in
pods
or
port
forward
or
attach,
there
are
better
protocols
that
are
now
available
that,
due
to
not
getting
prioritized
and
not
having
people
to
work
on
it,
it
just
hasn't
been
addressed
yet
so,
like
I
I
wished
that
we
had
picked
something
different.
That
was
a
little
bit
more.
B
You
know
widely
acceptable
across
proxies
and
different
technologies
like
the
web
web,
browsers
and
command-line
clients
and
different
different
languages.
If
you're
trying
to
do
an
integration
yourself
so
that
that's
something
I
would
have
done
differently
is
pick
a
different
protocol
for
for
those.
Oh.
B
C
I
can't
think
of
any
particular
hardest
decision.
I
think
we
make
a
lot
of
decisions
every
day,
I
think
every
contributor
does,
and
you
know,
with
the
impact
on
the
community
being
so
high,
like
every
decision
is
hard
in
its
own
way,
but
I
can't
think
of
any
specific
case
that
I'd
like
to
talk
about.
How
do
you
have
anything
I.
D
That
was
a
quite
hard
decision
for
me,
because
I
was
I
was
largely
involved
in
post
features
and
they
serve
more
or
less
similar
purposes.
I
think
at
first
I
was
very
fervent
on
pushing
the
initializer
feature
into
GA,
as
I
write
to
beta.
Then
we
realized,
after
after
having
met
I
had
invested
like
three
months
of
time.
In
the
initializer
thing,
we
realized
that
there
are
just
too
many
technical
obstacles
to
overcome
and
the,
but
because
of
the
sunken
investment
it's
hard
to
switch
our
course
in
the
in
the
middle.
D
Careful
calculation
of
the
cost
and
the
benefits
and
we
decided
to
switch
our
costs
to
push
the
webhook
feature
to
beta
instead
I
think
it's
a
right
call.
The
worker
feature
is
we
have
read
we're
trying
to
bring
it
to
GA
in
next
quarter
and
it's
well
adopted.
So
it's
a
hard
decision,
but
it's
a
distinct.
It's.
C
B
B
A
So
how
do
you?
How
do
you
not
take
it
personally
like
when
this
question
came
up
earlier
in
the
last
session,
when
you
create
something
and
someone
says
it's
broken
or
that
it
doesn't
work
for
them
or
it
doesn't
work
period
howdy?
What
do
you
know?
What
are
some
some
things
that
you
think
about?
In
that
case,
I.
B
It
personally
it's
hard,
especially
if
it's
code
that
you've
written
so
when
I
was
the
tech
lead
for
arc
slash
Valero.
It
was
great
to
see
all
the
random
people
coming
in
and
asking
questions
and
it's
humbling
because,
like
either
they're
doing
something
wrong
or
you've
done
something
wrong
with
your
code
or
you've,
designed
it
where
it's
too
difficult
for
people
to
use,
and
so
I
think
you
have
to
recognize.
B
Is
that
you're
going
to
get
feedback
and
that
it's
going
to
vary
and
you
need
to
pause
and
not
make
not
have
rash
responses
or
gut
responses
without
really
thinking
like
hey.
This
person
is
not
necessarily
attacking
me
and
my
code
they're
just
trying
to
use
the
tool
or
whatever
it
is,
and
if
it's
not
working,
then
let's
try
and
figure
out
what
the
problem
is
and
fix
it.
But
it's
hard.
It
really
is.
C
Our
grid
hearts
yeah
I.
Think
for
me,
like
I,
remember,
reading
something
somewhere
before
where
that
said,
like
you
are
not
your
code
and
I.
Think
thinking
about
that
sometimes
helps
me
a
little
bit
like
the
code
is
just
kind
of
an
artifact
of
what
I
was
thinking
at
that
current
time
and,
of
course,
I
am
as
a
person
and
a
and
a
software
developer,
I'm
growing
all
the
time,
like
even
code
that
I
wrote
six
months
ago,
sometimes
I
will
look
at
it
and
be
like
wow.
C
That's
not
not
great
or
I
would
have
done
this
differently,
and
so
it's
important
to
realize
that
like,
although
even
if
your
code
there's
like
some
criticism
on
your
code,
that's
not
criticism
on
you
or
your
abilities.
It's
just
you
know.
Maybe
you
didn't
write
the
best
thing
or
the
right
thing
or
the
needed
thing
at
that
moment
and
that's
totally
fine.
You
can
grow
and
you
can
improve
on
it
as
well.
You.
E
D
For
me,
I
I,
don't
I,
don't
really
feel
like
being
attacked,
but
I
will
be
very
I
would
be
very
worried,
worried
if
someone
is
criticizing.
My
coat
I
will
I
love.
You
I
owe
something
to
the
user.
I
mean
I
owe
that
I
owe
them
a
fixed,
but
sometimes
it's
just
there's
just
too
many
problems,
because
I
have
worked
on
the
project
for
quite
a
long
time.
They're
they're
quite
I
mean
my
footprint
is
quite
large,
so
there
are
sometimes
there
are
just
too
many
issues.
D
I
cannot
handle
and
at
that
time
I
I
found
it.
The
community
is
very
helpful.
Commit
many
community
members
are
willing
to
take
over
the
feature
you
used
to
own
or
do
it
many
people
are
just
they're,
not
just
submitting
issues.
People
are
also
willing
to
look
into
the
problem
and
help
you
to
debug
it.
So
I
think
the
community
is
giving
me
makes
me
feel
we
are
powerful
I'm.
Not
if
working
on
this
product
alone.
A
This
is
good,
it's
giving
me
the
warm
and
fuzzies
all
right
so
back
to
my
DMS
here
for
one
second,
those
were
really
good
responses
all
right,
so
we
have
a
direct
message
and
they
want
to
know.
Oh
it's
in
regards
to
API
machinery,
specifically,
they
want
to
know
like.
Why
is
it?
Why
is
the
on
ramp?
That's
so
hard,
and
why
is
it
so
difficult
like
what
are
some
of
the
concepts?
You
think
that
contributors
get
stuck
with
that?
Are
that
make
it
difficult.
B
So
if
we
get
it
right,
then
you're
either
like
working
with
API
machinery
or
you're,
not,
and
ideally
the
the
people
who
are
working
on
API
machinery
are
fairly.
It's
like
a
small
sized
group
because
it
should
just
get
out.
It
should
be
out
of
your
way
like
if
you're,
a
kubernetes
end-user
or
you're
developing
in
the
ecosystem.
B
C
The
way
I
learned
it
was
that
I
had
I
asked
for
a
review
from
a
more
experienced
developer
and
they
they
very
quickly
pointed
out
like.
Oh,
you
could
use
an
informer
here
and
just
being
open
to
that
idea
and
like
looking
into
it,
was
the
way
that
I
learned
about
a
lot
of
these
concepts
so
like
having
having
someone
experienced
review
your
code
as
soon
as
possible
is
helpful
to
help
unveil
kind
of
these
things.
D
Yeah
I
do
feel
so
when
I,
when
I
first
started
on
the
project,
I
was
always
on
the
API
machinery
team.
For
me,
I
also
learned
all
these
things.
The
hard
way
I
have
to
read
the
source
code
myself
to
to
just
understand
how
this
thing
works,
and
my
feeling
is
many
times
I,
don't
know
why
things
are
returning
this
way.
I
just
have
to
accept
it
and
develop
on
top
of
it.
I
do
agree.
We
can.
We
should
do
more
work
on
the
document,
documentation
we
and
yeah
I,
don't
know.
D
B
D
Also,
we
have
a
public
bug,
scrub
every
Monday
and
this
Thursday
now
so
we
are
going
over
the
open
issues
and
open
cures
for
sig
API
machinery.
I
think
this
thing
has
has
worked
well
inside
Google
when
we
onboard
a
new
member.
You
know
API
machinery
team.
We
bring
them
to
the
bug
scrub
and
get
familial
rights
to
us
all.
The
concepts
in
API
machinery
I
think
yeah
you're
welcome
to
join
the
bugs,
but
that's
also
a
good
way
to
get
a
get
exposure
to
the
code.
Yeah.
A
B
B
So
excited
I've
got
my
pull
request,
kubernetes
and
then
it
just
sits
there
and
maybe
maybe
you
try
and
figure
out
whatever
sig
is
responsible
for
for
reviewing
it
or
it
gets
auto
assigned
reviewers
and
you
ping
them
and-
and
you
don't
get
any
response
so
I
always
say
that's
a
pitfall.
That's
not
a
a
fault
of
a
contributor
by
any
means,
but
something
that
we're
definitely
trying
to
work
on
to
make
sure
that
PRS
don't
go
unreviewed,
but
there's
also
processes
for
how
to
get
new
features
into
kubernetes
that
have
evolved
over
time.
B
So
before
kubernetes
was
1.0,
you
could
just
open
up
a
pull
request
and
the
community
was
small
enough
that
we
would
get
it
reviewed
and
it
would
get
eventually
get
merged.
But
now
we
have
all
the
special
interest
groups
and
we
have
the
kubernetes
enhancement
process
with
caps,
and
so
it's
it's
not
okay,
anymore,
necessarily
to
just
open
up
a
giant
pull
request
that
have
some
good
feature
so
understanding
the
process
is
a
potential
pitfall
if
you,
if
you're,
not
aware
of
it
as
well.
D
To
to
add
on
the
Andy's
point,
I
think,
if
you're
trying
to
make
some
very
big
new
features,
if
you
are
a
new
contributor,
it
will
be
difficult
to
sell
because
that's
it
maybe
the
stick
doesn't
know
you
well
I.
Think
a
better
approach
might
be
starter,
was
fixing
like
bugs
and
issues
and
get
the
sick
get
the
special
interest
group
to
know
you.
First
and
after
you
accrue
some
credit,
then
then
you
can,
because
you
can
add
a
new
features
like
you
can
join.
You
can
come
to
the
community.
D
C
Think
I
mostly
agree
with
child,
but
I
also
don't
want
to
discourage
people
from
taking
like
a
meteor
feature
as
their
first
item.
If,
if
that's
what
you
wish
to
do,
but,
but
if
you
wish
to
do
that,
I
would
encourage
you.
I
would
say
like
the
pitfall
would
be
like
what
Andy
said
earlier,
where
you
just
submit
a
giant
PR
out
of
nowhere,
and
it's
very
likely
that
it
won't
really
go
anywhere.
People
won't
review
it.
C
You
don't
know,
what's
going
on
really
I
encourage
you
if
you're
doing
your
first
feature
or
something
to
really
go
through
the
cig,
so,
for
example,
if
you're
developing
and
if
you
see
the
need
for
a
new
storage
feature
and
it's
not
currently
being
developed,
and
you
want
to
propose
it,
there's
a
process
to
do
that.
So,
like
you,
should
you
could
reach
out
to
the
cig.
C
First,
like
six
storage,
ask
about
like
and
kind
of
talk
about
a
little
bit
and
then
you're
going
to
need
to
like
come
up
with
a
design
or
I
believe
we
use
caps
now
to
kind
of
encompass
that
design
process
and
really
go
through
the
whole
process
that
we've
built
to
get
that
feature
in
and
then
by
the
time
you
submit
your
pull
request.
Everyone
knows
what
you're
doing,
why
you're
doing
it
and
how
it
will
be
useful
to
the
community
and
your
pull
requests
will
have
a
much
easier
time
getting
merged.
A
A
B
I
can
at
least
give
a
readout
on
Cluster
API.
So
we
are.
We
released
our
initial
alpha
API,
the
one
alpha
one
at
the
end
of
March
in
beginning
of
April,
and
that
was
I
think
about
a
year
and
a
half
in
the
making,
but
we
recognize
that
there's
some
shortcomings
and
so
we're
trying
to
refine
the
API
the
overall
flow
of
things,
and
so
we
have
a
few
different
work
streams.
If
you
will
that
are
trying
to
put
together
some
some
proposals
for
changes
to
cluster
API,
so
they're
not
exactly
good.
C
So
so
we
in
six
storage,
sorry
I'm
just
trying
to
pull
up
the
date
that
I
need
to
reference.
It
is
in
a
second
yeah,
so
we
in
six
storage
or
are
always
looking
for
new
contributors.
We
have
way
too
much
work,
not
enough
people
working
on
it
and
one
unique
thing
about
us
all:
right,
I'm,
not
actually
sure
if
it's
unique,
but
since
moving
to
the
container
storage
interface,
the
plug-in
mechanism
for
storage
are
our
code
and
our
issues
are
actually
spread
out
across
several
different
repositories.
C
Now
so
they're
not
actually
all
going
to
be
in
kubernetes
kubernetes.
So
the
best
way
to
get
involved
with
CSI
and
with
six
storage
in
general
I
think
is
to
join
our
sig.
You
can
ask
questions
on
the
slack
channel.
We
have.
We
have
people
monitoring
that
pretty
much
all
the
time
you
ask
how
you
can
get
involved
or
we
have
our
Sigma
ting
I-
think
every
second
Thursday
at
9:00
a.m.
C
Pacific
time,
which
you
can
join
as
well
and
always
ask
how
you
can
help
out,
because
the
sig
is
going
to
be
your
central
location,
where
we
kind
of
have
the
pooled
experience
of
like.
We
know
where
all
the
issues
are
and
we've
done
an
ok
job
of
tagging.
Things
as
like,
Help
Wanted,
good
first
issue.
But
although
they're
tagged,
it's
hard
to
find
those
issues
in
the
first
place,
so
the
best
place
to
go
would
be
to
start
with
our
sig
slack
channel
or
a
sig
meeting.
D
Force
for
the
su
KPI
machinery-
I,
don't
I,
don't
know
any
open,
Help
Wanted
the
issue
of
the
top
of
my
hat
I
want
to
promote
the
open.
The
public
bug
scrub
again.
I
think
that
would
be
a
great
way
to
get
involved.
You're
welcome
to
join
the
meeting,
and
if
there
are
some
good
good
candidate
issue
for
new
contributor,
we
can
just
give
it
to
you
during
the
Box
growth.
A
B
B
B
A
I
think
everybody
said
not.
You
know,
plus
one
agreement
there,
so
what
he
said
all
right.
Well,
anybody
have
any
questions
for
each
other.
It's
nothing
that
rats
to
call
alright.
That
wraps
maze
edition
of
meet
our
contributors.
Thank
you
so
much
again
to
all
three
of
you,
including
n+
George,
for
taking
your
time
out
today
to
help
several
people
one
on
one
definitely
does
get
time
burdensome.
So
this
is
a
great
way
to
help
people
at
scale.
So
thanks
a
ton
alright
and
that
wraps
us
up
we'll
see
everybody
again.