►
From YouTube: Kubernetes SIG Architecture 20190606
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
welcome
everybody.
This
is
the
kubernetes
sig
architecture,
special
interest
group
meeting
and
today
is
Thursday
June
6
2019
I
am
one
of
your
mini
chairs,
jazz,
singer
Dumars,
and
we
are
going
to
kick
off
today's
meeting
the
agenda
in
notes.
If
you
want
to
check
in
after
the
fact
is
it
bit
dot,
Lee
/,
sig
architecture
and
code,
and
you
started
with
the
first
agenda
item,
which
is
release
post
mortems
with
a
question
mark
after
it.
So
I'm
not
sure
who
put
this
on
here
or
what
it
is
supposed
to
be.
B
Hey
sorry,
I
actually
heard
that
item
from
a
couple
minutes
ago.
I
remember
that
James
brought
up
the
idea
of
doing
for
these
post
mortems
a
you
know.
Every
time
we
do
a
major
major
release.
They
are
usually
not
production
ready
out
of
the
gate
and
there
have
to
be
a
lot
of
a
lot
of
work
to
to
get
to
get
to
the
stage.
So
I
just
wanted
to
check
in
again
and
see
if
I
mean
I,
guess
I
guess
this
is
for
doing
small
stupid.
Is
there
any
work
going
on
on
this
area?
C
Look
at
you
know
the
actual
PRS
that
got
merged
and
things
like
that
to
see
if
there
was
a
pattern
to
it
and
we
still
don't
have
a
set
of
people
who
are
interested
in
this
work
as
such
or
and
the
other
thing
was.
If
somebody
is
already
doing
something
like
this
for
their
own
companies,
we
thought
we
could
invite
them
to
come
and
talk
to
us
with
whatever
information
that
they
had.
That
was
the
two
ways
of
looking
at
it,
but
that
hasn't
happened
yet.
B
C
B
A
A
That's
that's
a
yeah
I
think
that's
good,
so
we
need
somebody
to
actually
take
that
signal
TS.
Who
wants
to
be
the
shepherd
for
that
I.
C
B
A
Left
go
for
it.
Thank
you.
A
E
So
just
to
give
context
for
this
for
a
long
time.
Actually
we
wanted
something
that
tests
in
place
that
would
catch
if
we
broke
serialization
compatibility.
We
have
lots
of
round-tripping
tests
and
things
like
that.
But
all
they
do
is
test
that
the
code
currently
in
master
can
serialize
and
then
read
back
data.
E
E
Just
like
this
we'll
say
you
added
a
field
deserialization
is
this
expected
update
the
fixture
and
same
thing
for
proto,
but
it
doesn't
in
a
readable
way,
so
you
can
see.
Ok,
this
is
a
strict
addition,
rather
than
losing
data
on
round
trip.
So
this
will.
Let
us
do
things
like
update
our
ancient
or
debuff
libraries,
which
have
been
causing
gridlock
with
other
dependencies
without
just
sort
of
holding
her
nose
and
saying
well,
I
hope
we're
not
breaking
reading
data
for
previous
releases
I
have
no
idea,
but
hopefully
we're
good.
E
C
E
Yeah,
so
you
can
ask
it
to
regenerate
it's
not
actually
gonna
regenerate
the
the
primary
fixture
is
going
to
regenerate
the
after
round-trip
one,
so
we
always
have
the
pristine
one
that
was
generated
on
that
release
too
to
pull
from.
So
we
don't
touch
that
once
we
cut
it
release.
All
we
do
is
optionally
put
one
aside
that
pristine
one
that
says
hey
when
we
read
in
the
version
from
the
prior
release
and
then
wrote
it
back
out,
here's
what
we
get
and
what
we're
expecting
that
way.
E
D
Is
there
a
plan
to
I
know
that
we,
if
you
look
at
the
API,
conversions
and
the
api's
that
are
supported?
Currently,
we
we
see
a
contract
event,
but
if
you
actually
go
back,
you
can
actually
see
we
support
actual,
really
really
older
versions.
We
have
in
the
past
is
our
plan
to
get
that
up
to
date
so
that
we
were
kind
of
we're
saying
you
haven't
now
a
way
to
have
contracts
right
unless
they're.
C
E
There
are
a
few
things
there.
One
is
just
like
the
actual
field
names
and
prototypes.
Those
can
never
change
for
a
given
version
like
you
can
never
change
the
proto
tags
in
the
JSON
field
names.
You
can
add
new
fields
which
we
do.
This
does
not
test
defaulting
and
conversion.
This
just
tests
can
we
read
the
bytes
into
the
struct
and
write
them
back
out
like
how
have
we
changed
photo
tags
proto
formats,
it's
the
pure,
like
on
the
edge
marshalling
on
marshalling
code?
E
E
A
All
right,
great
so
back
to
you
Jordan
API,
review
sub-project.
Do
you
think
you
want
to
share
about
that.
E
A
lot
of
API
reviews
happened.
There
was
kind
of
a
crunch
at
the
end
of
the
release
with
Q
Khan.
There
was
some
discussion
about
that
on
forget
which
photos
which
group
it
was
in
maybe
as
architecture
and
I,
think
we
need
to
do
a
better
job.
Communicating
that
the
way
we
prioritize,
if
you
have
reviews
so
in
general,
things
that
are
oriented
towards
stabilizing
and
graduating
efforts
that
are
already
in
progress,
are
going
to
take
priority
over
new
alpha
initiatives
in
general
right
if,
if
there's
a
new
Alpha
Initiative,
that
should
be
prioritized.
E
E
Part
of
that
was
the
overall
number
of
things
being
reviewed.
Part
of
that
was
bandwidth
around
Q
cone.
So
that
was
one
interesting
point
from
this
release.
The
other
is
that
we
had
a
ton
of
people
from
SIG's
involved
during
the
reviews,
which
was
really
great
storage
and
sig
windows
and
six
scheduling,
especially
where
we're
very
engaged.
So
we
did
a
good
job,
identifying
people.
E
A
C
So
me
and
Jordan,
but
yeah
I'll,
take
point
so
one
thing
that
we
identify
two
things:
one
working
on
the
other
one
you
have
to
start.
So.
The
one
thing
that
we've
been
trying
to
do
is
get
to
a
point
where
we
are
not
using
the
random
sha,
which
we
inherited
from
good
apps
and
actually
use
versions
in
in
the
go
mod.
So
I
have
a
PR
up
which
takes
care
of
a
bunch
of
them
without
actually
modifying
any
code
as
such.
C
But
then,
once
we
get
through
this
initial
PR,
then
we'll
have
to
figure
out
how
to
update
the
rest
of
the
things.
But
the
idea
is
to
not
have
random
shots
and
use
specific
release
versions
so
that
when
there
is
a
new
version
for
any
of
the
things,
then
we
can
go
back
and
check
if
there
is
a
CVE
or
a
bug
fix
or
something
in
the
release,
notes
and
see.
C
If
we,
you
know,
do
it
better
thing
of
managing
our
dependencies,
you
know
instead
of
just
pulling
up
whatever
the
tooling
fixin,
so
that
that
was
one
the
other
one
that
came
up
during
this
investigation
was.
We
still
do
have
a
lot
of
personal
repositories.
You
know
good
apps,
at
least
one
of
them
got
stale
and
got
archived
the
go
bin
data
one.
C
So
we
have
to
kind
of
like
identify
what
others
are
there
that
we
are
using,
which
are
you
know,
owned
by
people
and
not
orgs,
and
see
if
there
are
any
alternatives
or
if
there
is
any
updates
like
this
one
was
clearly
the
Gobind
data.
One
was
clearly
marked
as
no
longer
active,
and
then
there
is
a
group
of
people
who
picked
it
up
and
created
an
or
called
Gobind
data,
and
then
this
started
supporting
it
from
there.
C
So
we
have
to
go
look
for
other
things
where
we
have
old
dependencies
and
see
what
we
need
to
do
with
them,
so
that
that
was
this
end
part.
Then
the
third
one
is
when
1/16
opens
up.
We
will
have
at
least
three
cloud
providers
that
we
wipe
off,
so
they'll
be
deprecated
for
a
really
long
time
and
they'll
be
out
the
door,
so
that
will
help
clean
up
some
of
the
dependencies
as
well.
Those
are
the
ones
that
I
remember
Jordan.
Was
there
anything
else
that
you
remember.
E
Not
especially
I
some
of
the
dependency
work
that
they've
been
looking
at
getting
libraries
dependencies
up
to
date
will
be
unblocked
by
the
the
compatibility
test
that
we
have.
We
can
now
move
those
forward
with
confidence
so
that
that
unblocked,
some
of
those
workers
bones-
that's
all
we
had
so
I
would
love.
Thank
you.
Thank
you.
So
much
for
tackling
these
issues.
I
think
this
is
such
a
cool
and
interesting
topic.
I
would
love
to
see
us
talk
more
about
it.
Write
more
about
it
present
more
about
it.
E
So
not
that
I
want
to
love
more
work
on
you,
Dems,
because
you
know
you
don't
sign
up
for
enough
stuff,
but
it
would
be
interesting
if
we
could
find
a
way
to
get
together
and
write
or
present
or
talk
about
this
either
at
you
know,
go
for
con
or
Q
Khan
or
something
they'd
be
really
interesting.
Topic.
C
Definitely
so
we
I'm
kind
of
like
you,
gonna
use
like
1/16
as
one
full
cycle
where
we
did
this
and
then
at
the
end
of
the
cycle,
then
see
what
we
can
collect
the
things
that
we
worked
on,
go
back
and
look
at
the
PRS
and
go
back
and
look
at
the
things
that
we
tackle
and
then
use
that
to
write
it
up.
And
then,
hopefully,
the
people
in
the
core
organization
there's
a
bunch
of
new
people
who
are
in
there.
A
Creates
back
to
you
all
right,
I
think:
that's
it
for
that
sub
project.
Let's
move
on
to
our
last
one,
which
is
the
conformance
sir
project
and
Timothy
st.
Clair.
You
are.
D
On
so
most
of
everyone
is
spinning
back
in
and
the
release
is
locked
out.
So
there's
not
gonna
be
any
major
additions.
At
this
point
to
115
we
pretty
much
bumped
all
the
languishing
PRS
to
116.
There
was
a
good
discussion
and
a
follow-up
from
koukin
from
the
data
that
hit
me
heck
represented
and,
as
a
result,
we're
gonna
create
some
umbrella
issues
to
help
drive
discussion
for
how
we
want
to
prioritize
execution
for
116.
D
So
our
current
plan,
a
record
now,
is
to
go
through,
create
umbrella
tickets
and
get
everything
in
place
for
us
to
have
a
planning
discussion
for
116
in
the
next
meeting.
So
if
you're
interested
please
come
and
we
will
try
and
get
you
assigned
to
the
funsies
of
trying
to
beef
up
to
conform,
a
suite.
C
D
Have
a
reasonable
it
varies.
Sometimes
we
do,
and
sometimes
we
don't
I
think
for
this
last
cycle
is
the
first
time
we
actually
functioned
as
a
sort
of
execution
rate
to
some
project,
as
together,
I
think
we
need
to
get
our
our
sea
legs
for
beating
that
drum.
So
ask
me
again
in
about
mid
1/16
and
I'll.
Give
you
a
better
answer.
I
think
thank.
B
A
A
Great
I
think
that's
it
for
our
regularly
scheduled
agenda
items.
Is
there
anything
anyone
else
wants
to
bring
up
or
discuss
freeform
before
we
adjourn
early
and
get
half
an
hour
back,
I.
C
E
For
Cuba
notice,
I
can
adjust
to
that
yeah.
There
is
it's
wrapping
up.
It
was
a
joint
audit
between
two
vendors
and
so
I
think
we
have
the
report
from
one
vendor
and
the
other
one
should
be
in
shortly.
At
that
point,
I
expect
the
issues
that
are
found
and
reported
will
be
categorized,
and
some
of
them
will
be
open
publicly
and
dealt
with.
Some
of
them
will
possibly
be
affects
privately.
The
way
we
do
normal
security
issues,
so
the
individual
issues
will
trickle
out
and
once
they've
been
all
been
dealt
with.
E
A
Great
all
right:
well,
thanks
everybody
for
an
efficient
and
productive
meeting,
thanks
to
all
of
our
subject,
sub
project
owners
who
are
driving
things
forward
and
thank
you,
everyone
who
is
attending
to
listen
and
participate
so
have
a
great
rest
of
your
day,
everybody
and
take
care
yeah
thanks.
Everybody.