►
From YouTube: 20201105 SIG Architecture Community Meeting
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,
hello,
welcome
everybody.
This
is
the
kubernetes
stick
architecture,
community
meeting
for
november
5th
2020.,
please
I'll,
remember
that
this
is
a
recorded
meeting
that
will
be
preserved
on
youtube.
So
please
treat
each
other
with
respect,
follow
our
code
of
conduct
and
happy
to
have
you
all
here,
I'm
hoping
to
happy.
We
have
a
good,
interesting
discussion
today.
A
A
Okay,
all
right
last
meeting,
we
tim
all
claire,
brought
to
the
meeting
a
document,
an
agenda
item
around
the
discussion
around
possibly
some
sort
of
access
control
metadata,
whether
that's
labels
or
something
else,
and
we.
Unfortunately,
none
of
us
were
prepared
to
discuss
it
at
the
time.
A
So
we
put
it
on
the
agenda
for
this
meeting
and
I
sent
out
a
mail
an
hour
and
a
half
or
so
sorry
it
was
not
two
days
ago,
but
to
remind
folks
so
hopefully,
people
have
had
a
chance
to
review
that
and
and
start
the
discussion
so
to
him
as
you're
on.
So
if
you
want
to
provide
any
additional
context
or
we
can
jump
in
with
what
what
people
think
here.
B
B
In
the
case,
when
users
of
those
name
spaces
are
granted
permission
to
edit
the
labels
on
the
namespaces,
but
we
still
want
to
restrict
them
by
the
network
policy,
so
there's
sort
of
a
there's,
a
path
forward
for
network
policy
in,
in
this
specific
case
of
enumerating
the
names
based
names
explicitly
and
moving
away
from
labels.
B
So
that's
kind
of
the
context
for
for
talking
about
this
and
sort
of
around
secure.
I
would
call
it
like
secure
policy
binding
or
enforcement,
there's
kind
of
another
discussion
that
came
out
of
came
out
of
this
discussion
or
another.
I
guess
use
case
that
came
out
of
this
discussion
around
a
resource
hierarchy
and
so
we're
kind
of
policy.
B
It's
related
to
policy
delegation.
But
if
I
want
to
have
something
that,
let's
say
a
policy
that
applies
to
a
deployment,
how
can
I
kind
of
propagate
that
policy
down
to
the
pods
that
are
ultimately
created
for
that
deployment
or
a
policy
at
the
name?
Space
level
like
it's,
propagated
down
to
things
within
that
name
space
that
one's
a
little
more
clear.
B
So
that's
kind
of
related
to
some
of
the
discussion
around
inheriting
tags
and
inheriting
various
features
as
well.
A
All
right:
well,
thanks
tim,
I
guess
what
we
can
do.
Maybe
is
take
a
look
here
at
the
document
that
tim
that
team
and
garlene
put
together.
A
A
Okay,
I
was
curious
about
one
of
the
things
I
was
curious
about
with
tags,
so
we're
talking
about
so
with
with
the
others
I
mean
it
sounds
like
nobody's,
particularly
looking
for
metadata
policy
anymore,
like
that
was
you're
sort
of
mentioning
it
for
completeness,
but
I
didn't
hear
anybody
arguing
for
it
protected
attributes.
I
mean
these
are
my
opinions.
My
summary
is
protected.
Attributes
sounds
pretty.
A
You
know,
pretty
powerful,
pretty
complex,
pretty
pretty
pretty
difficult
to
implement
we're
really
not
so
much
that
but
pretty
unnecessary
to
implement
within
our
core
infrastructure,
because
we
can
already
do
this
with
gatekeeper
or
with
oppa
or
with
other
emission
controllers.
So
it
wasn't
clear
to
me
that
there
was
a
specific
need
for
that
anymore
and
tags
character.
The
thing
about
tags
that
I
thought
was
different
to
characterize
it
differently
than
the
others
was.
It
was
creating
a
separate
resource
that
could
be
our
backed
using
our
standard.
C
I
I
saw
some
comments
about
it
being
a
separate
resource,
but
then
it
wasn't
clear
that
that
was
what
everyone
was
expecting
like.
If
it's
a
new
type
of
metadata
in
some
cases
it
could
be
loosely
coupled,
but
in
other
cases
you
would
expect
it
to
be
associated
with
the
object.
So
I
saw
sort
of
pros
and
cons
discussed
in
the
thread
on
that.
The
the
main
difference
seemed
to
be
who
was
expected
to
set
it
rather
than
whether
it
was
stored
with
the
object
or
not.
A
Yes,
but
I
guess
the
implement
yes
right,
it's
more
the
implementation
detail
about
how
you
manage
the
separate
set
of
our
back
rules
that
would
apply
to
this
particular.
D
My
my
recollect
recollection
of
that
thread,
which
might
be
faulty
because
I
didn't
go,
re-read
it,
but
if
I
recalled
people
wanted
to
set
it
separately,
but
it
was
a
totally
open
question
whether
it
would
be
best
to
optimize
things
by
also
like
actually
literally
storing
it
with
all
the
objects
so
yeah.
C
E
D
E
E
A
That's
a
good
question:
it
doesn't
you
know,
I
guess
I
hope
to
have
a
decent
discussion
here,
but
we
probably
just
need
a
lot
more
work
in
defining
what
the
use
cases
are
and
and
why
any
one
of
these
solutions
may
be
better
than
the
other.
I
mean.
I
think
that
my
understanding
is,
like
jordan
said
it's
about
who's.
A
Writing
it
it's
it's
not
a
selection
use
case,
as
it
is
as
much
as
a
policy
use
case
in
that
every
you're,
evaluating
the
resources
against
the
policies
and
so
you're
looking
at
every
resource
anyway,
as
opposed
to
selecting
resources
using
these
now,
labels
obviously
are
selectors
and
that's
the
primary
use.
I
would
say
the
the
tags
would
have
a
different
set
of
it.
They
would
be
sent
admitted
by
administrators
as
to
as
opposed
to
by
the
people,
creating
the
objects
themselves.
A
So
it
sounds
like
what
daniel
was
saying.
Well,
I'm
not
sure
if
it
was
daniel,
jordan.
Somebody
suggested
you
create
this
tag
and
then
you
would
apply
the
tag
on
the
creation
of
the
object
or
something.
So
it's
almost
like
a
like
a
a
preset
or
something
of
of
tags.
Is
that
what's
being
proposed?
It's
not
it's
not
real,
clear.
D
D
A
That's
all
I
was
going
to
say
I
would
say:
maybe
what
we
should
do
coming
out
of
this
is
get
general
feedback.
On
of
these
three
approaches.
Do
we
feel
the
need
to
flesh
out
more
than
one
of
them?
Do
we
do
we
think
you
know?
Is
anybody
really
interested
in
number
one
or
number
two
or
number
three,
and
maybe
we
can
start
to
just
take
that
as
guidance
as
to
which
ones
need
to
be
fleshed
out
more
rather
than
since
it
seems
like.
F
D
From
my
perspective,
I
guess
the
thing
that
would
be
useful
in
this
group
is
to
decide,
if,
or
or
or
at
least
collect,
like
user
data
like
how
much
need
is
there
for
these
things
like
any
of
them,
because
it
would
be
kind
of
disruptive
and
a
little
risky
to
implement
without
breaking
existing
clients.
D
I
think
this
would
be
my
primary
concern
with
any
of
these,
and
I
think
the
actual
work
for
implementing
these
things
would
be
coming
from
mostly
sig
authentic
api
machinery.
So
I
think
we
would
need
to
get
those
sigs
to
like
actively
sign
up
for
this.
D
I'm
not
personally
excited
about
any
any
of
the
things
on
this
on
this
list,
but
I
I
you
know,
a
sufficient
hoard
of
users
would
probably
convince
me.
E
I
wanted
to
draw
an
analogy
here
to
the
challenges
we've
had
with
working
group
multi-tenancy
and
finding
like
implementing
things
that
aren't
just
mechanical
transformations
right.
So
namespace
selector,
like
some
of
the
work
huawei
did
where
they
created
an
entirely
different
virtualized
control
plane.
Some
of
the
other
elements.
You
know
we
really
just
have
a
couple
of
hammers
and
we're
using
them
the
same
way.
You
know
one
of
the
best
arguments
for
a
new,
a
new
mechanism
is
that
it
allows.
E
You
know
whether
it's
like
say
like
there's
a
new
scope.
We
only
have
cluster
and
namespace
like
a
new
scope,
that's
truly
orthogonal
or
the
idea
that
namespace,
like
the
whole
point
of
that,
is
to
free
up
and
allow
some
of
these
problems
to
get
solved.
E
Would
we,
as
a
group,
be
skeptical
of
something
that,
like
you
know,
we
talked
about
user
feedback,
is
user
feedback
from
things
like
say
multi-tenancy
or
the
working
group
multi-tenancy?
E
That
said,
you
know
which
of
the
approaches
there
even
benefit
from
some
of
these
things
or
not,
and
is
that
a
is
that
an
appropriate
test,
because
I
I
see
a
struggle
to
cross
policy
like
we've
delegated
a
lot
to
policy
and
that's
successful
web
hooks.
Kick
the
problem
down
the
can
and
we
have
our
back
and
we've
done
just
a
tiny
set
of
tweaks
around
it.
We
have
not
added
a
new
fundamental
concept
in
five
years.
I'm
not
saying
that's
the
reason,
not
to
add
a
new
one.
What's
the
bar.
C
The
only
way
we
can
choose
what
the
policy
is
with
the
selector,
but
then,
if
you
can
edit
it,
then
you
can
influence
whether
it
falls
into
the
policy
or
not
like
some
some
of
the
extension
points
we
have
today,
we
just
have
to
say,
like
you,
can't
let
someone
edit
a
namespace
labels
if
you
want
to
decide
whether
their
their
thing
falls
under
policy
or
you
can't
use
object
level
selectors
because
it
for
policy
security
related
web
hooks,
so
that
that's
a
pretty
big
caveat
to
the
current
I
mean.
D
Yeah,
we
definitely
don't
support
that
stuff
out
of
the
box,
but
I
really
think
if
you
were
motivated
enough,
you
could
build
it
with
web
hooks
and
separately
storing
things.
B
B
B
If
we
want
to
keep
it
simple
as
a
kind
of
built-in
admission
controller,
I
agree
with
you
daniel
that,
like
it
would
be
pretty
straightforward
to
implement
this
as
a
web
hook,
but
there
are
some
challenges
with
web
hook
admission
from
a
security
perspective,
and
this
feels
like
kind
of
a
fundamental
enough
use
case,
that
this
might
be
one
of
the
few
policies
that
actually
makes
sense
to
be
built
in
as
a
kind
of
core
policy
type.
D
I
I
mean,
even
if,
even
if
we
want
to
build
something
and
adopt
it
in
core,
like
I'd,
still
prefer
to
see
it
built
separately.
First,
you
may
not
want
to
use
a
like
admission
web
hook.
You
might
want
to
use
the
auth
z
web
hook
to
do
some
of
the
implementation
or
a
combination
of
both
but
yeah
yeah.
I
I
also
think
a
separate
implementation
would
demonstrate
that
the
concept
is
sound
and
that
it
has
users.
A
I
think
one
of
the
concerns
with
the
putting
constraints
on
with
reusing
labels
and
then
trying
to
tackle
individual
keys
on
labels
is
clients
that
don't
necessarily
properly
handle
merging
those
label.
Patching
those
labels
and
therefore
try
to
put
a
label
and
what
happens
for
them
does
the
whole
put
get
rejected.
D
Yeah,
no,
I
I
even
in
cases
where
I'd
really
like
to
break
clients
that
are
doing
bad
things
like
putting
in
duplicate
owner
references,
as
we
talked
about
yesterday
in
ap
machinery,
we're
coming
down
pretty
heavily
on
the
side
of
like
not
breaking,
not
actually
breaking
clients.
C
Clayton
to
your
to
your
question
about
like
what
is
different
or
new
about
this,
I
think
the
the
idea
that
it's
policy
oriented
and
therefore
there's
an
expectation
that
there's
ackle
around
it
and
it's
trustworthy,
like
labels,
were
super
useful
and
the
horse
sort
of
got
let
out
of
the
barn
and
then
later
we're
like.
C
Namespace
labels
are
totally
unprotected
and
anyone
can
set
anything
and
then
in
other
systems.
There's
all
this.
You
know
webhook
opa
gatekeeper
mechanism,
stuff
around
it.
I
I
think,
having
identifying
the
use
cases
and
then
thinking
about
like
are
those
possible
to
address
with
the
existing
mechanisms,
or
would
it
be
either
too
inconsistent
or
too
difficult
to
use
to
try
to
bolt
it
on.
E
Top
yeah
and
we've
never
done
a
two-way
like
so
an
example
here
would
be
like
with
persistent
volume
claims.
We
went
through
the
whole
thing
about
like
how
do
you
move
a
persistent
volume
from
one
namespace
to
another?
If
you
weren't
editor
in
both
namespaces
and
you
can't
fiddle
with
persistent
volumes,
we
basically
punted
and
said
admins,
but
there's
kind
of
a
this
is
like
the
standard
you
offer
something
up
and
someone
has
to
accept
it.
I
would
like
to
see
some
discussion
about
labels.
E
Is
there
a
difference
between
labels,
as
you
declare
them
and
labels,
as
you
are
allowed
to
be
selected
on
by
them,
which
is
not
really
any
of
these,
but
is
another
dimension
like
we
talked
about
this
with
our
back?
For
I
don't
know,
we
talked
about
it
a
while
a
couple
years
ago.
It
was
just
a
if
you
have
to
if
you
have
to
have
permission
to
be
queryable
or
selectable,
distinct
from
the
permission
to
set
it.
Does
that
change
some
of
the
the
calculations
here
for
things
like
labels?
C
E
We
know
that
there's
a
vast
majority
of
things
out
there
that
are
using
annotations
and
labels
for
policy
already
a
new
thing
that
you
would
would
have
to
be
a
superset
of
the
things
that
you
use
labels
and
annotations
for
that's
what
makes
me
a
little
squinty
about
tags.
Is
you
know
if
I
want
to
do
policy
on
your
ability
to
set
attached
data
on
an
object
like
attach
data
as
a
generic
concept?
Selection
is
a
generic
concept.
E
If
we
add
a
new
generic
concept,
it
doesn't
allow
me
to
control
those
those
previous
two
right
like
tags.
Wouldn't
let
me
carry
label
values
and
do
selection
tags.
Wouldn't
let
me
have
extended
json
descriptions
of
attached
data
now,
maybe
it
is
informational,
which
would
probably
be
the
counter
argument,
but
I
I
just
struggled
with
that
particular
angle.
E
Nobody
really
has
something
they
want.
That's
not
that's!
Generic!
We
have
a
bunch
of
individual
things.
We
want
is
the
best
way
to
come
up
with
a
generic
concept
to
try
and
make
the
biggest
possible
orthogonal
change,
or
is
it
to
say
design,
kubernetes,
2.0
and
good
luck
next
time,
we've
learned
better
from
this,
like
we've
had
that
discussion.
C
Before
yeah,
I
think
the
crisp
use
cases
would
be
helpful
so,
like
the
the
things
expressed
in
the
thread
around
hierarchy
right
now,
there's
not
an
expectation
of
higher
hierarchy
on
labels,
like
even
the
built-in
objects
are
inconsistent
about.
You
know,
do
the
do
the
labels
of
the
parent
get
propagated
to
the
child?
Generally,
they
don't
so
hierarchy
is
one
and.
C
The
ability
to
have
policy
applied
objects
and
not
have
to
basically
reinvent
the
wheel
with
your
own
gatekeeper
stuff,
to
keep
the
thing.
That's
selecting
the
object,
safe.
F
A
I
was
just
gonna
say
I
want
to
suggest
at
this
point.
I
don't
think
there's
a
lot
new
coming
out
of
this
conversation.
So
let's
be
respectful
everybody's
time
and
say
that
those
people
who
are
keen
on
this
concept
put
together
some
really
crisp
use
cases,
maybe
start
a
cap,
and
we
don't
have
to
do
what
the
solution
is.
Yet
it
could
be
any
of
these.
But
let's,
let's,
let's
enumerate
the
use
cases
so
that
we
can
start
to
evaluate
the
solutions
realistically.
D
Yeah,
I
have
one
additional
thought,
which
is
the
magnitude
of
like
how
much
work
this
is
I
I
would
say
this
is
at
least
half
as
big
as
server
side
apply,
so
it's
not
really
enough.
Just
to
have
use
cases
like.
We
also
need
probably
a
team
of
dedicated
people
who
are
who
are
excited
about
making
this
happen,
which
might
be
a
high
bar
so
yeah,
that's
all.
I
got.
A
A
Okay,
okay
sounds
good
all
right,
excellent!
Thank
you
everybody!
So
why
don't
we
move
on
then
a
couple
other
things
on
the
agenda.
We
have
just
just
just
sub
project
readouts
from
api
review
and
code.org.
So
jordan.
C
Yeah,
I
linked
a
couple
notable
api
reviews
that
recently
happened.
Dual
stack
continues
to
astonishing
amaze
and
break
ground
on.
C
New
api
patterns,
so
this
the
one
I
linked
there
was
actually
fixing
an
issue.
That's
existed
for
a
long
time
where,
if
someone
submitted
a
service
and
left
some
fields
on
set,
we
would
helpfully
auto
generate
values
for
those
fields,
ports,
node,
ports
and
things
like
that,
and
then,
if
they
later
changed
the
service
type
so
that
node
ports
were
not
applicable,
we
would
fail
their
update
so
and
complain
about
a
field
that
they
never
set
being
set.
C
So
tim
took
a
step
at
doing
sort
of
a
manual
version
of
discriminated
union
auto
clearing.
So
this
is
this
first
one
was
pretty
manual,
but
it
is
setting
a
pattern,
a
precedent
that
we
probably
will
look
to
make
more
automatic
for
discriminated
unions
in
the
future.
C
C
This
is
a
way
to
indicate
in
the
go
type
of
an
api.
What
the
default
is
for
a
field-
and
this
will
bubble
into
things
like
cube
builder
and
bubble
into
the
custom
resource
schemas
that
get
generated
and
inform
the
keys
that
are
used
for
individual
items
in
a
list
when,
for
things
like
a
port
where
the
port
type
might
default
to
tcp,
and
previously
that
would
cause
issues
apply,
would
get
confused
or
things
figuring
out
duplicates
would
get
confused.
C
C
D
F
I
I'm
here
I'm
here
I
was
just
lurking
for
the
first
time.
So
a
couple
of
good
news,
one
is
the
cube.
Cto
stuff
is
mostly
out
in
staging.
F
I
think
the
cmd
cube
cto
is
still
in
the
cake
in
in
the
main
where
it
was
before,
just
because
we
need
to
figure
out
packaging
and
release
strategies
for
next.
You
know
in
121,
I
guess
so,
but
it's
buildable
without
pulling
stuff
from
the
usual
kubernetes
kubernetes
stuff
cloud
controller
manager
is
also
doing
really
well.
If
walter
wants
to
chime
in
there.
H
I
don't
think
so
button
yeah
we're
trying
to
get
to
the
point
where
we
don't
have
to
the
individual
cloud
providers,
don't
have
to
fork
the
code
and
where
it
doesn't
make
any
use
of
any
kubernetes
private
methods.
So
I'm
hoping
that
we
will
be
there
completely
in
this
coming
release
and
then
we're
going
to
try
and
unify
the
ccm
and
the
cube
controller
manager
in
the
next
release
so
that
they're,
all
the
we
don't
have
any
duplicate
code.
C
Awesome
I
just
wanted
to
call
out
walter
and
cc
have
done
a
really
good
job
thinking
about
how
people
are
going
to
consume
this,
as
well
like
the
normal
use
case
of
I
want
to
start
with
the
stock
cloud
controller
manager
and
then
like
replace
one
of
the
controller
loops
that
they,
so
they
had
prototypes
and
things
that
make
that
pretty
low
maintenance.
So
that
was
great
to
see.
F
Then
the
next
one
was
something
we
were
trying
to
do.
We
were
trying
to
upgrade
to
newer
version
of
go
open
api
and
stefan
noticed
that
it
was
changing
our
contracts
a
little
bit,
so
we
went
back
to
an
old
idea.
Jordan.
You
might
want
to
speak
to
this
about
pulling
stuff
out
from
the
go
open
api
repository.
C
C
So
it
significantly
reduced
the
amount
of
code
that
we
were
depending
on
and
I'm
I'm
very
hopeful
that
it
will
be
it'll
support
our
usage
better
in
the
future.
F
Right
so
the
main
thing
to
note
here
is
it's
a
permafrow
fork.
So,
but
if
we
see
a
problem,
we'll
go,
look
in
upstream
go
open
api
and
copy
over
the
changes,
if
needed
other
than
that
we
are
not
going
to
do
do
any
things.
That
was
the
main
implication
here.
C
And
just
just
for
reference,
there
have
really
only
been
two
changes
that
I'm
aware
of
that.
We
needed
to
update,
go
open
api
to
pick
up
and
both
of
those
were
ones
we
identified
and
drove
upstream
and
most
of
the
other
changes
we've
brought
in
have
been
ones
that
we
needed
to
either
work
around
or
prevent
from
influencing
our
api
in
ways
we
didn't
want.
F
Right
so,
after
the
reason
why
we
ended
up
trying
to
do
this,
we
kind
of
rushed
into
it
also
was
because
somebody
was
wanting
the
value
to
print
out
the
value
in
in
an
error
message
that
was
coming
out
so
that
got
patched
also
after
the
fork.
So
we
are
all
set
there.
So
the
next
one
is
something
that
spanned
six
scheduler
and
signal,
and
basically
the
idea
was
there's
a
new
api
that
related
to
node
that
needs
to
be
used
in
the
scheduler.
F
So
there
were
multiple
angles
to
this,
so
there
were
a
couple
of
caps
that
got
updated
and
there
was
discussion
on
the
sig,
node
and
sigma
sig
scheduler
mailing
list,
and
there
was
discussion
in
signord
meeting
as
well
and
we
ended
up
going
down
this
route.
F
F
There's
a
few
problems
around
this,
but
we'll
deal
with
it
in
the
pr
review.
The
main
problem
was
x,
slash
cis,
we'll
end
up
needing
an
update
to
that,
because
you
know
we
ended
up
reverting
x
dash,
says
last
week
because
we
found
another
problem,
just
compiling
the
code
in
mac
os,
so
there's
some
problem
with
our
verified
dependencies.
So
I
have
to
go
look
at
that
and
make
sure
that
we
fix
that
before
we
let
this
prn
so.
A
All
right
great
well,
thank
you,
everybody!
That's
that's
it
for
our
agenda,
so
we
can
get
back
20
minutes
and
we'll
see
y'all
in
a
couple
weeks.
I
hope
to
get
some
more
more
details
on
this
proposal.
So
thanks
so
much
bye.