►
From YouTube: CNCF Kubernetes Conformance WG Meeting - 2019-01-23
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
No
Zoom
Zoom
gets
really
confused
and
thinks
I'm
either
Aaron
of
state
testing
and
a
cig
beard,
DIMMs
sig,
release
or
occasionally
say,
contributor
experience,
depending
on
which
meeting
I'm
currently
signing
into
which
meeting
I've
signed
into
recently.
It's
it's
nuts
and
are
you
dialing
in
versus.
B
B
B
A
Actually
put
the
agenda
item
in
because
I'm
sorry
y'all,
like
I've,
been
talking
a
lot
but
I
kind
of
forget
what
we
actually
really
well
and
truly
decided
so
just
scanning
through
the
notes.
I
feel
like
we
agreed
that
conformance
is
non-blocking
for
getting
windows
to
GA
I
feel
like
there
was
a
lot
of
nodding
of
heads
that
we
want
conformance
profiles
to
be
additive
only.
But
it's
unclear
to
me
whether
we
actually
got
into
the
finicky
details
of
how
we're
going
to
implement
that
back
to
Windows.
A
B
C
So
one
of
the
things
we
looked
at
was
calling
certain
things:
validation,
Suites
I,
believe
because
then
we
would
remove
the
confusion
of
for
now
at
least
we've
got
the
conformance
set,
but
this
allowed
everybody
who
had
to
build
all
the
use,
all
the
all
the
end
end
tests
that
they
needed.
We
were
calling
them
validation,
Suites
I.
Remember
that
being
a
big
part
which
was
really
helped
relieve
the
confusion
of
listen
when
we
get
to
having
a
real
profile.
Well,
we'll
know
what
a
profile
is
I
mean
we
can
call
it
a
profile.
C
Maybe
the
windows
one
day
gets
to
profile.
Brian
I
know
mentioned
hey.
We
still
got
a
figure
a
lot
of
stuff
out
here,
but
they
can
move
forward,
but
the
the
calling,
the
things
validation
sweet,
really
relieved,
a
lot
of
the
pressure,
as
you
know,
until
we
have
a
good
reason
to
have
a
quote,
unquote
conformance
profile.
C
A
Hard
so
strong
agreement
there.
So
the
way
this
was
phrased
in
the
meeting
notes
is
that,
right
now
we
have
a
set
of
tests
that
are
called
note
conformance
but
are
different
to
exercise
all
of
the
behaviors.
We
expect
out
of
a
note,
and
so
the
thinking
was,
let's
rename
note
conformance
to
note
validation.
So
there
is
currently
a
directory
called
common.
A
Sorry,
I'm
blanking
a
little
bit
here.
There's
a
directory
called
no
Tooey
Tooey,
that's
all
of
the
tests.
That
can
only
run
on
a
note,
so
they
require
they
assume
privileged
access
to
the
note
to
do
a
little
bit
more
like
white
box
testing
of
these
behaviors,
and
then
there
are
a
set
of
behaviors
that
can
be
tested
by
way
of
conformance
testing.
A
So
the
the
example
that
we
were
using
in
state
testing
yesterday
was
to
talk
about
file
system
permissions,
for
example,
as
a
behavior
I
think
file
system
permissions
are
a
pretty
fundamental
requirement
of
how
kubernetes
operates,
but
as
an
implementation
of
that
behavior
there's
like
a
different
string
that
you
have
to
use
for
Linux
versus
windows
in
terms
of
how
you
describe
those
permissions.
So
the
hope
would
be
that
you
have
different
implementations,
but
that's
the
same
behavior
and
that's
what
across
two
different
node
validation
suites?
E
E
I
agree
that
we're
kind
of
lacking
we
piggybacked
so
far
on
Linux
isms
and
in
general
we
need
to
identify
more
those
both
in
the
API
and
then
lower-level
behaviors
in
the
system,
if
we
hope
to
abstract
across
multiple
operating
systems,
name
a
significant
way,
I
think
we're
just
at
the
earliest
earliest
stages
of
that.
At
the
moment.
E
For
now,
I
windows
is
one
of
many
optional
behaviors
in
the
system.
I
don't
want
to
overly
fixate
on
just
Windows,
since
we
have
other
issues
like
single
noted
versus
multi,
node
or
GPUs
or
other
things.
So,
as
we
keep
in
mind,
how
do
we
support
these
optional,
non-portable,
environment,
specific
or
platform
specific
features?
What
is
the
right
way
to
accommodate
those
like?
E
We
don't
have
any
significant
persistent
volume
tests
in
the
system,
because
there's
no
common,
persistent
volume,
implementation
or
conventions
so
I
actually
think
that
one
is
way
more
critical
in
some
sense
to
think
about
conformance
wise
for
Windows
I
want.
Do
you
want
to
unblock
them,
like
any
other
optional
features
shouldn't
be
blocked
by
black
of
components.
To
us,
it
is
a
good
use
case
to
keep
in
mind.
It
has
some
pretty
significant
implications
across
the
system
and
we're
still
working
through
those.
E
My
party
right
now
is
just
to
help
them
meet
the
general
expectations
of
an
implementation
of
anything
in
the
project,
so
that's
sort
of
where
we
are
with
Windows
I
agree
to
reduce
confusion
with
the
note
conformance
test
that
renaming
them.
Validation
makes
a
lot
of
sense
just
to
reduce
confusion.
I'm
not
sure
any
specific
decisions
were
made
in
the
meeting,
and
usually
we
try
not
to
make
decisions
in
person
meetings
when
everybody
can
be
present.
Although
we
did
a
pretty
good
attendance.
A
Why
I'm
trying
to
get
us
to
rehash
some
of
these
conversations
here
in
a
publicly
reported
medium,
although
that
meeting
was
also
recorded
and
is
posted
on
YouTube,
thanks
to
the
wonderful
efforts
of
the
CN
CF
and
all
of
the
recording
staff?
For
that,
though,
I
feel
like
we're
in
agreement
on
those
two
goals
that
we
want
to
unblock
Windows.
So
Windows
is
not
going
to
be
necessarily
part
of
the
conformance
discussion
for
at
least
this
quarter,
and
there
is
a
hope
that
somebody
will
work
on
untangling.
A
All
of
this,
by
renaming
note,
conformance
to
note
validation,
just
to
speak
a
little
bit
to
how
tactically
we're
going
to
proceed
with
Windows.
If
this
is
of
some
interest
to
this
group,
we
have
had
a
thread
bouncing
around
between
city
architecture.
I,
think
this
group
and
I
think
seek
testing.
So
I
finally
said:
look
Patrick,
let's
just
let's
all
get
in
a
room
and
talk
about
this
until
we
have
agreement,
at
least
from
a
state
testing
perspective
that
we're
gonna
allow
for
there
to
be
a
Linux.
A
Only
tag
in
all
the
tests
that
they're
unable
to
get
passing
on
their
implementation
of
kubernetes
and
then
try
to
reduce
as
many
uses
of
that
tag
as
possible.
This
tag
being
completely
orthogonal
to
conformance
and
purely
for
informational
purposes
and
I
linked
the
mailing
list.
Where
we
kind
of
summarized
that
discussion
Brian,
you
have
your
hand
up,
yeah,.
E
I
just
want
to
clarify
that
on
tests
that
are
just
don't
work
yet
on
the
windows,
I,
don't
think
those
should
be
tagged.
Linux
only
I
think
only
the
tests
that
are
inherently
linux
only
because
they
depend
on
specific
Linux,
primitives
and
semantics
and
api's
should
be
tagged
when
it's
only
like
set
comp
or
analytics
capabilities
or
SELinux,
or
a
farmer
or
specific
file
system
permissions
and
whatnot
things
that
don't
work
out
on
Windows.
We
need
to
tag
a
different
way
and
there
may
be
some
other
categories
of
things
like
this.
E
You
know
we
are
tagging
things
that
require
privilege
and
know
that
Windows
doesn't
support
privilege,
it's
just
one
example.
So
I'd
rather
be
more
specific
about
the
reasons
for
why
a
test
might
or
might
not
work
in
a
different
environment.
So
I
just
wanted
to
clarify
that
one
point
we
mentioned
that
in
the
call
to
that
there
was
the
same
concern,
so
yeah
I
think
one
thing
that
we
did
discuss
at
the
meaning
which
we
do
need
a
resolution
to
and
I,
don't
know
that
we
have.
C
A
A
E
E
A
B
A
D
Some
mechanism,
where
there's
a
badge
this
cluster,
supports
Windows
workloads.
This
cluster
supports
GPU
workloads.
This
cluster
has
lasers,
that
I
seems
reasonable,
but
interacting
with
the
kubernetes
api
and
some
base
level
functionality
that
that
api
exposes
ought
to
be
universally
a
message
to
customers
that
they
can
expect
the
same
here.
F
But
it
I
can
say:
I
think
that
in
my
mind,
part
of
the
confusion
comes
in.
Is
that
because
we're
doing
this
bottom-up,
looking
at
existing
tasks
and
and
I,
think
I
was
just
looking
at
what's
trainee
put
together
and
some
tracking
issues,
but
I
think
that
when
we
put
together
the
conformance
criteria,
they
need
to
be
distinct
from
the
tasks
right
and
right
now
it
seems
like
they're
intermingled.
F
So
if
we
can
define
specifically
each
of
the
behaviors
apart
from
the
tests,
then
it
becomes
clear
that
whether
given
cluster
complies
with
that,
even
if
you
don't
have
tests,
you
can
manually
verify
it
right.
So
obviously
we
want
to
fill
in
tests
to
get
full
coverage,
but
I'd
only
test
and
whether
they're
tagged
with
this
or
that
or
that
bottom-up
approach
is
the
really
easiest
way
to
make
it
clear
to
everybody
like
if
you
had
a
list.
If
you
have
this
report,
you
could
say
I
mean
it
must
meet
all
these
criteria
and
I.
D
Sure,
I
I
think
the
tests
are
a
proxy
for
something
else
exactly
and
that
I
agree
with
and
I
think
if
we
had
a
comprehensive,
exhaustive
spec
on
what
it
is
to
implement
the
kubernetes
api
and
what
is
required
and
what
is
optional,
that
it
would
be
easy
to
start
there
and
write
the
test
suite.
We
don't
have
that
today,
so
we're
going
that
reverse
direction.
F
Right
but
we've
had
the
discussion
of
coverage
and
weather
coverage
is
sufficient,
and
it's
hard
to
know
that
without
knowing
that
that's
back
first
of
all,
and
second
of
all,
when
you
get
into
issues
of
is
this
test?
Should
this
test
go
towards
conformance
for
this
particular
platform
or
I?
Think
that
not
having
agreed
upon
that
back
ahead
of
time?
It
means
we
just
argue
a
lot
about
it,
or
people
can't
quite
come
to
agreement.
B
Just
to
summarize
there
what
we
talked
about
in
Seattle
was
that
the
if
we
did
do
profiles,
the
initial
profiles
we
would
do
would
only
be
additive.
So
very
specifically,
in
the
Windows
context,
it
would
not
be
possible
to
have
a
conformant
windows
only
cluster
you
had
gained
at
least
two
linux
nodes,
and
then
you
can
add
on
Windows
nodes
on
top
of
that,
and
so
it
sounds
like
we're.
B
E
Think
we're
ready
and
the
Windows
folks
had
much
more
practical
issues
like
some
of
the
current
conformance
tests.
They
don't
pass
so
they
wanted
changing.
Those
tests
is
hard
because
it
more
approvals,
so
how
could
they
make
progress?
And
that
involves
things
like
forking
the
tests,
the
tagging
mechanisms
and
so
on?
So
those
mechanical
details
are
still
getting
worked
out
in
terms
of
adding
it
as
a
profile.
E
I
think
it
is
useful
to
consider
Windows
along
with
other
profiles
we
might
add
and
how
those
might
be
packaged
and
communicated
to
users,
but
I
don't
want
to
just
consider
only
Windows,
because
I
don't
think
that's
gonna
be
sufficient.
I
also,
don't
think
it's
going
to
be
very
impactful,
because
right
now,
no
kubernetes
services
and
distribution
support
windows.
There
are
other
features
like
forces
and
volumes
that
are
much
more
widely
used.
They
would
have
more
impact
so.
D
E
Single
node
is
a
good
example,
because
it's
a
niche,
but
maybe
an
important
issue
and
purses
and
volumes,
because
the
impact
is
so
so
broad
is
such
a
heavily
used
feature
and
maybe
low
down.
Services
would
be
good
to
include
enough,
because
it's
something
that
most
cloud-based
services
support,
but
not
all
distributions
for
it.
D
E
So
I
never
want
to
have
a
subtractive
profile,
so
the
thing
to
can
think
eventually
we
will
remove
things
from
the
current
default
base
set
of
tests
and
add
them
as
additive
profiles.
I,
don't
think
single
node
meets
the
bar
for
that
right
now,
but
it
is
useful
to
consider
how
we
would
do
that
for
things
like
features
that
require
cluster
level
node
level
or
network
level
privilege,
which
is
something
we
talked
about
doing
or
how
we
would
handle
other
locked-down
environments,
which
people
are
more
and
more
interested
in
for
security.
So.
F
Brian,
unfortunately,
missed
the
meeting
in
Seattle,
but
down
last
I
heard.
The
discussion
on
profiles
was
have
a
very,
very
small
number
of
profiles,
but
based
on
what
you're
saying
now,
it
sounds
more
like
we
would
have
a
be
a
base
core
functionality
and
then
we'd
have
other
segments
of
functionality
like
persistent
volumes
and
load
balancer
integration
and
whatever,
though
that
sounds
like
we're,
gonna
get
quite
a
few
more
than
just
you
know
two
or
three
profiles:
we
what
need
your
subsystems
released?
They
are
optional,
I
guess
so.
E
This
is
where
I
say
we
need
to
think
about
how
we
bundle
sets
of
features
into
profiles.
I,
don't
think
it's
the
case
that
we
want
to
have
40
profiles.
We
might
have
40
test
tags
all
right.
This
is
where
we
can
look
at.
You
know
what
sets
of
features
our
distribution
supporting.
What
sets
of
features
do,
we
think,
are
broadly
useful
for
running
applications
and
ensuring
application
portability,
which
is
the
goal,
and
we
can
bundle
that
functionality
into
a
profile
or
something
like
that.
D
F
E
E
D
E
C
Mentioned
that
we
would
start
driving
to
have
a
the
validation
test
suites
for
those
and
then
everybody's
comfortable.
That,
though,
we've
got
a
whole
bunch
of
validation,
test
suites.
We
really
know
what
it
means
to
be
GPU
and
a
GPU
works,
or
your
purpose
per
system
volume
works
or
what
have
you
and
then
you?
You
would
then
have
a
process
for
potential
promotion
and
sort
of
a
you
know.
A
squashing
of
the
commits,
if
possible,
to
then
add
those
in
where
it
made
sense
right.
C
A
Hey
so
I
have
a
controversial
idea.
I
am
physically
and
mentally
incapable
of
thinking
about
profiles,
because
I'm
too
tactically
focused
on
what
is
it
that
we're
supposed
to
do
to
how
to
quickly
cover
our
base
before
we
even
get
to
profiles
and
I
would
greatly
appreciate
those
folks
who
care
tremendously
about
profiles
and
additional
extras
to
help
out
with
improving
the
base.
A
Otherwise,
we're
never
going
to
get
to
a
point
where
profiles
even
make
sense
and
I
would
like
to
applaud
Patrick
Lang
and
the
folks
who
are
pushing
hard
on
Windows
as
people
who
are
stepping
up
and
showing
up
and
helping
us
out
there
and
I
really
just
like.
If
you
want
to
keep
having
these
discussions
about
profiles
and
stuff,
that's
great,
but
I
think
I
should
be
involved
in
them.
Yeah.
C
A
C
Yeah,
but
just
to
be
clear
is
that
when
you
say,
hey,
I'd
rather
have
help
on
this
other
thing,
because
it's
the
crawl
step-
and
you
all
are
talking
about
the
walk
and
run
stuff
I
want
to
make
sure
is
reading,
is
engaging
you
sure,
Eenie
of
trainees
engaging
there
and
helping
you
on
that
base
that
that
you
just
described
so
you
so
you're.
Not
you
know
you
feel,
like
you
are
getting
some
relief
well.
A
So
I
wanted
I,
don't
know
if
I'm
jumping
as
too
far
ahead
into
the
point.
The
part
of
the
working
group
session
where
I
said
hey
everybody
I'm,
leading
the
114
kubernetes
released
this
quarter.
It's
going
to
heat
up
a
lot
of
my
bandwidth
and
I'm
not
going
to
be
really
available
for
this
as
much
this
quarter,
that
has
happened.
A
I
really
haven't
had
any
time
to
Shepherd
any
PRS,
and
so
what
I'm
like
the
very
next
step
that
I
have
taken
is
to
take
every
issue
that
we
labeled
with
area
conformance
and
put
it
onto
a
project
board
that
everybody
has
everybody
on
the
conformance.
Github
team
has
admin
access
to
you,
so
you
cannot
other
people
if
you
want,
and
then
everybody
who's
in
the
kubernetes
org,
which
is
most
of
us,
has
write
access
to.
A
So
the
next
steps
would
be
for
us
to
think
of
that
as
a
backlog
of
work
and
prioritize
it
and
filter
it
to
make
sure
that
it's
actually
the
scope
of
work
that
we
collectively
think
drives
us
forward
to
adequate
base
coverage,
and
so
I
think
I'm
talking
about
somebody
doing
that
or
a
group
of
people
doing
that
getting
consensus
and
then
actually
shepherding
the
appropriate
PRS
and
even
better
it'd.
Be
super
awesome.
If
people
were
writing
into
end
tests.
I
know
we
do
have
like
a
couple
contractors,
but
it's
it's
three
people
Brian.
E
H
A
A
You
might
know
him
as
the
guy
who
wrote
API
snoop,
but
like
one
of
the
options
we
have
is
to
take
him
and
his
team
of
people
and
run
them
through
the
exercise
of
writing
into
end
tests
and
seeing
how
the
what
the
whole
happy
path
for
that
process
is
including
using
something
like
API
snoop
to
drive
their
decisions,
but
I
feel
like
they're
gonna
lack
the
appropriate
consensus
from
this
group.
Like
I.
Look
at
the
discussion
we
just
attempted
to
have
on
profiles.
A
I
asked
us
if
we
had
made
any
decisions
and
I
feel
like
we
just
went
and
revisited
every
single
one
and
undecided
so
I
have
concerns
about.
How
are
we
actually
going
to
get
consensus
from
the
appropriate
group
of
people
to
push
these
things
forward,
and
so
any
somebody
who's
just
like
a
regular
old
project
manager
great.
We
would
really
appreciate
your
skills,
but
I
have
concerns.
A
D
I'm
just
gonna,
say
I
think
there
are
multiples
facts
going
on.
One
track
is
adding
tests
which
are
obviously
missing
and
promoting
tests,
which
could
be
conformance
tests,
but
just
don't
have
the
tag
to
be
coming.
Conformance
tests
and
folks
in
my
group
at
Google
have
pushed
that
along
significantly.
Writing
a
watch
test
rating
garbage
collection
tests,
like
writing,
stateful
set
and
workloads
API
tests
like
those
are
efforts
that
are
not
contentious
and
are
just
work
and
we
staff
and
move
this
things
along
quarter-to-quarter.
D
Someone
showed
the
number
of
conformance
test
Delta
over
time
and
that
has
grown
so
I
think
there
is
a
body
of
work
of
writing
tests
and
promoting
those
that
exists
or
breaking
them
into
being
more
targeted
tests.
Don't
test
things
by
accident,
there's
another
body
of
work
that
this
group
typically
ends
up
being
in
discussion
and
debate,
and
it
is
difficult
to
come
up
with
a
path
forward
for
profiles
and
what
does
it
mean
to
different
interested
parties
and
are
those
interested
parties
even
on
the
call
it
doesn't?
D
Look
today
like
Windows
folks,
are
on
this
call.
So
we
had
a
conversation,
but
their
voices
that
need
to
be
part
of
that
are
not
in
this
discussion
so
that
that
is
a
circular
ongoing
discussion
that
will
evolve
slowly
over
time.
But
I,
don't
think
that
means
we're
stuck
on
the
entire
effort.
We
can
continue
to
make
progress
on
pod
conformance
by
having
people
who
write
features
for
that
part
of
the
code
base
to
also
work
on
conformance
tests.
F
If
I
can
say,
yeah
I
think
there's
a
third
thing
and
I
brought
this
up
earlier,
maybe
M,
maybe
I'm.
The
only
one
thinks
things
we
need.
We
should
do
it
this
way,
but
the
built
like,
like
I,
said,
building
the
tests
and
tagging
them
as
confirmes
as
this
bottom-up
approach.
But
I
think
that,
where
we
need
to
agree
is
on
what
you
know,
what
the
behaviors
and
that
I
think
that
that
screen
II
did
start.
F
If
you
look
at
what
the
agenda
at
least
categorize
create
these
categories
of
okay,
we
need
Qantas
in
this
area.
But
what
exactly
that
means?
I,
don't
know
if
I
guess,
how
do
we
measure
the
coverage
of
whether
those
conformance
tests
actually
cover
the
behaviors
that
we
could
want
to
consider
as
part
of
conformance
and
go
ahead?
Joe
I
was.
H
D
To
describe
it
in
terms
and
very
high-level
terms,
how
do
how
can
we
guarantee
that
kubernetes
platforms
and
distributions
meet
this
claim?
It
was
very,
very
challenging.
The
documentation
is
out-of-date
or
inconsistent.
I
can
share
that
document
again,
but
I
found.
That
was
not
a
super,
fruitful
or
all
paths
forward.
So.
F
B
D
B
A
So
I
walked
through
trainees,
spreadsheet
and
the
issues
linked
therein
and
I
feel
like
a
lot
of
them,
are
placeholder
issues
and
my
my
my
suggestion
would
be
that
we
try
and
keep
all
of
our
work
in
the
kubernetes
org.
One
of
the
reasons
I
created
the
area
conformance
label
was
so
that
we
could
track
this
work
on
in
any
of
the
sundry
repositories
that
the
work
actually
happens
inside
of
the
community
sort.
A
So
if
we're
going
to
do
like
tracking
issues,
I'd
rather
have
them
be
somewhere
in
the
kubernetes
org
and
that
they
have
the
area
conformance
label
on
them
so
that
we
can
use
the
one
board
and
just
be
clear.
I
created
this
one
board
as
like
the
clearinghouse
for
everything
issues.
Np
was
kind
of
different
from
where,
like
Brian
had
Jay's,
create
a
tracking
board
for
city
architecture
to
sign
off
beyond
conformance
tests.
This
was
just
a
shepherd
like
one
conformance
test
to
another,
and
maybe
it's
still
good
for
that
sort
of
shepherding
process.
A
It
feels
like
it
has
a
little
bit
more
substance
than
the
placeholder
issues
that
Rainey
created,
though
I
am
open
to
somebody
telling
me
that
that's
way
too
overwhelming
and
we
should
start
fresh
with
a
clean
slate.
But
just
then
we
have
a
and
standard
way
of
tracking
all
of
our
conformance
work,
so
where's
your
board
on
I
linked
it
in
the
meeting
notes,
it's
I
will
place
the
link
to
it
in
chat
shortly.
E
A
G
A
Okay,
like
things
there's
a
little
bit
of
the
contractors,
are
gonna
run
into
this,
and
you're
gonna
have
to
help
them
through
that.
The
contractors
might
just
need
some
general
help,
and
maybe
you
have
some
more
domain
expertise
than
the
contractors
on
things
like.
How
are
we
going
to
keep
the
docs,
up-to-date
and
and
some
of
the
other
PRS
that
you
cerini
have
pushed
forward
in
kubernetes,
kubernetes
yeah.
G
E
D
D
A
Of
the
things
I
am
trying
to
do
as
part
of
this
release
cycle
is
to
encourage
the
communities
community
that
everything
that's
landing
and
by
landing.
That
means
going
from
alpha
to
beta
beta,
the
GA
or
just
landing
as
alpha
out
right
should
have
a
thing
called
a
cap,
but
kubernetes
enhancement,
proposal
and
part
of
the
contents
of
that
proposal
should
include
a
checklist
of
graduation
criteria
and
I
am
totally
fine
with
zigge
architecture.
Saying
that
anything
that's
landing
is
stable
should
have
conformance
tests
as
part
of
that
checklist.
I
feel
like
that's.
A
E
I
agree
that
that's
the
right
mechanism
it
is
documented,
is
in
the
place
where
we
currently
document
the
criteria,
but
again
only
four
things.
Work
informant
is
applicable
so
like
if
someone
we're
adding
a
new
our
back
feature,
our
back
is
not
currently
in
component,
so
it
wouldn't
be
caught
by
that
as
part
of
cigar
collection.
We
are
going
to
more
generally
to
enhance
the
documentation
of
the
bar
for
different
levels
of
maturity
for
api's
and
for
other
features
and
behaviors.
So
that's
something
on
our
slate
right
now.
E
A
A
It's
written
in
the
discussion
down
below
I
feel
like
maybe
that's
actually.
The
one
thing
we
do
agree
on
as
a
group
today
is
that
we're
not
going
to
consider
yeah
windows
going
to
GA
does
not
require
conformance
agreed
on
it.
Last
year
sounds
like
we
still
agree
on
that
this
year,
we've
tactically
repeated
that
in
a
number
of
other
recorded
meetings
such
as
siga
architecture
and
cig
testing,
and
it
will
be
written
down
in
the
cap.
B
B
What
yeah
so
one
one
proposal
we
accepted,
which
is
that
with
1.13
today,
you're
allowed
to
certified
not
just
1.13
and
1.12,
but
we
added
in
the
ability
to
certify
1.11
so
that
three
version
pieces
accepted
and
I
think
a
lot
of
people
are
appreciative
of
it.
You
had
a
separate
proposal
right,
which
is
essentially
to
say,
as
you
certify
it.
Let's
say,
a
new
vendor
comes
in
and
certifies
1.11,
1.12
and
1.13.
Your
proposal
would
allow
them
to
also
certify
1.0,
1.1,
1.2,
etc,
to
go
further
back
yeah.
H
H
Different
version
and
the
last
two
so
the
main,
the
main
thrust
behind
the
proposal
is
just
to
level
that
playing
field
so
that
everyone
can
offer
the
same
service
whereas
right
now,
if
you
didn't
kind
of
get
in
at
you
know,
when
you
could
then
you're
sorry,
for
you
can
never
offer
that
one,
whereas
someone
else
can
does
that
make
sense.
Goddess.
D
So
I
guess
I'm
a
little
confused
because
you
can
given
the
first
proposal
that
was
agreed
on
you
can.
If
you
came
in
today,
team
is
out,
you
can
certify
1:13,
okay,
112
is
available
and
supported
by
the
community.
You
can
certify,
112-111
is
out
and
still
within
the
mm-hmm
range,
so
you
can
say
112
and
111
exactly.
B
H
Carlene,
someone
that
had
a
110
certification
gets
to
keep
that
they
can
still
offer
certified
1.10.
Well,
what
we
said
in
the
terms
is
you
can
do
that,
but
only
if
you
also
offer
like
a
current
one
alongside
it.
So
as
long
as
they're
offering
1.11
one
or
twelve
one
of
thirteen
and
ones
they're
offering
one
of
those
in
a
sort
of
card,
they
can
continue
to
offer
there.
The
previous
you
know
one
of
ten
as
so
to
fundraise.
H
D
Lts
discussion-
maybe
we
extend
before
in
the
future
to
get
a
year
worth
of
support,
but
today
110
is
not
supported
by
the
community,
so
I
mean
we
won't
be
patched
on
that
version.
There's
no
community
support
for
it,
so
I'm
really
uncomfortable
allowing
a
newcomer
go
back
and
satisfy
an
unsupported
version
of
kubernetes.
So.
H
Maybe
we
need
to
revisit
that
role
because,
like
currently,
you
can't
still
offer
OneNote
ends
as
certified
canoes
as
long
as
you
certified
it.
While
it
was
current
and
you
still
offer
a
current
one,
so
we
were
actually
allowing
that
today,
so
maybe
maybe
the
the
result
ease
could
be
actually
revisiting
that
what.
H
I
I
D
I
B
But
just
on
a
practical
level,
I
want
to
point
out
that
there's
very
few
companies
who
have
the
level
of
investment
that
they
can
credibly
maintain
an
old
version,
security
fixes
on
an
old
version
of
kubernetes
and
I.
Think
we
acknowledge
that
Red
Hat
has
that
business
model
and
and
several
other
companies
a
decade
ago.
We
would
have,
ironically
said
yeah,
but
what
if
Microsoft
comes
in
and
they
suddenly
well,
but
I'll
actually
use
the
example
of
Ericsson,
where
they're
not
yet
certified
I
certainly
expect
them
to
be
soon
I.
B
Think
it's
a
very
different
message
to
say:
hey
come
in,
you
can
have
111
112
113
and
then,
if
your
engineers
get
up
to
speed-
and
you
want
to
claim
to
your
customers
that
you're
understanding
every
security
pass,
that's
made
and
maintaining
that
going
forward
on
111.
That
still
seems
to
me
like
a
very
different
story
than
them
saying:
oh
yeah
we've
had
this
1.7
version
out
there
and
we
want
to
certify
that
as
well
into
but
I
guess.
B
If
somebody
asked
for
it
with
a
really
specific
reason
on
why
they
need
to
go
backwards,
I
think
we
could
always
reconsider
it,
but
I
would
suggest
that
we
table
this
for
now.
I
feel
like
the
proposal
we
did
include
already
incorporate.
So
it
really
is
a
lot
of
the
pressure
of
folks
who
are
feeling
like
it
was
yeah.
H
I'm
having
that
outcome,
let
me
just
give
you
a
concrete
examples
and
Google
is
currently
offering
1.10
in
production.
You
know
presumably
little
bug
fixes
and
security
patches
applied,
and
that
is
certified.
One
ok
and
we
can
continue
to
offer
certified
one
to
ten
for
as
long
as
we
want
someone
else
like
Ericsson
kennel
PETA.
So
there
is
a
little
bit
of
a
yeah.
You
have
to
have
been
there,
I
guess
when
that
version
was
current
in
order
to
to
have
that
certification
bark
on
it,
so
it
wouldn't
be
able
to
do
that
now.
H
That
was
the
reason
how
the
PR,
just
to
kind
of
equalize
that
opportunity,
but
yeah
I'm,
happy
to
table
it
on
any
votes.
Like
I
said
in
the
beginning,
I'm
not
strongly
attached
with.
D
B
A
And
search
for
version
support
policy
lays
out
how
many
versions
of
kubernetes
we
support
with
security
fixes.
There
is
no
such
thing
as
LTS,
though
there
are,
is
a
very
motivated
group
of
people
talking
about
it
and
whether
or
not
it
should
be
a
thing
and
what
LTS
even
means,
but
right
now
we
just
have
a
support
policy
and.
D
A
Discussed
this
a
bunch
in
sync
release
where
the
CI
infrastructure
to
allow
us
to
patch
or
release
is
back,
which
is
outside
the
window
of
three
releases
back
exists
for,
like
the
first
four
to
five
weeks
of
the
release
cycle,
just
purely
out
of
happenstance.
No
other
reason
than
that,
and
if
that's
something
we
need
to
formalize
or
extend
all
the
way
to
four
procedures.
Back
I
would
hope
that
that's
being
discussed
at
stick
release
because
we
just
had
an
in-depth
discussion
about
like
well.