►
From YouTube: Kubernetes SIG Architecture 20180208
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
A
B
I
got
a
little
bit
of
information
from
Brendan
on
the
cloud
provider.
Thing
I
think
that
he's
concerned
about
it
running
as
a
pod
or
service
on
the
cluster
and
basically
I
I
think
that
he
was
hoping
to
do
it
in
a
different
way
or
their
binary
is
on
each
node
and
the
couplet
shows
out
to
them.
So
I
think
that
that
was
the
the
concern
in
a
nutshell:
okay,.
A
A
Because
you
know
it's
I
should
look
at
that.
The
I'm
not
a
fan
of
shelling
out,
but
then
yeah
I
can
I
can
follow
up
on
that.
The
one
confusing
thing
about
the
cloud
provider,
the
current
cloud
provider
interface-
does
it
needs
both
no
local
functionality
and
cluster
level
functionality
without
a
clear.
C
Distinction
between
user
is
confusing.
I
tried
to
trace
that
the
AWS
cloud
provider
was
doing
it
different
modes,
and
it's
it's
like.
The
interface
makes
it
hard
to
figure
out
who's
doing
what
yeah.
So
the
interface
is
just
the
current
interface
is
just
wrong.
I
mean
the
interface
also
assumes
that
everything
is
being
provided
by
one
pattern.
As
you
look
to
go
things
like
on
Prem,
you
may
have
your
load
balancing
stuff,
be
one
type
of
thing
in
your
your
you
know,
octave
eye
stuff,
be
a
different
type
of
thing
or.
A
Even
that
all
nodes
are
in
the
same
provider
as
well,
though
I
think
that's
definitely
something
that
we're
gonna
have
to
look
at
at
some
point.
But
so
today
was
an
office
hour.
Those
were
the
two
potential
things
that
may
I
thought
may
had
been
brought
here,
but
I
don't
expect
them
to
be
brought
here
today.
A
Aaron
is
taking
a
well-deserved
break,
I
believe,
but
he
did
a
bunch
of
work
on
the
pushing
the
sub
projects
identification
forward,
starting
mostly
with
the
independent
repos,
the
freestanding
repos
and
then
just
doing
the
workloads.
Api
is
kind
of
an
example
of
some
things
that
are
in
the
kubernetes
repo,
so
we
need
to
flush
out
the
rest
of
the
sub
projects
in
the
kubernetes
repo,
which
is
most
projects
I
added
a
few
like
you'd,
be
nothing
like
that,
but
I
think
we're
ready.
A
C
I'm,
just
thinking
like
and
I
think
we
see
this
with
the
kept
stuff
right.
It's
like
it's
like
if
it's
all
processed
with
no
gain
it's
you
know
it's
like
people,
understand
yeah.
It's
like
eating
your
vegetables,
but
like
unless
there's
some
sort
of
clear
benefit
out
of
it.
I
think
it's
gonna
be
a
little
a
lot
trickier
to
do
this
stuff.
It.
D
Just
to
jump
on
dosing
here,
real
quick
here-
it's
actually
I
think
more
that
the
people
who
would
go
put
this
stuff
in
are
probably
overloaded
with
so
much
to
do
that.
This
is
just
gonna,
be
a
low
priority
on
their
list.
So
is
there
a
carrot
to
like
raise
the
priority
to
get
them
to
actually
look
at
this
or
get
engaged.
E
I
see
is
like
getting
engagement
because
an
awareness
right
because
getting
engagement
is
something
that
I'm
focusing
a
lot
on
lately
a
lot
more
than
I
have
in
the
past,
because
it's
I
think
it's
more
important
than
actually
just
doing
the
work
yourself,
but
getting
a
cohesive
group
of
people
to
make
it
sustainable
over
time.
Right.
We've
were
in
this
stage
now,
where
kind
of
like
we're
past
the
formation
of
the
star,
and
it's
now,
it's
animate
sequence
right
in
norfert
to
like
you
know,
not
implode
on
us.
E
We
need
to
make
sure
that
we're
like
have
a
sustainable
group
that
can,
like
you
know,
come
and
go
overtime.
That's
that's
important,
but
I,
don't
know
how
you
turn
that
into
a
carrot.
Right
like
that's
right
for
people
who
are
currently
the
sing
leaves
if
you
want
to
call
them
that
you
know
they're
doing
too
many
things
right
so.
C
I
mean
so
once
like
small
thing
we
can
do
here
is
update
the
generation
scripts
in
the
community
repo
such
that
on
the
sort
of
sig.
Read
me
page.
It
lists
out
and
I,
don't
know
if
Erin
already
did
that
it
lists
out
all
the
the
repos
that
are
associated
with
that
sig,
and
so
that's
just
I
mean
it's
some
simple
discovery,
but
you
know
I
think
people
can
be
like
okay
yeah.
C
A
C
Okay
thinking
here,
Justin
goes:
is
that
like,
if
we
can
actually
have
cigs,
be
more
sort
of
self-contained,
and
we
have
clear
lines
with
delineation
for
what's
happening
and
what's
saying,
then
those
things
can
actually
be
healthier
more
functional
over
time.
But
we
really
need
to
start
having
things
be
owned
by
the
project
as
a
whole,
which
is
now
a
tragedy
of
a
cop.
C
The
comments
to
actually
be
an
identifying
sort
of
what
is
the
small
group
of
people
or
a
smaller
group
of
people
that
is
responsible
for
any
particular
piece
of
code,
and
so
it's
one
of
those
things
where
you
know
when
we
get
there
I'm
confident
that
we're
actually
gonna
end
up
in
a
better,
more
functional
situation.
But
all
the
little
steps
along
the
way
are
a
little
bit
harder
to
justify.
I.
F
Mean
right
now,
I
think,
there's
a
massive
carrot,
which
is
a
little
different,
but
which
is
the
idea
that
sings
can
now
have
their
own
projects
in
a
repo
right.
So
I
think
that
will
be
something
which
I
don't
think.
It's
confirmed
yet
but
like
when
that
is
confirmed
in
an
hour
or
two
right.
Then
we
will
like
tomorrow
a
sagacious
meeting.
We're
gonna
talk
about
like
who
wants
to
have
a
project,
understand
a
DBS
and
what?
What
does
it?
C
C
A
C
A
A
G
C
That's
a
great
question:
it's
something
that
the
steering
committee
has
been
taking
up,
essentially
sort
of.
How
do
we?
How
do
we
start
getting
some
more?
You
know
explicit
governance
over
SIG's,
I,
don't
to
say
formal,
but
at
least
explicit
and
spelled
out.
There
is
a
PR
in
the
community,
repo
I
believe
it's
in
the
community
or
is
it?
Is
it
in
the
steering
committee
repo
forget
which
one
it's.
C
C
G
Reason
for
asking
that
is
when
you
would
somebody
into
becoming
a
member
of
a
particular
sig,
then
you
can
tell
them
that
look.
This
is
what
we
expect
from
you,
and
you
know
you
have
to
keep
track
of
issues.
You
should
help
try
out
stuff.
We
should
help
review
so
here,
essentially
they
are
buying
into
this
something.
Okay,
this.
A
A
A
So
that
would
be
a
way
that
we
could,
actually,
you
know,
put
those
drills
into
the
owners
files
and
specify
those
people
so
I'm.
A
fan
of
that
idea.
The
my
original
motivation
for
that
idea
is
I,
saw
success
within
the
release
team
of
getting
people
to
sign
up
by
saying
there
were
a
couple
of
aspects
to
it.
One
is
the
responsibilities,
the
scope
and
the
time
can.
It
was
a
lot
more
clear
for
people
then,
just
like.
A
Oh
there's
this
pile
of
github
issues
and
it's
not
clear
which
ones
are
important
or
you
know
how
actionable
they
are
and
stuff
like
that.
Please
go
help
us
with
that,
but,
like
that's,
not
people
didn't
even
know
how
to
get
started
on
that,
but
also
you
know
is
easy
for
them
to
explain
to
their
manager
is
easy
for
them
to
get
some
amount
of
credit
or
visibility.
H
H
Do
we
want
to
kind
of
put
a
canonical
set
of
roles
together
that
we
don't
have
to
force
on
any
SIG's,
but
like
these
are
kind
of
lone
four
or
five
roles,
whatever
that
we've
seen
work
in
a
few
good
SIG's?
And
maybe
you
want
to
pick
up
these
roles
and
names
just
so
that
there's
otherwise.
We
just
end
up
for
this
plethora
of
unintelligible
terms,
for
these
roles.
D
Maybe
do
it
as
examples,
because
a
number
of
SIG's
may
already
have
some
of
this
going
but
I
like
the
idea
of
documenting
this
in
examples,
because
when
people
get
recognition,
they
they
tend
to
jump
in
and
be
excited
about
that
kind
of
stuff
and
it
kind
of
gets
to
that
human
carrot.
There
they're
recognized
in
there
and
so
I
like
that
when
it
comes
to
that
you're
thinking,
the
mailing
list
is
a
way
to
describe
sig
membership.
D
So,
if
not,
but
is
there
a
better
way
to
say
who's,
a
member
of
a
sig
and
it's
hard,
because
if
you
say
you've
got
to
get
them
listed
in
the
file,
then
that
puts
expectations.
A
lot
of
our
commits
that
come
to
like
kubernetes
kubernetes
are
from
a
core
group
of
people,
then
there's
just
really
long
tail
and
so
to
become
a
member
you've
got
to
get
into
a
file
and
get
more
involvement.
D
Are
we
now
saying
they're,
not
a
member,
even
if
they
come,
but
they
lurk
that
that
kind
of
gets
into
an
odd
line
there,
and
you
know
we
want
to
be
careful
because
right
now
we're
talking
about
people
being
overloaded
doing
too
much
now
we're
talking
about
ways
of
raising
the
barrier
to
entry
to
involvement.
I
don't
do
anything
to.
A
H
G
D
And
I
get
a
lot
into
this
because
when
we
start
talking
about
members,
it
invariably
goes
into.
How
do
you
do
elections
and
now
you've
got
an
electorate
set
and
that's
where
a
number
of
the
conversations
have
come?
And
so
you
know
if
somebody's
involved
in
a
lurker
are
they
not
to
be
involved
in
elections?
Do
we
gotta
wait
for
that
to
be
contributors?
D
You
know,
and-
and
this
gets
to
the
sig
level,
because
people
have
been-
maybe
not
here-
I
can't
remember:
all
the
locations
have
to
talk
about
sig
level
elections,
and
then
how
do
you
decide
what
to
do
with
those
kinds
of
things?
If
we
eventually
go
that
route,
and
so
member
conversations
can
have
an
impact
on
that
or
the
language
we
use
now
contributor
is
a
little
bit
easier
to
look
at,
because
I
can
go
to
github
and
I
can
see
all
the
contributors
well,
I
can't
see.
G
That's
right,
but
then
what
happens
is
during
a
release
cycle,
for
example
right.
If
there
is
a
smaller
group
of
people
in
a
specific
thing
that
that
are
reachable
by
the
city
in
a
release,
team
lead
for
issue
for
things
that
need
to
be
fixed
or
in
a
mood
out
or
whatever
right
that
that
is
where
it
helps.
Oh
yeah.
D
Totally
but
there's
the
difference
between.
Are
you
a
member
of
something
and
are
you
fulfilling
a
specific
role
like
on
call
for
the
sake
and
that's
a
that's
a
vastly
different
thing.
Like
am
I
a
citizen
of
the
country
I'm
in
or
do
I
serve
in
the
government?
That's
kind
of
two
different
things,
but
you're
involved
in
it
from
one
way
or
another.
Okay,
Joe
I'll
be
quiet.
Now,
no.
C
Think
there's
also
the
question
of
as
we
look
towards
future
steering
committee
elections.
How
do
we?
How
do
we
come
up
with
the
members
of
standing
there
and
is
that
sort
of
the
transitive
closure
of
all
the
members
to
some
degree
of
what
member
means
of
all
the
sig
so
yeah,
all
right,
so
Brian
you
you,
you
had
a
comment.
Yeah.
A
I
just
want
to
put
the
brakes
on
like
way
off
topic.
Firstly,
architecture
at
this
point
and
it's
a
good
discussion,
but
it's
not
really
the
within
scope
of
cigar
picture
quinton
did
drop
a
link
into
the
backlog
for
his
labels
of
the
first-class
resource
proposal.
Do
you
just
want
to
say
a
few
words
about
that
Quintin
I.
H
Don't
want
to
waste
everyone's
time
because
the
documents
not
done
yet,
but
basically
it's
an
attempt
to
try
and
address
a
couple
of
issues
we've
run
across
and
various
different
guises
related
to
kind
of
referring
to
groups
of
objects,
and
it
came
up
in
multi-tenancy
and
it
came
up
in
Federation
and
since
throwing
that
dock
out
there,
a
ton
of
people
have
come
to
me
and
said:
that's
you
know,
we've
run
into
exactly
these
problems
before
so
it
seems
to
be
getting
some
traction.
H
I
haven't
had
time
to
finish
it
off
this
week,
yet,
but
I
just
want
to
make
everyone
aware
of
it
and
aware
that
it
doesn't
really
fit
terribly
well
into
any
of
the
existing
SIG's
other
than
this
one.
So
we
could
shoehorn
it
into
probably
sick
or
something
or
we
could
take
it
on
in
the
sig
I,
don't
know
what
your
preferences
are.
It.
H
C
C
C
The
problem,
though,
is
that
is
that
the
are
back
rules
are
based
on
the
actor
and
most
controllers
use
some
sort
of
joint
service
account.
That's
that
doesn't
represent
the
the
person
who
created
the
original
object,
and
so
this
is
this
is
our
issues
that
have
been
talked
about
quite
a
bit
and
say:
god.
There's
this
proposal
around
validated
annotations
that
is
facing
similar
problems,
that
Mike
Denis
and
some
of
the
security
folks
at
Google
have
been
pushing
also
fundamentally
objects
and
kubernetes
are
owned
by
the
namespace.
C
There
is
no
owner
field
on
an
object
and
so
that
there's
no
sort
of
propagation
or
reference
to
that
owner.
So
if
we
did
something
like
saying,
hey
certain
certain
labels,
we're
only
visible
to
a
specific
namespace
that
starts
getting
more
tractable,
because
most
things
operators
understand
the
namespace
that
they're
working
in
they
don't
understand
the
user
that
they're
working
on
behalf
of
but.
C
They're
only
at
scope
again
and
I
think
some
of
this
comes
down
to
notes
right
and
so
the
idea
of
like
having
a
label
on
a
node
that
gets
to
I,
don't
know
so
I
would
think
about
it
in
terms
of
name
spaces
being
the
security
boundary.
Because,
honestly,
that's
where
we're
at
right
now
versus
trying
to
actually
tie
this
back
to
users
because
of
the
confused
deputy
issues,
around
controllers.
H
Yeah
so
I
saw
your
comment
and
I
responded
to
it
in
the
document,
but
but
maybe
we
can
spend
if
we
have
a
minute.
So
a
lot
of
it
comes
down
to
exactly
this
problem.
I
think,
which
is
that
you
know
the
word
name.
Space
in
my
mind,
implies
that
it's
a
partitioning
of
the
names
so
that
you
can
have
duplicate
names
in
different
namespaces
and
it
has
come
to
take
on
a
meaning
of
role.
Essentially,
if
you're
in
this
namespace,
then
you
get
a
whole
bunch
of
you
know.
H
Permissions
to
do
things
is
that
is
that
a
and
then
and
then
we
we
had
a.
We
have
these
labels,
which
are
designed
to
divide
things
up
in
a
different
way.
Are
we?
Are
we
comfortable
that
the
word
that
the
concept
of
a
namespace
has
has
come
to
be
to
mean
in
many
respects
a
role
something's
in
that
namespace?
It
it
fulfills
a
role
and
has
all
the
permissions
associated
with
what
is
effectively
a
role
and.
H
C
Just
concretely
Brian
like
if
I,
if
I,
create
a
replica
set,
if
I
have
permission
to
create
a
replica
set,
I
have
a
permissions
to
essentially
create
a
pod
with
any
permissions
inside
of
a
inside
of
a
namespace.
Oh
because
we
don't
transitively
checked
our
back
right.
So
so,
if
there
was
like,
if
we
did
something
like
hey,
you
know
we
don't
have
this
pattern
now.
C
But
if
we
said
hey,
when
I
specify
a
when
I
specify
a
replica
set
part
of
the
metadata,
there
is
the
principle
that
the
controller
should
be
using
when
actually
creating
the
downstream
objects
right
and
then
it
impersonate
to
that.
And
then
it
uses
that
identity
to
create
the
downstream
objects.
If
we
had
that,
then
you
could
start
perhaps
tying
this
stuff
up
to
two
users
in
in
a
more
concrete
way.
But
then
that
would
be
up
to
the
controllers
to
actually
really
do
that
impersonation
and
make
that
happen
when.
I
A
C
I
H
Rather,
write
all
that
down
in
the
duct,
and
it
is
very
light
on
that.
But
the
basic
problem
is
is
referring
to
objects
and
it
boils
down
to
what
we've
just
been
discussing.
So
how
do
you?
How
do
you
determine
whether
an
action
is
allowed
based
on
the
are
back
authorization
of
whoever's
doing
it,
as
opposed
to
which
namespace
it
some
things
that
are
related
to
it,
live
in.
C
So
so,
for
what
it's
worth,
I'm
perfectly
happy
with
name
space
being
the
security
boundary
I,
don't
think
it's
it's
worth
the
turn
or
the
complexity,
to
try
and
subdivide
things
more
finely
and
just
historically.
This
is
based
on
you
know
lightly,
based
on
the
Google
model,
where
the
thing
that's
most
closely
analogous
to
a
namespace
and
Borg
is
in
fact
a
a
principal
in
a
roll,
and
it's
not
perfect,
but
but
it
actually
is
is
simple
enough
that
that
it
doesn't
have
any
sort
of
super
crazy
failure.
Modes,
yeah.
A
Namespaces
have
multiple
functions:
it's
a
scoping
mechanism
to
avoid
name,
collisions
and
label
selector
committees,
and
things
like
that
and
I
would
like
it
usable
for
that.
So
you
know
we
need
to
make
sure
that
users
have
all
the
partitioning
their
resources
into
multiple
namespaces
and
I.
Don't
think,
we've
done
a
great
job
at
that.
I
A
I
I
was
gonna,
say
for
what
it's
worth
the
azure
API
system
more
or
less
has
namespaces
and
hangs
our
back
and
policy
and
all
kinds
of
stuff
off
of
them,
and
it
is
that
lack
of
flexibility
has
actually
become
increasingly
a
problem,
so
we
should
consider
extending
it
to
be
label-based
effectively
at
some
point.
Yeah.
H
I
think
that
married
what
Clayton
said
as
well,
so
I
tell
you
what
I'll
do
is
I
will
get
much
more
concrete
in
the
dark
out
trying
to
enumerate.
You
know
20
important
things
that
we
would
like
to
do
and
that
we
either
cannot
do
with
the
current
system
or
can
do
with
with
some
major
compromises
and
then
once
we
have
that
on
the
table,
we
can
decide
whether
changes
necessary
to
accommodate
those
and
similar
types.
C
Of
things
so
for
what
it's
worth
I
think
you
know
the
core
of
this
discussion,
probably
you
know,
would
make
the
most
progress
and
sig
off.
This
is
the
type
of
stuff
that,
like
bakes,
your
noodle,
and
you
just
have
to
go
deep
into
it
to
really
understand
all
the
implications.
I
think
it's
a
feature
in
kubernetes
that
objects
are
not
owned
by
users.
It
creates
that
problem.
C
Where
I
mean
it
avoids
the
problem
where
individual
people
own
a
thing
and
then
that
person
needs
text
or
you
have
the
magic
laptop
with
the
key
on
it
or
whatever.
It
writes.
So
I
think
that
idea
of
group
ownership,
not
just
by
default
but
just
like
if
there
is
no
individual
ownership,
makes
a
ton
of
sense
that
Google
works
around
this
with
org.
Is
that
developers
get
a
private
namespace
for
their
private
stuff
and
then
anything
that's
running
in
a
shared
namespace
is
a
is
assumed
to
be
shared
across
a
group,
so
Joe.
A
A
B
A
I
A
A
I
I
know
that
that's
that's
fine
of
me
and,
as
you
said,
I
was
actually
there
for
most
of
that
discussion.
It
doesn't
feel
that
onerous,
so
yeah,
I
didn't
really
I
didn't
really
have
anything
to
add.
So
I
didn't
talk,
but
I
was
listening.
Yeah.
C
View
so
I
didn't
know
who's
on
and
then
and
then
there
was
Sebastian
asking
about
stuffs
which
brought
home
the
point
that,
like
we
aren't
being
very
explicit,
that
this
is
this
is
replacing
the
incubation
process
with
something
that
is
with
these
three
stages,
so
I
think
just
being
super.
We
were
explicit
about
that
would
be
helpful.
As
you
talked
about
yeah.
I
A
A
So
the
I
have
a
few
requests
already
for
some
transfers
of
existing
code
in
general.
I
think
there
are
a
bunch
of
issues
to
work
out,
but
my
read
of
the
CLA
is
if
the
code
is
from
a
single
author
who
has
signed
the
CEO
aid
and
it's
effectively
like
a
PR
right
right,
like
they
can
submit
the
code,
so
we
may
want
to.
I
I
H
C
So
Brian
I
I
mean
just
you
know,
separately,
I
think
understanding
the
different
ways
of
importing
code
under
the
under
the
CLA,
especially
around
the
Associated
project
stuff,
because
we're
looking
at
hefty.
Oh
do
we
want
to
take
some
of
the
stuff
that
we've
been
doing
and
make
it
associated
projects?
What
does
it
mean
because
those
things
do
have
multiple
offers,
some
of
them
outside
a
hefty?
Oh,
you
know
what
are
the?
What
are
the
forms
we
have
to
do
in
terms
of
chasing
people
down
and
getting
them
to
agree?
Yeah.
A
We
can
get
some
input
from
C&C
up
on
that
they
so
a
couple
of
things.
One
is
this
is
the
kind
of
thing
we
can
file
a
service
desk
ticket
for
so
we
should.
We
should
try
that,
and
the
second
thing
is,
they
are
reevaluating
the
whole
inception.
Little
project
idea-
oh
I,
know
so
that
may
be
an
avenue
for
for
some
of
these
associated
projects
as
well
as
to
go
into
the
scenes
you
have
sandbox
man
so.
D
A
Happens
a
lot
so
there
must
be
some
motivations,
I,
think
they're,
looking
for
tying
into
the
Kuban
I
I.
Guess
we're
trying
to
make
it
better
known
that
we
can
give
people
things
like
slack
channels,
but
I
think
people
perceive
that
they
will
get
more
collaborators
if
they
do
that
and
I
think
even
Matt
butcher
said
for
a
helm
that
he's
pretty
sure
that
moving
to
the
kubernetes
organ,
the
kubernetes
being
under
the
kubernetes
project
umbrella
did
help
with
that.
Okay,
well
blur
some
process.
D
Because
you
give
up
a
certain
amount
of
control,
you've
got
other
things
that
come
along
with
it.
You've
got
process
changes
that
happen
when
you
move
in,
and
so
that
becomes.
You
know,
there's
positives
to
it
and
negatives
to
it
and
I'm
wondering
if
there's
some
underlying
problem,
we
could
solve
in
a
different
way
than
bringing
more
stuff
that
the
steering
committee
and
whoever
else
needs
to
deal
with
so.
C
D
C
You
know
the
the
most
sort
of
core
net
easiest
ish
stuff
moving
out
from
that
is
stuff,
that's
sponsored
by
SIG's,
where
it's
it's
stuff
that
you
know
doesn't
have
full
endorsement
or
participation,
but
it's
a
place
for
SIG's
to
actually
start
working
on
some
code
in
a
collaborative
way,
and
then
you
know
there
are
still
some
open
questions
in
terms
of
how
do
those
projects
grow
up?
Do
they
then
migrate
in
is
what's
the
process
for
that?
C
Do
they
stay
in
that
org,
you
know,
can
they
call
themselves
GA
or
not,
based
on
like
what
does
that
mean
but
like?
But
in
any
case,
that's
the
idea,
and
then
there
was
the
third
thing
which
is
associated
projects
where
they
could
live
anywhere.
The
amount
of
process
overhead
and
whatever
that
goes
along
with
that
is
is,
is
near
zero.
C
It's
things
like
code
of
conduct,
I,
think
and,
like
you
know,
is,
is
probably
going
to
be
the
the
one
thing
that
that
would
come
along
with
that
and
and
the
biggest
gain
out
of
that
at
least
you
know,
from
from
my
point
of
view,
is
actually
being
able
to
take
advantage
of
the
CLA
from
from
the
CNCs
so
that
you
can
smooth
any
future
migration
path
and
not
have
to
go
through,
and
you
know,
do
a
very
painful
chase
down
of
everything.
That's
going
on
so
yeah
yeah.
D
So
I
actually
see
a
couple
of
things
that
you
pointed
out
there.
One
is
the
CLA
and
for
a
lot
of
us,
because
we
work
for
companies
that
have
signed
it.
It's
not
a
problem
but
to
bring
in
new
contributors
to
sign
a
CLA
that
does
raise
a
barrier
to
entry
to
a
lot
of
people
at
a
lot
of
companies,
because
a
lot
of
people
work
for
companies
that
haven't
signed
the
CNC
F
CLA
and
to
get
the
lawyers
at
their
company
to
do
so
or
their
associated.
C
E
I
really
like
it,
because,
if
you're,
if
you're
working
on
all
these
different
projects
around
the
periphery
as
the
ecosystem
grows
like
you,
don't
want
to
have
to
have
12
different
clas
that
you
have
to
sign
or
other
DCO
checks
or
all
the
other
stuff
going
on
you,
you
sign
one
and
you're,
you
hit
all
the
projects
associated
with
the
main
org
or
the
main
body.
That
is
a
highly
beneficial
thing.
I
see
it
also.
We
also
talked
about
it.
We
never
kind
of
explicitly
wrote
it
down.
E
D
D
Rpc
are
the
only
ones
using
a
CLA
and
so
there's
a
whole
lot
of
DCO
usage
out
there,
because
it
smoothes
that
out
and
now
we're
saying
a
lot
of
projects
should
go
into
the
CLA
and
Joe
actually
hit
on
a
point
of
because
maybe
someday
it'll
move
into
core
kubernetes,
and
so
you
can
already
see
a
thought
out.
There
you
know
is
that
is
that
the
reason
people
think,
oh,
maybe
someday
I'll
get
into
course.
D
Let's
get
CLA
going
early
because
that'll
smooth
that
process
eventually,
because
if
we
want
a
small
moving
core
where
we
don't
have
a
lot
to
manage,
which
I
keep
hearing
people
say,
then
we
don't
really
want
to
bring
in
a
lot
more
projects.
We
want
to
have
a
healthy
ecosystem
outside
of
it,
like
everything,
I
install
from
apt
from
Debian.
It's
not
run
by
Debbie
and
that's
that's
much
smaller
right.
Those
are
all
individual
projects
that
are
separately
managed.
D
They
don't
all
have
to
be
brought
into
Debian
to
be
part
of
it,
and
so
the
same
kind
of
thing
can
apply
to
kubernetes.
If
we
want
to
keep
the
course
small
and
what
the
project
has
to
manage
small
and
enable
people
outside
do
we
want
to
look
at
something
that
doesn't
tightly
couple
them
to
have
some
kind
of
association?
To
maybe
say
you
know
what
you
don't
have
to
have
the
CLA
by
checking
to
see
all
of
the
other
associated
things
right.
Is
there
other
ways?
We
could
do
that
yeah
they
didn't
they.
D
They
actually
had
a
lot
of
problems
and
I
know
there
was
a
lot
of
heartburn
about,
because
moving
from
a
CLA
to
a
DC
I
was
hard
I.
Don't
remember
the
final
reason
on
why
they
didn't,
because
I
had
moved
on
to
other
things
by
the
time
that
happened,
but
they
looked
into
it
because
there
was
a
lot
of
desire
to
do
so,
but
legally
it
was
very
hard
to
sway.
So.
C
Mad
I
think
so.
First
of
all,
like
my
comment,
around
keeping
flexibility
open
was
not
necessarily
moving
to
court
kubernetes.
You
have
no
idea
sort
of
other
ways.
We're
gonna,
find
a
group
and
promote
and
sort
of
you
know
layer
these
things
in
the
future
right,
so
I
think
it's
just
a
matter
of
flexibility,
and
the
second
thing
is
that
I'm
not
quite
sure
what
you're
asking
for
there,
because,
like
projects,
don't
have
to
opt
into
this
world,
I
mean
they.
Can
you
know
they?
They
can
continue
to
do
whatever
they
want
outside
of
kubernetes.
C
There's
no,
must
here,
I,
think
and,
and
the
name
you
know,
associated
project
is
not
perfect.
I
think
the
idea
was
to
to
have
a
class
of
projects
where
the
endorsement
level
was
near
zero
right.
This
is
not
endorsement
by
kubernetes.
This
is
just
somebody
who
you
know
wanted
to
say
I'm
in
the
kubernetes
orbit.
I
want
to
just
make
sure
that
I,
you
know
folks
who
are
already
contributing
to
kubernetes,
so
I'm,
not
quite
sure.
What
exactly
it
is
that
that
you're
asking
for
well.
D
I
would
actually
say
the
endorsement,
isn't
zero,
because
we're
saying
it's
an
Associated
project
and
we
may
all
say
the
endorsement
is
zero.
But
anybody
who
goes
and
sees
a
list
of
this
is
not
going
to
think
the
endorsement
is
zero,
because
it's
listed
as
an
Associated
project,
and
so
people
will
see
some
form
of
endorsement
to
these
projects.
Maybe
somebody
opted
in,
and
somebody
else
didn't
opt
into
this
they're
gonna
say:
oh,
this
is
an
Associated
one
and
its
competitor
isn't
associated.
So
this
is
kind
of
the
declared
one
we're
totally.
E
D
C
D
Then,
what's
the
difference
between
an
Associated
project
and
an
ecosystem
project,
when
one
has
decided
to
like
it
in
people's
minds
who
are
going
to
be
the
consumers
in
this
because
a
majority,
the
consumers
of
everything,
have
nothing
to
do
with
contribution?
How
will
they
perceive
the
difference
in
this
and
what
does
it
mean
and
then
how
will
people
try
to
use
that
to
gain
the
systems
and
one
extra
workload
does
that
put
on
the
kubernetes
org?
That's
the
reason
I'm
asking
these
questions
because
we're
we
say
it
means
no.
D
A
B
What
I
was
gonna
say
and
we
shouldn't
try
and
future-proof
ramifications
from
things
that
haven't
happened
yet
either
there's
there's
just
too
many
variables
so
also
being
mindful
that
community
is
on
on
top
of
trying
to
watch
for
these
sort
of
social
norms.
If
former
on
the
project,
so
there's
levels
of
reassurance
that
we
can
invoke,
if
you
need
it,.
A
All
right
so
about
15
minutes
left
so
I
actually
want
to
call
the
meeting.
I
have
some
stuff
I
need
to
do
for
the
community
meeting
and
we
exhausted
everything
on
the
agenda
and
we've
been
mostly
talking
about
not
Sagarika,
texture
stuff,
so
I
am
gonna.
Take
off.
You
can
continue
to
chat
if
you
want,
but
I
have
to
go.
Okay,
thanks,
Brian,
but
if
you
do
have
something
that
you
want
to
try
to
talk
about,
please
try
to
get
it
on
the
next
week's
agenda
as
soon
as
possible.
A
E
A
H
E
E
A
As
long
as
the
sig
says
yeah,
we
want
this
repo
I
think
they're
they're
not
going
to
be
any
barriers
to
that
move
that
that's
the
intent
anyway
and
we
can
say
that
at
the
meeting
but
like
at
home,
wants
to
move
to
the
sig
repo
or
some
scheduling
project
wants
to
move
to
the
sig
repo
or
whatever
yeah
I'm,
totally
cool.
With
that
we.