►
From YouTube: Kubernetes SIG Archicture 20180628
Description
A
All
right,
everybody
welcome
to
the
community,
say,
architecture
office
hours
meeting
today
is
Thursday
June
28
2018
I
am
your
host
and
moderator
and
chair,
co-chair
Jay,
singer
new
Mars
and
I'm,
not
sure
if
my
co-chair
Brian
is
on
yet,
but
hopefully
he
is
and
some
other
folks,
so
I'm
gonna
go
ahead
and
get
started
if
you
are
watching
after
the
fact.
The
the
agenda
and
notes
for
this
meeting
is
available
at
bitly.
Slash,
take
architecture
which
I'm
going
to
write
this
one
myself
and
we'll
take
a
look
at
what's
on
the
agenda
today.
So.
A
A
One
of
the
things
that
I'm
trying
to
do
across
the
project
in
various
places
is
to
have
these
project
boards
for
things
that
we
need
to
keep
an
eye
on,
especially
when
it
comes
to
stack,
ranking
and
understanding
where
things
are
added
processes,
especially
where
you
have
long
live
processes
like
caps
or
steering
committee
backlog
items
or
soon
we're
gonna
have
conformance
test
tracking,
which
I
will
convert
to
a
backlog.
Much
like
this,
and
the
idea
is
simply
that
we
can
at
a
glance,
see
what
needs
to
be
done.
A
You'll
notice
that
the
third
column
in
this
project
board
is
actually
needs
a
PIR
to
serve
you
so
as
as
caps
reach
the
point
where
they
are
implementing.
It
needs
some
sort
of
you
either
from
this
group
or
the
API
review
group,
which
is
being
formed,
that
you
can
put
those
issues
into
this
column
and
then
basically
we'll
review
this
every
singer,
contexture
meeting,
so
that
people
understand
you
know
what
needs
to
be
looked
at,
and
hopefully
this
will
be
something
that
is
is
easier
to
sustain
than
people
just
sort
of
ad
hoc
doing
this.
A
Initially,
we
want
to
provide
a
method
for
people
that
you're
track
a
Google
Tanaka
folks
you're
not
on
you
justify
Wow,
it's
not,
and
so
that's
pretty
much
that
for
the
project
board
and
it
looks
like
there's
nothing
in
review
for
this
week.
So
we'll
go
to
move
on
the
EPI
review
process.
There
is
a
document
that
we've
discussed
is
out
there
I
mean
looked
at
by
the
EPI
reviewers
has
discussed
the
last
meeting.
A
We
basically
have
made
the
LG
team
from
the
review
team
themselves
blocking
so
until
those
are
all
LG
teams,
we're
gonna
keep
this
document
open
alive
and
once
it's
LG
teamed
by
the
API
approvers
listed,
we
will
go
ahead
and
put
this
in
a
markdown
and
put
it
open
for
a
final
week
of
comment
from
the
community
and
then
merge
it,
and
this
is
will
become
the
process.
So
if
you
have
questions
comments,
concerns
please
go
ahead
and
go
to
that
document
and
check
it
out.
There's
been
some
really
great
feedback
so
far.
A
B
A
D
B
Okay,
I
hadn't
from
I
didn't
actually
see
the
claim
that
it
was
broken,
but
my
guess
is
that
is
part
of
its
that
now
that
the
caps
are
being
moved
into
six
specific
subdirectories,
it's
not
very
easily
discoverable
I
have
seen
a
number
of
caps
get
renamed
renumber
after
the
fact,
I
actually
thought
that
was
the
original
plan.
That
caps
would
initially
just
go
in
as
zero,
zero,
zero
zero
and
an
editor
would
sweep
through
and
apply
numbers
once
they
got
merged.
That
has
not
been
what
is
happening.
B
B
B
That
there's
a
huge
amount
of
value
that
actually
is
signing
like
low
digit
numbers
to
the
caps
and
for
my
purposes
just
having
some
historical
sense
of
recency
and
overall
sequential
timing
of
the
proposals
is
somewhat
valuable.
That
could
be
done
just
by
putting
gates
inside
the
documents.
If
we
had
a
tool
for
plucking
out
those
dates
and
sorting
them,
I,
don't
actually
believe
in
practice.
B
B
The
idea
of
you
know
if
we
kept
a
backlog
of
kemp's
much
like
the
proposal
for
the
API
reviews.
I
could
imagine
just
using
issue
numbers,
so
you
just
file
an
issue,
and
that
would
give
you
a
number
and
then
you
could
put
that
here
kept.
That
would
seem
to
be
work
reasonably.
It's
also
become
similar
to
the
features
process.
A
Yeah
I
agree,
I
mean
it
was
the
idea.
I
think
that
this
the
idea
was
served
like
a
primary
key
that
could
be
used
in
terms
of
automation
or
I.
Don't
know
what,
but
it
doesn't
seem
that
important
to
the
overall
integrity
of
the
process,
so
I
think
that
it's
causing
way
more
friction
than
it
needs
to.
So
I
think
that
we
should
target
just
documenting
what
that
should
be
in
moving
forward,
so
it'd
be.
Maybe
if
somebody
wants
to
step
up
and
volunteer
to
make
some
sort
of
proposal
there.
That
would
be
great.
A
B
So
much
to
just
send
a
message
to
the
mailing
list
with
a
link
to
the
issue
and
mentioned
that
this
we
should
aim
to
resolve
this
quickly.
I,
don't
know
if
a
week
is
a
reasonable
goal,
since
we
don't
have
a
meeting
next
week,
July
and
such
yeah,
but
maybe
two
weeks
we
should
just
have
a
decision
on
that.
I
actually
think
we
can
I
like
the
you
use,
create
a
repo
just
to
allocate
the
numbers
and
maintain
the
backlog,
but
not
actually
move
the
caps
there.
That
would
be
my
preference
I.
B
A
D
B
D
D
A
But
I
like
this
I,
think
this
pattern
and
I'm
really
starting
to
like
it.
The
more
the
more
time
goes
on
the
more
like
it,
and
then
people
can
create
a
commentary
in
those
issues
on
the
tracking
that
are
related
to
the
project
management
around
the
cap,
as
opposed
to
having
it
be
in
the
cap
itself,
which
should
be
technical
discussion.
So
it
sort
of
separates
those
two
concerns
out,
which
I
think
is
important:
yeah.
A
C
Hello,
I'm
marking
there
was
delete
of
C
cups
of
the
scanning.
So
to
give
you
a
little
bit
more
context
in
March
this
year
we
launched
alpha
version
of
vertical
photo
scanner.
It's
a
thing
that
adjusts
the
auto
request,
based
on
the
actual
CPU
and
memory
usage
users
are
allowed
to
configure
the
dupatta
together
for
a
particular
set
of
thoughts
which
they
want
to
control,
so
the
providers
selector
plus
some
extra
configuration
options
for
alpha.
We
added
that
we
will
do
our
debased
configuration
now,
the
more
we
think
about
it.
C
B
C
So
we
are
thinking
about
putting
into
the
auto
scaling
group
so
that
it
is
next
to
horizontal
pot
autoscaler,
which
does
a
little
bit
similar
job.
However,
instead
of
standing
vertically,
it
scales
things
horizontally,
so
there
was
an
attempt
to
do
this.
Api
addition
at
the
very
last
minute
and
in
kubernetes
1.11,
the
attempt
was
rejected
and
it
was
suggested
that
we
go
to
seek
architecture
to
check
whether
it's
right
move
at
this
extra
vertical
pot.
Autoscaler
api
to
this
building,
api's.
C
B
So
unfortunately,
I'm
actually
gonna
suggest
that
we
schedule
this
reschedule
list
to
a
future
meeting.
If
you
could
put
links
to
the
proposals
and
the
api's
into
the
agenda
and
potentially
prepare
like
a
five
minute
presentation,
I
think
that
would
be
super
helpful.
I,
don't
think
we
can
have
a
constructive
conversation
about
this
without
adequate
background
at
this
meeting.
Okay.
C
B
So
I
will
I
added
the
topic
about
office
hour
versus
meaning
distinction.
So
I'll
just
sidetracked
that
for
a
moment,
I
actually
believe
that
distinction
has
not
been
useful.
We
haven't
really
paid
attention
to
it,
so
I'm
gonna
suggest
we
just
eliminate
that
distinction
and
we
just
try
to
schedule
some
amount
of
working
time
and
some
amount
of
presentations
of
issues,
API
reviews
etc
in
every
meeting.
B
C
D
Okay,
the
question
is
I.
Don't
think
we
have
a
clear
guidance
on
where
we
want
the
line
to
be
for
what
we're
taking
you
know
or
not
we're
not
what
the
rationale
for
being
in
the
same
groups
and
not
it's
like
I,
find
the
argument
of
being
in
the
same
group
as
HPA.
Actually
pretty
strong
I
know
that
argument
was
rejected
for
storage,
stuff
I.
Agree
with
that,
because
it's
in
the
storage
argument
was
not
a
strong
well.
B
C
B
D
F
I
was
just
about
to
ask
that
this
is
Sally.
The
turn
on
my
video,
the
other
say
auto-scaling
lead
I've,
actually
been
wondering
for
a
little
while
now,
if
it
makes
sense,
because
we're
we've
been
trying
to
iterate
some
on
the
horizontal
pod
autoscaler
as
well
and
I've
been
wondering
if
it
makes
sense
to
just
move
auto-scaling
out
in
two
separate.
You
know
aggregated
API,
server
or
something
and
have
the
controllers
be
separate.
B
B
G
D
Put
it
another
way
using
an
aggregated,
API,
solves
the
immediate
problems
and
a
really
high
cost,
and
we
think
that
the
problems
over
the
long
term
need
to
be
solved
for
C
or
D
anyway.
I
fully
acknowledge
that
pushing
things
out
like
taking
HP
and
putting
out
to
a
CRD
architectural
e
is
right,
but
may
not
be
right
right
now,
but
maybe
starting
new
things
there
is
is
right
enough
yeah!
Is
there
a
rush
to
so
aside
from
could?
D
Could
you
do
vertical
pod,
auto
scaling
in
an
auto
scaling
group
that
lived
as
a
CR
d
or
as
an
API
server
outside
of
the
main
repository
punt
on
removing
HPA
until
CR
D
becomes
mature
enough
and
provide
feedback
to
the
current
developers
of
the
CRE
versioning
to
get
it
mature
enough
and
then,
after
that's
done
and
consider
moving
it
back
out
into
a
separate
group?
So.
C
D
B
Keeping
them
as
both
from
the
auto
scaling
group-
and
you
can
also
just
have
the
controller
watch
both
loci
eyes
in
terms
of
migrating
to
a
newer
version.
You
know
deleting
an
HPA
and
recreating
it
I,
don't
actually
we
couldn't
I,
don't
know
if
the
implementation
would
handle
that
gracefully
today,
but
I,
don't
think,
there's
any
strong
reason.
Why.
D
E
D
D
C
D
Many
cases
yes
I,
agree
I
just
think
it's
an
open.
It's
an
open
question
to
connect
to
your
point
about
how
a
API
occurrence
is
supposed
to
involve
inversion
together.
I
asked
that
exact
question
of
API
machinery
this
week
last
week,
I
was
told
no,
that
is
in
fact
not
the
intention
and
that
API
versions
are
sparse
and
not
versions.
Groups
groups.
Yes!
So
if
I
have
a
group
with
resources,
ABC
and
they're,
all
at
version,
1
and
I
want
to
add
version.
D
G
Currently
works
for
the
batch
group
today
right
exist
an
example
cron
jobs.
There
are
other
examples
as
well
related
to
admission,
and
at
least
one
other
one
related
to
the
API
server,
where
you
have
different
resources
in
different
space.
I'm
gonna
offer
some
one
theta,
some
a
ga
and
good,
and
so,
if
you're
evolving,
for
example,
a
cron
job,
but
that
you're
not
evolving
a
regular
job,
then
you
don't
put
a
regular
job
into
a
beta
level.
There's
just
no
need
so
the
particular.
D
A
B
Yeah
I
agree
I'm,
trying
to
get
my
way
through
some
of
some
of
the
backlog
issues.
So
you
know
now
is
the
time
to
comment
any
other
API,
approvers
or
other
interested
people
on
the
call.
Please
do
take
a
look
at
the
API
review
process
as
I
mentioned
earlier.
We
are
also
going
to
put
into
place
a
backlog
for
four
caps
in
facts,
Jace
or
te
created
one
in
the
community
repo
which,
if
we
create
another
boats,
race,
called
the
the
numbering
issue
that
backlog
would
have
to
be
moved.
Savi
I,
don't
know
that.
D
B
B
A
Make
a
ton
of
sense
because
there's
no
automation
from
get
up
on
the
project
boards
is
atrocious.
So
so
it's
really
a
manual
process
regardless
and
so
yeah
Brian.
Let's
go
and
I
just
work
offline
to
get
that
repo
created
and
I'll
run
with
it.
Does
that
work?
Okay,
yep,
okay,
great
reminder
to
everybody,
we're
canceling,
the
next
week's
meeting,
and
so
we'll
adjourn
the
week
after
that
we
are
abolishing
the
notion
of
office
hours.
A
D
I,
just
one
more
echo
for
anybody
here
who
considers
themselves
to
be
either
an
API
reviewer
or
not.
Consider
anybody
who
is
an
API
reviewer
or
would
like
to
be.
Please
please,
please
go
read
that
doc
and
make
sure
you
read
it
as
if
you
were
a
community
member
so
that
it
is
crystal
clear
what
they
have
to
do
and
what
they
can
expect
from
us,
and
that's
not
true.
Please
do
feedback.