►
From YouTube: 20220714 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,
everybody!
This
is
the
kubernetes
architecture.
Meeting
for
july,
14
2022.
looks
like
we
just
have
one
agenda
item
today
and
that's
on
conformance
subprojects,
so
riyan.
Why
don't
you
want
to
take
it
over.
B
B
So
I
would
like
to
propose
that
we
actually
cancel
the
meeting
and
then
just
bring
the
points,
because
if
we
look
at,
if
we
can
get
the
pr's
in
that
are
sitting
in
the
queue
we're
going
to
end
up
with
less
than
20
end
points
by
the
end
of
this
release,
so
we'll
just
kill
that
meeting
and
come
here
every
two
weeks
and
run
the
things
past
past
this
group.
If
that
would
be
okay,
usually
the
same
people
attend
this
meeting.
A
That's,
I
think,
that's
totally
reasonable.
You
know
just
be
aware
that
occasionally
we
actually
have
an
agenda
and
which
case
you
may
get
bumped
because
but
we
can
have
an
ad
hoc
meeting,
maybe
for
those
cases.
B
Good
I'd
appreciate
it
yeah
and
and
it's
everything's
are
really
running
around
smoothly
now.
So
I
think
this
this
and
it's
very,
very
little
policy
discussion
over
all
about
the
things
that
that
should
be
okay.
Okay,
then
test
review.
I've
got
one
test
in
there.
If
anybody
in
this
meeting
clayton
has
reviewed
and
asked
questions
stephen
answered,
but
we
really
need
that
in
the
next
lighting
just
moved
our
jobs,
so
he's
probably
over
his
head.
B
So
if
kind
of
somebody
can
have
a
look
at
that,
okay,
that's
obviously
I'm
gonna
prove
if,
if
we're
in
agreement,
because
we're
running
out
of
time
to
get
that
in
for
this
release,
I
think
we've
got
about
a
week
left.
A
Okay,
that's
109
763.
B
Then,
looking
at
forward
to
promotions
so
other
than
this
there's
four
tests,
that's
the
preparation
next
week
and
another
one
two
weeks
down
the
line.
If
we
can
get
this
763
also
in
the
queue
that
will
add
another
18
points
to
conformance
within
this
release,
so
good
progress
there,
and
if
we
can
get
this,
that
those
and.
C
B
Then,
from
our
last
meeting
people
that
was
in
that
meeting
to
remember,
we
discussed
the
topic
of
what
what
to
do.
We,
we
found
some
conformance
test
that
has
been
updated.
B
They
were
directly
updated
in
the
conformance
test,
no
rolling
it
back
to
an
etv.
So
we
discussed
the
possibility
of
that.
We
should
make
a
copy
of
the
conformance
test.
Do
the
changes
in
the
copy
of
the
conformance
date
as
an
e2e,
then,
when
that
proves
to
be
working,
it
would
be
a
viable
option
to
then
just
promote
that
to
conformance
and
delete
the
previous
one
and
go
incidentally,
just
after
that
meeting.
B
If
you
look
at
the
example,
pr1
1107.98
that
I've
got
there,
it's
actually,
there
was
one
endpoint
missing
from
a
life
cycle
test,
so
we,
but
we
did
exactly
the
thing
that
we
proposed
last
time,
so
we
took
the
conformance
test
made
a
copy
of
that
rolled
it
back
as
the
e
to
e
added
the
extra
endpoint
and
that
actually
got
merged
in.
So
the
plan
is
as
soon
as
we
done
with
on
the
test
grid,
which
I
think's
next
week.
B
B
So
the
question
that
we
have,
if
you
look
at
the
policy
the
policy
says
you're
only
allowed
to
not
like
to
make
any
changes
to
the
test.
There's
only
a
few
minor
things
you
can
change
the
heading,
you
can
add
the
release
and
the
details
and
the
metadata
for
the
conformance.
That's
going
to
add
that,
but
nothing
else.
If
we
strictly
apply
that
policy,
the
procedure
would
be,
then
we
promoted
the
e
to
e
test
to
conformance,
and
then
we
make
a
second
pr
to
remove
the
other
test
form
from
performance
as
a
certificate.
B
A
Yeah,
I
think
that's
fine,
I
I
I
we
don't
want
the
policies
just
to
make
extra
work
for
no
reason,
the
the
the
as
I
recall,
and
maybe
I'm
out
of-
maybe
I'm
not
recalling
correctly,
we
are
able
to
to
change
conformance
tests,
but
we
we
add
another,
there's
like
a
metadata
that
says
basically
what
version
you
know
that
we
made
a
change
in
that
in
a
particular
version,
so
that
people
kind
of
can
track
that
a
little
bit
so,
but
this
sounds
very
reasonable.
A
There's
no
reason
to
do
this
in
two
separate
pr's,
all
you're
doing
is
it's
the
same
test
you're,
just
adding
an
additional
field.
The
main
concern
is
that
we
mark
that
so
that
you
know
if
somebody
starts
failing
their
conformance
test
now
with
a
new
version.
They
know
that
there's
a
reason-
and
you
know
they
have
to
they-
have
to
fix
like
it.
It
just
helps
the
the
distributions
figure
out
what's
going
wrong
and
that
something
actually
changed
in
the
conformance
test.
Not
just
you
know
something
in
there
in
their
platform.
B
B
See
if
it's
in
the
policy
and
then
if
I
don't
see
it
there
I'll
make
a
small
update
to
the
policy.
If
you
update,
if
you
update
in
this
way,
please
add
a
versioning
saying
chinese
has
been
made
to
the
conformance
test
with,
say
the
data
yeah.
C
B
Good,
I
will
see
what
changes
would
be
needed
to
the
policy
just
practically
one
or
two
two
lines
if
and
then
with
that
promotion
come
around
so
I'll
appreciate.
If
we,
because
we're
gonna
run
a
little
tight
for
the
test
freeze
when
we
do
bring
around
the
promotions
I'll
throw
them
in
the
sig
arch
and
the
conformance
channel
just.
A
B
I'll
put
I'll,
assign
you
specifically
in
the
in
the
pr
and
I'll,
also
being
you
directly
in
slack,
I
do
realize
you
and
plato
are
extremely
busy
and
unfortunately,
those
are
the
only
people
that
can
help
me
here
yeah,
but
we're
almost
there
almost
finished.
B
Something
that
I
did
not
put
on
the
engender
is
something
that
I've
been
thinking
about,
specifically
about
life
cycle
tests,
there's
quite
a
few
resources,
specifically
in
the
apps,
where
there
is
tests
that
create
a
resource
list,
the
resource
delivery
source,
then
there's
another
one,
create
the
resource,
get
the
resource
and
delete
the
resource.
So
all
the
all
the
lifecycle
functions
is
not
taken
in
one
test.
B
Would
it
be
viable
business
to
go
on
and
basically
go
resource
by
resource
and
try
and
consolidate
all
the
tests?
So
you
have
a
single
cycle
of
creating
deleting
listing
delete
collection.
Everything
inside
of
a
single
test
make
that
the
e2e
promote
that
or,
if
successful,
promote
that
and
then
clean
out
all
the
all
the
tests.
That
is
not.
B
A
B
B
We're
doing
the
dirty
dishes
now,
but
that
would
be
the
real
that
would
be
washing
the
floor
to
go
clean
up
those.
But
if,
if
there
is
consensus
it
would
make
sense,
I
will
start
putting
something
together
too,
to
consider
that.
C
So
if
I
understand
correctly
that
we
did
something
similar
in
the
network
services
test
for
load
balancers,
where
we
realized
creating
load
balancers
was
painfully
painfully
slow,
and
so
we
coalesced
those
all
into
a
single
test
test
that
spins
up
one
load
balancer
and
then
tests
a
million
different
things
against
it.
C
C
I
don't
think
it's
flakier
or
well.
My
memory
is
terrible,
so
it
might
have
been
after
we
made
the
change
and
then
we
fixed
it
all.
But
I
I
don't
recall
that
being
a
particular
issue.
Just
that
there's
not
like
you
know,
test
that
tests.
One
thing
and
it's
very
clearly
that
test
failed.
It's
one
like
test,
load,
balancers
and
then
it
has
like
75
individual
conditions
within
it
right
right.
C
B
Would
be
much
less
complicated
because,
basically,
just
all
the
api
operations
for
a
specific
resource,
which
is,
I
think,
usually
about
seven
operations
and
sick
abs?
Actually
they
directly
asked
us
to
if
we
can
have
a
look
at
that,
because
they
have
several
resources
just
all
over
the
place.
So
I'll
start,
maybe.
A
C
A
That
that
exhausts
our
our
entire
agenda,
so
I
I'm
happy
to
let
everybody
go
with
45
minutes
back
unless
there's
some
urgent
business
anybody
wants
to
raise.
I
guess
we
can
allow
that.