►
From YouTube: Kubernetes SIG Architecture 20190411
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
Today,
as
we've
come
to
our
new
format,
we're
going
to
cover
each
of
our
major
sub
projects
along
with
gaps,
because
we're
just
kicking
off
1.15
and
everything
that
goes
in
again
has
to
go
through
a
cap
and
sig
architecture
has
some
involvement
in
that,
and
so
with
that.
The
very
first
thing
we
have
up
is
code
organization
and
underneath
that
we
have
the
NGO
modules,
update
and
Jordan
I
think
you're
on
and
the
one
who
can
talk
about
this.
B
First
of
all,
we
talked
about
doing
a
Tech
Talk.
That
kind
of
just
walked
through
use
of
go
modules,
how
they
worked,
how
people
can
use
them
not
even
necessarily
specific
to
kubernetes
just
an
introduction
to
the
topic,
and
so
we
did
that
yesterday
and
API
machinery
that
was
recorded
and
there's
a
video
link
there
and
all
of
the
materials
demo
repos
and
scripts,
and
everything
that
we
did
are
also
published.
B
Jumping
down
to
how
kubernetes
is
using
go
modules,
our
use
of
go
modules
to
manage
the
vendor
directory
has
merged,
so
in
kubernetes
master
we
are
no
longer
using
go
depths
that
has
been
removed
from
our
tree.
That
has
already
let
us
do
things
like
identify
and
get
up
to
date.
Several
of
our
dependencies.
B
There's
some
follow-up
items
that
we're
working
on
around
making
sure
all
the
various
places
we
document
management
are
updated
and
then
some
feature
requests
that
we're
getting.
The
one
open
question
is
how
we
tag
our
published
dependencies
and
we're
still
working
through
some
questions
there.
We
want
to
move
slowly
and
carefully
before
we
change
any
strategy
to
make
sure
we
get
maximum
compatibility.
That's
where
we
are.
We
go
much.
A
C
Is
that
right,
yeah
I'm
working
on
that,
so
the
background
or
to
this
one
is
C
advisor
was
pulling
in
a
bunch
of
dependencies
that
didn't
really
need
or
or
we
had
already
eliminated,
like
rocket
and
missiles.
So
we
had
to
do
some
work
on
the
C
advisor
side
and
again,
Jordan
helped
with
a
lot
of
the
changes
there
as
well
to
kind
of
like
restructure
the
code.
C
So
we
we
don't
pull
in
everything
that
C
advisor
needs
for
itself,
so
we
had
to
distinguish
between
what
CL
grows
and
needs
to
support
all
its
runtime
versus
what
we
support
in
our
use
of
the
see
advisor.
So
that's
the
change.
That's
going
to
drop
like
harridan
90k
lights
of
code.
It's
specifically
from
me,
so
son
rocket.
It's
a
few
files
that
were
generated
that
were
used
most
of
it,
but
still
it's
a
significant
drop
in
what
we
need
to
support.
That's
fantastic.
A
C
I
have
the
pen
on
that,
so
I
was
waiting
for
some
of
these
preliminary
stuff
to
land.
Now
that
we
have
the
go
stuff,
we
we
are
piloting
some
of
the
things
with
like
the
darker
dependency
and
the
see
advertiser
dependency.
So
those
and
the
docker
is
landing
today
see
advisor,
will
land,
probably
tomorrow,
so
I
wanted
to
get
them
make
mechanism
smooth.
First
then,
a
locus,
for
example,
helping
me
try
to
figure
out
where
we
need
to
do
what
we
need
to
tackle
next
and
I
pointed
him
to
you
Andrew
to
help
prune
dependencies.
C
D
C
C
Right
and
you
know
what
we
were
talking
yesterday-
also
was
okay,
so
so
far,
what
we
have
done
is
individual
SIG's.
Like
say
gay
p.m.
actually
requested
for
an
import
of
an
external
repository,
and
then
they
they
were
willing
to
own
that.
So
the
president's
that
we
have
is
4G
log,
llamo,
I,
don't
remember,
exact
I
was
involved
in
these
two,
at
least
where
they
ended
up
in
one
specific
thing.
C
So
now,
if
we
are
going
to
do
this
between
where
multiple
things
are
involved,
we
don't
have
a
precedent
for
that
right
now
and
if
the,
if
we
need
to
do
this
for
an
existing
repository,
then
again,
that
is
something
that
we
haven't
done
that
yet
so
we
will
have
to
figure
out
the
best
way.
Probably
to
do
this
is
to
start
a
cap
with
information
on
what
the
code
is
going
to
be
and
who's
going
to
own
it
and
get
the
six
to
sign
off
and
then
start
the
github
process.
C
E
C
Right,
one
more
thing
that
I've
heard
from
before
is
people
saying:
oh,
if
it
is
not
in
the
main
KK
repository
I,
don't
want
to
actually
be
responsible
for
it
so
again,
so
this
is
that's
why
I
think
it
makes
sense
to,
since
we
are
going
to
span
multiple
SIG's
and
if
fitting
its
existing
code,
and
things
like
that,
so
I
think
it
would
make
sense
to
like
do
a
cap.
Does
that
sound
fair
to
everyone?
Yes,.
E
E
F
That's
exactly
the
case
for
like
sync
poster
lifecycle,
sponsors,
and
it
doesn't
only
a
bunch
of
individual
repositories.
The
only
purpose
of
us
being
on
the
owners
files
is
to
clean
up
in
the
in
the
state
of
could
be
a
shoe
or
like
in
the
no-win
scenario.
When
we
need
to
put
this
thing
in
attic,
we
have
apples
and
rights
to
push
it
into
a
different
location
other
than
that
the
owners
files
are
the
source
of
truth,
and
they
are
the
ones
that
maintain
it
right.
C
So
that
is
just
for
the
ownership
part
right
now.
We
also
have
to
talk
about
if
you're
gonna
get
code
in
from
an
existing
repository
outside
that
was
developed
the
outside,
then
you
know
what
is
there?
What
do
we
do
right
now?
What
we
do
right
now
is
we
get
the
6-2
sign
off.
We
get
the
cigarette
texture
to
sign
off,
and
then
we
essentially
tell
the
github
the
people
who
manage
our
github
resource
to
create
the
repository
so
I
guess
we
have
to
do
exactly
the
same
thing
here
as
well.
A
Probably
I,
although
I
don't
know
that
we
need
to
have
two
cigs
owning
it.
You
know,
as
it
was
kind
of
said,
I
think
everything
these
days
falls
under
a
single
cig,
which
in
many
cases
again
is
coby
Marashi
proof
for
something
like
this.
If
something
happened
and
everybody
left
you
need
to
have
somebody
with
rights
and
sig
apps
has
some
projects
that
are
the
same
way.
A
Those
kinds
of
things,
I,
don't
know
that
we
need
to
have
multiple
things
and
some
of
the
stuff
we
work
on
in
say,
gaps
is
a
perfect
example,
because
we
work
with
sig,
node
and
scheduling,
and
things
like
that.
We've
had
to
divide
up
who
owns
it
and
some
things
like
upon
disruption.
Budgets
have
actually
moved
from
one
cig
to
another
to
who
owns
these
things
over
time,
even
when
people
on
both
sides
end
up
working
on
it.
So
I
don't
know
if
we
need
to
go
with
that
kind
of
complex
on
it.
A
C
D
A
And
if
you
probably
get
sign-off
from
both
of
the
SIG's
on
it,
I
don't
think
there
will
be
a
big
deal
and
the
Charter
could
be
amended
and
you
can
bring
the
right
people
and
from
the
steering
committee
and
you
can
have
all
the
sig
sign
off
on
it,
and
everyone
will
probably
be
okay
with
that.
That's
what.
E
I
was
just
wondering
you
know:
there
are
a
number
of
these
incubator
projects,
which
are
sponsored
by
particular
SIG's,
and
you
know
some
of
them.
As
you
said,
they
are
owned
by
multiple
SIG's
and
we
could
have
even
more
of
those
one
thing
that
I've
noticed,
at
least
in
the
case
of
our
own
sig
sig
scheduling
is
that
a
lot
of
these
projects
are
developed
completely
independently.
In
other
words,
and
not
in
a
very
political
way,
we
don't
care
about
them
in
a
way
all
right.
E
So
it's
just
people
who
own
those
repositories
are
free
to
check
in
anything
they
like,
and
you
know,
sometimes
people
go
away.
Other
people
take
over
stuff
like
that
happens,
and
since
they
are
still
under
the
kubernetes
repository
I
believe
there
is
a
sense
of
trust
in
such
repositories,
and
people
may
think
that
the
code
in
these
repositories
are
benign
and
have
certain
quality,
while
that
say
basically
false
impression.
A
lot
of
times
many
of
the
folks
who
are
really
responsible
for
the
six,
don't
know
it.
E
F
This
was
explicitly
specified
as
part
of
the
steering
committee,
governance
and
project
structure
that
brandon
burns
created
the
organizational
structure
around.
We
should
probably
update
language
to
basically
make
that
make
it
clear
that
these
are
not
communities
core
projects,
I
mean
by
creating
the
community
SIG's
repo.
F
This
follows:
there's
a
broader
set
of
issues
that
arise
from
this
like
we
need
to
make
sure
that
things
that
are
created
in
there
have
some
type
of
naming
convention.
Maybe
that
allows
things
if
they
create
CR
DS
that
those
CR
these
are
well
typed
or
well
scoped
to
a
given
name.
So
that
way,
you
know
it's
clear:
what
is
Korn,
what
does
not
I
think
we
do
I
think
we
should
have
some
conventions,
but
we
haven't
formalized
any
of
that.
E
F
E
That
a
lot
of
people
see
a
link,
for
example,
to
download
certain
code
from
a
certain
place
and
as
soon
as
they
see
that,
for
example,
the
link
is
pointing
to
a
kubernetes
repository
that
sense
of
you
know,
trust
worthiness
comes
with
it.
They
don't
necessarily
go
and
read
all
the
documents,
so
we
should
probably
so
basically
along
the
same
line.
What
is
the
benefit
of
having
these
depositors
are
the
vanities.
C
Right
and
more
specific
reason,
I
would
say
is:
is
this
code
that
is
coming
in
going
to
be
used
by
other
projects
in
cumin
artists,
which
is
what
we've
been
doing
so
far?
We
did
the
CSI
stuff
cloud
provider
stuff,
it's
all
feeds
into
other
communities,
projects
or
pulled
in
by
a
libraries
or
whatever
right,
so
is
there
any
overlap
of
such
kind
in
the
incoming
code?
That
would
be
the
other
question.
I
would
ask
yeah.
E
G
E
D
Right,
I
just
wanted
to
make
an
observation
that
this
is
a
very
analogous
sort
of
situation
to
what
we
haven't
seen
CF
in
general,
we
have,
you
know,
seen
CF
projects.
The
fact
that
they're
in
the
CNC
air
convey
is
some
kind
of
degree
of
trust,
but
you
know
the
CNC
F
itself.
The
staff
of
the
CNC
are
for
the
TOC
or
whoever
do
not
do
not
actually
verify
exactly
what
goes
in
there.
D
They
do
some
due
diligence
at
some
point
when
the
thing
enters
and
and
the
effective
way
of
dealing
with
this
is
either
if
there
is
something
bad
happening
in
a
project.
Someone
escalates
that
there's
a
well-defined
escalation
path
where
you
can
say
I,
don't
like
what
this
project
is
doing
and,
conversely,
there's
also
like
an
annual
review
process
where,
once
a
year,
we
have
a
look
at
the
stuff,
that's
in
the
CNC
F,
and
we
we
say:
oh
that
still
you
know,
should
be
here
or
it
should
be
retired
or
archived,
though
so.
F
I'm
gonna
try
and
table
this
conversation
because
this
this
is
not
cigar
ch.
This
is
steering
and
there's
documentation
around
this.
That
outlines
this
that
was
created
by
steering
and
if
we
want
to
refine
the
process
or
if
we
have
issues
I
highly
folks,
violent
issue
with
the
steering
repository
and
we'll
follow
the
up
button
that
item
so.
I
I
would
I.
This
is
a
little
mountain
daily.
Yesterday
we
were
talking
about
this
and
we
said
we
wanted
to
move
it.
I
think
what
we
should
probably
do
is
get
this
into
a
written
form
and
decide
whether
it's
steering
or
arch
and
then
move
it
to
one
of
those.
But
yesterday
we
were
talking
about
doing
it.
An
arch,
so
I
think,
there's
like
I
think
we
need
to
decide
the
student
committee
we
want
to
bump
with
the
steering
committee
ask
whether
it's
there
and
then
we
should
make
it
there.
F
I
F
Creation
of
the
creation
of
repositories
and
the
guidelines
of
what
promises
exist
there
it.
What
you
know,
what
type
of
suppositions
we
make.
That
alone
was
created
by
steering
like
how
they
do
their
business,
which
was
this
the
the.
What
the?
How
was
the
question
of
we
don't
care
and
that's
a
separate
cigars
discussion
to
define
of
like
if
people
want
to
have
some
type
of
policy
thing
right.
C
A
F
A
F
First,
step
was
a
PSA
that
we
had.
We
have
switched
from
weekly
to
bi-weekly,
I.
Think
the
purpose
or
intent
behind
the
initial
weekly
is
to
get
everybody
up
to
speed
who's
going
to
depend
for
most
meetings
and
no
one
objected
to
going
to
bi-weekly.
I
thought
weekly
was
a
bit
too
much
just
as
a
peer
as
a
number
of
PSAs.
That
kind
of
follow
on
from
here.
F
The
first
is
that
we're
kind
of
updating
the
criteria
for
promotion
and
for
what
a
conformance
distance
part
to
take
into
account
some
of
the
windows
isms
that
exist
and
making
sure
it's
very
explicit.
So
as
people
do
reviews,
they
have
enough
literature
to
go
back
on
and
to
verify,
there's
also
an
update
to
people
who
are
doing
reviews
and
approving
that
they
can.
They
can
kick
the
windows
test
via
the
bots,
so
I
highly
recommend
taking
a
look
at
that
PR.
F
C
I
have
an
update
from
that.
The
three
of
us
talked
today
and
we
wrote
up
what
we
did.
It's
back
in
the
notes
for
wherever
document
was
so.
Basically,
the
issues
are
around.
How
do
we
make
sure
that
we
can
build
windows
image
with
the
make
files
on
the
dacha
files
in
our
in
our
cake,
a
repository
either
in
the
CI
or
when
somebody
builds
it
by
hand
for
a
test
image,
for
example
right
and
be
sure
that
it
ends
up
in
the
manifest
which
for
the
multiple
architectures?
F
As
a
group,
we
walk
through
good
prioritization,
using
Brian's
l
doc
as
a
rubric.
It
kind
of
I
think
we
should
try
to
try
to
refine
and
have
explicit
prioritization
for
how
we
want
to
evaluate
what
we
should
be
doing
next
and
I.
Think
we'll
talk
about
that
during
the
next
meeting.
Last
but
not
least,
there's
a
couple
of
asks
that
are
ongoing
of
where
some
test
automation
work
to
help
refine
and
manage
our
project
board
a
little
bit
easier.
F
A
B
B
So
there's
a
link
to
pull
the
first
step
is
to
come
in
identify
the
existing
approvers,
like
which
areas
they've
worked
in
and
have
knowledge
in,
and
the
next
step
will
be
asking
sig
owners
to
and
leads
to
identify
people
from
their
areas.
And
there
are
commented
out
aliases
that
will
identify
those
people
and
that
will
give
us
a
really
good
way
to
funnel
reviews
the
right
people
quickly.
So
the
next
step
is
to
when
questions
do
bubble
up
new
new
types
of
api's
or
new
concepts.
B
I'll,
probably
start
it
by
weekly
a
little
lesson
from
the
congruence
one
and
not
not
trying
to
be
an
overachiever,
probably
start
by
weekly
and
then
pick
a
specific
place
either
my
own
list
or
Tim
was
saying
the
discuss
topics
we're
working.
Well,
for
them
where
we
can
start
discussions
ahead
of
time.
A
All
right,
then,
we'll
move
on
to
the
last
topic,
which
is
I
have
kept
here.
Caps
in
114
became
a
mandatory
thing
for
features
and
changes
to
land
into
kubernetes
and
in
115
that's
going
to
continue
along,
and
so
those
that
relate
to
sikh
architecture
are
something
we're
gonna
want
to
keep
on
top
of
just
to
make
sure
we
don't
inadvertently
block
someone
to
make
sure
we're
reviewing
them.
A
We've
got
somebody
assigned
to
approve
them
if
we
need
that
and
so
forth,
and
so
the
couple
of
quick
links
I
have
in
here
are
for
the
114
or
115
release,
so
anything
that's
going
into
the
release.
Even
if
it's
a
cap
needs
a
tracking
issue
and
that
tracking
issue
should
end
up
in
the
115
release
and
then
they're
all
the
sig
architecture
kept
updates.
You
can
find
both
of
those
as
of
right
now
and
115,
so
the
115
release.
The
list
is
really
short.
A
There's
only
one
sig
architecture,
one
which
is
to
add,
go
module
support
to
kubernetes.
That
is
already
ongoing.
As
we
talked
about
the
list,
right
now
doesn't
have
much
in
it
because
they
haven't
started
curating
it
or
working
on
it.
That
is
something
that
they
plan
on
doing
later
this
week
early
next
week
to
get
the
ball
rolling
on
this,
and
so
it's
something
we'll
need
to
keep
our
eye
on
and
I
just
wanted
to
put
the
links
in
here
and
make
sure
everyone's
aware.
A
You'll
see
there
are
9
or
10
things
that
are
currently
there
across
various
SIG's.
So
maybe
one
of
your
other
SIG's
has
something
in
here
that
needs
review,
but
these
are
all
the
things
that
are
being
tracked
for
115
at
the
moment
will
expect
that
to
change,
probably
by
the
time
we
meet
back
in
two
weeks
and
maybe
we'll
have
something
to
talk
about,
but
I
just
wanted
to
raise
that
up.
A
Alright,
we
are,
we've
got
about
27
minutes
left
and
we've
burned
through
the
agenda,
that's
fantastic,
so
we
can
have
a
minute
for
open
discussion
just
in
case
there's
something
that
needs
to
come
up.
So
does
anyone
have
anything
else
that
we
need
to
discuss,
or
is
there
something
we
should
break
early
for
you?