►
From YouTube: Antrea LIVE: Episode 5 (CNI lifecycle in Tanzu, Carvel Packages, Tanzu Addons Manager)
Description
Let's learn about Antrea's lifecycle in Tanzu, with Carvel Packages and Tanzu Addons Manager. The Carvel team will join us so we'll be sure to get into the nitty gritty details about PackageRepositorys, Kapp Controller, and PackageInstalls. In the process we'll learn alot about how VMWare tanzu views the world of custom build K8s infra.
- api deprecations
- https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/
- https://github.com/vmware-tanzu/tanzu-framework/pull/959/
- https://github.com/vmware-tanzu/tanzu-framework/pull/959/, addon reconcilers
- How tanzu addons for CNI, etc, work
- kubetail on https://github.com/vmware-tanzu/tanzu-framework/tree/main/addons#workflow-of-tanzu-addons-manager
- https://carvel.dev/kapp-controller/docs/latest/packaging/
- PackageRepository
- PackageMetadata
- Package
- PackageInstall
- note the `cluster` field... its multicluster by default
- kubectl edit pkg cert-manager.tanzu.vmware.com.1.5.3+vmware.2-tkg.1-zshippable
- goes to custom APIServer extension
- not a CRD
- Managed by kapp controller
A
B
What's
up
zudong,
I'm
sorry!
What's
up
lubron
and
lou
bronze
from
my
team
over
on
the
tkg
networking
side,
so
yeah
yeah?
Definitely
we
do
have
a
calendar
invite
so
for
folks
that
are
interested
like
reach
me
reach
out
to
me
on
slack
and
I'll.
Send
you
the
calendar,
invite
so
that
you
can
always
remember
to
come.
Hang
out
with
us,
so
yeah
we
can.
We
can
update
the
the
youtube
stuff
for
sure
lupron,
so
yeah,
so
carvel
features
these
through
six
six.
A
B
All
right,
so
I
wanted
to
sort
of
sort
of
like
so
today
we're
to
take
it.
We've
been
we've
done.
The
last
four
episodes
have
been
real
focused
on
andrea
and
you're.
Welcome,
lubron
lubron
said
thank
you
he's
such
a
gentleman,
so
we've
done
a
few
episodes
on
on
some
android
internals
and
played
around
with
tons
of
framework
and
vmware
tons
of
run
entry
on
tkg
before
but
mostly
on
kind.
B
B
Some
drama
folks
have
seen
what's
up
zack,
yes,
sir,
how
you
doing
and
the
the
one
of
the
problems
that
carville
manages
for
us
is
sort
of
package
management
and
upgrades
and
all
that
stuff
using
using
cap
controller,
which
is
sort
of
I
don't
know.
You
know
john
once
mentioned
to
me,
dimitri,
it's
like
almost
like
sort
of
an
orchestrator
for
all
of
cap.
Is
that
like
are
we
allowed
to
say
that
or
we're
not
supposed
to
say
that
I
feel
like
it's.
I
feel
like.
A
B
Build,
gives
you
sort
of
a
declarative
way
to
do
like
production
grade,
builds
that
are
reproducible
and
so
on
and
so
forth.
So
all
these
things
play
together,
but
in
tanzania
we
recently
ran
into
an
issue
where
not
actually
with
android
videos
with
calico.
We
had
a
regression
because
the
tajera
opera
or
I'm
sorry,
calico
itself
used
uses
used,
uses
some
of
the
older,
like
the
older
version
of
calico
that
we
had,
which
was
like
3..
B
I
don't
know
11
or
something
like
that,
was
using
some
of
these
old
apis
and
then
we
upgraded
to
122
and
so
there's
an
interesting
pr
that
just
came
out.
That
gets
us
really
talking
about
package
management.
How
important
it
is
for
kubernetes,
where
what
we
found
out
we
needed
to
do
in
order
to
upgrade
calico
properly
was
in
tkg
is
actually
changed.
The
way
that
we
manage
add-ons
in
tkg,
so
this
pr
just
came
out
and
it
was
who
was
it
that
did
this
lucheng
ucheng
was
doing
it.
B
That
cat's
working
hard,
that
cat
is
working
hard
on
on
thanksgiving
weekend.
Okay,
so
here
we
go
so
so
this
so
this
pr
by
luchang
he's
distracting
me
with
his
cab,
but
I
wanted
to
show
you
something
else.
This
one
is
so
this.
This
is
what
this
is
doing.
Is
it's
making
it
so
that
you
have
a
version
of
maybe
I
can
open
up,
let's
open
up
the
myro
board
right
and
let's
go
over
to
yeah.
Actually
this
is
the
entry
live
board
right,
so
so.
A
B
C
A
B
B
But
so,
like
you
know,
I've
got
this
node
and
it's
like
you
know,
running
a
121
kubelet
like
right,
it's
running
a
121
kubelet
and
then
that
same
node
is
going
to
come
back
up
and
it's
going
to
be
running
a
122
kubelet
right-
and
you
know,
as
I
go
from
here
to
here,
things
are
going
to
break
right.
So
in
this
case
I
was
saying
you
know
with
calco.
B
You've
got
calico
311
here
right,
and
this
runs
just
fine,
but
when
you
upgrade
this
node
you're
going
to
want
to
be
running,
you
know
you're
going
to
have.
If
you
have
this
311
running,
when
you
upgrade
this
node
nothing's
going
to
work
right
and
so
in
tkg
right
so
in
tkg
we
have
to
orchestrate
this
upgrade.
We
have
to
upgrade
all
these
packages,
including
you've
got
calico
right.
You've
got
you've,
got
andrea
right.
Well,
you
may
not
you're
not
going
to
have
both,
but
you'll
have
one
or
the
other
right.
You've
got.
B
Obviously,
you've
got
all
the
kubernetes
components
right.
You've
got
the
scheduler.
You've
got
the
api
server.
You've
got
the
controller
manager
right.
You've
got
all
those
things.
You've
got
your
csi
providers
right.
You've
got
a
whole
bunch
of
other
you've
got
all
these
different
containers
that
you're
running
we'll
see
them
all
in
a
little
bit.
I've
got
them
on
another
screen
over
here.
Actually
I
could
just
share
it
really
quickly
but
like
these
are
all
the
different
crds
that
you're
running
and
and
that's
really
small,
I'm
going
to
make
it
bigger
in
a
little
bit.
B
B
B
A
B
B
There's
a
cni
contract,
but
the
cni
interface
doesn't
change
much
right.
So
so
there
is
so.
Let's
pull
that
up.
I
don't
know
if
we
have
any.
I
don't
know
if
june
jen's
here,
because
he
c
and
I
meant
to
get
the
cni
right,
so
the
cni's
stable
right
so
like.
If
we
go
here
right,
you
know
and
they
are
designing
1.2
or
they
are
designing
the
2.0
api
and
so
on
and
so
forth,
but
like
it's
stable
and
it's
not
changing
a
lot
and
there's
only
three
real
things.
B
There's
add
check
and
delete
right
so
like
when
you
make
a
pod
container
d
right
container
d
so
like
when
I
make
a
pot,
I
have
the
kublet
and
then
the
kublet
is
gonna.
Then
over
a
socket
talk
to
the
cri
right,
talk
to
container
d
and
then
container
d
is
gonna.
Talk
to
my
cni
provider.
Right
and
it's
gonna
say,
like
you
know:
okay,
add
right
or
delete
right
or
whatever,
and
it's
really
gonna
be
only
doing
one
of
these
three
things
right,
so
that
api
is
very
stable
and
it'll.
B
Send
it
like
a
blog
blob
of
json
along
the
way,
and
maybe
you
might
have
one
new
field
or
something
that
isn't
there
or
is
there
but
like
for
the
most
part,
it's
stable.
It's
a
good
question,
though,
because
like
for
example,
the
reason
it's
an
interesting
question
is
like
it's
we're
going
to
have
to
deal
with
this.
If
we
get
to
cni
2.0
right,
we're
going
to
have
some
other
problem.
A
Yeah,
so
I
guess
you
know
with
what
seems
like
what
luchang
then
was
trying
to
solve
is
not
really
the
well.
I
mean
I
guess
yeah,
so
I
I
I
would
imagine
yeah.
So
if
we
consider
the
cni
interface
stable
and
let's
ignore
for
a
second
that
it
may
change
in
future.
Right
then
really
I'm
guessing,
then
what
the
things
that
are
running
on
each
cubelet
else
so
talk
to
the
control
plane
and
that's
what
pisses
them
off.
If
the
control
plane
gets
upgraded.
B
A
B
I
mean
I'm
sure
for
some
period
of
time
it
may
have
the
thing:
is
we
upgraded
from
311
to
319.,
so
we
did
a
huge
upgrade
of
calico
right.
It
wasn't
like
we
weren't
keep.
We
weren't
doing
a
very
good
job,
admittedly
of
keeping
up
to
date
with
the
latest
calico
right.
So
if
there
was
a
bridge
in
place
to
to
manage
that,
it's
like
you
know,
it's.
A
A
Yeah,
because,
what's
interesting
about
this
is
then
you
know
imagine
if
you
jump
far
enough
right,
where
the
version
of
a
let's
say,
calico,
that
you're
trying
to
install
on
your
existing
cluster
is
just
it
doesn't
support
the
existing
cluster
right
yeah.
I
think
this
becomes
a
problem
of
really.
How
far
can
you
jump,
because
you
need
that
window
of
backwards
compatibility
right
to
you
know,
I
guess
shift
between
the
versions.
B
Yeah
yeah,
you
need
that
and
you
need
some
weird
glue
logic,
and
so
this
so
this
this
pr,
the
main
thing
it
did
is
it
changed.
It's
a
good
way
to
learn
about
framework
is
to
study
this
pr
because
it
sort
of
it
changed
the
it
it
added.
This
function
on
upgrade
add-ons
post
node
upgrade
right
and
it's
pretty
easy
to
walk
through
this
right.
B
You
know
these
standard
package
repositories
that
are
sort
of
becoming
a
thing
more
and
more
in
tkg
right,
and
these
things
then,
are
associated
with
add-ons,
and
we
have
a
downstream
way
of
managing
the
add-ons,
and
we
have
these
upstream
add-ons
and
there's
a
controller
that
sort
of
manages
all
of
this
all
of
these
add-ons
and
then
ultimately
like
this.
This
pr
like
makes
it
so
that
we
do
this.
B
We
do
this,
we
upgrade
this
contain.
We
upgrade
this
add-on
and
then
after
we
upgrade
this
add-on,
then
we
add
the
nodes.
It's
like
a
one
and
then
a
two
and
it
used
to
be
the
other
way
around.
It
used
to
be
first
upgrade
the
node,
and
now
your
node
is
totally
broken
because
it's
using
a
new
version
of
kubernetes
in
an
old
version
of
this
add-on,
and
so
now
your
node
is
broken,
and
then
it's
like
hard
to
do
an
upgrade
when
you
have
a
broken
node,
because
nothing's
nothing's
working
anymore
right.
B
A
B
Yeah,
well,
you
know
like
you
can
you
came
for
the
you
came
for
carvalho
and
you
stayed
for
myro,
so
so
so
we're
gonna
yeah
like
get
into
this
package
manager.
So
so
y'all
recently
built
all
this
package
stuff
right.
You
built
a
package
repository.
You
built
package
metadata
package
package
install.
B
This
is
huge
for
us
on
the
tkg
side,
because,
while
on
the
andrea
side,
you
know
we're,
look
we're
thinking
about
making
a
forward-facing
sort
of
networking
focused
tanzu
package
repository
so
that
people
running
tanzu
that
want
to
run
like
the
bleeding
edge
version
of
andrea
and
a
bunch
of
other
bleeding
edge
stuff.
Whatever
we
might
decide
that
stuff
is,
can
just
run
it
we're
not
even
sure
what
that
looks
like.
B
Yet
it's
just
an
idea,
but
like
tell
us
about
how
this
package
repository
idea
evolved
because
I
was
looking
into
blog
and
it
was
like.
You
had
a
blog
where
you're
saying
like
yeah,
like
we
finally
decided
to
build
a
package
management
solution.
So
like
I'm,
assuming
that
for
a
while,
you
debated
that
and
you're
like
no,
we
don't
want
to
be
another
package
manager,
and
then
you
change
your
mind.
B
You
decided
you
wanted
to
be
one,
and
I
know
that
some
folks
asked
me
beforehand
wanted
me
to
talk
to
you
about
the
difference
between
the
carvel
package
management
philosophy
and
how
you
manage
packages
and
help
and
how
you've
gone
about
it
in
a
different
way.
So,
like
I'm,
gonna
switch
to
this
computer
and
as
I
switch,
why
don't
you
just
start
talking
us
through
these?
These
things.
A
Well,
since,
since
you
did
ask
a
question,
maybe
a
more
historical
question:
how
do
we
end
up
with
the
with
the
package
management
layer?
I'll
start
off
by
saying
that
we
have?
You
know
when
carvel
was
a
baby,
it
really
started
off
with
a
few.
You
know
fewer
number
of
tools
right.
We
I
think
we
started
off
actually
with
one
and
out
of
one
they're.
Actually,
we
split
out
you.
A
So
in
the
beginning-
let's,
let's
say
there
was
ytt
and
cap
right-
and
you
already
mentioned
that
ytt
is
really
about
templating
and
overlaying.
Well,
more
specifically,
the
idea
behind
ytt
was
you
really
want
to
be
working
with
the
data
structures
and
you
don't
want
to
be
working
with.
You
know,
text
templating
right
because
there's
so
many
things
that
you
could
actually
be.
You
know
doing
with
the
data
structures
and
not
having
to
worry
about.
A
Ctl
is
perfectly
fine,
but
once
you
kind
of
start
using
cube,
ctl
and
anger
and
actually
try
to
productionize
it,
you
really
start
questioning.
You
know
why
isn't
there
a
concept
of
an
application?
That's
at
least
what
we
call
it
right:
a
collection
of
resources
right
and
so
cap
really
has
turned
to
be
that
tool
that
that
manages
resources
in
bulk
and
converges
them
right.
So
over
time
as
you
delete
resources,
as
you
add
resources,
as
you
as
you
update
them
as
you,
you
know,
tweak
them
right.
A
You
want
to
be
able
to
be
absolutely
certain
that
the
cluster
is
converged
to
that
particular
state,
and
so
that
was
kind
of
the
beginnings
of
carvel
right.
We
have
these
two
tools
that
you
know
can
be
piped
together.
Right,
for
example,
ytt
actually
has
no
idea
what
kubernetes
is
and
cap
is
obviously
very
much
kubernetes
centric
right.
So
bringing
that
you
know
building
on
on
on
the
unix
philosophy
right,
we
were
able
to
separate
those
two
responsibilities
into
two
distinct
tools.
A
A
Some
users
will
take
advantage
of
only
a
few
tools
that
they
really
you
know
have
a
problem
for,
and
that
was
really
the
the
origins
and
and
really
the
and
really
the
kind
of
the
starting
point.
I
do
see
there's
a
question
here:
what's
the
difference
between
cap
and
helm?
Well,
you
can
think
of
helm
as
it's
a
tool
that
does
lots
of
kind
of
phases
right.
A
So
a
phase
of
templating,
a
phase
of
you
know
bringing
the
templates
and
packaging
them
up
right
phase
of
deploying
maybe
a
phase
of
configuring,
those
templates
right
versus
our
approach.
We
think
it's
it's
much
more
flexible
to
actually
split
up
each
one
of
those
faces
and
tackle
them
with
different
tools
right,
so
we
may
so
cap.
Specifically,
it
just
focuses
on
deployment.
It
doesn't
know
how
to
template
anything.
A
It
doesn't
know
how
to
package
anything
all
it
knows
how
to
do
is
take
a
yaml
and
apply
it
to
the
cluster
right,
and
so
you
know
that
that's,
ultimately
the
the
difference
that
I'm
trying
to
highlight
so
yeah.
So,
as
I
was
saying
we,
you
know,
we
have
started
where
we
have
these
smaller
sharper
tools
that
solve
very
particular
problems,
but
but
we
also
have
realized
that
well,
it's
nice
to
take
advantage
of
this
tools.
A
You
know
tools
that
somebody
would
use
locally
or
maybe
in
their
ci
flow
and
run
those
same
tools
as
a
deployment
workflow
as
part
of
a
controller
and,
ultimately
that's
what
that's.
What
turned
into
app
cr
provided
by
the
cap
control.
So
I
don't
know
yeah.
I
guess
here's
an
example
of
an
app
cr.
You
know
skipping
all
the
boring
metadata
sections
if
you
jump
to
like
spec
yeah.
So
here
we
have
so
app.
A
Cr
really
gets
split
into
this
three
sections
that
we
think
are
the
right
ways
of
kind
of
separating
the
responsibilities
there
is
a
first
section
is
actually
fetch.
So
in
this
yaml
it's
not
really
sorted.
Well,
it's
sorted
based
on
the
names,
but
we
typically
write
out
our
yamls
in
a
slightly
different
order,
but
the
idea
is
that
you
first
fetch
something
right
and
that
could
be
some
configuration.
A
So
the
idea
here
is
that
the
common
flows
that
you
know
users
typically
run
into
you-
should
be
able
to
codify
in
this
unified
interface
and
that's
what
appcr
is
to
us.
So
I'll
pause
over
here.
Maybe
for
a
second,
I
don't
know
if
anybody
got
any
questions
or
or
I
should
revisit
any
of
the
explanations
so
far,.
A
A
A
B
A
Yes,
so
in
templating,
in
as
it
has
some
of
the
templating
providers,
you
can
use
helm
template
right,
so
you
can,
for
example,
mix
and
match
things
right.
You
could
fetch
your
helm
chart
from
git
and
then
you
can
help
template
it,
and
then
you
can
maybe
even
pass
it
through
itt
to
apply
some
overlays
and
then
maybe
you
can
even
pass
it
through
k,
build
to
turn
all
the
image
references
into
digests.
A
D
A
Yes,
it
could,
or
it
could
share
things
in
theory,
I
mean
so
it's
really
up
to
you
what
you
end
up
fetching
right.
We
have
folks
who
are
fetching,
for
example,
from
a
shared
git
repository
and
maybe
applying
their
own
data
values,
or
maybe
you
know
they
they
decide
to
fetch
from
their
own
entirely
separate
git
repository
or
maybe
it's
fetching
what
we
call
image
package
bundles.
So
we
we
try
to
not
in
any
way.
B
B
Okay,
I've
got
internal
packages.packagingcardwell.dev
package
installs.
Then
I've
got
the
secret
stuff.
I
really
wanted
to
talk
about
package
repositories,
but
I
figured
since
we're
on
a
live
cluster.
It
might
be
interesting
if
you
wanted
to
just
sort
of
bounce
around
and
if
any
of
these
anything
interesting
that
you
want
to
do.
D
A
A
That's
what
we've
been
just
talking
about,
so
appcr
has
been
there
in
cap
controller
since
the
beginning,
and
that's
ultimately
one
of
the
core
things
that
actually
implements
the
actual
package,
install
mechanics
underneath
the
package
install
right
so
similar
how
deployment
create
pods
right,
create
pods
package
installs
they
create
apps,
and
so
that's
that's.
Ultimately.
Why
I'm
trying
to
highlight
the
app
is
that
you'll
see
that
there
is
a
there's,
a
very
direct
relationship
between
the
package
installed
in
an
app.
A
B
B
A
A
But
the
point-
the
point
that
I
was
trying
to
make
here
right
is
that
if
you
see
the
cube,
ctl
get
app
and
cube
ctl
get
package.
I
it
shows
you
effectively
one
two
one
mapping
there
right
for
every
single
package
installed:
there
is
going
to
be
an
app
cr
created
and
app
cr
is
actually
the
thing
that
does
all
the
heavy
lifting,
so
package
install
doesn't
actually
do
anything
really.
A
Yep
and
there's
actually-
and
you
know
due
to
this
layering
right
users
of
cap
controller,
for
example-
they
could
be
using
app
cr
to
deploy
their
own
applications,
but
also,
at
the
same
time
they
could
be
using
package
install
to
consume.
Let's
say
distributed
software
created
by
somebody
else
right,
but
it
ultimately,
in
both
cases,
boils
down
to
having
an
app
cr
that
gets
that
gets
added
to
the
cluster,
which
you
know
has
a
benefit
same.
As
you
know,
deployment
to
parts
you
have
that
singular
layer.
So.
B
A
B
B
B
A
A
That's
pretty
much
it
at
the
green
layer
and
the
yellow
layer.
We
do
have
a
concept
of
package
repository
now,
there's
actually
one
one
interesting
note
here
to
make.
We
have
not
implemented
everything
as
crds.
We
have
implemented
package
install
and
package
repository
as
crd
and
obviously
app
cr,
but
the
package
and
package
metadata
they're,
not
actually
crds
they're,
served
by
a
custom
api
server,
so
you
won't
find
actually
a
package
crd
in
the
cluster.
A
It's
been
out
there
for
two
years
before
the
rename
and
everything
so
we
felt
it
wasn't.
It
wasn't
worth
doing
the
larger
rename
and
we
may
eventually
do
some
renaming
and
you
know-
support
both
we're
kind
of
sticklers
for
backwards
compatibility.
So
it's
it's
a
it's
a
very
cautious
game
that
we
would
play.
A
B
A
A
Well,
it
is
a
first
class
in
a
sense
that
it's
a
first
class
api
right
so
from
a
consumer
of
kubernetes
apis,
you
don't
know
the
difference
right.
One
of
the
reasons
why
we
went
with
this
approach
is
actually
maybe
a
little
bit
of
a
future.
Looking
reason
is
that
we
don't
necessarily
want
to
store
all
packages
which
you
know
over
time.
You
may
actually
have
quite
a
bit
of
them.
A
B
A
You're,
probably
going
to
see
some
scary
looking
things,
oh,
what
is
this
these
are.
These
are,
I
believe,
base64
encoded
names.
I
forget
exactly
or
base
36
encoded
or
something
like
that,
because
we
didn't
want
anybody
trying
to
depend
on
these
kind
of
things
you
might
want
to
do.
Base
32
or
I
forget
what
we
use,
who.
B
A
So
yeah,
so
where
I
was
going,
was
this
right?
So
you
know
one
of
the
you
know.
One
of
the
requirements
that
we
felt
is
is
important
to
fulfill
is
being
able
to
discover
the
package
metadata
via
the
standard
kubernetes
apis
right
because
you're
using
kubernetes
api
for
the
rest
of
the
interaction
with
your
control
plane
right.
So
it
didn't
really
make
sense
to
try
to
move
that
api
elsewhere.
A
So
we
felt
this
was
a.
This
was
a
good
experience.
To
offer
now
package
package
is
something
that
you
can
add
to
the
api
to
the
you
know,
kubernetes
cluster
directly
right.
So,
for
example,
you
don't
have
to
use
a
higher
level,
primitive
or
package
repository
to
add
multiple
packages.
You
could
actually
just
do
cube.
Ctl
apply
some
package
cr.
B
A
But
that
really,
you
know,
is
there
for
folks
who
might
be
you
know,
maybe
they're
iterating
on
a
package
cr
and
said
they.
Of
course
they
don't
want
to
be
creating
package
repositories
every
time
they
iterate
or
maybe
there
is
some
other
cases
of
where
you
actually
want
to
be
in
control
of
package,
crs
more
directly
versus
trying
to
to
to
group
them
as
a
package
repository.
C
B
B
B
What
does
the
what
tell
me
you
have
to
tell
me
one
thing
that
the
andrea
agent
does
before
it
can
come
online
and
begin
assigning
ip
addresses
to
new
pods?
Okay,
there's
a
few
steps,
there's
a
few
things
that
the
android
agent
does
when
it
comes
online.
If
anybody
can
just
tell
me
one
of
them,
just
put
it
in
the
chat,
you
get
a
free
t-shirt
and
susan's
gonna
mail.
A
That's
all
I
was
really
saying
it
was
a
package.
Cr
right
is
that
you
know
they're
no
different
than
other
resources
right.
So
you
know
if
you,
for
whatever
reason
need
to
you,
know,
need
to
create
package
crs
yourself
right
and
manage
them.
Maybe
with
cap
deploy
directly
or
whatever
else
right,
you
totally
can
right,
and
this
again
goes
back
to
the
laying
principles
here.
B
A
There
is,
there
is
a
library
right
that
you
can
fairly
easily
import
into
your
code
and
I
think
you
just
have
to
implement
some
interfaces
now.
The
question
of
course
ends
up
to
be
like.
Where
do
you
actually
want
to
store
things?
And
you
know
crgs
do
quite
a
bit
for
you
right.
So
there's
got
to
be
a
really
compelling
reason
of
why
you
would
want
to
leave
what
the
crd
mechanism
provides
and
and
go.
A
You
know
the
custom
way,
but
there
is
definitely
compelling
reasons
for
you
know,
maybe
lower
level
projects
right
so,
for
example,
metric
server,
as
far
as
I
recall,
also
uses
an
api
server
right,
and
I
imagine
that's
probably
you
know
similarly
thought
about.
Is
you
don't
want
to
be
polluting
at
cd
with
lots
of
things,
but
I
don't
know
anything
about
actually
metric.
A
I
guess
I
mean
yeah,
you
you
can,
you
can
definitely
throw
in.
You
know
the
the
stateful
versus
stateless.
You
know
argument
in
there.
So
there's
actually
an
interesting
question
here
is
like
do.
We
need
to
persist
package
crs
anywhere
versus
just
have
them
be
ephemeral
and
the
next
time
yeah.
You
know
the
package
repository
or
whatever
else
you
know
reconciles.
Then
it
will
redownload
them,
and
you
know
here
they
are
kept
in
memory
or
on
disk
or
something
like
that.
Yeah.
A
C
A
A
A
A
This
is
actually
an
interesting
thing
that
we've
done
here
is
we
have
a
very
clear
separation
between
the
metadata
right,
the
package
cr
and
the
package
metadata
versus
what
actually
instantiates
the
packages
right,
and
I
mean
it's
not.
You
know
nothing
mind-blowing
here,
but
the
point
here
is
that
the
metadata
really
is,
you
know
you
could
blow
it
away
and
then
you
can
re-download
it
and
it's
the
same
metadata
right
in
here
right
and
so
from
at
least
on
the
metadata
side.
A
B
Yeah,
okay,
so
all
right!
So
then
I
didn't
really
know
this.
This
is
real
interesting.
So
a
lot
of
these
api
objects
that
we
look
at
when
we
manage
packages
are
actually
being
flowed
through.
Cap
controllers,
custom,
api
server
extension
that
you've
written
and
you
split
it
up.
So
when
you
run
cap
controller,
you
got
some
okay,
cool.
A
D
B
Okay
cool,
so
when
I
look
at
we're
running
out
of
client
here,
but
if
I
was
to
go-
and
I
was
to
look
at
oopsie
I'll
get
sketchy
if
I
was
to
look
at
our
so
in
tanza,
we
have
this
add-ons
controller
manager.
We
have
a
capabilities,
controller
manager,
we
have
a
feature
gates
and
at
some
point
I
think
we
should
talk
about
how
whether
there's
some
weird
meta
space,
where
things
that
are
evolving
in
the
carvel
ecosystem
or
doing
some
or
all
of
the
things
that
we're
doing
here.
B
A
Yeah
I
can,
I
can
maybe
say
that
you
know,
at
least
from
my
understanding
the
reason
why
there
is
a
need
for
something
like
tons
of
add-ons
is
you
do
have
that
you
do
have
to
have
that
glue
between
a
cluster
definition
indicating
like
here's,
a
package
version
x
that
need
to
be
wrapped
with
a
particular.
You
know
kubernetes
version
and
that's
what
it
means
to
create
a
cluster
right
to
install
a
particular
cluster
right.
B
A
D
B
Yeah
it
does,
it
does
have
a
lot
of
tons
of
specific
logic
in
it
like
when
we
started
out.
We
were
looking
at
that
stuff
with
the
upgrades
and
all
that
stuff
and
like
that's
a
lot
of
the
glue
that
you
have
when
you're
managing
like
a
kubernetes
distribution,
you've
got
a
lot
of
stuff.
That
is
just
that
you
can't
make
more
generic
without
unless
you
just
want
to
waste
a
tremendous
amount
of
time
making
useless
abstractions
so
which
actually
is
something
that
most
programmers
like
to
do,
including
me
so
like.
B
A
Well,
I
don't
know
I
guess
I
was
more
specifically
talking
about
well,
if
you're
trying
to,
I
don't
know,
trim
up
your
cluster
in
terms
of
what
it's
actually
offering,
because
maybe
there's
no
need
for
you
to
discover
packages
right
or
something
like
that
right.
Maybe
you
know
exactly
what
you're
doing
right,
like
exact
versions,
et
cetera,
that
then
you
will
be
able
to
you
know
to
get
rid
of
it.
B
B
If
you
had
just
you
know,
if
you,
if,
if
you
had
you
know,
the
easy
one
to
mention
is
makes
a
call
to
the
api
server
and
finds
out
what
its
node's
ip
address
is.
That's
kind
of
an
interesting
one:
okay,
but
anyways
scott
next
time
you
can
next
time.
Maybe
you
can
win
a
t-shirt.
So
here's
the
people
who
won
t-shirts
so
y'all
reach
out
to
me
on
slack
and
make
sure
I
send
you
a
t-shirt.
B
A
A
B
A
Similarly,
similar
to
similar
to
the
spec
portion
of
the
app
cr,
there
is
a
almost
a
mirrored
structure
in
the
status
where
there
is
a
deploy
section.
Then
there
is
a
fetch
section
and
there
is
a
template
section,
and
so,
especially
when
app
cr
for
the
first
time
runs
where
it's
you
know,
creating
all
the
resources
right.
B
A
Then
the
name,
the
name,
the
naming-
is
a
little
interesting
right
because
we
do
have
a
cap
cli
versus
this
one
is
a
cap
controller
cli.
So
I
think
right
now
the
front
runner
is
kctrl,
but
you
know
you
never
know
who's
the
naming
cap,
ctl
yeah,
never
know
but
yeah
so
yeah.
So
so
you
can
actually
see
in
this.
Actually
what
you're,
showing
right
now
on
the
screen.
It
says,
inspect
it's
actually
using
cap
inspect
because
you
know
cap
controller
uses
cap
heavily,
so
it's
using
cap
inspect
and
showing
you.
B
A
D
A
B
D
A
D
B
A
B
B
A
Cool
there
you
go
so
if,
if
you,
if
you
notice
here
they
again,
they
match
to
what
the
app
crs
are,
because
the
app
cr
internally
just
does
cap
deploy.
So
it's
it's
layer
after
layer,
you
can.
You
know
all
the
same
things
that
you
you
may
be
doing
directly,
they're
just
being
done
by
the
higher
levels,
higher
layers
in
in
this
in
this
abstraction
three.
B
A
This
is
actually
all
it's
doing
is
listing,
so
cap
deploy
is,
is
very
minimal.
It
doesn't
really
have
any
server
side
requirements
except
being
able
to
write
a
config
map
yeah.
So
all
it's
doing
is
listing
config
maps
over
here
and
if
you
do,
cap
inspect
dash
a
on
one
of
them.
You'll
see
that
it
will
actually
try
to
find
individual
resources
associated
with
that
so
lowercase
a
and
then
give
it
a
name
of
one
of
the
from
the
above
list
and
then
throw
in
dash
and
tkg
system.
B
A
B
D
B
Okay,
let's
okay,
so
we'll
see
you
again
in
a
little
bit
all
right
thanks
everybody
for
coming
and
hanging
out.
Definitely
thanks
scott!
For
coming
to
hang
out.
You
got
to
do
a
show
with
us
sometimes
and
show
us
your
1
000
files
of
ytt
that
you
use
you
gotta,
see:
scott's
collection
of
custom,
carvel
recipes;
okay,
all
right,
we'll
see
y'all
in
a
little
bit
thanks
everybody
for
showing
up
thanks
thanks.