►
From YouTube: Kubernetes Public Steering Committee Meeting 20190703
Description
C
A
Goes
beyond
the
scope,
so
yeah
and
API
governance,
an
API
review
order,
the
cigars,
the
specific
cigar
sub-project
as
well
I
haven't
looked
at
the
recent
this
discussion,
but
I
didn't
expect
it
to
come
up
here
but
yeah,
and
we
should
put
it
on
the
agenda
for
cigar
I
thing
as
the
action
item
here.
The.
C
I
already
did
actually
okay,
the
I
did
have
a
separate
topic
that
I
thought
I
wanted
to
raise
awareness
and
get
feedback
from
is
that
this
came
in
from
the
wild
and
I
was
kind
of
wondering
like
who,
from
the
kubernetes
space
has
any
say
or
has
governance
or
oversight
into
the
CIOs
benchmarks
like
who
is
that
report
into
through?
Like
are
the
six
structure,
because
we
got
is
that.
D
Bet
the
computer
information
security
ones,
yeah,
there's
a
goth
they've
worked
with
them,
I,
don't
know
the
date
they
they
probably
as
much
as
anybody
own
the
relationship
with
the
suspension
marks,
since
they
also
technically
own
they're,
making
the
recommendations
for
security
on
kubernetes
from
a
feature
capability
perspective.
Although
I
guess
Brandon
I
mean,
like
the
the
security
group
also
has
a
tie-in
there.
Okay.
C
The
reason
I
ask
is
because
we
got
a
bunch
of
we
got
some
reports
back
in
from
the
wild
four
deployments,
and
one
of
the
things
we
found
is
that,
as
we
dug
into
the
benchmarks,
we
found
that,
like
a
bunch
of
the
benchmarks,
are
really
bad
or
wrong.
That's
so
they're
terrible
yeah,
so
I
was
like
who
is
this
and
we
have
no
idea?
Who
actually
was
it
because
well.
B
Trying
through
folks
at
core
OS
who
were
sitting
on
sing-off,
who
were
sitting
on
the
sea
is
like
Advisory
Committee,
helping
to
explain
why
certain
things
were
not
recommended
and
they
just
who
are
very
stringent
on
wanting
the
like,
tightest
possible,
almost
non-working
set
of
standards.
So
it's
like
they
want
to
recommend
something.
That's
terrible!
It's
not
really
something
we
can
manage.
We
can
put
up
a
blog
post
or
something
saying
these
are
terrible
and
as
community
we
reject
these
standards.
Yeah.
C
I
think
the
expectation
from
the
community
was
the
big
one
that
was
weird
because
they
kind
of
publicized
themselves
as,
like.
You
know
the
standard
bearer
for
what
is
kubernetes
deployment
and
I.
Think
some
people
actually
expected
that
a
lot
of
deployments
were
past
serious
benchmarks
and
were
surprised
by
the
results
they
got
back.
B
C
B
E
Yet
I
kind
of
seen
the
same
thing
that
you
see,
people
with
configurations
are
attending
to
make
configurations
for
a
cluster
to
be
compliant
with
running
the
suspension,
arcs
and
effectively
configuring
the
cluster
and
that
way
for
the
workloads
are
trying
to
run,
makes
a
control
plane
unstable
by
default.
So
I
think
one
of
the
real
issues
might
be.
Is
it
if
we
do
nothing?
There's
a
potential
that
the
sort
of
the
compliance
standard
for
security
for
a
cluster
generates
clusters
that
are
unstable
for
our
users?.
A
D
I
think
the
Sigma
is
the
appropriate
forum
for
this,
given
previous
involvement,
and
it
gives
any
support
that
they
need
well.
I
think
they're
concerned
that
I'm
hearing
there
is
a
more
of
an
urgency
like
these
are
bad
and
we
should
fix
them.
We
just
accosted
on
both.
If
we
need
to
help
from
an
urgency
or
communications
perspective,
we
can
yeah.
A
B
F
B
So
I
guess
the
other
thing
I
would
give
to
Tim
is
if
you
go
back
to
sig
off
and
tell
them
we're
seeing
some
issues,
I
think
we
can
also
just
mark
it
that
sig
off
or
a
set
of
authors,
don't
agree
with
the
standard
and
just
I.
Think
and
get
people
are
having
trouble
with
the
standards
and
it's
actively
causing
SIG's
issues.
It's
okay
to
not
just
be
polite
and
continue
to
slowly.
Work
with
this,
so
that'd
be
my
last
piece
of
feedback.
F
Right
some
of
the
things
that
were
recommended
we
actually
like
deprecated
and
removed
because
they
didn't
make
sense
and
didn't
work
on
any
clusters
and
so,
like
that's
kind
of
the
big
hammer
version
like
no
one
should
ever
set
this
setting
ever
and
if
a
benchmark
is
recommending
it
incorrectly
like.
Why
do
we
even
have
that
lever?
So
a
few
things
have
been
done
that
way,
but
because
there's
a
lot
tale
of
stuff
that
they
recommend
that
doesn't
make
sense.
Yes,.
B
G
Can
I
can
I
topic
really
sure?
Can
we
talk
about
like
budget
for
contributors
on
it?
It
is
Brendan
burns
we
do
have
quorum.
I
just
wanted
to
see
like
when,
where
what
the
platform
is
that
we
should
discuss
funding
for
contributors
on
it.
H
G
I
feel
like
this
one
is
definitely
higher
than
anyone
to
date
because
of
that,
but
I
don't
necessarily
foresee
that
being
a
benchmark
for
the
future
either,
but
we
do
definitely
have
a
number
now
I
know:
Deb
Giles,
with
CN
CF
is
going
to
get
some
more
firm
quotes
instead
of
the
ranges
and
then
we'll
have
that
information
there,
so
I'd
say
within
the
next
week
tops
they'll
have
a
more
firm
number.
So
at
that
point,
do
you
feel
like
we
could
dive
deeper
into
some
solutions
for
sustainable
funding.
A
So
the
information
that
was
shared
previously
wasn't
entirely
clear
to
me
what
we
were
asking
for
like
in
terms
of
our
objectives
and
what
we
plan
to
do,
and
things
like
that
some
was
speculation
on
the
part
of
other
people.
So
do
we
have
a
proposal
about
what
we
would
like
to
do?
That's
pretty
flushed
out
at
this
point.
No.
G
We
are
working
on
that
we've
set
issues.
I
can
add
those
to
the
agenda,
but
we
have
a
deadline
of
July
15th
to
send
steering
committee.
What
we
are
intending
of
doing,
but
we're
intending
to
have
a
full
show
here
and
full
show,
meaning
all
contributor
personas
represented
and
some
kind
of
in
some
kind
of
content
value,
add
to
them
and
we're
specifically
going
to
be
focusing
on
current
contributors
and
workshops
and
things
to
get
folks
trained
on
code
reviews
and
things
like
that.
G
So
you'll
see
all
that
information,
July
15th,
but
we
definitely
have
future
intentions
of
making.
Every
contributor
summit
have
have
goals
and
objectives
like
we
did
with
Barcelona,
because
we
just
don't
have
the
staff
to
run
a
full
show.
Nor
clearly,
do
we
have
the
budget
to
run
a
full
show
every
year,
so
we're
we
want
to
be
conscientious
of
that.
Essentially.
So
that's
why
Shanghai
and
Barcelona
are
a
little
bit
on
the
cheaper
end,
because
we
expect
that
the
North
America
shows
are
gonna,
have
much
more
participation
and
things
like
that.
G
G
B
B
H
A
D
D
I
B
H
A
A
A
J
Agenda
so
I'm,
sorry,
I'm
late,
all
I
don't
want
to
re-litigate
the
topic
that
I
put
on
there
and
they
didn't
show
up
to
talk
about
because
I
saw
the
notes,
but
the
concern
I
did
want
to
actually
raise
there
and
we
can
actually
see
if
this
becomes
a
critical
problem.
It's
really
one
of
seek
autonomy.
J
Influence
what's
happening
within
a
particular
sig
I
mean
we
can
see
if
this
practically
becomes
a
problem,
but
I
don't
think
this
is
purely
a
sake.
Architecture
thing
this
really
is
and
I
think
you
know
fundamentally
also
save
architecture,
because
it
does
have
so
much
impact
across
across
the
project
cross.
Other
SIG's
really
is
pretty
special
here.
There
aren't
other
SIG's
that
that
have
that
kind
of
cross-cutting
impact.
J
Yes,
a
release
and
scalability
or
I
think
are
good
once
but
I
think
release
is
really
it's
a
process
thing.
It's
not
an
architectural
thing.
It
doesn't
actually
tell
SIG's
what
they
can
and
can't
do
in
total.
It
actually
just
talks
about
sort
of
like
how
do
we
pull
a
release
together?
It
gets
to
decide
what
goes
in
and
out
of
a
release
which
is
different
than
saying.
This
is
the
architecture
I
think
scalability
also
has
purview
but
I.
You
know
I.
D
J
D
H
D
Allowed
to
add
things,
but
not
but
they're
a
process
for
cig
architecture
says
this
is
also
part
of
kubernetes
api
reviews.
Kind
of
doing
some
of
that
now
I
think
there's
singing
I
think
stick
architecture
doesn't
work
as
well
as
we
would
like,
but
starting
there
felt
appropriate
because
we'd
already
delegated
and.
A
Originally
targeted
things
completely
outside
the
project,
even
though
it
was
interpreted
differently.
Maybe
it's
targeting
both
but
much
like
we
came
up
with
the
different
types
of
repos
for
different
types
of
work.
It's
possible
that
it's
some
kind
of
affordance
may
need
to
be
made
for
things
that
will
be
user
facing
and
things
that
will
not
be
user
facing,
like
we
don't
expect
all
kubernetes
users
to
consume
brown.
K
F
Have
none
of
that
for
custom
resources,
and
so
like
my
main
concern,
is
what
I
would
like
to
see
primarily
is
getting
some
of
those
tools
in
place
so
that
we
find
problems
and
aren't
counting
on
human
eyeballs
to
catch
all
of
these
issues,
and
so,
but
until
we
have
that
like
I,
it
doesn't
seem
like
a
great
approach
to
say:
well
we're
we
it's
too
slow
to
depend
on
human
eyeballs.
So,
let's
just
not
I.
C
Don't
think
that's
the
case.
The
problem
is
not
that
the
problem
is
government's
an
autonomy
so
like
we
want
to
make
sure
that
the
expectations
are
clear
and
like
when
we
created
the
organizational
structure.
Kk
had
a
bar,
we
wanted
that
bar
to
be
high
and
we
wanted
to
lock
it
down,
and
it
was
clear
that
we
wanted
to
have
certain
expectations
met,
but
we
also
felt
that
we
that
bark
is
sometimes
be
too
high
for
people
to
iterate
fast.
C
So
we
wanted
to
have
a
set
of
projects
outside
of
the
core
to
have
the
ability
to
very
fast
and
break
things,
break
themselves
against
the
rocks
and
that's
okay,
because
it's
a
part
of
that
as
innovating,
and
so
we
didn't
want
to
have
the
same
restrictions
for
core
to
be
put
on
things
that
are
outside.
So
that's
the
reason
why
we
created
the
original
governance
model
and
this
the
current
documentation
has
areas
where
it
kind
of
cuts
against
that,
instead
of
decentralizing
it
centralizes
again.
C
So
in
my
mind,
it's
just
a
matter
of
writing
down
clarifying
some
of
the
original
words
that
are
inside
the
doc
to
make
sure
it's
more
explicit
and
a
recommendation
for
things
outside
it,
and
you
know
we
want
people
to
follow
best
practices,
because
right
now,
there's
no
way
you
could
review
Jordan
Sun
even
humanly
possible.
The
sheer
number
of
sub
projects
that
have
CR
DS
now
McHale
OTT
of
them
would
probably
not
be
within
up
to
snuff
either
so
I.
It's
just.
We
need
to
find
a
balance
of
policy
as
well
as
tooling.
F
F
What
is
a
beta
version
and
what
does
the
G
a
version
mean
and
so
I
think
it
makes
sense
to
clarify
you
know
if
you're
in
alpha
mode
and
it's
unsupported,
here's
guidance
for
what
namespace
to
use
and
sure,
like
iterate,
fast,
knock
yourself
out,
make
it
clear
that
you're
moving
fast
and
breaking
things
at
the
point
where
you
want
to
like
have
a
stable,
published
API,
and
you
want
it
to
be
like
part
of
the
kits
IO
namespace
right,
then
here's
here
are
the
expectations.
The
I
would
say
the
same
expectations
for
an
compatibility.
F
We
should
hold
CRT,
backed
it
guys
to
that,
and
then
we
can
figure
out
like
what's
the
best
way
to
achieve
those
goals,
and
so
that's
gonna
be
a
mix
of
tooling
and
review
and
hopefully
tooling,
develops
and
hopefully
review
expertise
develops
and
and
we
can
afford
that
way.
I
think
that's
totally
fair
to
I
mean.
J
So
that
I
mean
one
of
the
concerns
that-
and
maybe
this
is
a
straw
man,
so
maybe
I'm
full
of
crap
here
and
feel
free.
To
tell
me,
if
that's
the
case,
is
that
what
exactly
is
in
scope
of
an
API
review,
because
I
think
a
lot
of
times,
and
especially
since
the
folks
who
are
API
approvers
are
overlapped
with
architectural
roles
in
other
places.
J
I
think
we've
got
to
make
it
clear
that
during
an
API
review,
it's
okay
to
say
something
like
you're,
not
following
the
conventions
via
XYZ,
or
this
name
is
not
consistent
with
this
other
name
over
here
or
or
like
you
know
something
along
those
lines
which
is
largely
syntactical.
What
I
don't
want
to
have
happen
is
part
of
an
API
review
is
something
like
I.
Don't
like
the
way
you
modeled
the
solution
of
this
problem
right
and
because
I
think
that's
mixing
these
two
things,
and
so
that's
the
that's.
J
The
concern
that
I
have
and
I
would
love
to
actually
tighten
up.
You
know
not
in
did
know
not
only
unblocking
this
appropriately,
but
also
making
sure
that
we
tighten
up
sort
of
what's
what's
in
scope
and
out
of
scope
for
an
API
review
and
which
stuff
should
be
handled
as
part
of
the.
The
large
process
is.
E
The
real
issue
about
I,
don't
like
the
way
you
model
the
problem
or
is
it
I?
Don't
think
you
should
be
solving
this
problem
at
all
right
because,
like
as
a
developer,
if
somebody's
giving
me
feedback
that
hey
I
think
there's
a
better
way
that
you
can
model
this
problem
and
they're
doing
it
in
a
constructive
way,
whether
they're,
an
API,
reviewer
or
not,
I'm
gonna
actually
be
grateful
for
that
feedback.
E
Now,
if
the
issue
is,
we
have
people
who
are
API
reviewers,
who
are
also
fulfilling
an
architectural
governance
role
who
are
coming
in
and
telling
individual
SIG's.
You
should
not
be
solving
this
problem
and
they're
a
little
out
of
place
on
doing
that.
I
think
that's
a
little
bit
different
and
then
the
other
thing
that's
kind
of
different
between
CR
DS
and
built-in
types
is
that
the
expectation
for
a
kept
for
a
built
in
type
is
that
you
have
API
review
prior
to
even
going
alpha,
whereas
with
C
RDS.
E
If
we're
gonna
allow
people
to
move
fast
and
break
stuff,
maybe
one
thing
we
could
do
is
say:
okay,
you
don't
need
to
have
API
approval
going
into
alpha,
but
if
you
want
it
like
Jordan
said,
if
you
want
to
go
bader
GA,
you
could
happen.
Those
are
the
kind
of
the
two
thoughts
that
came
up
with
you
guys
write.
A
A
Sometimes
people
wear
multiple
hats
and
I.
Think
in
those
cases
is
desirable,
like
Tim,
put
a
lot
of
effort
into
reviewing
the
dual
stack
proposals
wearing
his
signet
working
hat,
and
he
is
also
an
API
approver,
so
he
also
looked
at
the
API
aspects
at
the
same
time,
so
that
is
sometimes
gonna
happen
and
I
personally
think
it's
a
non-issue
for
those
to
be
overlapping
and
in
fact,
it's
kind
of
a
goal
to
make
sure
that
we
have
people
who
are
reviewing
the
domain.
A
A
J
D
Think
Jo
like
to
get
to
your
original
employment.
We
had
early
discussions
for
the
first
couple
of
years
of
cube
where
we
were
trying
to
limit
the
scope
of
kubernetes
as
we
you
know,
and
that
was
growing
an
ecosystem
allowing
people
to
execute.
We
never
really
defined
the
gray
area
between
outside
and
SIG's
to
a
degree
we
struggle
with
incubator.
We
struggled
with
associated
projects,
we
struggled
with
helm,
so
I
do
think.
There's
an
element
here
of
the
aspect
of
this.
D
That
is
the
semantics
part
we
did
delegate
to
sig
arch,
but
then
we
ran
into
challenges
and
we
haven't
necessarily
closed
the
loop
on.
Do
we
have
an
effective
process
for
resolving
semantics
references
with
consumers,
because
I
do
think
the
role
of
cigars,
my
personal
video
will
be.
The
role
of
cigars
is
to
help
negotiate
semantics
disagreements
about
the
meaning
of
what
is
kubernetes,
which
may
be
a
peer
review,
is
being
used
to
enforce
that's
a
day
but
reasonably
we
could
do
a
better
job
of
talking
about
the
semantics
and
the.
Why?
J
No
definitely
like,
if
there's
a
semantic
question,
then
the
kept
process
sig
arch.
It
should
be
going
that
way
it
shouldn't
sort
of
like
land.
On
these
you
know
five,
six
people
to
essentially
like
like
API
approver,
does
not
equal.
You
know
architectural
master
right,
I,
just
wanna.
You
don't
accidentally
create
that
equivalency.
Yeah.
F
One
of
the
things
that
we
call
that
in
the
doc
was
trying
to
distinguish
between
those
two
things
like
the
cap,
is
primarily
focused
at
the
cig
or
SIG's
that
are
over
that
area
and
so
they're
the
ones
who
are
saying.
This
is
a
thing
we
think
is
worth
doing
it's
within
our
area.
It's
within
our
charter
here
are
the
goals,
and
then
the
API
process
is
saying
is
this?
Is
this
working
coherently
and
like
have
we
done
the
same
thing
in
other
places?
F
Let's
do
it
consistently
and
are
you
gonna
run
into
compatibility
issues
that
type
of
thing,
so
it
was
very
much
trying
to
say
like
before
it
even
touches
API
review.
You
should
have
a
cat,
but
the
tech
leads
for
that.
Sub
project
should
have
said.
This
is
the
thing
we're
doing
and
it
makes
sense
and
that's
a
goal,
and
we
agree
with
this
direction.
So
yeah.