►
From YouTube: History of Carvel Tools by Dmitriy Kalinin
Description
During our community meeting on May 26, 2022, our overall project lead, Dmitriy Kalinin, gave a history of the Carvel tools and how they came to be.
A
B
B
B
You
know
certain
ideas,
you
know
they
they
kind
of
form
and
you
know,
get
refined
polished.
Maybe
certain
ideas,
obviously
quickly
die
or
slowly
maybe
even
die
if
they
don't
make
much
sense,
and
so
a
lot
of
that
kind
of
initial
inspiration
for
carvel
came
out
of
this
type
of
experiences
right:
working
with
real
production
environments,
working
with
real
users
with
their
production
environments,
working
with
just
different
types
of
organizations
and
different
types
of
users.
B
You
know,
because
organizations
may
also
influence
how
you
build
your
software
and
how
you
actually
manage
your
software,
and
so
this
kind
of
a
I
don't
know
pile
of
factors
led
me
on
the
road
of
trying
to
think
about
this
different,
concrete
problems
that
we
were
encountering
into
various
places
right,
and
so
you
will
notice
that
carvel
is
really
fairly
decomposed.
It's
not
a
monolithic
tool.
I
worked
on
projects
that
were
built
in
a
very
monolithic
way
and
there's
definitely
benefits
to
such
tools.
B
There's
obviously
downsides
that
come
with
such
design
decisions,
and
so
it
was
kind
of
an
interesting
design
kind
of
a
journey
to
take.
And
how
do
you
actually
decompose
some
of
these
different
processes
into
smaller,
maybe
simpler,
a
little
bit
more
focused
tools
right
and
so
to
make
it
a
little
bit
shorter
here,
carvel
started
out
with,
I
believe
first
tool
was
kwt,
which
is
actually
not
in
any
way
really
mentioned
on
the
website.
B
B
How
do
you
bridge
it
to
your
local
computer,
and
this
is
something
that's
been,
for
example,
done
by
some
of
the
other
tools
out
there
there's
a
little
section
about
that
in
in
github,
but
while
playing
with
all
that
stuff,
you
know
I
was
deploying
all
kinds
of
resources
or
workloads.
Two
kubernetes,
you
know
one
of
them
was
k-native.
I
think
another
one
was
cert
manager
and
a
few
other
things
like
istio,
and
things
like
that
and
I've
come
to.
You
know
from
my
previous
experience.
B
You
know
I've
always
had
the
challenge
trusting
tools,
especially
in
the
production
environment
at
2am.
What
will
it
do,
and
so
you
know,
there's
all
kinds
of
great
influences
out
there
in
ecosystem,
like
terraform,
for
example,
where
they
really
split
this
notion
of
planning
and
applying,
and
so
the
first
tool
that
actually
popped
out
out
of
kwt.
B
This
was
actually
some
code
that
I
was
playing
around
with
in
kwt
and
it
got
extracted
out
as
its
own
project
was
cap
this
this
little
bit
over
here
this
box-
and
you
know
the
principles
behind
cap-
were
really
about.
How
do
you
actually
provide
that
confidence
to
a
user
who's
using
it
to
converge
the
system?
B
And
you
can
you
know
you
can
hopefully
hopefully
see
that
level
of
well.
You
can
hopefully
get
that
gain
that
extra
confidence
by
actually
being
presented
with
a
set
of
steps
that
will
happen
to
your
cluster
right
now.
There's
all
kinds
of
other
innovations
that
went
into
cap
as
I
was
deploying
various
types
of
workloads,
and
you
know.
Obviously
the
tool
continues
to
be.
You
know
improved
on
daily
basis
by
a
much
larger
team
than
just
me,
but
there's
definitely
some
interesting
annoyances.
B
One
might
say
that
cap
tries
to
hide
from
the
user
that
you
may
see,
for
example,
with
cube
ctl,
or
you
may
see,
with
some
of
the
other
tools
that
may
even
kind
of
hit
some
of
the
limitations
that
kubernetes
provides
right.
Maybe
a
tiny
little
example
to
make
this
concrete
might
be
some.
Some
resources
might
be
immutable
right
or
maybe
a
field
within
the
resources
immutable
right,
and
so
that
becomes
much
harder
to
automate
without
any
kind
of
manual
intervention.
B
If
you
don't
have
a
certain
level
of
configuration
at
your
fingertips,
so
that
your
tool
can
do
this
for
you
right
so
anyway,
so
cap
kind
of
popped
out
of
there,
and
so
once
cap
popped
out
of
this
tool
and
became
kind
of
its
own
thing.
You
know
I
was
really
you
know,
just
exploring
and
researching
this
other
space
like
okay
well,
but
how
does
one?
Actually,
you
know,
develop
and
iterate
on?
B
Maybe
something
that
you
have
deploy,
that
you
want
to
deploy
to
a
kubernetes
cluster
right,
and
you
know
I'll,
just
I'll
just
throw
in
here
like
ytt
and
k,
build,
for
example,
right
both
of
these
tools.
They
again
try
to
focus
on
this
idea
that
let's
try
to
solve
this,
you
know
problem.
Let's
say
of
configuration,
building
configuration
mutation
in
in
a
tool
that
only
knows
how
to
do
that
right.
So,
for
example,
ytc
does
not
know
anything
about
kubernetes.
B
It
does
not
know
anything
about.
What's
going
to
happen
with
the
output
that's
coming
in
there,
it
just
knows
how
to
deal
with
data
structures,
data
structures,
being
you
know,
maps
arrays,
you
know,
document
sets
documents
etc.
Right-
and
it
just
happens
that
I
was
also
obviously
in
the
kubernetes
ecosystem,
so
yaml
is,
is
one
of
the
kind
of
central
points
to
it,
because
everybody's
working
with
yaml
now,
of
course,
influences
of
the
design
influences
in
ytt
came
again
from
previous
experiences
of
bumping
around
the
configuration
gradient.
B
You
know
on
one
side,
you
have
templating
and
some
folks
are
all
into
templating
and
it
solves
lots
of
their
problems
and
then,
of
course,
on
the
other
side,
you
end
up
with
kind
of
about
patching
mechanisms
right
or
overlaying
tools,
as
some
folks
call
it,
and
so
there
is
that
gradient
right,
and
you
know
you
definitely
find
tools
that
either
go
into
one
direction
or
go
into
another
direction.
In
my
opinion,
they're
really
the
the
mix,
the
the
the
perfect
tool
is
somewhere.
B
But
yet,
at
the
same
time
you
know
it's
not
a
it's,
not
maybe
it
it.
It
doesn't
push
you
towards.
Maybe
a
very
opinionated
way
of
doing
it
right,
because
you
can
solve
a
lot
of
problems.
If,
if
you
get
to
have
all
your
stakeholders
agree
on
on
a
particular
pattern
right,
but
if
you
are
really
working
with
all
kinds
of
different
configuration
coming
in
from
any
you
know
anywhere,
you
really
need
that
flexibility
and
so
templating
overlaying
kind
of
bringing
it
together
in
one
tool
allowing
programmatic
access
to
it.
B
I,
I
think
kind
of
hits
that
sweet
spot
and,
of
course
you
know
as
a
as
I
already
mentioned
for
cap,
you
know
we're
we're
continuing
to
iterate
on
ytt
continuing
to
elevate
some
of
the
ideas
there.
You
know
every
week
or
so
when
john
and
I,
for
example,
have
our
chats.
You
know,
there's
always
some
more
futuristic
things
that
we
could
be
doing.
It's
not
quite
you
know
it's
not
quite
on
concretely
concretely
figured
out,
but
there's
cool
ideas
about
static
analysis
around
the
configuration.
B
How
do
we,
you
know,
maybe
visualize
the
configuration
better
to
understand
how
things
are
happening
and
whatnot,
and
so
so
that
was
that
that
was
that
was
kind
of
how
ytt
got
born
it's.
It's
really
this
this
this
pain
with
the
existing
tools
that
either
shift
to
one
side
of
the
gradient
or
shift
to
another
side
of
the
gradient,
and
just
don't
quite
don't
quite
give
you
what
you
want.
B
Over
here
is
actually
build,
turned
out
to
be,
in
my
opinion,
that
little
thing
that
just
kind
of
fell
out
as
an
semi
obvious
thing,
at
least
at
least
in
the
workflows
that
I
I
tend
to
use.
So
we
have
cap,
that's
doing
the
converging,
we
have
ytt.
That's
doing
you
know
configuration
mingling
if
you
just
run
this
pipeline
right
on
your
local
machine,
and
you
know
you
get
your
stuff
deployed,
the
ultimate
question
becomes
well.
B
How
do
you
actually
build
the
image
and
throw
the
image
into
your
yaml
and
whatnot?
And
of
course
you
can
try
to
build
something
custom
with
some
shell
scripts,
and
you
know
ytt,
maybe
inserting
image,
references
and
whatnot,
but
that
that
just
doesn't
quite
scale,
because
then
you
have
to
do
this
every
single
time
for
every
single
project
and
it's
just
different,
so
k
build
kind
of
comes
in
and
says
you
know
what
we
we
know
that
there's
plenty
of
great
tools
to
build
images.
B
You
know
docker
build
packs,
basel
all
kinds
of
tools
right.
How
do
we
actually
take
those
tools
and
just
easily
integrate
that
into
a
flow
that
you
know?
You
might
have
over
here
right
and
by
the
way,
as
as
an
example
here,
because
because
these
tools
are
really
just
focusing
on
their
own
single
kind
of
a
purpose
right,
this
kind
of
workflows
right,
the
idea
was
always
we
don't
want
to
solve,
or
we
don't
want
to
force
users
to
change
their
entire
workflows
right.
B
We
want
to
really
help
the
user
solve
a
problem
that
they
have
that
they're
coming
to
us
to
say,
hey
look,
I
got
this
problem
to
maybe
deploy
or
got
this
problem
to
build
images,
or
maybe
it's
something
else
right
so
tool
specifically
designed
to
solve
a
particular
problem
and
then
continue
on
with
your
rest
of
the
flow
that
you
may
already
have.
Or
you
know,
of
course
you
can.
B
We
have
that
shared
format,
for
what
is
this
set
of
resources
right,
and
so
you
know,
the
the
interface
between
these
tools
is
is
all
the
same,
and
of
course
you
know
there
could
be
other
ecosystem
tools
out
there,
that
you
know
you
can't
use
the
same
interface,
so
kind
of
a
plug-and-play
there
and
so
yeah,
so
that
was
kind
of
just
the
the
the
basic
kind
of
a
thinking
around
like
okay.
We
got
all
these
tools
that
that
kind
of
work
together
well
and
they
also
work
with
other
tools.
B
Well,
and
so
then,
you
know
kind
of
a
carvel
project
started
iterating
into
some
of
the
other
interesting
problems
that
we
have
faced
historically
right.
So
we
have
image
package.
For
example,
I
kind
of
threw
this
picture
in
maybe
it's
a
little
bit
of
a
funny,
looking
picture
that
image
package
just
comes
before
here,
but
what
I'm
trying
to
showcase
here
right
is
that
maybe
in
your
one
type
of
workflow
right,
you're,
really
picking
up
this
configuration
from
your
git
repository
like
you
get
cloned
and
you
run
the
steps,
but
a
lot
of
times.
B
You
also
want
to
capture
your
you
know
workload
in
some
kind
of
in
immutable
way
right
and
look
at
that.
They
actually
have
registries.
They
know
how
to
hold
content.
I
think
I
want
to
say
image
package
in
my
opinion,
kind
of
came
out
at
the
right
time,
where
it
hasn't
kind
of
a
kicked
in
for
all
kinds
of
other
users
that
hey
it's
actually
a
really
interesting
idea
to
store
content
in
registries,
and
so
I
think,
image,
package
kind
of
came
at
the
right
time
and
said:
okay.
B
Well,
you
know
what
let's,
let's
actually
store
other
types
of
content
that
you
may
use
in.
You
know
in
in
various
other
places
right,
and
so
we
have
image
package
over
here
as
an
example
being
used
to
store
kubernetes
configuration
right,
and
so
of
course,
once
you
fetch
that
configuration,
then
you
end
up.
You
know
maybe
going
through
this
flow.
Maybe
you
end
up,
I
don't
know
storing
your
helm
chart
inside
the
image
package
inside
the
registry.
B
So
this
is
a
little
picture
of
just
showing,
like
you,
have
your
bundle,
that's
built
by
image
package
and
of
course
you
have
your
content,
but
then
you
have
all
these
images
and
whatever
right
that
you
you
reference
right,
so
you
can
kind
of
build
hierarchies
and
you
can
kind
of
build
your
software
graph,
and
this,
of
course,
becomes
really
handy.
If
you
actually
need
to
move
that
graph,
maybe
to
a
different
registry.
B
We
want
to
be
able
to
take
the
software
that
we
build
locally
within
vmware
and
then
bring
that
out
to
our
users
right,
and
so
this
is
a
kind
of
a
a
typical
use
case
that
image
package
could
really
be
used
for
all
right,
I'll
jump
to
the
next
one
over
here,
real
quick,
and
so
you
know
stepping
back
from
the
image
package.
You
know
we
have
those.
We
have
this
kind
of
a
little
pipeline
that
you
might
be
running
locally.
You
might
be
running
somewhere
in
your
ci
right.
B
There's
nothing
wrong
with
running
this
exact
same
thing
in
your
ci
right.
The
tools
are
designed
to
be
run
in
any
type
of
environment,
but
what,
if
you
actually
run
the
same
tools
in
in
your
kubernetes
cluster
right?
And
so
this
is
where
idea
of
cap
controller
kind
of
came
about,
and
you
know
it
evolved
with
the
same
tools
it
actually
evolved
by
a
lot
of
the
feedback
from
from
our
users
around
like
hey.
I
want
to
do
this.
B
I
want
to
do
that
and
so
app
cr
concept
in
cap
controller
really
evolved
rapidly.
Just
to
get
to
this
stage,
where
you're
able
to
flexibly
combine
these
ideas
of
where
to
fetch
the
data
from
where
to
how
to
template
the
data,
and
then
you
know
how
do
you
actually
deploy
right?
So
this
concept
or
this
pipeline
that
you
might
be
running
in
ci,
you
could
also
decide
hey.
You
know
what
let
me.
B
Let
me
have
a
first
class
api
for
that
in
kubernetes
cluster,
and
this
is
a
little
picture
of
kind
of
a
you
know
forget
about
the
stop
part,
but
appcr
really
just
focuses
on
this
three
three
pieces
right:
fetch
template
deploy
to
represent
an
application
of
workload
running
on
your
cluster
right,
and
so
once
we
had
that
kind
of
idea
around
like
okay.
Well,
we
have
this
app
crs
right.
How
do
you,
actually,
you
know,
take
advantage
of
them?
Well,
you
could
obviously
do
gear
ups
on
your
cluster
with
your
app
crs
right.
B
You
can
configure
it
to
pull.
You
know,
maybe
from
git,
maybe
from
http
endpoint.
Maybe
from
I
don't
know,
image
package
bundle
from
anywhere
right
and
you
can
actually
do
all
kinds
of
massaging
of
the
kubernetes
configuration
with
ytt
becomes
again
really
powerful
because
you
can
really
take
whatever
somebody
else.
B
It
seemed
to
be
a
really
good
idea
right,
and
so
we
kept
on
kept
on
exploring
it
kept
on
kept
on
adding
the
features
to
kind
of
support,
these
different
use
cases
and
actually
a
bit
a
bit
later
after
that
kind
of
ideas
came
around
well.
Okay,
you
have
this
app
cr,
that's
great,
I
can,
I
can,
you
know,
put
an
app
cr
into
some
place
and
then
I
can
give
it
to
somebody
and
they
can
also,
I
guess,
install
the
same
type
of
content
into
their
cluster
right.
B
Is
that
really
we
just
want
to
be
able
to
assign
some
name
and
a
version
right
and
let
the
user
reference
that
and
not
really
worry
about
the
underlying
implementation
of
where
the
thing
is
coming
from
how
it's
configured
you
know
and
maybe
how
it's
deployed
right,
and
so
that
was
the
kind
of
idea
of
okay.
Well,
we
have
this
building
block
app
cr,
let's,
let's,
let's
build
the
package
install
on
top
of
that
right.
We
want
all
that
functionality
for
free
right,
it's
the
same
kind
of
model
as
the
pod
and
a
deployment
right.
B
B
What
I
mean
is
the
controller
needs
to
create
a
cluster,
and
so
the
package,
cr
idea,
is
really
just
hey,
attach
a
bunch
of
metadata
to
an
app
cr
template
and
that's
what's
going
to
get
created
now
again,
once
you
get
to
this
layer
suddenly
this
again
naturally
starts
falling
out
as
a
next
step.
Okay!
Well,
I
have
all
this
bunch
of
package
crs.
How
do
I
actually
give
it
to
the
users
right
and
so
again
the
next
idea
was
okay.
B
Well,
we'll
just
put
them
in
a
package
repository
whatever
that
may
be,
and
so
in
this
in
this
picture
I
guess
it
says
package
repository.
It
could
be
an
oci
bundle
and
that's,
for
example,
my
favorite
option,
but
there's
no
reason
why
that
couldn't
be
inside
a
git
repository
or
some
other
place
and
so
yeah.
B
So
so
this
was
kind
of
the
general
transition
or
not
transition,
but
evolution
of
these
tools
and
all
of
this
kind
of
of
this
concepts
right
the
principles
that
we're
still
you
know
very
much
sticking
to
is
that,
ideally,
you
know
the
tools
are
single
purpose.
They
know
how
to
do
something
well
and
they
delegate
the
the
other
type
of
functionality
that
you
may
find
to
different
tools
right.
It's
actually
an
example
of
secret
gem
versus
cap
controller
that
came
up
in
the
earlier
section
was
secret.
B
Gen
is
all
about
dealing
with
secrets
right,
generating
some
secrets,
or
maybe
actually
one
of
the
features.
There
is
also
sharing
the
secrets
between
the
name
spaces
right.
So
cap
control,
it
doesn't
really
have
a
any
special
notion
of
a
secret,
but
secret
gen
is
all
about
secrets,
and
so
there's
there's
all
kinds
of
an
interesting
kind
of
a
division
of
labor.
You
can
imagine
between
these
two
controllers,
so
anyway,
I'll
I'll
I'll,
just
say,
okay,
so
this
this
was
all
kind
of
where
we
are
how
we
got
here.
B
B
B
We
absolutely
want
our
greater
you
know,
kubernetes
ecosystem,
to
embrace
some
of
these
apis
and
tools,
as,
as
you
know,
tools
that
anybody
can
expect
to
use
right
so,
for
example,
a
lot
of
the
open
source
projects
we
would
love
if
they
would
be
providing
packages
for
their
software
from
their
repositories
and
we're
obviously
working
towards
making
the
package
authoring
experience
easier
and
more
just
accessible
to
everybody.
We.
B
We
also
hope
that,
even
aside
from
the
packaging
side
of
it,
a
lot
of
these
tools
are
really
used
in
this
different
context
for
the
in-house
application
development
right.
How
do
you
actually,
you
know,
configure
the
multi-cluster
systems
multi-environment
systems
right,
so
the
the
tools
and
the
the
features
are
there
now
our
next
steps
are
really
try
to
produce
guides
content
around.
How
do
we
actually?
B
How
do
we
actually
make
this
make?
Adopting
of
these
tools
may
be
as
as
easy
as
as
one
would
hope
right
and
that
that
obviously,
is
a
is
a
lot
of
work
in
itself,
so
yeah
I'll
I'll
just
maybe
pause.
I
know
I've
been
rambling
for
a
long
time,
maybe
a
little
bit
all
over
the
place.
Any
I
don't
know
any
comments
from
from
anybody
or
anything.
C
Totally,
just
I'm
really
glad
that
you
did
this
presentation,
dimitri,
I
think,
like
showing
kind
of
where
the
project
comes
from.
I
think
the
really
special
thing
about
the
carville
project
is
that,
like
you
get
this
really
nice
like
individual
factoring
of
sub
problems,
it's
like
so
good
for
users.
It
doesn't
force
opinions
on
people
and,
like
we've,
ended
up
with
these
very
sharp
targeted,
like
tools
for
problems
that
are
like
so
common
for
the
the
practitioner
of
container
native
workloads,
and
I'm
just
like.
B
C
Yeah,
we
definitely
we.
I
don't
know
if
you've
given
like
these.
This
like
talk
like
elsewhere,
but
definitely
I
would
be
happy
to
like
signal
boost
this
message.
You
know
we
should.
We
should
like
propose
this
presentation
like
two
places
and
like
have
people
talk
about
it
because
like
showing
where
these
things
come
from,
it's
unique
honestly,
like
I
think,
a
lot
of
times
when
you
like,
find
popular
solutions
in
the
cloud
native
space
right
now.
C
It's
like
the
ecosystem
is
so
early
and
like
the
problems
that
people
are
running
into,
are
so
broad
that
many
of
the
tools
that
solve
these
problems
they're
either
only
like
a
single
project,
solving
a
single
sub
problem-
or
you
have
very
opinionated
tool,
sets
right
like
if
you
look
at
helm,
which
is
very
early
on
right
before
crds
were
even
a
thing
before
formal
api
extensions.
Like
really
thing
helm
was
already
coming
out
of
dais,
which
is
no
longer
a
thing.
It's
probably
microsoft.
C
Oh,
I
only
want
this
piece
right,
or
I
only
want
that
part
like
now
we're
getting
away
from
specific
opinions
or
even
getting
away
from
focusing
hyper
like
hyper,
focusing
on
kubernetes,
specifically
like
you
can
use
k,
build
like
docker
swarm
and,
like
that's
just,
I
think
so.
Special
like
that's
unique.
You
don't
see
that
elsewhere.
In
the
ecosystem,
so
we
we
should
be
talking
about
this
more.
You
know
we
should.
We
should
definitely
keep
sharing
the
message.
B
Yeah-
and
I
think
there
is
definitely
you
know
it-
it's
a
it's
an
opportunity
to
capitalize
on
on
this
decouplement
of
these
different
problems
and
different
tools,
yeah,
but
but
it's
also
a
messaging
challenge
on
its
own
right.
The
the
the
type
of
messaging
that
one
may
may
find
easier
to
digest
for
a
monolithic
project
is
potentially
doesn't
just
you
know,
apply
easily
for
a
project,
that's
composed
of
the
smaller
units
and
whatnot.
But
that's
I
don't
know,
maybe
that's
also
true
for
just
composed
or
decomposed
software
as
well.
C
We
we're
learning
some
of
these
things,
even
in
the
flux
project,
which
has
been
running
for
a
similar
amount
of
time
and
like
the
original
flux.
V1
was
a
monolithic
solution
with
some
pretty
strong
opinions,
but
it
was
extensible
in
some
really
hacky
ways
and
like
as
the
user
base
grew,
you
know
we
like
outgrew,
that
design
and
like
needed
to
factor
things
into
individual
components
and
now
flex
v2
is
a
healthier,
more
individual
component,
extensible
ecosystem.
C
It's
one
of
the
reasons
why,
as
like
vmware,
we
have
other
projects
that
are
actually
gluing
like
flux
and
cargo.
Stuff
together
is
because
they
kind
of
both
can
compose
since
they're,
so
individual
or
like
so
well
factored,
but
still
with
flux
like
it
has
a
completely
different
presentation
and
there's
still
like
you
know,
flex
bootstrap
flex
install
is
still
like
pull
all
of
these
components
together
and
give
somebody
you
know
kind
of
a
default
starting
point
and
that's
sort
of
different
and
kind
of
speaks
to
that
challenge.