►
From YouTube: Contributing to Kubernetes Conformance Coverage - Hippie Hacker & Caleb Woodbine, ii.coop
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Contributing to Kubernetes Conformance Coverage - Hippie Hacker & Caleb Woodbine, ii.coop
In this session we'll walk through the Certified Kubernetes program followed by a deep-dive into the tooling developed for identification, removal and prevention of gaps in certification test coverage. In the intro, we will cover the steps required to become a CNCF Certified Kubernetes provider. We will also deep dive into the APISnoop technologies supporting conformance, specifically: Identifying Gaps Closing Gaps (apisnoop audit sink + test writing w/ Preventing Gaps (release blocking w/Verifying cloud provider submissions
https://sched.co/ekHw
A
Hello
and
welcome
to
contributing
to
kubernetes
conformance
coverage,
I'm
with
ii,
and
we
are
a
coding
cooperative
in
new
zealand,
with
a
focus
on
cooperative
coding.
Pairing
is
sharing
for
us
and
anytime.
Two
or
more
of
us
are
together
cooperating
on
things.
Then
we're
iii
is
there
right,
so
the
people
of
the
co-op
or
myself
and
my
friend
caleb,
who
is
co-hosting
this
talk
with
me
and
our
friend
zach,
who
down
in
wellington,
focuses
on
the
ui
and
the
database
and
many
other
pieces.
B
A
A
B
A
I,
like
that,
I
we
have
the
the
readme
from
the
kind
sig
that
submitted
their
four
files
about
seven
months
ago
for
118
and
their
documentation
includes
how
to
run
it.
We
will
go
ahead
and
change
our
view
to
include
that
and
walk
through
the
steps
for
them.
So
we've
just
created
a
new
sono
boy,
so
we're
gonna,
look
at
the
logs
for
that
as
well,
and
the
logs
will
allow
us
to
probably
see
that
test
running
and
we
can
see
that
set
up
the
pod,
creating
the
watch
deleting
the
pods
and
verifying.
A
So
all
those
verification
steps
were
run
as
part
of
the
sonuboy
test
suite
and
they
will
create
some
output
for
us,
but
while
we're
waiting
for
the
output,
maybe
we
could
look
at
the
the
coup
cuddle,
the
sono
boy
namespace.
Well,
let's
look
and
see:
what's
there
in
the
watch,
you
can
note
that
there's
a
sona
boy
pod
running
along
with
all
the
normal
expedited
environments,
including
oh,
this
api
snoop
that
might
come
important
later
yeah.
A
Remember
that
subtle
boy
will
export
some
results,
including
the
two
log
files
that
you
will
need
and
we'll
do.
A
quick
check
to
make
sure
that
those
log
files
do
exist
and
they
do
excellent.
So
combining
the
files
we
need
to
submit
our
conformance
results,
the
instructions
that
they
provide,
and
I
will
go
ahead
and
focus
on
the
website
here.
That
shows
uploading
the
files
and
the
fields
that
you'll
need
to
fill
in
your
product
panel.
A
A
That's
already
filled
out
for
case
conformance,
but
for
our
demo
here,
I'm
actually
going
to
file
this
against
the
cncf
infrared
case
conformance
and
go
ahead
and
look
at
the
pull
requests
that
we're
creating
based
on
that
we'll
come
back
to
this
a
little
bit
later
in
the
demo.
But
this
contents
of
the
pr
contain
these
four
files
that
are
part
of
the
documentation
and
we'll
visit
that
again
after
our
deep
dive.
A
Thanks
for
that
caleb,
our
deep
dive
is
going
to
consist
of
several
things
regarding
the
gaps
that
we
have
in
kubernetes
conformance
coverage,
three
main
things
identifying
those
gaps,
closing
those
gaps
and
preventing
the
gap.
So
we
can
color
in
all
of
the
parts
that
are
missing
first
identifying
the
gaps
in
kubernetes
coverage
is
going
to
require
filling
in
our
thank
you
for
filling
in
our
graph
here.
A
Apisnoop.Cncf.Io
is
built
on
top
of
a
database
that
looks
at
the
entire
surface
area
of
the
kubernetes
api
and
lets
us
see
the
operations
that
have
conformance
coverage,
which
is
the
darker
color
and
test
coverage.
That's
not
yet
conformant,
which
is
a
lighter
color
and
the
gray
areas
which
have
no
test
coverage
at
all.
You
can
see
that
there
are
quite
a
few
gaps
we'd
like
to
fill
in,
particularly
in
the
green,
stable
area.
B
It's
a
great
question:
well
turns
out,
there's
actually
many
ways
to
deploy
api
snoop.
You
can
use
your
own
clusters
or,
if
you
want
to
do
some
local
testing
with
it
and
figure
out
the
endpoints
that
you
care
about,
then
you
can
deploy
it
with
kind.
Using
this
configuration
that
we
have.
If
you
climb
the
api
snip
repo
check
out
the
kind
folder,
there's
a
neat,
little
configuration
that
just
might
be
for
you,
which
would
bring
up
apis
loop
and
auto
logo
straight
away.
A
The
schemas
that
we're
going
to
focus
on
first
are
the
audit
events
and
the
open
api.
The
open
api
is
pulled
from
that
swagger
json,
that's
in
the
kubernetes
repository.
I
think
it
weighs
in
at
around
two
megs
normally,
but
once
it's
loaded
into
the
database
with
all
of
the
indexes
and
extra
data
it
weighs
in
at
around
five
megs.
A
We
load
the
swagger
json
directly
from
the
github
repository
for
kubernetes,
and
this
allows
us
to
have
a
table
based
on
just
the
shape
of
the
kubernetes
api,
to
be
really
clear
and
precise
about
what
it
is.
We're
trying
to
make
sure
that
we
cover
without
having
any
logs.
This
allows
us
to
do
as
you
could
an
example.
Psql
query
that
focuses
on
the
release
upcoming
called
120
and
the
stable
endpoints
to
just
show
us
what's
brand
new
and
stable
in
this
next
release.
A
Let's
keep
an
eye
on
this,
get
internal
api
server
group,
because
it'll
be
important
later
in
the
presentation
when
we
have
some
ui
elements
to
show,
in
addition
to
the
surface
area.
So
we
have
this
big
gray
underlying
thing.
We
need
to
color
in
the
areas
that
we
are
actually
testing.
Snoop
db
has
a
second
phase.
It
goes
through
instead
of
beyond
loading,
just
the
api
definition,
it
also
loads
test
deck
data.
A
The
kind
conformance
audit
job
was
created
this
week.
In
order
to
create
an
audit
log.
You
can
see
that
the
audit
log
that
it
creates
there
is
brought
in
to
our
api
snoop
db.
So
we
can
have
all
of
these
tests
and
see
all
the
endpoints
that
it
hits
the
database
table
underlying
that
that
ingests,
those
logs
allows
us
to
know
and
query
the
test,
whether
that
test
was
a
conformance
test
or
not,
and
all
of
the
raw
json
data
that
is
part
of
that
audit
log
entry.
A
A
A
This
is
the
front
page
of
api
snoop
that
if
you
go
down
to
the
bottom
of
any
of
the
releases
that
you
can
select
from
you'll
see
that
list
of
new
endpoints.
It's
pretty
obvious
that
there
is
a
new
category
being
brought
in
in
120
called
internal
api
server,
which
has
a
slew
of
alpha
endpoints,
which
will
need
to
eventually,
as
they
progress
from
alpha
to
beta,
to
stable,
to
reach
table
will
need
conformance
tests.
A
A
The
orange
areas
are
where
we
introduced
new
endpoints
and
didn't
include
any
test.
This
makes
it
hard,
as
it
makes
the
whole
we're
digging
deeper
while
we're
trying
to
fill
fill
it
in.
So
we
we're
lucky
in
that
from
115
onward.
We
don't
really
see
a
lot
of
new
endpoints
being
promoted
without
test
and
we'll
show
a
little
bit
later
when
we're
ensuring
that
that
will
never
happen
again.
A
B
Once
we
get
the
end
point,
we
we
want
to
go
to
the
reference
docs
to
understand
the
api,
endpoint
and
yeah
shout
out
to
sig
docs
doing
great
work.
We
want
to
understand
the
the
way
that
we
can
talk
to
the
resource
and
all
of
its
function
handlers.
So
we
we
go
to
client
go
for
that
which
is
really
useful
and
we
look
in
the
core
v1
folder,
here's
an
outline
of
the
test
and
the
way
that
we'll
write
the
test.
A
B
So
that
is
all
before
creating
a
pr
and
then
next
on,
we
we
run
mock
tests
in
our
local
clusters
and
we
make
sure
that
our
user
agent
is
set
to
live
test.
Writing
this
allows
us
to
see
the
new
untested
endpoints,
which
we
want
to
target
in
our
tests
and
then,
following
on
we,
we
we've
noticed
that
this
test
wasn't
effective
enough,
creating
a
pod
because
pods
they're
already
covered
in
conformance.
So
we
we
don't
get
any
changing
coverage
there,
which
is
fine.
B
So
we'll
look
again
for
more
endpoints
later
on
now
that
we've
got
a
ticket.
It's
the!
By
this
point,
you
should
have
endpoints,
which
unhit
and
you've
proven
that
you
can
hit
them
and
you've
gotten
some
code.
That
actually
does
do
that.
Now
we
can
submit
a
ticket
and
in
this
screenshot
right
here
we
have
a
whole
bunch
of
issues
on
github
that
are
submitted
as
tickets
and
they're
exported
as
markdown
and
they're
all
ready
for
review.
A
A
To
summarize
our
deep
dive
was
all
about
the
gaps
in
kubernetes
conformance
coverage,
where
we
would
identify
the
gaps
using
api
snoop.cncf.io.
With
the
underlying
snoop
db,
we
were
able
to
close
those
gaps
using
qmax
and
our
in
cluster
workflow
that
the
ii
team
uses
and
we
were
able
to
prevent
gaps
by
creating
our
release
blocking
jobs.