►
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
Intro: Knative Productivity BoF - Srinivas V. Hegde & Adriano Cunha, Google
Knative is Kubernetes based platform to build, deploy and manage modern serverless workloads, it extends Kubernetes to provide a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere. The project has 8 repositories on GIT and has hundreds of contributors actively working on its repos on daily basis, which makes productivity super critical so that every contributor’s time is well spent and quality of code is ensured. This talk gives an overview of how contributor productivity is achieved for Knative from 4 dimensions: test health, release health, metrics, and performance. We will go over test infrastructures in place to show how it makes writing and running tests is an easy and pleasant experience for contributors. We will explain how release is done in automated and predictable fashion, and what thoughts have gone into release design so that it also benefits other Knative personas. We will go over a set of metrics defined for Knative project health, show how we measure and track metrics at ongoing basis to drive up project health overall. We will also look at performance and explain what type of infrastructure has been built to support perf/scale/load testing.
To Learn More: https://sched.co/Grbz
A
We
definitely
everyone.
My
name
is
Srinivas,
hey
Griff
I
am
from
Google
and
will
be
talking
about
an
introduction
to
K
native
productivity
and
some
basic
things
about
what
K
native
is,
and
what
do
we
actually
mean
by
K
native
productivity
and
what
we
are
doing
to
make
the
community
productive
within
K
native,
so
just
to
show
of
hands
how
many
have
actually
heard
or
actually
read
or
know
about
K
native
and
would
like
to
use
them
yeah.
That's
pretty
great!
A
A
A
It
also
has
a
build
system
where
you
can
actually
build
from
your
source
directly
to
a
kubernetes
container,
and
it
also
has
an
eventing
framework
which
you
can
use
to
create
and
define
different
kinds
of
events
and
K
native
is
designed
with
several
different
personas
in
mind.
When
we
think
about
K
native
users,
we
think
of
them
as
either
contributors
who
users
who
actually
want
to
actively
contribute
to
the
kinetic
codebase
and
make
it
better.
A
There
can
be
developers
who
want
to
use
K
native
components
like
serving
or
eventing
or
any
of
these
or
all
of
them,
into
their
own
products
and
functions
or
as
a
service,
and
we
also
think
of
them
as
operators
who
actively
want
to
monitor
how
their
product,
which
do
uses
K
native
implementation
under
the
hood,
actively
is
working
on
and
is
maintained
and
K
native
is
designed
with
not
just
Google.
But
it's
a
community
forum,
and
we
have
multiple
partners,
including
pivotal
IBM,
Red,
Hat
s,
AP
and
several
others.
A
Kennedy
right
now
has
12
rep
opposed
under
the
creative
umbrella,
and
we
have
more
than
400
users
actively
interacting
with
the
DES
code
base.
On
a
daily
basis,
so
what
do
we
mean
by
K
native
productivity?
In
this
scenario,
so
the
K
native
productivity
is
AI
led
by
Jessie,
Zoo
and
Adriana
Cunha.
These
are
their
github
user
names
and
we
meet
every
other
Thursday
at
2:30
p.m.
A
so
this
is
basically
the
mission
statement
or
the
Charter
for
K
native
productivity.
We
want
to
enable
all
the
contributors
to
write
high
quality
high
velocity
deliverables.
We
want
to
have
predictable
releases
that
can
be
measured
and
drive
high
community
collaboration
and
improve
the
overall
productivity
of
everyone
who
wants
to
actively
use
or
contribute
to
K
native.
So
what
do
you
exactly
mean
by
these
terms
here?
So
writing
code
and
the
tests
is
fine,
but
we
want
a
system.
A
We
want
a
very
oval
oiled
machine
that
also
enables
us
to
do
good
issue
management,
good
PR
management
and
several
other
things
that
that
a
contributor
would
need
to
actively
contribute
code
to
key
native
with
high
velocity.
What
we
aim
at
is
basically
the
contributors
should,
whenever,
from
the
time
it
takes
to
the
first,
commit
to
merging
your
PR
to
actually
releasing
the
releasing.
Your
changes
should
be
super
fast,
and
everyone
should
be
responsive
enough
and
four
releases,
every
contributor
or
developer
or
external
user
who
wants
to
use
K
native.
A
We
want
them
to
have
a
predictable
amount
of
release,
cadence
which
they
can
define
and
they
can
use.
And
finally,
we
want
very
high
collaboration
amongst
single
person
who
wants
to
contribute
to
Kiev.
We
want
it
to
be
all
the
owners
are
pretty
responsive
and
we
want
them
to
respond
to
the
github
PR
conversations
or
our
slack
channels
or
any
other
chat
messages
or
things
like
that.
We
we
we
set
a
very
high
bar
on
fast
response
times,
so
when
we
think
about
creative
productivity,
we
actually
think
in
these
four
scenarios.
A
So
first
we
will
be
looking
at
test
health,
where
we
are
trying
to
target
very
fast
resubmits
attack.
Any
flakiness
from
your
tests
reduce
the
amount
of
toil
in
debugging
and
improving
the
debugging
experience
for
any
test
for
release
health.
We
want
good
release,
automation
that
can
produce
us
releases
releases
predictably
and
handle
different
kinds
of
versioning
between
tests
and
CR
DS
for
performance.
A
A
The
conformance
tests
define
how
the
implementation
performs
against
the
actual
runtime
contract,
so
if
any
contributor
or
user
should
be
able
to
run
the
conformance
test
and
confident
enough
that
their
implementation
satisfies
the
runtime
contract
or
not,
along
with
the
conformance
test,
we
need
a
set
of
versioning
tests.
What
the
versioning
tests
define
is.
Basically,
there
are
difference,
so
we
have
C
or
DS
that
define
different
objects
on
top
of
the
kubernetes
implementation.
A
So
you
have
different
CID
versions
and
you
can
even
target
different
versions
of
K
native,
so
we
want
some
tests
that
basically
target
different
versions
of
your
releases
and
different
versions
of
your
series,
so
for
release
health.
What
we
are
targeting
for
is
we
need
a
predictable
release,
cadence
for
all
your
releases.
A
We
really
have
an
early
job
to
run
all
the
tests
and
we
have
a
nightly
job
to
push
the
latest
code
to
a
nightly
environment
and
we
have
a
weekly
job
that
actually
runs
and
pushes
all
the
code
to
a
weekly
environment
and
for
performance.
We
think
of
performance
as
different
different
two
types:
the
black
spot,
the
blackbox
performance
testing,
is
basically
sending
a
bunch
of
QPS
to
an
end
point
and
just
testing
whether
you
get
the
number
of
200s
and
the
number
of
500s
and
things
like
that
for
white
box
performance
testing.
A
What
we
are
looking
at
is
if
we
send
a
bunch
of
QPS,
the
controller
will
emit
some
kind
of
matrix.
The
different
components
emit
different
matrix.
How
do
we
actually
serve
the
requests
and
how
do
we
actually
handle
those
requests,
and
these
can
either
be
for
your
pre
submits
or
we
can
run
them
nightly
or
we
can
them
them
weekly
and
the
different
components
that
we
care
about
during
a
performance
test
is
basically
the
load
generators
or
the
benchmarking
and
the
different
charting
that
we
can
use.
A
So
all
this
is
great,
but
we
need
metrics
and
we
need
some
actionable
metrics
so
forth.
So
different
kinds
of
metrics
that
we
are
looking
at
right
now
in
K
native,
is
base
for
test
health.
We
are
looking
at
the
test
flakiness,
we
verify
how
much
the
tests
are
passing
or
failing
the
amount
of
code
every
test
covers.
We
have
a
PR
job
that
actually
looks
at
the
amount
of
code
coverage
that
every
test
runs
the
time
to
actually
run
the
test
and
the
resources
that
are
needed
to
run
the
test
and
for
realies
health.
A
We
have
a
periodic
job
that
or
it's
all
our
releases,
and
so
we
look
at
how
the
job
is
doing
and
what
are
the
other
tests
that
we
run
with
the
releases?
Was
there
flakiness
rate
and
how
much
time
does
it
take
to
run
so
for
performance
metrics?
What
we
look
at
is
the
latency
metrics,
for
example.
What's
the
percentile
for
P
50,
P,
90,
p
99
things
like
that,
and
what
we
are
low
also
looking
at
is
the
auto
scaling
matrix.
A
Auto
scaling
is
an
important
feature
for
K
native
and
what
we
are
looking
at
is
how
much
time
does
it
take
for
0
to
1,
auto
scaling?
That
means
that
when
I
deploy
and
send
the
request,
how
much
time
does
it
take
for
the
first
part
to
come
up
and
actually
serve
the
request?
We
are
also
looking
at
1
to
0,
auto
scaling,
for
example,
if
I,
if
I,
don't
send
a
request
for
a
lot
of
time.
A
How
much
time
does
it
take
for
the
last
part
to
actually
turn
down,
and
we
are
also
looking
at
1
to
1,000
scaling
is
basically
how
much
time
does
it
take
for
it
to
go
from
one
part
to
1,000
parts
to
serve
your
request
and
the
different
server
metrics
that
we
are
looking
at
is
the
different
controller
matrix.
So
for
all
se
IDs
we
have
custom
controllers
that
serve
different
kinds
of
metrics.
We
are
looking
at
the
different
controller
metrics
that
the
server
responds
with.
A
We
are
looking
at
the
different
pod
metrics,
like
number
of
pods,
required
to
run
the
test
or
number
the
amount
of
time
it
takes
to
bring
up
a
pod,
and
we
are
also
looking
at
the
autoscaler
metrics
like
how
much
time
does
it
take
for
the
autoscaler
to
actually
respond
to
the
first
request.
What's
the
queue
length
for
it
to
serve
different
kinds
of
requests
and
other
things
like
that,
so
now
we
can
actually
take
a
look
at
the
different
tools
that
we
use
or
want
to
use.
A
So
first
is
CI
CD,
so
for
CA
CD
we
have
different
kinds
of
pre,
submit
and
post
submit,
workflows
that
gate
the
quality
of
check-ins
and
we
have
different
release,
automation,
pipelines
and
we
want
to
maintain
the
quality
of
the
release.
We
want
to
define,
implement
the
different
release,
criterias
and
define
the
process
around
it,
and
the
CI
CD
system
should
allow
us
to
run
all
sorts
of
tests
that
we
want
to
run
on.
Also
all
different
Cadence's
and
all
the
outputs
and
metrics
should
be
stored
in
the
logs.
A
So
the
CI
CD
system
that
we
use
is
proud.
If
you
attended
the
prowl
lecture
recently
like
a
couple
of
hours
ago,
there
was
they
give
a
good
live.
There
was
a
good
lecture
for
prowl,
so
Prowse,
basically
a
kubernetes
for
CI
CD
solution.
It
is
being
used
for
all
the
kubernetes
repos.
It's
been
battle
tested
with
kubernetes,
it's
very
easy
to
configure
it's
very
easy
to
extend
and
it
handles
all
the
plumbing
for
you
from
github
to
storage.
A
A
So
the
next
thing
we
will
talk
about
is
the
load
generator
matrix
so
as
a
load
generator.
What
we
wanted
for
our
purpose
was
we
wanted
a
simple
goal,
angle,
library,
that
we
can
integrate
with
inkay
native,
and
we
wanted
the
low
generator
to
provide
all
the
data
points
that
it
can
from
the
response.
A
For
example,
if
we
send
a
thousand
QPS,
it
should
not
just
tell
me,
like
I,
had
five
hundred
two
hundred
and
five
hundred
two
hundred
and
find
it
find
its
I
want
to
know
what
exactly
will
happen
with
each
request
and
how
it
was
responded
and
what's
the
response
from
that
for
every
cube,
query
that
I
sent
and
if
it
has
advanced
features
like
latency
calculation
and
charting,
and
things
like
that.
That
would
be
great.
So
the
the
tool
that
we
are
using
for
performance
testing
is
called
for.
A
A
Standard
HTTP
in
addition
to
HTTP
11.1
and
for
teo
is
a
simple
go
library
which
we
can
easily
integrate
with
our
gove
testing
framework
so,
and
it
provides
some
default
charting
capabilities
that
allow
us
to
show
the
histogram
data
of
all
the
response
rates
and
provides
all
the
data
points
that
we
can
later
on
interact
with,
and
it
also
help
gives
us
your
JSON
output
of
everything
that
happened.
So
you
can
easily
parse
the
data
and
act
on
those
things.
A
A
So
the
solution
that
we
are
currently
using
is
grid,
so
template
is
great
because
it
gives
you
a
nice
grid
view
of
the
status
and
the
metric.
So
you
can
actually
see
what's
happening
for
your
tests,
whether
they
are
passing
failing
and
any
latency
metric.
If
you
are
looking
at,
then
you
can
say
p50
what's
the
value
and
it
can
be
expanded
to
actually
show
the
value
of
the
metric,
so
it
you
can
actually
say.
A
What's
the
value
of
my
a
50
right
now,
and
it
can
tell
you
p,
50
is
one
second
or
for
example,
and
it
has
some
default
charting
capabilities
to
show
the
actual
trends
in
recent
runs.
So
you
can
expand
that
and
say:
I
want
to
know
how
what's
happening
in
my
50th
percentile
latency
for
the
last
three
days,
and
it
can
show
you
that
value
and
test
period
has
been
battle
tested
with
kubernetes
again
kubernetes
uses
tested
heavily
to
show
all
its
metrics
and
all
its
tests.
A
A
Yeah
so
there
is,
there
is
actually
a
deep
dive
session
on
Thursday
at
4:30
p.m.
where
we'll
go
a
bit
more
detail
about
the
tools
that
we
are
trying
to
use.
That
will
explain
how
we
actually
contributors
can
commit
to
the
PRS
interact
with
the
code
base
and
how
you
can
actually
see
those
metrics
later.