►
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.
For more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
A
All
right,
you
friendly
be
friendly.
Hi,
everybody
welcome
to
November's
edition
of
meet
our
contributors.
My
name
is
Paris
I
work
at
Google.
We
have
a
awesome
panelists
panel
today
from
steering
committee
members
who
are
also
all
mentors
as
well.
They
do
their
part,
but
this
session
you
can
address
governance,
questions
any
really
any
question
about
the
project
and
in
order
to
do
so,
please
use
the
meet
our
contributors,
slack
channel
or,
if
you'd
like
to
be
anonymous,
feel
free
to
DM
me
on
slack
it's
my
name,
Paris,
that's
being
displayed
right
now
and
zoom.
A
C
A
And
please
be
excellent
to
each
other
panelists
included.
If
you
have
something
to
say,
please
raise
your
hands
and
I
will
come
to
you,
but
with
that
I
think,
let's
get
started
first
things.
First,
we'll
do
some
quick
intros.
First
George,
you
want
to
say
a
quick
intro.
I
know:
George
is
on
the
are
what
we
call
our
ones
and
twos
rvj
George
works
that
have
teo
and
he's
awesome
and
then
Sara.
Let's
start
with
you
for
a
quick,
intro
sure.
C
D
My
nickname
is
dibs,
I
have
a
longer
name.
If
you
would
like
to
know,
you
know
me,
I
work
for
Huawei
and
I
kind
of
like
go,
find
things
that
are
broken
and
try
to
fix
them,
and
things
like
that
generally
help
out
in
the
project
mainly
work
on
upstream
in
Cuba
notice,
and
you
know
I
used
to
work
on
OpenStack
as
well,
so
I
have
a
little
bit
of
a
background
and
working
in
open
communities.
D
E
Everybody
I'm
Coleman
I
work,
the
Red
Hat
I've
been
working
on
kubernetes
since
the
day
it
went
public
as
an
open
source
community,
so
I
feel
like
I,
get
to
do
awesome,
stuff,
building
things
that
I
love
to
build
and
I
only
get
to
do
that
because
of
community,
and
so
it's
community
that
like
makes
this
job
worthwhile
working
on
open
source.
So
I
am
very
grateful
to
everyone
who
has
helped
make
this
community
success
over
the
last
X
years.
I,
don't
even
know
how
long
it
is
now
that's
how
old
I
am
it.
A
A
Yes,
so
we
Brian
helped
me
do
some
digging
for
that,
so
I
can
so
I
can
properly
credit
it
on
banners
for
the
summit.
There
was
a
moment
there
that
I
was
going
to
click
the
publish
button
on
five,
but
luckily,
luckily
did
not
out
of
it
untrue.
Alright,
so
let's
kick
things
off
right
now
as
it
stands,
I
have
seven
questions
and
again,
if
you
are
listening,
feel
free
to
DM
me
and
slack
or
feel
free
to
chat
with
us
and
in
the
stock
channel
the
same
name
again
meet
our
contributors.
A
C
It
was
our
first,
no,
not
our
first
open
election,
but
our
first
election
after
instantiating,
the
steering
committee
and
I
have
to
say
mad
props
to
our
election
committee,
George
and
Parris,
spearheaded
that-
and
there
were
many
others
who
contributed
to
making
sure
we
evil
or,
for
example,
making
sure
we
got
a
good,
unbiased
election,
a
very
topical
thing
for
the
US
this
week,
making
sure
that
we
got
the
right
people
nominated
and
then
seeing
with
the
community.
You
wanted.
As
far
as
our
elected
official
dims.
It's.
E
C
D
A
C
Which
is
super
awesome
part
of
why
we
had
these
continuity.
Members
is
a
continuity,
but
also
be.
We
knew
the
first
couple
of
years
was
going
to
be
a
lot
of
a
lot
of
backlog
and
a
lot
of
extra
effort.
I'm
not
entirely
sure.
We've
made
as
much
progress
as
we
wanted
and
I
will
jump
up
and
down
and
say
I'm
one
of
those
people
who
has
not
contributed
as
much
as
I
would
like
to
have
in
last
year.
But
that
will
continue
to
be
something
we
work
against.
D
Alright,
we
are
also
focusing
on
trying
to
get
new
people
engaged.
We
are
trying
to
build
like,
for
example,
the
community
in
China
or
the
community
in
India,
and
trying
to
get
more
people
like
filing
good
first
issues,
trying
to
show
what
things
are
of
value
to
the
community
and
not
just
you
know,
PRS
with
typos,
for
example
right.
How
can
you
go
from
PR
with
typos
to
the
next
step,
where
the
next
step
is
actually
useful
for
things
that
needs
to
be
done,
for
a
specific
release
or
for
the
long-term
health
of
the
project?
E
And
it's
actually
it's
kind
of
important
too.
You
know
one
of
the
things
we
talked
about
really
early
on
was
we
wanted
to
make
sure
that
the
community,
the
people
actually
contributing
the
code,
the
people
helping
to
like
bring
people
together
the
people
helping
to
answer
questions
that
everybody
that
responsibility
didn't
just
concentrate
and
the
steering
committee,
but
was
actually
just
something
that
was
owned
by
someone
else.
So
the
charters
are
the
formalization
of
saying
you
know.
E
B
Yeah,
so
the
charters
is
one
of
the
many
things
that
were
doing
with
the
continuity
members,
but
also
the
broader
steering
committee
to
write
down
a
bunch
of
the
things
that
have
been
informal
in
the
project
from
the
beginning
that
have
evolved
over
time.
Just
so,
it's
really
clear
to
everyone,
as
people
rotate
in
and
out
of
the
project,
which
is
inevitable
at
this
point
in
the
projects
you
know,
depending
on
when
you
account
from
there
been
people
on
the
project
for
more
than
five
years.
B
B
B
Cigars
check
it.
Sick
architecture
is
different
from
a
lot
of
the
SIG's
like
cig,
API
machinery
or
cig
note,
or
even
six
scalability.
You
know
some
of
the
SIG's
had
been
around
for
a
really
long
time,
not
from
the
very
beginning
of
the
project,
but
from
when
we
first
started
breaking
out
some
efforts
and
sub
teams,
but
cig
architecture
is
a
relatively
new
sig.
It
was
born
out
of
a
Leadership
Summit
we
had
when
was
that
that
was
a
couple
years
ago.
At
this
point,
yeah.
B
That
has
broad
impacts
across
the
project
like
improving
this
of
conformance
test
and
ensure
that
they
work
for
all
the
different
scenarios
that
people
want
to
use.
Kubernetes
api
review
was
mentioned,
we'd
had
a
set
of
official
api,
reviewers
and
approvers
for
a
long
time,
so
we're
bringing
that
under
the
umbrella
of
cigar
futures,
one
of
the
main
efforts
to
ensure
the
consistency
and
coherence
of
the
API
surface
of
the
project,
which,
as
an
API
sub,
the
direct
system,
is.
B
Very
very
important:
it's
the
way
everything
interacts
with
kubernetes,
and
that
is
something
the
users
say
that
they
value
you
know
so
formalizing
that
governance
writing
down.
We
have
been
writing
down
API
conventions
for
a
long
time,
but
we're
now
trying
to
write
down
the
API
review
process
itself,
so
we
can
get
more
people
who
do
do
actually
have
a
fair
amount
of
the
knowledge
that
is
required.
You
know
bring
those
people
into
the
process
and
help
with
the
API
to
review
load.
B
C
C
C
So
this
is
another
point
in
the
whole
continuity
work
that
we're
doing
and
trying
to
make
sure
that
there
that
this
information
gets
written
down,
gets
shared,
gets
passed
on
so
that,
in
the
event
that
Brian
ever
decides,
he
wants
to
do
something
else,
for
which
we
would
be
terribly
sad.
That
there
is
there
is
this
knowledge
captured
and
we
don't
actually
just
have
to
always
call
Brian
which
yeah,
because
right
now
the
answer
is
we
call
Brian
find.
D
B
Those
are
in
the
community
repo,
each
sig
has
a
subdirectory.
There
is
a
big
list
of
SIG's,
both
loose
markdown
and
as
60ml,
which
is
the
source
of
truth
for
the
it's,
the
directory
of
SIG's
and
the
charters
reside
in
each
subdirectory,
and
there
should
be
a
link
from
the
digging
list
to
the
charters.
A
A
So
we
just
heard
that
there
was
an
election.
There
is
a
question
for
DIMM,
specifically
about
his
experience
with
the
election,
and
the
question
is
from
someone
who's
interested
in
running
next
year,
which
is
awesome
DIMMs.
What
is
a
good
tip
for
someone
who
is
interested
in
running,
especially
something
that
they
can't
necessarily
find
in
documentation
right.
D
In
in
some
ways,
people
need
to
know
you
to
work
for
you
and
for
doing
that,
you
need
to
increase
your
presence
in
the
community.
It
doesn't
need
to
be
something
you
know
being
on
all
the
time
doing
everything
by
yourself.
It's
not
like
that.
It's
more
about
trying
to
do
simple
things
like
triaging
issues,
helping
out
with
pull
requests
and
trying
to
yes,
man.
D
So,
and
do
the
things
so
there's
a
lot
of
things
that
things
get
that
get
done
in
the
community,
but
there's
a
lot
of
things
that
do
not
get
done
and
there
are
you
know
technical
debt
and
things
like
that,
so
you
know
make
it
a
point
to
go.
Look
for
long-term
issues
where
users
are,
you
know
really
asking
for
something,
but
you
know
because
of
one
reason
or
the
other
we
haven't
been
able
to
make
do
it.
You
know
advocate
for
the
end
users
advocate
for
make
things
easier
for
people
who
are
contributing.
D
You
know,
try
to
welcome
them
and
things
like
that.
That'll
help
you
with
you
know
not
just
what
you're
doing,
but
in
the
general
will
being
on
the
community
as
well.
So
once
you
are
able
to
do
that,
then
you
know
everything
else
will
flow.
Naturally,
you
know
like
standing
for
elections
or
anything
like
Brian,
okay,.
B
Emphasize
that
I
really
like
what
Tim
said,
I
think
it
does
really
work.
We
don't
want
people
to
have
to
campaign
for
the
elections.
We
want
it
to
be
natural
or
everybody
would
already
know
you
and
appreciate
you,
because
you
were
chopping,
wood
and
carrying
water,
and
you
already
understand
how
the
project
works,
because
you've
already
interacted
with
a
number
of
people
across
the
number
of
different
functions
on
the
project.
Right,
that's
basically
the
ideal
scenario
right.
You
don't
want
to
make
it
a
super
political
process.
B
B
It's
just
making
the
whole
project
function
better,
like
I
noticed
that
there
are
some
people
jumping
in
triaging
PRS
to
come
in,
although
I
think
we
now
have
to
change
dev
stats
to
take
that
into
account,
because
it's
changing
the
meaning
of
time
to
first
engagement.
But
you
there's
also
just
a
ton
of
steering
committee
work
and
it
doesn't
have
to
be
just
the
steering
committee
doing
it
right.
So,
a
typical
thing
we
tell
people
at
Google
and
probably
other
companies
is
you
want
to
get
promoted,
do
the
job
right.
B
B
C
Going
to
say
that
the
other
thing
that
you
you
looking
to
work
on
the
steering
committee,
this
isn't
really
about
building
a
platform
for
change,
and
for
you
know
these
are
my
ideas
or
what
I
think
needs
to
happen.
It's
a
whole
lot
more
of
enabling
what
is
happening
and
what
the
community
is
is
asking
for
and
looking
for.
So
this
is
much
more
like
servant
leadership
than
what
I
really
think
the
project
should
be
doing
is
blah,
and
here
is
my
platform.
C
So
the
whole
idea
of
chopping,
wood
and
carrying
water
and
fixing
pain
points
for
the
community
is
is
really
the
goal
of
the
steering
committee
there.
We
occasionally
have
opinions
and
we
will
argue
about
them.
So,
firstly,
when
we
do,
but
we
are
always
doing
this
and
working
with
the
the
community's
focus
as
the
first,
the
community
and
the
end
users
focus
as
our
as
our
first
principles.
I
was.
D
Yeah,
the
other
thing
that
I
would
add
here
is
like.
If
you
find
a
small
bug,
yes,
you
can
create
a
PR
and
you
are
able
to
get
it
much
and
you
will
get
a
plus-one
in
the
dev
stats.
But
then,
if
you
can
log
a
good
first
issue,
then
you
are
actually
helping
a
new
person
who,
and
you
can
help
them
do
the
PR,
and
you
kind
of
like
multiply
the
force
that
you're
providing
to
the
community
right.
C
C
A
Tips
all
right,
speaking
of
casual
contributors,
someone
pinged
me
and
they
are
currently
casually
contributing
on
their
own
time.
Unfortunately,
they
want
to
do
it
during
work
and
they're
having
some
issues
with
their
current
manager,
allowing
them
to
do
upstream
work
during
like
a
nine-to-five.
Essentially,
what
are
some
business
justifications
that
this
individual
could
give
to
Sarah's?
Like
I
know
this.
B
A
C
I
will
tell
you
the
the
key
to
getting
your
manager
to
align
with
something
you
want
to
do
is
always
finding
how
this
also
contributes
against
a
pain
point
they
have
so
open
source
can
can
be
strategically
important
in
a
number
of
ways
for
companies,
but
making
sure
that
you
align
your
pitch
to
your
managers.
Pain
point
is
the
first
thing,
so
maybe
your
team
is
overloaded
and
really
needs
to
be
recruiting.
C
C
C
C
B
If
you
search
for
extrinsic
and
intrinsic
motivations
for
open
source,
you
can
find
a
lot
of
ammunition.
There
are
a
lot
of
articles.
There
are
academic
articles,
there
are
studies,
you
know
you
can
listen
to
people
from
prior
keep
Khan's
who
said
we're
so
happy.
We
contributed
to
the
community
here's
why
we
wanted
to
be
part
of
the
community
that
other
people
gave
back
to
you.
So
we
don't
have
to
face
this
all
ourselves.
We
don't
have
to
solve
all
the
problems.
All
ourselves.
We
have
people.
We
can
go
to
to
ask
questions.
B
We
can
have
people,
we
can
share
tools
with.
There
are
open
source
projects
where
people
don't
share
back
to
the
community
that
way,
and
then
they
are,
you
know
they
get
a
leg
up
by
starting
with
the
open
source
and
then
they're
all
on
their
own
right,
which
is
a
little
bit
better
than
trading
your
own
infrastructure
for
everything.
But
it's
not
nearly
the
same
experience
as
being
in
a
community
where
there
is
a
culture
of
sharing
sharing
back
and
it
just
magnifies
the
impact
and
a
benefit
of
the
entire
ecosystem
right.
C
I'll
jump
on
with
that
sorry,
dams
and
the
the
point
another
point,
especially
if
you're
a
small
company,
because
those
are
a
lot
of
the
times
where
it's
really
hard
to
justify.
If
you're,
a
very
small
company,
you
can
the
peer
group
that
you
can
get
and
the
amount
of
help
you
can
get
from
the
broader
community
against
even
problems
that
you're
working
on
on
your
own
in
the
inside
the
company
is,
is
huge.
There's
a
huge
value
in
that
right.
D
D
You
know
time
and
effort
in
trying
to
learn
what
the
community
is
doing,
make
sure
you
are
in
the
feedback
loop
with
new
features
that
are
being
talked
about
or
participate
in
the
kept
process
and
try
to
understand
why
we
are
doing
what
we
are
trying
to
do,
and
also
you
have
to
get
to
the
point
where,
when
you
have
to
face
an
upgrade
situation
from
112
to
113
or
115,
you
are
prepared
for
it
and
it
doesn't
come
as
a
shock.
Okay,
how
many
things
have
changed?
D
D
A
Excellent
excellent
tips
and
advice,
I
have
so
many
questions
right
now,
I've
been
trying
to
write
them
all
down
and
group
them.
I've
been
getting
tons
of
questions
and
DMS
I
have
a
few
that
are
similar,
I'm
gonna,
try
them
combining
them
in
my
head
right
now.
It
looks
like
folks
want
to
know
tips
for
technical
disputes,
also
tips
on
building
influence,
so
lots
of
I
guess
current
contributors
who
are
actively
engaged
on
the
project
and
I
guess
maybe
disagree
with
technical
decisions
that
are
going
down.
How
can
they
have
their
voice
heard?
A
D
A
A
how
do
you,
what
are
some
tips
for
dealing
with
technical
technical
disputes?
It
sounds
like
this.
Individual
is
very
confident
that
they
are
that
they
are
correct.
So
what
are
some
advice
with
some
advice
there
and
then
also
in
that
same
kind
of
regard?
How
can
how
can
one
gain
influence
within
the
project
so
that
they
can
be
seen
as
a
technical
decision
maker
/
in
an
owner's
file.
B
B
You
know
Tim's
talked
about
just
starting
with
you
know,
filing
issues
helping
the
project
go
more
smoothly.
That's
also
true.
On
the
technical
side
right,
there
is
a
huge
amount
of
grungy
work
that
needs
to
get
done.
You
know
bugs
the
Navy
fixed
code
that
needs
to
be
refactored
tests
that
need
to
be
debugged
or
deflate
tests
that
need
to
be
written.
B
It
helps
people
see
on
a
regular
basis
that
you
are
they're,
capable
that
you're
meticulous
that
you
care
about
code
quality
that
you
develop
an
understanding
of
how
the
system
works
at
a
technical
level
and
what
the
impacts
of
changes
are
to
correctness
or
test
flakes
or
scalability
to
the
release
getting
out
on
time
right
so
that
it
doesn't
come
quickly,
but
it
is
how
how
it
works
right.
Like
fundamentally,
people
need
to
trust
trust.
B
You
you,
you
know,
no
matter
how
great
of
work
you
did
outside
the
project
before
if
people
haven't
worked
with
you
before.
It's
hard
for
other
people
to
really
understand
that,
and
also
there
are
different
styles
of
coding,
for
example,
and
not
you
know,
different
styles
may
be
equally
valid
in
different
contexts,
but
may
not
fit
with
how
the
project
is
actually
being
developed,
and
that
can
be
in
this
small,
like
whether
you
write
code
that
looks
like
Java,
hood
or
or
it
can
be
in
the
large
in
terms
of
the
house.
B
Sims
architected
right
and
definitely
one
thing
that
I
want
to
do
in
cigar.
Texture,
for
example,
is
improve
the
documentation
about
the
system
design
so
that
the
overall
architecture
doesn't
degrade
over
time
and
really
become
kind
of
non-obvious,
and
that
sometimes
forces
decisions
to
somewhat
be
more
rigid.
You
know
the
the
reason
may
be
consistency
and
keep
the
system
understandable
and
working
the
same
way.
It
was
before,
and
you
know,
even
though
there
may
be
four
individual
decisions,
ways
of
doing
things
that
are
superior
in
some
other
dimension.
Right
I
was.
E
E
B
D
The
other
thing
we
tree
haven't
touched
about
is:
do
your
homework
right,
it's
important
to
figure
out
how
to
discover
information
in
the
communities
projects.
What
repositories
are
there?
How
does
each
cig
work?
Where
are
the
Google
Docs?
Where
are
the
caps?
What
is
the
history
of
a
particular
problem?
Is
it
in
a
logged
in
an
issue?
Did
it
come
out
of
a
PR?
So
do
your
homework,
and
so
you
know
the
background
of
you
know
why
a
decision
was
taken
before
you.
D
D
You
know
where
we
are
now
so
that
helps
out
a
lot
as
well,
when
you
are
talking
to
people
because
not
everybody
remembers
everything,
and
so,
when
you
present
information
this
way,
you
know
people
will
know
that
you
have
done
your
homework
and
you
will
know
the
pros
and
cons
of
the
different
options
that
are
there
and
why
you
are
advocating
for
a
specific.
You
know,
change
Sarah,.
A
C
I
talked
about
moving
communities
too
fast
and
getting
immune
reaction
yeah.
If
you,
if
you
to
come
to
a
group
and
say
we
you're,
doing
it
wrong.
However,
you
start
this
conversation.
If
you're
going
to
get
just
an
immune
reaction
there,
you
don't
necessarily
know,
especially
if
you're
new
to
a
community
or
you
don't
have
a
lot
of
influence.
Yet
there
isn't
that
commutative
trust
as
Brian
was
describing
like
hey
I've
worked
with
Clayton
long
enough.
That
I
don't
quite
understand.
Why
he's
pushing?
C
How
did
I
have
a
really
good
reason,
and
so
he
gets
some
good
will
just
from
having
done
as
much
work
as
he
has
there.
So
there's
the
commutative
trust
piece:
there's
the
making
sure
that
you're
not
trying
to
press
the
change
too
fast
for
a
group,
because
there's
a
lot
of
especially
any
project
of
this
size,
there's
a
lot
of
accreted
decision-making.
That
gives
constraints
at
this
point,
and
so,
while
your
solution
may
be
perfectly
elegant
and
the
best
technical
solution,
you
know
independent
of
everything
else
in
the
project.
C
It
may
not
be
the
best
technical
solution
for
the
project
and
that
is
not
a
place
to
to,
or
I
describe
dying
on,
Hills,
let's
not
die
on
that
hill,
because
it's
not
it's
not
worth
it's
not
worth
the
fight
and
it
does
damage
to
your
techno
social
capital.
What
one
of
the
other
points
I
was
going
to
add
fundamentally
into
technical
disagreements,
is:
do
your
homework
on
the
other
side
as
well.
Why
is
the
other
position
being
advocated?
C
C
B
We're
also
becoming
more
and
more
risk
adverse
as
we
have
more
and
more
users
using
communities
and
production.
We've
had
a
lot
of
test
escapes.
We've
had
broken
compatibility,
a
number
of
times
you
know
so
one
thing
I'm
looking
at
right
now
is
how
we
can
improve
reliability
and
compatibility
release
over
release.
B
You
know
so
that
may
require
different
measures
when
trying
to
convince
people
like
it
used
to
be.
We
were
very
willing
to
accept
partial
implementations
and
move
quickly
and
now
we're
at
a
stage
where
we're
much
more
conservative.
So
you
may
need
to
prototype
to
feature
in
a
future
branch.
So
people
can
see
what
the
more
complete
solution
looks
like
you
may
need
to
come
up
with
a
more
complete
test
plan.
A
All
right
that
leads
us
into
the
next
question
which
has
to
do
with
time
and
your
time
specifically,
we
always
hear
that
everyone
is
super
busy.
What's
a
part
of
the
project
that
you
wish,
you
had
more
time
to
work
on
what,
for
instance,
what
sig
would
you
join
if
you
had
more
time
what
project
has
been
kicked
up
that
you
are
watching
and
really
wish
you
could
help
out
with
just
there's
just
not
enough
time
in
the
day,
Sarah
I.
C
Chocolate
is
always
welcome
on
my
desk.
Italy
finds
the
contributor
experience.
I
think
is
the
heart
of
how
this
project
actually
runs
as
successfully
as
it
does
and
I
any
efforts
that
are
put
into
that
to
make
the
contributor
experience
better
make
the
engagement
with
new
contributors
make
the
engagement
with
existing
contributor
supporting
contributors
like
this
is
why
it's
called
contributor
experience.
That,
for
me,
is
where
I
would
spend
my
time
again.
C
D
For
me,
it's
where
we
make
the
sausage
sig
testing,
we
that's
where
it's
very
important
that
we
get
more
people
involved
across
six,
because
when
you
see
a
flake,
when
you
see
a
lot
of
rejects
on
something
some
specific
CA
job,
we
don't
have
enough
people
who
help
us
out
in
trying
to
trying
to
figure
out
why
the
things
a
failing,
a
white,
some
job
is
flaky.
Why
some
tests
are
flaky
across
jobs,
so
I
wish.
D
We
could
figure
out
how
to
turn
more
office,
who
who
work
across
six,
not
just
like
signal
or
six
or
eight,
but
then
get
to
the
point
where
they
are
able
to
help
out
with
trying
to
figure
out
why
the
CI
jobs?
You
know
how
to
make
the
CI
jobs
better,
how
to
make
sure
that
the
coverage
is
better,
how
to
make
sure
that
conformance
is
better
I
think
we
definitely
need
to
figure
out
a
way
to
get
people
to
get
there.
James.
A
E
E
You
know
we
don't
want
to
shut
the
project
off
and
just
say
like
okay,
it's
never
going
to
change,
there's
kind
of
fix
bugs
because
that's
not
useful
for
the
people
who
use
kubernetes
day-to-day
and
so
trying
to
do
more
to
offload
and
get
that
process
going
from
you
deferred
to
be
really
something
you
just
don't
you
go
through.
It
feels
you
know
just
another
part
of
the
process
today.
B
E
Try
to
help
people
create
the
right,
api's
right,
yeah
and
spending
more
time
upfront,
Thank,
You
Brandon
that
was
actually
I
want
to
spend
even
more
time
upfront
so
that
I
don't
have
to
do
anything
later
so
that
it's
a
you
know,
hey
like
this
was
like
you
know.
Maybe
it's
not
the
perfect
API,
but
it's
consistent
and
meets
all
these
factors
and
we
can
evolve
it
in
the
future.
E
D
E
Interesting
because
I'm
very
like
this
is
like
I
put,
my
super,
like
I,
wrote
a
large
chunk
of
the
API
machinery
code
and
everybody
on
the
project
curses
me
for
it
when
they
remember
that
I
was
involved
in
it.
Fortunately,
people
are
starting
to
forget,
so
you
know
if
you
run
into
codex
or
serializers
or
parts
of
the
scheme,
like
that's
Daniels
fault,
but
it's
also
my
fault,
hey
blameless,.
E
Postmortem
that
some
of
the
just
the
the
messiness
of
like
it
like
we
want
to
have
really
big
clusters,
and
we
want
things
to
scale
and
so,
like
there's
a
lot
of
parts
of
me
that
are
like
we
want
to
take
control
of
it,
but
see
ours
are
very
much
I
hae,
like
you
know
what
this
is,
don't
worry
about
it
too
much.
You
know
they
don't
quite
they're,
not
very
rigid
on
schema.
You
can't
do
clever
things
with
validation,
but
that's
okay
and
I.
Think
like
as
a
project
we
for
us
to
grow.
E
B
E
B
So
it
gives
you
a
lot
of
freedom
to
implement
new
api's
kubernetes
was
designed
to
be
composable
from
a
concept
point
of
view,
but
in
fact
ended
up
being
mostly
monolithic,
there's
the
monolithic,
API
server
and
a
monolithic
controller
manager.
So
what
I
see
CR
CRS,
really
I?
Think
of
them
as
dynamic
resources.
It's
just
another
way
to
create
api's
and
some
of
them
might
be
user
defined
and
they're
over
500
projects
on
github
the
last
time
we
counted
that
are
actually
using
them,
but
you
could
do
interesting.
B
Things
like
you
can
upgrade
a
controller
and
it's
API
independent
of
the
rest
of
the
cluster
right.
If
you
define
it
using
a
custom
resource
definition,
they
are
constrained,
but
the
constraints
keep
people
from
shooting
themselves.
In
the
foot
like
when
we've
done
fairly
creative
things
across
API
versions,
it's
been
actually
really
really
hard
to
make.
It
work
the
way
that
you
would
actually
want
it
to
work.
So
the
constraints
themselves
have
value
to
to
make
it
easier
to
design.
B
Api
is
provided
you
can
stay
within
those
constraints.
So
I
think
that
you
know
now
that
we
have
the
mechanism
it
behooves
us
to
try
to.
You
know,
figure
out
how
we
can
make
it
as
useful
as
possible.
So
we
can
reduce
the
scope
of
changes
in
the
model
at
the
core
and,
as
we
see
you
know
more
and
more
uses
of
it.
E
B
You
know
now
that
we're
building
you
know
and
see
ours
together
with
other
features
like
aggregation
like
at
Michigan
admission.
Webhooks
are
more
useful
than
CRS
just
on
their
own,
so
I
think,
as
people
do
start
to
do
interesting.
Things
we'll
see
more
more
use
cases
figure
out
more
more
ways
that
we
can
use
them
that
involve
them.
C
B
There
are
some
thorny
technical
issues
in
the
initial
design
and
there
are
somewhat
of
a
priority
mismatch.
We
were
creating
actually
api's
that
had
a
different
storage,
back-end
right,
custom
resource
definitions,
one
of
the
main
values
people
find
is
that
it
shares
the
same
storage
back-end
with
the
clusters,
so
they
don't
have
to
run
their
own.
But
the
initial
use
case
for
aggregation
was
for
custom
metrics,
which
was
a
resource
that
had
a
different
storage
back-end
right.
B
So
there
was
a
prioritization
mismatch
when
we
were
in
the
middle
of
doing
aggregation
and
also
we
ended
up
using
in
the
rewrite
of
third-party
resource
to
custom
resource.
We
ended
up
using
aggregation
to
implement
that
so
the
extension
server
that
serves
CR
T's
is
actually
a
separate
API
server.
That's
aggregated
in
yeah.
E
I
I
would
add
to
like
at
the
time
we
didn't
have
enough
of
the
tools
to
actually
make
custom
resources
secure
for
some
of
the
use
cases
that
people
had,
and
so,
as
we
added
those
tools,
some
of
the
needs
went
down.
I
do
think.
Aggregate
api's
are
really
good
for
resources
that
sit
in
front
of
custom
resources
or
sit
in
front
of
other
resources
like
metrics
is
actually
just
a
fake
metrics
is
talking
to
things
in
building
little
caches
and
then
returning
it.
E
Other
people
do
aggregate
api's
that
take
other
cube
resources
and
then
show
a
different
view
of
them
that
stitches
in
data
I
think,
like
probably
over
time,
aggregated
api's,
will
end
up
more
as
in
front
of
things
where
you
need
to
pretend
that
it's
something
else
while
custom
resources
will
be
like
the
raw
data
that
may
be.
Like
you
know,
the
the
underlying
things
talk
to
her
admins
talk
to
and
maybe
you'll
end
users
might
talk
to
a
great
API
is
when
you
don't
want
to.
Let
them
touch
all
the
details.
For
instance,.
B
E
B
E
We're
very
close
to
it.
We
actually,
we
were
really
blocked
on
a
mission
control,
because
I
was
like
how
do
you
extend
cubed
to
put
policy
in
because
we
were
very
like
oh
we're
gonna
do
soft
multi-tenancy
turns
out
soft
melted
tendencies
hard
unless
you
really
control?
Who
can
do
what
and
so
like
we're?
Actually
getting
close
to
the
point,
and
maybe
we'll
talk
about
this
at
Q
Khan,
about
how
close
we
are
to
running
on
top
of
cube
versus
being
like
as
a
plugin,
to
cube
versus
being
getting
cube.
B
B
E
E
I,
don't
know
why
you're
working
on
cube
because,
like
the
point
of
building
software,
is
to
make
it
useful
for
someone
and
I
think
most
of
the
challenges
people
see
are
when
the
different
types
of
users
of
cube
like
there's
immensely
different
users
of
cubes,
like
they're
people
who
care
very
deeply
about
security
and
have
a
heart
attack.
Every
time
a
new
cube
release
comes
out.
E
You
need
to
remember
that.
There's
these
other
users
of
cube
and
they
will
not
be
happy
with
you
when
you
break
them,
and
that
has
to
be
well.
You
know
if
I
break
them,
then
I
can't
my
my
users
aren't
happy
because
then
I
can't
make
changes
to
cube
or
I
can't
convince
other
people
that
I'm
really
working
in
everybody's
best
interest,
so
I
try
to
tie
it
back
to
you
have
to
remember
to
be
able
to
talk
about.
E
You've
got
your
users
and
you
have
to
empathize
with
everybody
else's
users,
and
you
have
to
be
able
to
say
I'm
going
to
help
me
and
you
and
your
users
and
other
users
and
everybody
I
know
on
Cube
who
I've
worked
with,
knows
how
to
do
that,
and
sometimes
it's
like
you
know
that
we
don't
always
communicate
it
well,
but
I
actually
am
pretty
like
I've
been
impressed
with
every
single
person.
Who's
contributed
to
cube
in
terms
of
trying
to
do
the
right
thing
for
users.
B
Yeah
I
agree
with
that
I
think
most
people
are
working
on
kubernetes
care,
pretty
deeply
about
about
our
users
and
it's
you
know
I
would
say:
there's
no
conflict
really,
because
the
bigger
the
community,
the
more
users
there
are,
the
bigger
the
ecosystem
is
a
virtuous
cycle
that
benefits
everybody
who
has
a
stake
in
kubernetes
right.
It
was
actually
created
for
the
purpose
of
creating
that
huge
ecosystem
that
spans,
you
know
multiple
clouds
and
even
edge
running
it
an
edge
and
raspberry
PI's
education.
C
E
I
mean
that's
gonna
happen,
because
that's
what
Brian
does,
but
you
know
trying
to
trying
to
say
like
I'm,
going
to
build
trust
with
this
team
so
that
we
can
set
joint
priorities
every
little
bit.
You
do.
That
makes
the
whole
project
more
efficient.
I
mean
I.
Look
like
that.
Some
time,
but
it
really
does
and.
D
A
Was
excellent
advice
and
on
that
we
are
done
for
this
month's
meet
our
contributors
steering
committee
Edition.
Next
one
is,
let's
see,
December
5th
at
the
same
time.
Actually
we
are.
We
have
steering
committee
AMA
for
I
think
the
next
three
months
at
this
time,
since
the
other
slot
collides
with
their
regular
steering
committee
meeting.
Thank
you
so
much
to
our
panelists
today,
you
all
are
great.
They
you
so
much
for
your
dedication
to
the
community
and
we're
out
thanks
Lauren
thanks.