►
From YouTube: The Hitchhiker's Guide to Evaluating Dependency Updates to Kubernetes - Arsh Sharma, VMware
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
更新的 “Hitchhiker "指南对 Kubernetes 的评估依赖性 | The Hitchhiker's Guide to Evaluating Dependency Updates to Kubernetes - Arsh Sharma, VMware
本次演讲将讨论在 Kubernetes 这样的大型项目中跟踪依赖关系的重要性，以及“depstat”，这是一个为跟踪 Kubernetes 代码库的依赖关系更新而创建的工具。Kubernetes 存储库每天都会收到许多 pull 请求，其中许多请求会带来依赖关系的变更。大多数时候，维护人员必须手动发现这些更改，确定它们对整个依赖谱的影响，然后 ping 此 pull 请求作者以采取行动。为了避免这种情况并帮助更好地跟踪依赖项更新，创建了 depstat。Depstat 是一个上游项目，用于分析 go 模块支持的项目的依赖关系。它目前作为 Kubernetes 代码库中 prow 作业的一部分运行，并提供四个关键的依赖关系相关指标。“depstat”还提供了通过创建图形直观分析依赖关系的能力。
This talk will be about the importance of tracking dependencies in a large project like Kubernetes and about "depstat" which is a tool created to track dependency updates to the Kubernetes codebase. The Kubernetes repository receives many pull requests each day many of which bring dependency changes with them. Most of the time, the maintainers manually have to spot these changes, determine their effects on the overall dependency tree, and then ping the pull request authors to take action. To avoid this and help better track the dependency updates, depstat was created. depstat is an upstream project which analyzes dependencies for go modules enabled projects. It currently runs as part of a prow job in the Kubernetes code repository and provides four crucial dependency-related metrics. "depstat" also provides the ability to analyze dependencies visually by creating a graph.
A
Hello,
everyone
and
welcome
to
the
hitchhiker's
guide
to
evaluating
dependency
updates
to
kubernetes
wow.
That
was
quite
a
mouthful.
I
hope
you
all
have
been
having
an
amazing
conference.
So
far,
this
session
is
going
to
be
about
the
dependencies
of
core
projects.
What
are
they,
why
is
it
important
to
keep
track
of
them
and
how
we
use
a
tool
called
depstart
to
do
that
in
the
upstream
kubernetes
project.
A
But
let
me
introduce
myself
before
we
begin.
I
am
r
sharma
and
I
work
as
a
member
of
technical
staff
at
vmware.
I
am
also
part
of
the
current
kubernetes
1.23
release
team
other
than
that
I
help
out
the
project
in
other
areas
like
sega
architecture,
docs
testing
and
with
onboarding
new
contributors
to
the
project.
A
A
So,
first
things.
First,
what
exactly
are
dependencies
well
dependencies
put
simply
are
external
packages
which
your
code
uses.
These
external
packages
are
distributed
as
modules
as
per
the
definition
of
a
module
in
go.
It
is
nothing
but
a
directory
containing
a
collection
of
nested
and
related
go
packages
with
a
go
dot
mod
file
at
its
root.
A
A
If
you
look
closely,
there
are
other
packages
and
modules
that
we
are
importing
to,
but
they
are
internal
to
go,
so
we
don't
consider
them
as
dependencies
of
our
project
by
default.
If
you
create
a
main.co
file
and
start
writing
code
in
it,
you
won't
get
the
support,
of
course,
dependency
management
tools.
A
A
A
Please
note
that
the
code.some
file
is
auto
generated
based
on
your
code.mod
file,
and
you
should
never
need
to
edit
it
manually
to
keep
your
managed
dependency
set
tidy.
You
can
use
the
go
mod
tidy
command
using
the
set
of
packages
imported
in
your
code.
This
command
edits
your
go.mod
file
to
add
modules
that
are
necessary
but
missing.
A
A
So
now
that
you
know
what
dependencies
are
and
how
go
handles
them,
let's
talk
a
bit
about
why
you
should
even
care
about
managing
and
keeping
track
of
your
project
dependencies
right.
Well,
the
thing
is
that,
sooner
or
later
you
would
have
to
update
the
dependencies
of
your
project
now.
This
might
be
because
you
want
the
changes
in
the
latest
release
of
that
dependency.
A
A
You
have
to
make
sure
that
it
doesn't
break
the
current
code
and
that
it
is
compatible
with
the
existing
versions
of
other
dependencies.
You
are
using
in
your
project,
so
I
think
when
it
comes
to
dependencies,
it
is
safe
to
say
the
lesser
the
better.
Now,
please
don't
mistake
this
as
me
suggesting
that
you
should
try
implementing
the
functionality
of
each
external
package
on
your
own.
No,
no,
the
reason.
A
Now.
All
of
this,
to
be
honest,
may
seem
a
little
trivial
for
a
small
project,
and
maybe
you
could
get
away
with
not
caring
about
the
dependencies
of
your
project
at
all,
but
when
a
project
grows
to
the
size
of
kubernetes,
all
of
this
becomes
very
important.
Updating
dependencies
could
often
mean
breaking
stuff
skipping.
A
crucial
dependency
update
could
mean
exposing
a
lot
of
users
to
a
security
risk.
A
So
long
story
short,
the
simple
the
dependency
chains
are
the
better
being
particular
about
your
project's
dependencies
right
from
the
start,
and
tracking
them
is
extremely
helpful,
and
I
cannot
stress
this
more
extremely
helpful
in
the
long
run
if
you're
not
particular
about
them
from
the
start.
You
might
find
yourself
in
a
situation
similar
to
that
of
marvin.
The
paranoid
android.
A
A
Not
only
that,
but
more
importantly,
how
would
these
pr's,
which
change
the
dependencies
and
what
was
the
impact
of
these
changes
we
wanted
to?
We
also
wanted
there
to
be
a
way
using
which
pr
authors
can
themselves
see
the
impact
of
the
dependency
changes
they
are
making
without
one
of
the
maintainers
having
to
go
and
ping
them,
and
it
was
to
all
it
was
to
solve
all
these
problems
that
we
came
up
with
depth
start.
A
A
The
first
and
the
most
important
thing
from
the
point
of
view
of
upstream
kubernetes
debstat
provides
us
with
is
the
start.
Sub
command
running
debstat
stats
on
your
project
directory
would
give
an
output
which
would
look
something
like
this.
It
would
show
you
the
number
of
direct
dependencies
transitive
dependencies,
total
dependencies
and
max
depth
of
dependencies.
A
A
A
A
A
The
next
thing
in
the
output
is
the
total
number
of
dependencies
of
our
project,
which
is
pretty
self-explanatory,
apart
from
one
slide
caveat,
even
though
here
in
this
example,
you
see
that
the
sum
of
direct
dependencies
and
total
dependencies
is
equal
to
and
transitive
dependencies
is
equal
to
the
total
dependencies.
It
doesn't
necessarily
have
to
be
so.
Why
is
that
simply
because
a
dependency
can
be
both
a
direct
as
well
as
transitive
dependency?
A
A
A
The
final
thing
in
the
output
is
the
max
depth
of
dependencies,
which
is
nothing
but
the
length
of
the
longest
dependency
chain.
Going
back
to
the
previous
slide.
We
see
that
there
are
two
dependency
chains
here.
One
is
from
our
module
to
wolf
to
meow,
which
has
a
length
of
three
and
the
other
is
from
our
module
to
now,
which
has
a
length
of
two.
A
A
A
A
Now
this
graph
is
produced
by
a
simple
go
modules
project
I
had
created
for
this
talk,
but
I
also
want
to
show
you
the
beauty
which
gets
generated
when
we
create
a
graph
out
of
all
the
dependencies
of
the
kubernetes
repository
beautiful,
isn't
it
well?
This
should
give
you
an
idea
of
the
complex
dependency
chains
in
a
project
as
large
as
kubernetes,
and
should
probably
also
tell
you
why
we
needed
a
way
to
analyze
these
dependencies.
A
What
this
does
is
show
all
the
cycles
present
in
the
dependencies
of
the
project,
so
here
for
the
simple
project
I've
been
using
till
now,
you'll
see
that
the
cycles
and
dependencies
are
due
to
xnet
depending
on
crypto,
which
further
depends
on
x
net
for
kubernetes.
There
are
many
more
cycles,
which
are
also
much
more
complicated
and
longer,
and
this
isn't
even
like
the
complete
output
of
the
command.
A
A
What
is
pro
you
might
ask.
Brow
is
a
kubernetes
based
ci
cd
system.
Brow
jobs
can
be
triggered
by
various
types
of
events
and
report,
their
statuses
to
different
services.
To
put
it
in
very
simple
terms,
and
in
the
context
of
this
talk,
prow
is
basically
responsible
for
running
certain
tests
on
pr's
that
are
made.
It
can
also
run
these
tests
on
the
master
branch
of
a
repository
for
depth
start.
We
have
two
brow
jobs.
A
This
can
also
be
manually
triggered
on
prs
by
commenting
forward,
slash
tech
test,
check,
dependency,
stats,
all
thanks
to
brow.
What
this
job
does
is
run
depth
start
on
the
code,
which
is
present
in
the
pull
request
and
then
prints
its
difference
with
the
output
of
running
depth,
stud
on
the
master
branch
of
the
kubernetes
depository.
A
A
So
if
your
pr
changes
dependencies
brow
would
catch
that
and
run
the
check,
dep
stats
job,
which
would
give
an
output
similar
to
the
one
you
see
on
the
right
here.
For
this
pr,
the
number
of
direct
dependencies
were
being
changed
by
one,
which
is
what
debstart
reported
another
way
the
periodic
job
helps
us
is.
It
allows
us
to
give
a
track
of
how
the
project
dependencies
are
changing
over
time,
not
only
that,
it
is
also
you.
A
So
this
was
it
from
my
side
and
thank
you
so
so
much
for
attending.
If
you
have
any
questions
related
to
the
project
or
how
you
can
use
it
or
try
it
or
if
you
want
to
contribute
to
it,
please
feel
free
to
reach
out
to
me
on
twitter
or
drop
a
mail
once
again.
Thank
you
so
much
for
attending,
and
I
hope
you
learned
something
new
from
this
session.