►
From YouTube: 20220616 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
B
B
There
is
a
the
first
point
is
an
ineligible
endpoint,
so
the
node
endpoint
has
been
discussed
in
quite
some
detail.
Clayton.
You
previously
made
a
very
nice
comment
about
why
it
shouldn't
be
eligible,
and
then
I
took
the
issue
to
the
Sig
node
mailing
list
and
also
I
made
a
br
to
move
it
into
ineligibility
and
shared
that
also
with
signode
and
I
got
some
feedback
everybody's
good
with
that.
So
I
just
need
it
and
approve
on
that.
If
nobody
have
any
objections
and
we
can
merge
those
in
and
make
them
ineligible.
C
A
B
B
No
worry,
it
was
very
low
attendance
anyhow.
So
that's
why
I
took
the
liberty
to
bring
the
things
here
because
we're
running
out
of
time
there
is
seven
weeks
less
left
of
this
release
before
test
freeze
and
we
have
10
endpoints
that
that's
the
next
point
that
I'm
raising
10
endpoints
that
needs,
review
and
I
think
they're
good
to
go.
B
I
don't
want
to
be
the
judge
on
behalf
of
anybody,
but
I
think
they're
pretty
well
sorted.
So
if
we're
going
to
have
some
eyes
on
those
three
tests,
I
have
Austin
sick,
Arch,
I
have
of
case
conformance
Channel
I
have
director
Austin
API
Machinery,
but
many
people
has
taken
leave.
It
was
kubecon
but
I'm
just
afraid.
We're
gonna
run
out
of
time.
B
If
we
don't
get
this
in
now,
because
we
have
at
least
one
other
test
waiting
in
the
queue
that
is
gonna
cause
my
immersed
conflict,
we
don't
want
to
read
base
and
make
it
complicated.
So
we
need
these
in
and
then
I'm
going
to
bring
in
more
endpoints
with
another
test
after
this.
So
it's
kind
of
a
cue
and
I
the
happy
news
here
we
started
off
with
45
endpoints
for
this
release.
B
Once
we
get
all
the
all
that
here
merged
we're
going
to
have
21
endpoints
left
and
we
have
some
more
in
the
queue
so
we're
really
banging
it
out
to
try
and
get
to
through
Detroit,
with
the
the
news
of
100
coverage.
B
B
I
will
do
I'll
have
to
do
it.
After
all,
the
hits
yeah
and
that's
fine
I'll.
A
A
A
B
C
B
A
Okay,
so
I
made
sure
that
Clayton
is
assigned
to
these
three
I'm
gonna
close
these
three,
yes
close,
close
Okay
back
here
so
seven
weeks.
Yes,
we
got
that.
Hopefully
we
we
can
land
these
four
today,
yeah.
B
If
we
can
get
them
in
today
in
two
weeks
time
quite
an
opinion
with
the
other
one
and
then
yeah,
we'll
we'll
really
be
under
20
by
the
end
of
the
release,
which
is
super
exciting.
If
you
just
go
like
look
back
on
the
API
Snoop,
we
were
two
years
ago
when
I
started
on
this,
we
were
I,
think
40.
We
got
a
break
95
property,
this
release,
so
it's
super
exciting.
All
right,
then,
if
everybody's
good
with
those
topics.
A
B
B
A
B
A
And
so
I
will
watch
those
four
and
ping
Clayton
tomorrow,
if
all
right,
if
they
don't
allow
okay.
B
Really
appreciate
if
they
get
if
I
get
the
algae,
team
and
proof
both
me
and
Steve,
and
over
the
weekend,
will
keep
an
eye
on
them.
Make
sure
if
there's
anything.
B
Retesting
or
make
sure
they
go
in
because
we're
quite
Keen,
a
sticky
thing
that
we
have
now
is
because
of
the
size
of
the
logs
that
trimmed
down
the
taste
grid.
So
you
can't
see
the
two
week
flight
free,
but
what
we
do
do
both
me
and
Steven.
Follow
the
district
daily
then
check
for
flights.
Okay!
So
there's
a
bit
of
Integrity
thing.
When
we
come
back
and
tell
you,
it
passed,
I
hope.
D
A
Yeah
the
desk
doesn't
show,
but
we
should
be
able
to
pull
the
information
from
GCS
Market
if
necessary.
Yeah
we'll
trust
you,
but
if
necessary,
people
can
go
there
and
check
them.
Yeah.
A
A
B
Yes,
please:
okay,
the
next
one.
If
you
can
open
that
BR,
it
was
a
change
that
Stephen
was
working
on
a
test
and
he
started
running
into
issues
and
it
turned
out
some
I
mean
he
actually
stumbled
upon
this
BR
because
things
kept
on
failing
and
if
you
look
at
the
changed
files
you'll
see,
there
is
several
conformance
tests
that
has
been
updated.
B
I
can't
remember
exactly
I
have
to
open
the
link
to
to
remember
what
the
update
will
is.
They
change
permissions.
A
B
Oh
yeah,
so
the
same
security
policy
on
this,
which
is
a
needed
change,
but
my
concern
is
not
with
specifically
this
PR,
but
we
have
at
the
moment
I
policy
as
we
just
went
through.
If
you
want
the
conformance
test,
we
don't
want
it
to
be
flaky.
It
needs
to
sit
for
two
weeks
to
prove
itself
and
then
it
can
be
merged
in.
B
But
now
what
happened
here
is
they
updated
several
conformance
tests
with
a
security
level
change
which
could
be
breaking
for
some
people
if
it
gets
back
ported
which
it
would
this
wouldn't,
but
looking
at
Future
changes,
we
need
to
think
about
the
policy
around
allowing
conformance
test
to
be
to
be
updated.
So
what
I,
what
we
discussed
internally
yesterday?
What
a
possibility
is,
if
you
want
to
make
a
change,
you
need
to
copy
the
test
and
then
make
your
change
turn
it
into
an
e2e
test.
B
Again
let
that
run
in
parallel
with
the
conformance
test
for
two
weeks
and
then
once
that
pass
you
basically
delete
the
conformance
test
and
promote
the
E2
again
to
conformance
the
other
option.
Is
you
roll
back
the
conformance
test
which
I
don't
like
because
it
could
be
once
they
do
that
we
could
set?
There
were
some
orphans
that,
because
of
the
change,
there's
endpoints
that
become
untested
again,
there's
a
risk
in
there
and
I'm.
Also
looking
for
the
reason
why
this
worries
me
is
when
we
finish
this
work,
I
I
would
still
monitor
API
Snoop.
B
A
I,
like
the
first
option
for
sure
now,
the
question
is:
is
there
a
way
for
us
to
catch
that
a
conformance
test
was
updated
and
being
you
know
and
make
sure
that
we
can
get
sign
offs
on
from
the
conformance
test
data
folks?
A
C
I
mean
you
know,
there's
and
there's
other
there's
several
types
of
ways
that
it's
just
gonna
make
that
really
hard
like
someone
changes
common
utility
functions,
even
if
we
split
out
the
tests
into
their
own
files,
it's
going
to
be
a
little
problematic.
I
mean
certainly
better
monitoring
when
conformance
tests
become
flaky.
Probably
is
the
ultimate
like
we're
at
the
end
of
the
day,
the
it's
about
getting
the
flakiness
back
down
for
those
because
they
are
such
an
important
signal,
which
is
a
subset
of
a
statistic:
responsibility
on
flaky.
C
You
know
making
sure
that
flakiness
is
monitored
already.
Is
there
a
larger
thing
that
we
can
hook
into
that
isn't
specific
to
conformance
here.
B
Then
the
the
one
thing
that
I
I
fully
agree
that
the
one
signal
would
be
that
the
tastes
go
flaky,
but
my
concern
is,
it
could
be
that
you
make
a
small
change
and
the
change
drop
one
or
two
endpoints
that
was
inside
the
test,
but
because
of
the
change
now
they're
not
and
the
only
way
we
will
pick
that
up
is
by
when
API
Snoop
is
updated.
It
will
become
a
that
coverage
will
go
down
from
100
to
whatever
and
show
as
untasted.
A
Yeah,
whatever
we
can
do
on
the
API
Snoop
side,
that
is
the
best
way
to
do
it.
The
other
signal
is
definitely
you
know
the
conformance
is
going
flaky
and
that
can't
be
done
in
APS.
No,
we
allowed
to
do
it
by
monitoring
the
test
grid.
B
A
A
B
A
Yes,
please,
please
send
them
a
note
on
slack
or
on
their
mailing
list
to
watch
out
for
conformance
test
flakiness
and
tell
us
earlier
than
later.
A
Well,
they
can
log
an
issue
and
ping
us,
like
usual.
B
I
will
also
speak
to
the
people
on
our
side,
working
on
API
Snoop
and
see,
if
there's
some
sort
of
way
that
they
can
pick
up
when
there
is
conformance
test
changes
which
will
all
automatically
flag
us
to
have
a
look
and
see
if
something
goes
funny.
So
it's
kind
of
an
early
warning,
but
I
don't
think
it's
going
to
be
easy
to
pick
it
up.
A
There
we
do
have
one
way
to
do
that.
Right,
like
we
have
the
aggregated
test
results
and
we
can
say
the
test
is
conformance
right
and
then
it
is
in
the
ca
and
we
can
actually
type
in
a
job
there
too
right.
So
look
here,
for
example
right
this
is
failing
in
kind.
A
This
is
failing
in
node,
so
this
is
one
way
to
go.
Look
at
it
like
you
know
how
many
things
are
failing
and
which
jobs
they
are
failing
in.
So
if
you
have
a
list
of
jobs,
we
can
do
the
regex
here
and
you
know,
ask
the
ca
signal
folks
to
like
you
know:
oh
yeah,
let's
do
this,
so
let's
get
the
list
of
jobs
from
the
you
know,
release
blocking
and
release,
informing
and
construct
the
regex
for
this
field
and
tell
them
to
monitor
it
right.
B
A
B
Specific
yeah.
A
Give
them
a
specific
URL
that
they
can
watch
every
day
or
every
other
day.
B
A
B
A
D
Hey
I,
we
had
some
discussion
on
a
cap
that
is
being
worked
on
in
Sig
cloth
and
actually
it
feels
kind
of
silly,
because
I
sent
a
message
to
the
list
and
now
both
of
the
points
on
which
we
were
said
hey,
we
should
go
talk
to
cigarch
about
this.
Actually,
we
are
not
going
to
do
either
of
them.
Probably
so
this
is
kind
of
pointless,
but
basically
the
two
points
were
we
were
originally
going
to
so
I.
Don't
know
how
much
you
guys
know
about
the
in
cluster
certificate.
D
D
D
C
So
constraints
on
names,
there's
different
sets
of
name
constraints
and,
if
necessary,
we
could
have
a
broader
discussion
about
whether
those
are
two
restrictive.
Although
there's
a
lot
of
infrastructure
in
the
ecosystem,
now
that
probably
hobbles
us
a
bit
who
was
specifically
bringing
up
name
limitations.
C
And
that's
because
go
standard.
Library
does
not
correctly
handle
path
encoding,
which
is
the
primary
reason
why
we
just
basically
punted
it
and
there's
also
like
various
security
concerns
around
that.
So
slash
is
one
of
those
names.
That's
probably
always
going
to
stay
in
the
restricted
is
that
set
for
names,
but
that's
the
only
character
that
should
be
in
the
restricted
set
and
that
in
the
sense
that
that's
the
one
that's
fundamentally
tied
to
the
choices
go
made
early
in
a
standard
Library.
D
Yeah,
so
the
proposal
is
currently
in
the
cap
is
to
take
the
dash
as
an
escape
character,
so
the
dash
dash
means
Dash
and
dash
slap
like
the
literal
text.
S-L-A-S-H-
means
a
slash
which
is
like
super
ugly
and
fortunately,
like
I,
said
I
think
we're
actually
going
to
change
it.
So
if
a
name
can
be
arbitrary,
but
there
is
a
spec
dot,
signer
name
field
and
use
admission
to
control
to
enforce
that.
You
can
only
create
something
with
a
valid
dot:
spec
dot,
signer.
C
Name,
oh
with
a
valid
one
or
a
duplicate,
one.
C
D
Yeah
having
it
work,
kind
of
the
same
way
as
certificate
signing
requests,
they
have
a
DOT
spec.signer
name
field
and
there's
some
special
admission
control
that
goes
into
like.
C
Generally,
we
would
just
say:
there's
validation,
so
you
said
admission
for
a
second
I
thought
that
you
were
talking
about
using
that
to
enforce
uniqueness
outside
and
this
just
that
would
just
be
validation,
implemented
via
admission
control.
Okay,
yeah
I
mean
that
seems
reasonable,
yeah,
the
name
encoding
thing.
If
we
could
encode
slashes,
there
are
use
cases
for
it.
I
think
at
this
point
that
ship
has
sailed,
and
so
slash
would
be
the
one
that
would
be
special,
and
that
is
a
little
unusual
of
a
encoding
scheme.
C
I'm,
not
sure
if
anybody
else
has
ever
tried
to
do
something
like
that.
I,
don't
remember
we.
We
definitely
had
gone
through
this
with
usernames
identity
names
and
various
folks
doing
stuff
around
the
ecosystem.
Right
because
you
you
do
want
some
uniqueness
tokens
ran
into
this
as
well,
and
then
almost
every
one
of
those
cases
we
just
said
either
were
base64
encoding,
binary
data
into
the
name
like
for
tokens.
That's
been
a
something
someone's
done,
or
we
do.
We
just
don't
put
those
characters
in
and
we
work
around
it.
C
D
Yeah,
that's
that's
good
and
we
also
considered
like
well.
We
could
just
drop
this
lash,
but
then
you
can
force
collisions,
which
is
also
bad
for
this
use
case.
Yeah
and.
C
I,
if
you
know
there,
we
haven't
talked
about
this
in
quite
a
while,
but
there's
probably
a
reasonable.
C
If
we,
if
we
needed
to
do
some
sort
of
escaping
pattern,
I
would
actually
recommend
that
we
do
something
across
the
board.
Now
one
of
the
challenges
would
be
anybody
who
has
a
name.
That's
only
limits,
so
someone
could
say
could
have
a
aggregated
API
server
that
the
only
thing
that
they
don't
allow
is
a
slash.
That's
a
totally
valid
thing
you
can
do
and
clients
would
be
required
to
like
generic
clients
in
the
cube
ecosystem,
Cube
control,
various
config
tools
would
be
expected
to
work
with
that.
C
I
bet
you
they
don't
so
there's
other
wrinkles.
There
certainly
I
think
we
did
a
pretty
good
job
of
not
tying
name
to
file
system
safe
characters.
Most
people
are
using.
You
know,
the
names
of
the
file
is
similar
to
the
resource
name,
but
it
doesn't
have
to
be
identical,
but
I
would
probably
say
if
we
did
come
up.
If
you
ever
come
up
with
another
need
for
escaping,
it
would
be
a
reasonable
thing
for
us
to
be
like.
Let's
can
we
pick
something?
C
That's
reasonable
in
across
the
board,
however,
at
this
point,
our
life
cycle
that'd
be
a
very
hard
thing
to
change
effectively.
D
And
so
similar,
so
for
this
other
point,
it's
a
similar
thing.
We
actually
someone
raised
the
objection,
hey
you're,
creating
this
cluster
trust
bundle
object.
It
has
only
a
status
field,
so
it's
not
a
kubernetes
object
trademark,
TM
because
it
doesn't
have
a
spec
there's,
an
architecture
convention
stock,
I
found
that
says
that
handles
the
case
of
hey.
What?
If
your
object,
has
spec
but
no
status,
in
which
case
like
that's
fine,
you
can
even
name
the
spec
field,
something
more
useful
for
your
use
case,
but
there's
nothing
about
what.
C
If
your
object
only
has
a
status
field,
I
would
highly
recommend
putting
everything
else
in
spec
and
we
don't
definitely
because
the
intent
of
status
is
to
indicate
that
there
is
some
that
the
object
itself
doesn't
represent.
Truth
like
robindings.
Those
are
true,
you
create
them
they're.
True,
the
the
mental
idea
behind
status
would
be
that
there's
some
truth
that
takes
time
to
emerge,
or
you
know
like
because,
like
PVC
bindings,
they're
they're
one
way
pod,
some
pod
status
is
technically
One,
Way
pod
phase,
those
one-way
statuses.
C
Basically,
there
implies
are
some
delay,
and
so,
if
there's
some
delay,
then
there's
an
implication
that,
even
if
you,
even
if
the
delay
is
one
way
some
spec
might
be
updated
after
the
fact
so
I
would
probably
say
we
can
add
some.
We
can
make
a
recommendation
to
a
camera
API
conventions.
I
would
always
recommend
spec.
If
you
have
status.
D
Okay,
so
in
this
case
we
will
be
adding
a
spec
field
for
an
unrelated
reason,
because
we
want
to
put
signer
name
in
there,
but
in
this
case,
like
the
status
field
is
really
not
spec.
It's
controller
updated
state.
It
has
a
conditions
field
where
the
controller
will
report
whether
or
not
it
doesn't
that's.
C
That's
not
actually
like
so
status
doesn't
mean
spec
paired.
It
means
derived
from
reality.
That's
different
from
the
request,
if
maybe
I
misunderstanding
what
you're
saying,
but
the
implication
would
be
if
you
ever
have
a
status
block
or
things
that
act
like
status,
you
should
pair
everything.
That's
not
staticy
into
a
spec
would
be
my.
C
D
C
Asking
yeah!
So
if
you
hadn't
okay,
sorry
I
misunderstood,
if
you
don't
have
any
spec
yet,
should
you
create
an
empty
spec
field?
I
would
probably
say
just
off
the
cuff
and
I'll
I'll.
Take
this
to
a
PR
to
API
conventions.
I
would
probably
recommend
creating
an
empty
spec
field.
If
you
go
so
far
as
having
status.
I,
don't
know
that
it
matters.
C
The
one
nice
thing
would
be
that
no
one
can
create
anything,
but
there's
a
little
bit
of
the
human
nature,
which
is
eventually
some
Fields
going
to
show
up
yeah
and
the
part
of
like
putting
things
into
structs
like
from
a
convention's
perspective.
Is
that
we're
all
fallible
and
that
eventually
we
need
something
more
and
we
kind
of
have
that
advice
for
when
you
have
booleans
right,
we
say:
don't
use
booleans,
because
you
can't
really
ever
interpret
the
full
scope
of
the
field.
C
D
That
makes
sense
all
right,
I
actually
I
have
one
other
question:
if
there's
no
other
business
in
this
yeah
go
for
it,
okay,
and
maybe
that
maybe
there's
an
answer
to
this
somewhere,
but
I'm
still
pretty
new
to
like
actually
doing
open
source
work
in
kubernetes.
D
So
we're
proposing
adding
this
V1
Alpha
One
cluster
trust
bundle
object.
We
also
want
to
propose,
at
the
alpha
stage
of
the
kep,
adding
the
ability
to
reference
it
from
some
other
objects
that
are
currently
like
V1,
beta1
and
V1
by
adding
new
fields
that
could
refer
to
the
this
cluster
trust
bundle
by
name.
C
C
So
New
Field
comes
in
no
one
should
be
able
to
use
that
until
that's
promoted
to
Beta.
Therefore,
It's
featured
since
it's
featurated.
It's
likely
that
these
would
be
related
if
there's
no
other
user,
even
if
there
was
another
user
that
would
still
be
an
alpha
field.
So
it's
Alpha
field
inside
a
stable
or
V1
beta
API.
So
it's
feature-gated
or
flag
gate
feature
flag,
gated
and
then,
when
you
decide
to
promote
it
would
probably
be.
C
We
would
not
promote
that
field
until
something
that
it
references
is
not
beta
and
if
it
could
select
two
things
like
if
you
had
something
that
it
did
it
on
being
beta.
That's
not
this
Alpha
object.
That
would
be
another
case
where
you
might
say,
selecting
an
alpha
object
requires
the
gate
to
be
enabled.
C
So
if,
like
let's
say,
you
have
like
an
object
reference
and
you
support
three
resource
types,
the
resource
types
that
aren't
supported
would
still
be
behind
a
feature
gate,
while
they
are
alpha
I
think
would
be
what
we
would
probably
what
I
would
recommend
in
this
case,
which
is
if
it's
a
stable
object
and
it's
not
pointing
to
something.
That's
Theta
or
higher:
it's
always
feature-gated.
D
C
Correct
and
you
have
to
go
through
all
the
you
have
to
jump
through
all
the
Hoops
that
adding
any
feature
gate
gated
field
is,
which
is
a
little
bit
more
work
than
generally
adding
a
new
Alpha
object,
which
you
don't
need
all
those
Clauses,
because
the
appearance
of
the
object
itself.
So
it's
just
more
work
to
do
the
feature
gate
than
to
put
the
field
in
an
alpha
object.
But,
okay,
it's
less
work
than
dealing
with
people
getting
confused
about.
What's
alpha
or
not
asking
for
support
and
getting
broken
when
we
change
the
future.
A
So
you're
on
block
now
you
can
summarize
the
discussion.
I,
I,
I
I,
didn't
follow
everything,
so
you
would
like
to
do
it.
D
Yeah
I
think
the
main
thing
is
yes:
if
there
is
a
need
in
the
future,
we
can
come
settle
on
a
sort
of
name
encoding
scheme.
We
don't
need
this
right
now,
so
I'm
not
gonna,
bother
pushing
that
and
then
we
should
probably
have
an
empty
spec
field
if
our
object,
even
if
our
object
is
currently
only
status
e.
C
H,
it's
probably
there
are
probably
fewer
things
that
will
break
having
an
empty
status
that
you
probably
would
want
to
work.
In
a
sense,
it
also
gives
you
a
place
to
put
documentation
that
says:
there's
no
field,
but
we
might
anticipate
controlling
how
this
is
used
in
the
future.
C
Otherwise,
you'd
have
to
stick
that
at
a
higher
place
on
the
object,
which
gets
weird,
not
that
our
documentation
on
API
types
is
really
great.
Today,.
A
Okay-
and
there
is
one
action
item
for
Clayton-
to
file
a
PR
against-
you
know
the
convention
stock
to.
A
Okay
sounds
good
to
me
is:
is
there
anybody
else
wanting
to
talk
about
anything
else?
Brian,
mayank
Ben,
oh
no,
I'm,
good
I'm,
just
trying
to
attend
as
as
many
times
as
possible
and
follow
what's
going
on,
sounds
good
Mike.
Thank
you.
Thank.