►
From YouTube: 20200716 SIG Arch 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
Hello,
everybody:
this
is
the
kubernetes
league
architecture,
meeting
for
july,
16th,
2020
and
just
reminding
everybody
of
our
code
of
conduct.
Please
treat
each
other
with
respect
and
assume
good
intent.
So
with
that,
I
think
we
have
a
short
agenda.
I
did
not.
A
Rope
anybody
in
for
some
project
updates
this
week,
so
unless
somebody's
on
there,
that
wants
to
just
give.
B
D
C
D
Okay,
so
conformance
profiles.
To
recap
ever
so
slightly
conformance
tests
are
what
we
use
to
validate
that
kubernetes
is
a
kubernetes.
Today,
conformance
tests
are
written
against
a
set
of
functionality
that
is
expected
to
be
non-optional
ga
standard
possible
across
all
kubernetes
clusters
everywhere.
D
There
has
always
been
discussion
about
moving
beyond
that,
though,
the
desire
to
validate
functionality,
that
is
optional.
That
may
not
necessarily
work
across
all
clusters,
but
that
would
still
help
users
validate
that
their
workload
will
work
as
expected,
regardless
of
which
kubernetes
offering
they
use
so
long
as
it
passes
a
given
set
of
conformance
profiles.
D
Informants
profiles
have
always
been
talked
about
in
the
discussion
of
not
too
many
of
them
and
they've
also
been
talked
about
in
the
context
of
let's
make
them
additive
only
if
at
all
possible,
please
so
that
it's
really
obvious
and
intuitive
that
there's
a
base
level
of
functionality,
that's
always
guaranteed,
and
then
there
is
not
that
much
additive
stuff
to
avoid
user
fragmentation,
so
on
and
so
forth
that
you
could
think
of
some
example
profiles
as
being
like
storage,
for
example,
persistent
storage
isn't
necessarily
available
out
of
the
box
and
you
might
not
want
persistent
storage
on
some
kubernetes
offerings
that
are
intended
to
be
like,
embedded
or
lightweight
or
edge
focused
things
of
that
nature.
D
You
could
also
I'm
just
making
these
up.
I'm
not
saying
these
are
representative
of
what
a
profile
could
be.
You
could
also
say
there
might
be
a
profile
for
like
machine
learning
or
something
where
there's
a
certain
set
of
hardware.
That's
not
going
to
be
available
by
default
everywhere,
but
if
we
were
to
have
that
hardware,
it
would
be
really
great
to
ensure
that
kubernetes
exposes
that
in
the
appropriate
way.
A
I
just
will
make
a
comment
or
two:
if
you
don't
mind,
aaron
one
is
that
for
this
group
to
understand
the
conformance
actually
is
split
into
two
things:
there's
what
sig
architecture
controls,
which
is
sort
of
the
specific
process
and
tests
that
signify
what
kubernetes
is,
but
the
cncf
runs
a
separate
program
to
actually
validate
given
vendors
distributions
or
managed
offerings,
and
so
this,
what
we
do
here
is
sort
of
within
the
scope
of
defining
how
profiles
are
done,
but
there's
another
aspect
of
getting
profiles
supported,
which
is
getting
the
cncf
to
revise
their
program.
A
Now
this,
I
think,
like
two
years
ago,
was
already
discussed
with
them
and
there
was
an
agreement
made
to
that.
This
was
a
feasible
thing,
but
just
want
to
be
sure
people
understand
the
difference
between
the
responsibilities
of
the
two
groups.
The
second
comment
is
that-
and
maybe
maybe
this
goes
to
screening
ross's
second
bullet
point
in
the
agenda
and
maybe
we'll
talk
about
it
then,
but
we
do
have
to
sort
of
figure
out
how
we
want
to
define
profiles.
A
If
we
do
it
by
specific
feature,
we're
going
to
end
up
with
too
many
profiles,
potentially
because
there's
so
many
different
sets
of
features,
so
we
want
to
figure
out
how
to
aggregate
those
into
a
smaller
number
of
profiles
that
customers
can
understand,
and
you
know
those
could
be
based
on
customer
use
cases
like
say,
stateless
stateful
things
like
that
or
could
be.
A
Other
suggestions
have
been
you
know.
Oh
there
should
be
a
cloud
provider
profile
for
that
sort
of
has
a
whole
lot
of
functionality,
the
cloud
providers
and
an
edge
profile,
which
is
also
a
kind
of
customer
use
case.
But
it's
more
about
the
deployment
architecture
than
the
types
of
workloads
you
run.
A
So
none
of
this
is
clear
yet,
but
I
just
want
in
people's
heads
and
if
people
have
suggestions,
love
to
hear
them,
and
then
I
think
what
aaron's
going
to
talk
about
more
is
the
mechanisms
which
we
use
to
identify
tests
as
part
of
profiles.
So
that's
all.
E
F
John,
this
is
derek.
It's
okay.
Can
I
ask
you
a
question?
I
my
parsing
of
your
statement
was
that
the
cncf
would
be
the
one
defining
the
profile
set.
A
A
Distribution
needs
this
profile,
but
really
we
provide
all
the
the
tooling
and
then
the
sono
body
team
is
the
ones
who've
traditionally
kind
of
built,
the
the
tooling
that
is
used
by
the
vendors.
So
I
may
have
caught
more
confusion
than
clarification
with
my
statement.
I
apologize.
F
G
And
there's
a
I
know,
we
talked
about
this
early
on
and
I
hadn't
seen
it
was
like
there's
the
thing
of.
If
we
do,
the
profiles
does
anyone
care
and
is
there
an
incentive
for
people
to
actually
bother
with
that,
and
so
we
should
think
at
least
about
those
elements
of
it
at
a
at
the
meta
level,
above
where
we're
doing
here
like
coming
up
with
the
profiles,
is
great.
G
If
nobody
cares
about
the
profiles,
they're
just
getting
their
cncf
trademark
badge
and
they're
done,
you
know
we
should
ask
ourselves
like
how
do
we
loop
that?
How
do
we
loop
that
back
into
our
process.
D
Thank
you.
I
appreciate
that,
so
I
just
again
want
to
walk
through
the
logistics
of
how
the
project
controls
the
definition
of
conformance
today.
So
we
have
because
we
use
a
framework
called
ginkgo
to
define
our
end-to-end
tests.
The
only
way
we
can
currently
select,
which
tests
to
run
or
not
run,
is
by
use
of
a
regular
expression
applied
against
the
test
name.
The
system
we've
evolved
within
the
project
is
to
use
tags.
D
The
way
that
we
ensure
that
the
appropriate
set
of
people
decide
what
is
or
is
not
a
conformance
test
is
we
have
a
tool
that
sort
of
scrapes
all
the
test
names
looking
for
those
that
have
the
word
conformance
in
them
and
compare
them,
compares
that
list
against
a
known
defined
list.
That's
checked
into
the
kubernetes
repo,
and
so,
if
they
match
a
specific
set
of
people
have
to
approve
that
up
yeah.
D
I
think
I
think
that
covers
that,
so
the
requirements
for
to
defining
profiles
are,
we
need
to
be
able
to
specify
which
test
belongs
to
which
profiles
in
case
it's
one
to
n
mapping
or
one-to-one
mapping,
we
should
be
able
to
restrict
which
tests
are
added
or
added
to
a
given
profile
in
the
same
way
that
we
can
restrict,
which
tests
are
added
to
conformance
and
we
need
to.
Since
sonaboy
is
the
tool
that
is
used
by
the
cncf,
primarily
for
end-to-end,
test
execution
and
verification.
D
D
The
reason
so
the
example
I'm
going
to
give
here
is
there's
an
x
there's
a
sense
that
the
set
of
tests
that
currently
we
call
conformance
may
actually
be
may
actually
require
like
more
privileges
and
more
abilities
than
we
actually
expect
to
be
available
across
all
clusters.
And
so
we
may
want
to
be
able
to
retroactively
say
that
what
is
currently
the
conformance
test
may
event
may
actually
look
more
like
a
base
profile
and
then
like
a
privileged
profile
or
a
cluster
admin
profile
or
other
stuff.
D
On
top
of
that,
and
it
would
be
nice
to
say
that
people
who
passed
the
conformance
tests
against
an
already
released
version
of
kubernetes
would
have
the
ability
to
say
actually,
I
passed
the
base
profile
and
these
additional
profiles,
because
that's
what
the
project
has
defined
retroactively.
D
To
assist
with
this
ability
to
define
things
retroactively,
it
would
be
really
great
to
define
these
sort
of
hard-coded
lists
or
whatever
that
we're
looking
against
out
of
the
kubernetes
tree.
This
is
so
we're
not
necessarily
tied
to
the
life
cycle
of
kubernetes
and
we're
not
necessarily
tied
to
the
pain
that
comes
to
contributing
to
the
main
kubernetes
tree
at
times,
and
it
would
also
be
nice
to
say
that
I
only
want
to
run
a
given
set
of
tests
for
this
profile
or
this
other
profile.
D
We
continue
to
use
like
the
conformance
tag
and
we
add
more
tags
for
each
profile,
so
we
add
a
profile,
foo
tag
for
each
profile
and
then
to
run
tests.
You
can
still
focus
on
the
conformance
or
you
could
focus
on
a
specific
profile.
D
We
would
continue
to
gate
changes
the
exact
same
way
they
would
all
land
in
a
file
inside
of
kubernetes
kubernetes.
The
only
way
we
would
be
able
to
retroactively
define
profiles
is
if
we
cherry
pick
these
changes
back.
So
it
could
be
cherry
picking,
test
changes
back
and
cherry
picking
data
changes
back.
D
This
would
interact
with
sonobuoy
by
requiring
the
it's
not
much
of
a
change
for
sonobuoy.
You
just
update
the
e2e
focus
environment
variable
that
sonical
uses.
So
the
pro
is
this
is
the
most
straightforward
approach.
It
follows
from
what
we
do
the
con
is
it's
going
to
end
up
changing
a
lot
of
things
as
we
change
sort
of
the
metadata
about
the
test
like
which
test
belongs,
to
which
profile?
It's
also
going
to
make
our
test
names
even
more
illegible.
D
I
don't
know
how
many
people
here
really
depend
upon
having
all
those
tags
live
inside
of
the
test
name,
so
one
thought
we
could
do
to
mitigate
the
pain
there
is
if
we
use
the
custom
ginkgo
reporter
to
strip
away
all
that
extra
noise,
and
so
you
see
just
sort
of
the
straightforward
test
names
test
grid
in
you
know,
reports
that
say
what
it
is,
but
we
could
still
use
the
tags
to
select
and
focus
against
end-to-end
tests.
D
So
this
is
the
approach
that
most
closely
models
today,
I
don't.
I
don't
love
it,
but
I
also
don't
hate
it
just
because
it's
what
we
have
today
the
option.
I
feel
that
that
hits
most
of
the
the
nice
to
have
requirements
is
to
currently
conformance
tests,
parse
a
bunch
of
their
information
out
of
comments
above
the
the
line
of
code
that
says
conformance
it,
and
so
we
would
add
another
piece
of
information
to
that
comment
called
profile.
D
We
would
parse
out
of
that
and
then
we
would
not
actually
add
any
additional
tags
or
anything
to
the
test
names.
So
users
would
continue
to
run
all
the
tests
that
have
the
tag
conformance
in
them,
but
they
may
end
up
potentially
running
tests
for
a
ton
of
profiles
that
they
don't
actually
intend
to
pass.
D
D
We
would
define
this
as
a
new
tool
that
the
kubernetes
project
provides
that
would
be
written
in
a
repo
out
of
tree
and
in
that
repo
would
also
be
the
lists
of
all
of
the
profiles.
So
in
this
way
we
could
define
the
profiles
independent
of
the
life
cycle
of
kubernetes
changes
would
be
gated
for
review
in
the
same
way,
like
conformance
tests
would
still
have
to
go
through
the
existing
review
process
but
which,
which
profiles
are
allowed
would
be
gated
by
a
separate
review
process
in
the
external
repo.
B
Far
hi,
so
let
let
me
start
with
the
first
one,
which
is
sona
boy
right.
I,
you
know
suno
boy
kind
of
ended
up
in
my
larger
team.
So
if
things
need
to
be
done
in
sono
boy,
please
don't
hesitate
to
have
that
as
a
blocker
for
the
work
that
we
are
trying
to
do
here.
So
that's
one,
the
other
one
is
the
the
idea
with
the
tags
right
do
do
the
do.
B
We
have
to
do
profile,
colon
base
or
whatever
in
the
tags
itself
or
can
we
just
say
here
is
the
regex
that
you
use
for
a
specific
profile
right
and
then
we
are
free
to
use
whatever
tags
we
want
in
the
code
itself.
But
then
all
we
are
publishing
is
here
is
the
regex
for
this
profile
so
that
that
is
one
way
to
skin
the
cat
as
well,
so
you're
not
actually
specifying
the
profile.
Colon
foo
tag
in
the
conformance.
B
All
you're
saying
is
like
you
when
you're
running
here
is
the
regex
that
you
need
to
use.
That
is
one
way
of
that
is
that
could
be
something
useful
for
previous
releases.
So
that's
one
way
of
looking
at
it.
The
other
one
was.
A
B
Yeah,
that's
that's
the
con
right
that
it's
likely
to
be
very
long,
and
you
know
it
could
have
like
a
whole
bunch
of
things
that
you
know
and
it
will
be
hard
to
update
and
we
can't
guarantee
that
the
text,
the
test
that
we
wanted
actually
ran
right.
So
that's
probably
why
we
need
to
lean
towards
the
yaml
one
for
sure,
then
the
other
one
was
e
to
e
test.
Currently,
we
do
add
the
conformancy
amol
into
the
e
to
e.test.
B
So
if
we
need
to
make
changes
to
like
for
multiple
yaml
files
to
be
in
there
and
then
have
a
base
and
a
four
and
a
bar,
we
can
definitely
do
that
that
that
that
should
be
trivial
at
this
point
to
add
more
yamls.
So
that
gives
us
a
way
to
e2e
tests
can
spit
out
yaml.
That
is
that
we
embed
as
well.
So
people
have
a
way
to
check
okay.
This
is
the
e2e.test
print
me
the
base
a
list
of
tests.
B
It
can
do
that
today
it
just
prints
whatever
is
in
conformance.tml,
but
then
we
can
add
a
parameter
there
saying:
okay,
if
you
don't
send
any
parameter,
we
can.
We
can
play
around
with
the
command
line
options.
So
not
a
problem
so
and
the
other
one
is
I'm
like
it's
a
toss-up
between
having
a
separate
repository
versus
entry.
B
The
entry
seems
to
be
useful
going
forward
and
I'm
like
not
too
sure
do
we
really
really
need
to
go
back
and
fix.
You
know
all
the
you
know
not
fix.
Rather
do
we
need
to
what
is
the
specific
need
for
defining
profiles
for
things
that
have
already
shipped?
B
A
You're
in
well
I'll
say
something:
aaron
might
have
a
different
opinion.
I
think
that
you
know
there
may
be
no
need
for
that,
but
what
we
were
thinking
about
was
like
there
may
be
existing
distributions
that
say,
constrain
certain
apis
or
like
cluster
administrator
or
privileged
pods,
or
things
like
that.
That
currently
aren't
considered
conformative.
Because
of
that,
and
if,
if
we
separate
out
those
things,
maybe
those
become
conformant
on
a
base
profile,
just
not
on
a
cluster
administrator
profile
that
sort
of
thing
but
get
granted.
B
Yeah,
I
would
rather
focus
on
going
forward
and
and
do
the
right
thing
going
forward,
rather
than
worry
about
too
much
about
like
retrofitting
existing
stuff.
That's
my
two
cents
there.
B
I
I
don't
want
to
suddenly
start
people
starting
to
claim
that
oh,
I
wasn't
performed
before
conformant
before,
but
I
am
confirmed
now
that
kind
of
like
sends
mixed
messages.
I
think.
A
B
Yeah,
so,
given
all
that,
then
the
only
toss
up
I
have
is
between
having
the
yaml
files
in
the
same
repository
versus
another
repository,
and
then
the
flip
side
of
also
also
is
like.
Does
the
release
team
play
into
it?
Do
they
need
to
do?
Can
you
put
it
in
their
repository
instead
of
having
one
more
repository,
so
that
that
was.
A
Alright,
I
think,
there's
two
there's
two
general
just
to
recap:
there's
two
general
things:
one
is
just
added
in
the
tags:
you're
editing
the
text,
there's
no
new
yaml
files
or
anything
right,
there's
just
existing
conformance.yaml,
and
that's
that
the
other
one
is
added
in
the
test
metadata
and
and
rather
than
doing
test
selection,
we
do
a
post-processing
even
there.
There
doesn't
need
to
be
any
new
additional
yaml
files,
because
it's
in
the
test
metadata
already,
it
would
just
be
copied
to
the
same
conformance.yaml
we
post.
A
C
D
And
I
think
yeah,
your
your
specific
concerns
are
why
I
wanted
to
make
sure
I
asked
the
broader
audience
here,
because
I
don't
feel
like
I've
gotten
sufficient
feedback,
yet
in
just
the
conformance
definition,
where
I'm
of
the
opinion
where
it
it
would
be
nice
to
say,
if
we're
going
to
roll
out
profiles
as
a
concept
that
you
get
them
today,
rather
than
you're
going
to
have
to
wait
until
a
later
release
to
start
segmenting
pro
flask,
because
it
could
be
that
we
sort
of
we're
going
to
be
changing
the
definition
of
what
conformance
means
today.
D
When
you
get
these
additional
profiles
where
you
didn't
have
that
with
earlier
versions,
I
could
see
it
causing
confusion
where
it's
like.
Well,
I'm
I'm
conformant
on
like
kubernetes
117,
but
like
what's
this,
what
are
all
these
other
profiles
like?
Can
I
can
I
say
that
I
have
that,
or
am
I
gonna
have
to
wait
until
I
get
to
120
to
have
that.
D
I
guess
I
don't
hear
a
lot
of
people
vocally
pushing
for
that.
G
Right
yeah,
I
feel
like
my
worry,
is
we
want
to
grow
test
coverage
profiles
are
the
way
we'll
do
it
we'll
do
it,
and
then
nobody
will
care
about
anything
other
than
the
base
profile
and
then
we'll
have
a
bunch
of
confusion
that
takes
time
away
from.
It
is
the
general
goal
of
growing
coverage
under
the
conformance
program
worthwhile.
G
Yes,
every
new
profile
comes
with
some
additional
overhead
in
all
of
the
outward
stuff,
because
it
is
a
new
thing
it's
like
well,
I
was
today
you're
conforming
or
not,
and
you
use
that
to
get
trademark
or
not
and
that's
it
like.
I
don't
know
that
the
the
theory
of
conformance
is,
we
all
get
a
warm
fuzzy
on
the
trademark.
If
you
satisfy
this
the
moment
we
have
more
than
one
things,
get
confused
or
complex,
not
confusing,
and
we'll
need
to
manage
that
complexity
with
consumers.
I
don't
mean,
I
don't
think
it's.
G
A
Yeah
I
mean,
I
guess,
question
is
like
there's
the
trademark
piece
and
that's
the
primary
purpose
it
serves
today
and
then
the
there's
another
question
of
like
from
an
actual
functional
user
point
of
view.
Like
okay,
can
I
can
I
move
this
workload
from
this
kubernetes
distro
to
this
other
kubernetes
distro
and
you
know,
or
can
I
run
this
workload
on
this
edge
distribution
when
I've
been
running
it
in
the
cloud?
A
That's
that's
a
much
more,
like
that's
a
longer
term
thing
that
I'm
not
hearing
huge
demand
for,
but
so
I
mean
we
are
focused
on
like
okay.
Let's
make
sure
that
storage
works
the
same
way
across
different
vendors
and
that's
the
target
right
now.
B
So
far,
the
stuff
that
I've
definitely
heard
there
are
people
who
don't
want
to
switch
on
privileged
mode
by
default
right
in
the
default
cluster
thing
and
then,
but
we
insist
that
you
know
it
needs
to
be
in
the
default
needs
to
be
privileged.
Only
then
you
can
pass
the
conformance
right.
So
that
is
one
limitation
we
already
have
so
so
secure
by
default
is
definitely
something
that
people
struggle
with
you
know
some
of
the
vendors
want
to
be
more
secure
than
what
the
conformance
currently
provides
right.
B
B
So
that's
definitely
one
way,
one
feedback
that
we've
heard
so
many
times
already
other
than
that
I
haven't
really
heard
clamoring
for,
like
okay,
I've
heard
clamoring
for
like
specific
test
suites
for
like
csi
or
cni,
or
things
like
that,
but
not
with
the
conformance
test
that
we
already
have.
E
E
How
many
of
the
profiles
do
you
put
together
and
you
call
that
the
cloud
provider
one
and
hey
who's
on
my
team
right
and
you
know,
and
then
you
know,
does
it
break
up
into
there's
basically
two
equivalent
classes
cloud,
a
pro
cloud
provider,
a
non-cloud
provider?
And
I
think
what
always
happens-
and
I
think
this
is
happening
to
aaron-
is
you
know,
aaron's
trying
to
figure
out
what
really
what's
the
best
way?
E
So
I
can
create
these
little
profiles
so
that
we
can
make
progress
from
a
testing
point
of
view
and
say
we
got
a
suite
of
tests
for
storage.
We've
got
a
suite
of
tests
for
cr
whatever,
and,
and
so
I
think
we
want
to
be
a
little
bit
careful
to
give
him
some
some
freedom
here
that
if
he,
if
he
can
get
some
advice
on
the
right
way
to
do
it,
then
we
can
go
all,
have
the
the
really
fun
and
useful
conversation
which
is
hey.
How
do
we
get
all
these
folks
to
agree
on?
B
Understood
brad
aaron
asked
the
specific
question,
which
was
what
we
were
trying
to
answer
like
who
here
is
interested
in
what
so
that
was
the
feedback
for
that.
D
I
do
appreciate,
like
I
do,
think
it's
healthy
to
explore.
Some
of
these
things,
for
me
to
help
understand
is
the
is
my
nice
to
have
of
being
able
to
retro
effect
retroactively
like
carve
things
up
and
define
these
too
much
complexity,
or
is
it
warranted
given
like
the
secure
by
default
profile
scenario,
I
saw
derek
had
his
hand
up
and
just.
F
Thanks
aaron,
I
was
trying
to
correct
my
past
interruption,
so
I
I
want
to
make
sure
I
answered
your
original
question,
though,
which
was
the
feedback
you
were
prompting
for
which
was
my
understanding
was
if
kubernetes
defines
a
new
profile.
F
Why
and
is
the
definition
of
profile
inherently
tied
to
the
release
that
that
profile
was
first
defined
in,
and
so
I
thought
your
question
was:
if
profile
y
is
declared
in
releasex,
must
I
be
running
release
x
in
order
to
claim
conformance
on
profile
y,
and
I
thought
my
first
reaction
was.
That
was
very
reasonable
and
I
want
to
make
sure.
D
F
A
A
Oh,
I'm
now
conforming
because
I'm
conforming
to
the
base
profile,
because
before
I
I
didn't,
allow
certain
privileged
operations,
but
that's
why
I
couldn't
be
considered
conformant.
That
would
be
the
only
and
that
fixes
itself
right.
So
it
would
be
that
that
that
initial
decomposition
of
the
current
conformance
suite
would
be
the
only
time
this
would
be
relevant.
I
would
think.
D
And
so
derek's
question
is:
wouldn't
it
require
cherry
picks
prior
to
previous
releases
to
do
this,
and
that's
why
I
was
proposing
there's
a
there's,
an
option
where
the
answer
is
no.
If
we
define
the
lists
completely
out
of
tree,
so
we
would
still
like
block
the
lists
to
version,
but
we
wouldn't,
like
cherry
pick
anything
around
in
kubernetes,
kubernetes.
B
Yeah
and
and
my
response
to
that
was
like-
let's
not
design
for
that
case,
but
let's
design
for
now
for
going
forward
which
will
make
it
easier
on
ours
right
now,
because
you
know
this
profile
thing
we
are
just
starting
to
explore.
B
D
Your
hand
is
still
up.
I
don't
know
if
you
have
more
to
say:
oh
apologies,
aaron.
I
will
take
my
hand
down.
That's
all
good,
just
one
one
concrete
example
I'll
give
of
a
retroactive
adjustment
of
conformance.
So
we
were
approached
by
michelle
from
sig
storage
about
it
turns
out.
The
conformance
tests
were
exercising
a
piece
of
storage
functionality.
That
was
actually
a
bug
like
the
conformance
tests
were
verifying.
D
Something
was
happening
that
shouldn't
be
allowed
to
happen,
and
so
we
proposed
the
idea
of
we're
going
to
remove
those
conformance
tests
that
are
that
are
verifying.
This
bug
can
happen
from
earlier
releases
of
kubernetes,
so
this
is
cherry.
Picking
back
is
changing
the
definition
of
conformance
for
earlier
releases
of
kubernetes,
but
it's
lowering
the
bar.
It's
not
raising
the
bar
for
anything
and
then
it's
up
to
us
going
forward
whether
we
want
to
write
negative
tests
that
verify
that
that
bug
can
no
longer
happen
so,
like.
G
I
mean
if
it's
a
bug
and
it's
broken,
and
it's
important
enough
and
it's
in
conformance
either
that
condition
doesn't
belong
in
conformance
or
it's
just
something
that
like
I,
I
do
think
that
if
people
are
running
conformance
off
of
like
tagged
versions,
there's
like
a
bunch
of
stuff
is
like
the
conformance
definition
will
never
be
complete,
and
so
the
reason
I
so
it's
weird
because,
like
from
a
test
perspective,
of
course,
we
try
to
pick
those
fixes
to
verify
the
bug
is
fixed
conformance
to
get
a
trademark.
G
No
one
is
going
back
and
re-running
their
conformance
tests
to
re-get
trademarks
on
116,
because
the
process
doesn't
require
it
and
so
for
the
primary
consumer
of
conformance
today,
which
is
getting
a
trademark.
No
one
cares
once
they
have
it.
They
ignore
that
branch
forever.
The
cncf
doesn't
require
re-running
people
should,
but,
like
I
mean
so,
I
think.
A
It
could
only
come
up
if
somebody
tried
to
replicate
it,
but
then
I
think
it
would
be
clear
to
just
say:
hey
yeah,
that
that
test
shouldn't
still
be
in
there
right
you're.
You
should
yeah
it.
G
B
And
the
other
thing
is
like
then:
we'll
people
will
there
will
be
people
who
will
want
to
okay,
I'm
going
to
try
the
new
grey-based
profile
that
you
have
defined
and
then
it's
the
question
of
okay,
which
version
of
sono
boy
did
you
use,
which
version
of
e2e
conformance
container
image?
Did
you
use
and
then
what
did
you
use
to
pass
the
list
of
tests?
It's
it's
gonna
be
a
nightmare
for
people.
So
I'll
put
my
hat.
G
On
right
now
and
like
that's,
a
problem
too
of
like
there
is
what's
in
kubernetes,
kubernetes
sono
buoy
is
not
part
of
that,
and
this
is
a
challenge
like
we're
fine
with
that
today,
and
you
don't
have
to
run
it
that
way
like
we
don't
enforce
it,
it's
a
convenient
way
to
do
it.
I
feel
like
the
sono
buoy
project.
You
know
that's
something
they
could
communicate
and
add
value
that
way,
and
that
is
a
benefit
to
the
ecosystem
to
have
like.
That
is
a
place
where
sanobui
not
being
part
of
kk,
actually.
D
B
Okay,
so
we
have
to
retrofit
the
tool
to
say:
okay,
even
though
you're
running
against
1.6,
you
need
to
get
the
e2e
test
from
1.9
and
then
you
have
to
use
the
pull
the
yamaha.
G
If
your
tests
are
broken
and
we
backport
a
fix
that
would
break
the
tests,
we
should
also
backport
the
fix.
The
head
of
a
branch
is
truth,
like
cube
source
is
truth
for
conformance,
and
so,
if
we
backport
a
fix,
we
backport
the
test,
fix
and
head
of
the
branches.
Truth
and
tools
need
to
you
know.
Truth
is
true,
there's
a
source
code,
and
then
we
want
the
the
projects
and
processes
around
it
to
be.
G
D
Okay,
so
to
recap
what
I
have
heard
it
sounds
like
we
don't
we
want
to
keep
it
in
tree
and
we
don't
want
to
allow
retroactively
defining
things,
and
we
are
indifferent,
whether
we
do
that
with
more
tags
or
whether
we
try
to
be
clever
with
our
use
of
yaml
files.
The
the
only
other
comment
I'll
make
on
the
yaml
file
thing
is
like
I
I'm
so
thankful
you,
you
added
that
dims
it.
D
It
is
like
yet
another
addition
to
our
rube
goldberg
machine
that
is
defining
all
this
stuff.
It's
only
landed
in
118,
so
it
can't
be
used
retroactively
for
versions
of
116,
117
and
part
of
my
proposal
here
was
to
offer
a
tool
or
a
service
that
allows
the
cncf
to
benefit
from
defining
that
using
something
like
that.
D
Yaml
file
retroactively
because
I
think
today,
the
way
they
verify
conformance
to
validate
verified
performance
test
runs
is
like
they
look
at
the
number
of
tests
that
say
past
they
don't
actually
verify
the
names
of
the
tests
that
the
set
of
tests
that
ran
is
the
expected
set
of
tests,
and
so
I
think,
it'd
be
really
helpful
to
help
them
validate
that
by
embedding
that
ammo
file
in
118.
We
can
do
that
going
forward.
I
think
it
would
be
useful
to
figure
out
how
to
do
that
for
previous
releases
of
kubernetes
as
well.
A
D
Attack
just
tags
is:
what
is
the
feedback
I've
gotten
in
shopping
this
around
so
far,
I
feel
like
it's
gonna
cause
more
pain
on
the
release
team,
but
I
will
help
work
through
that
with
them.
H
B
H
H
Right,
I
understand
yeah.
That
means
the
conformance
it
block
is
going
to
contain
the
information.
Rather
than
that
I
would
say
profile
it
profile,
one
hit
or
profile
to
it,
that
kind
of
stuff.
So
we
keep
wrapping
for
the
number
of
profiles
we
have,
so
we
just
can
run
those
blocks
rather
than
have
to
deal
with
the
regex
or
something
like
that.
B
Yeah
so
the
way
I'm
thinking
of
it
srinivas
srinivasa's,
just
conformance
it
will
take
a
list
of
profile
names
and
it
could
be
empty,
which
is
the
base
profile.
You
know
something
like.
D
That
a
it's
a
definitely
a
possible
approach.
I
didn't
want
to
constrain
folks
who
are
interested
in
defining
what
the
profiles
are
to
saying.
One
test
can
only
belong
to
one
profile.
It
could
be
that
you
find
you
want
the
ability
to
define
one
task
going
into
different
profiles
if
they're
more
like
use
case,
focus
profiles
as
opposed
to
capability
specific
profiles
that
make
sense.
D
A
A
Exactly
an
actual
decision,
so
it
sounds
like
brad
had
to
drop
off
screenie.
Do
you
want
to
go
on
to
your
bullet
point?
Do
you
want
to
wait
next
time.
H
Yeah,
I
I'm
basically
yep
you're
right,
I
mean
brad
has
some
ideas
around
this,
and
probably
we
should
wait
for
the
next
week.
That
would
make
sense,
but
general
idea
is
this
and
aaron
linked
another
kept
there.
So
we're
looking
at
figuring
out
what
the
process
on
how
we,
from
the
technical
point
of
view,
define
these
profiles
or
so
that
you
know
there
is
some
kind
of
convergence
among
various
cloud
providers.
So
definitely
we
can
take
it
out
next
week.
If
that
is
possible.
Next.
A
A
A
I
think
that
was
the
last
thing
on
our
agenda
is
as
anybody
who
wants
to
give
an
update
on
any
of
the
sub
projects
before
we
drop
off,
because
we
have
12
minutes
left,
if
not
still,
watching
happy
to
drop
happy
day
and
early.
A
Okay,
well,
thank
you
very
much
everybody
and
it's
almost
the
weekend
so
enjoy
your
weekend.
We'll
see
you
in
a
couple
weeks.