►
From YouTube: Carvel Community Meeting - May 26, 2022
Description
Carvel Community Meeting - May 26, 2022
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
This week we covered a preview of ytt validations - a powerful new feature in v0.41.0, the kapp v0.48.0 release, items the team is working on this week, and, a special presentation on the history of the Carvel tools. See full agenda here:
https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw#May-26-2022-Agenda
A
Hi
everyone
welcome
to
this
week's
edition
of
the
cargo
community
meeting.
Today's
date
is:
may
26
2022..
If
you
are
watching
this
recording
from
home,
we
encourage
you
to
come.
Join
us
live
we
meet
every
thursday
at
10
30
a.m.
Pacific
time
it's
a
great
way
for
you
to
come
and
meet
other
members
of
the
community.
Folks
that
are
that
are
using
the
carnival
tools,
the
maintainers
that
are
working
on
the
cardboard
tools.
If
you
have
any
questions
on
how
to
use
any
of
them,
we're
here
to
help.
A
If
you
have
any
feature
requests,
you
can
also
make
those
requests
here.
You
can
also
ask
any
questions
that
you
might
have
about
using
karvel
if
you're
unable
to
attend
these
meetings
live,
and
you
still
want
to
get
in
touch
with
us.
There
are
other
ways
you
can
find
us
in
the
karbal's
channel
in
the
kubernetes
slack
workspace,
you
can
email
us.
A
Any
of
those
channels,
please
read
and
abide
by
our
code
of
conduct,
which
is
linked
here
and
you
can
and
is
found
within
any
of
our
repos
for
those
that
are
at
the
meeting
today.
If
you
have
anything
you
wish
to
discuss
with
the
team
for
any
members
of
the
community,
please
be
sure
to
add
that
down
at
the
bottom,
the
agenda
in
the
discussion
topic
section.
A
It
also
helps
the
community
understand
more
about
how
folks
are
using
the
karmal
tools
and
helps
them
better
use.
It
use
them
as
well.
So
be
sure
to
add
that
comment
there.
We
would
love
to
hear
hear
about
how
you're,
using
the
tools
and
for
those
that
folks
that
are
attending
today,
please
make
sure
to
add
your
name
and
any
organization
that
you
are
representing
here
to
the
attendees
list.
A
A
B
B
So
not
just
are
they
the
right
type,
but
are
they
within
the
right
range
of
of
acceptable
values
which
is
really
really
cool,
so
we're
not
done
with
it,
but
what
we
wanted
to
do
is
make
it
available
for
folks
give
you
a
preview,
so
we've
set
it
up
so
that
we
actually
have
a
new
feature
in
ytt
called
experiments,
and
it's
validations
is
that
first
experiment.
So
it's
a
once.
B
We
get
our
release
out
there
and
and
we've
got
a
release
today,
we'll
talk
about
in
a
minute
that
has
both
that
experiments
feature
and
this
validations
experiment
you'll
be
able
to
kick
the
tires
on
that
turn
that
on,
if
you
want
to,
but
it's
turned
off
by
default
so
anyway,
but
the
the
blog
article
kind
of
goes
into
like
what
are
we
doing
what's
going
on
with
this?
Why
is
this
important?
What
what
it?
What
would
it
mean
to
you
and
how
to
kick
the
tires
and
give
us
feedback.
A
Okay,
so
for
those
that
aren't
aware,
we
do
have
con
weekly
and
it's
not
just
limited
to
our
maintainers-
to
come
up
with
some
content
that
they
wish
to
share
with
the
community.
We
have
a
community
content
sharing
sign
up
on
our
repo
here
and,
if
there's
anything
that
you
would
like
to
share
with
the
community
on
how
you're
using
any
of
the
cardboard
tools,
we
would
love
for
you
to
participate.
A
You
know
if
you're
doing
a
workshop
somewhere.
That's
also
something
that
we
would
like
to
to
promote
on
here,
and
if
you
want
us
to
tag
you
any
of
our
tweets,
you
can
go
ahead
and
add
your
twitter
handle
as
well
and
for
those
that
are
not
a
part
of
the
maintainers.
We
would
love
to
send
you
a
t-shirt
as
a
thank
you
so
once
you
sign
up
I'll
I'll,
be
reaching
out
and
getting
more
information
to
get
that
shirt
to
you.
A
C
We
have
included
two
bug
fixes
in
this
release
as
well.
There's
one
about
decoding
a
tommel
array
of
values
or
array
of
tables
that
was
being
decoded
in
incorrectly,
and
another
bug
fix
that
we
have
pushing
through
with
this
release
is
the
data.list
function
when
you
give
it
the
the
root.
Slash
saying
give
me
the
data
read
the
data
from
the
root.
It
was
not
reading
from
the
root
when
within
a
data
values
file,
so
that
has
been
fixed.
C
B
Yeah
there
was
one
more
thing
to
scare
this
perfect
and
then
one
more
thing
was
we
made
some
enhancements
to
the
data
values
file
flag.
So
before
it
it
received
just
a
single
file.
That's
just
plain
yeml,
but
we
got
a
request
to
be
able
to
actually
support
loading
in
a
directory
that
we
would
scan
through
call
the
the
yaml
files
from
that
and
merge
those
and
make
that
available
as
data
values,
so
that
works
while
we're
at
it.
B
We
also
support
http
urls,
just
like
you
can
with
the
dash
task
file,
flag
and
standard
in.
So
all
this,
all
the
sources
that
you
can
reach
out
to
when
you're
loading
in
ordinary
files
through
the
dash
file
flag,
are
now
available
on
the
dash
dash
data
values
file
flag
as
well
so
yeah.
It's
a
big
release.
A
D
D
So
yeah,
that's
pretty
cool.
I
probably
drop
a
link
to
the
docs
in
the
document
like
in
the
meeting
document,
so
that
anyone
who's
interested
can
have
a
look
at
that
and
the
last
one
is
pretty
minor.
So
a
lot
of
our
users
were
not
feeling
great
about
cap
leaving
config
maps
on
the
cluster
when
we
do
a
different
and
this
sort
of
makes
sure
that
it
does
not
so
yeah
yep
dimitri's
right.
It's
not
exactly
an
overlay
as
the
release
notes.
D
C
Yeah,
so
we've
picked
up
a
rather
large
story
to
add.
Excuse
me
to
add
some
built-in
validation
rules
so
right
now
the
way
that
validations
work
is.
You
have
to
write
your
own
custom
assertion
to
run
against
the
value
of
the
node
that
you're
annotating,
but
we
would
like
it
to
be
a
little
easier
out
of
the
box,
so
we
are
creating
these
built-in
functions
like
min
length
or
max
or
not
null.
C
That
will
have
some
automatically
like
pre-made
functionality,
for
you
to
easily
assert
that
a
string
isn't
empty
or
that
an
array
has
more
than
five
values
or
all
sorts
of
things,
but
yeah,
so
we're
getting
the
built-in
validation
rules
going
there,
and
then
we've
had
some
preliminary
docs
merged
in
for
the
ytt
validations.
We
can
add
that
link
in
later.
C
C
Basically,
I
think
one
secret
or
a
couple
of
secrets-
and
this
lets
you
and
kind
of
everything
would
get
copied
into
the
generated
secret
and
now,
first
of
all,
you
can
use
jsonpath
to
like
subselect
only
the
pieces
that
you
want
so
that
hence
the
template
name,
but
second
of
all,
you
can
use
almost
any
kubernetes
resource
to
populate.
So
you
can.
You
can
jsonpath
subselect
from
almost
anything
and
shovel
it
into
the
secret
that
you're
generating.
C
E
Wrong
yeah,
maybe
just
a
little
addition
is
this
feature,
would
potentially
play
very
nice,
as
was
pointed
out
by
somebody
with
cap
controllers,
app
cr,
and
you
know,
package
installs
that
really
build
on
app
cr.
So
it
would
be
interesting
to
see
kind
of
a
how
to
apply
that
in
you
know
real
environments,
and
it
sounds
like
there's
already
a
few
few
folks
who
are
eager
to
try
it
out
themselves
and
and
see
what
happens.
E
Maybe
maybe
one
thing
I'll
throw
in
is
also
it
in
a
context
of
using
this
feature
with
cap
controller.
What
it
does
interior
allow
you
to
do
is
you
know?
Let's
say
you
have
multiple
packages
installed
or
you
have
multiple
app
crs
installed
or
or
being
installed,
and
so
this
would
interior,
provide
you
a
way
to
glue
them
together.
Right
input
from
one
place
becomes
the
or
rather,
output
from
one
place
becomes
the
input
to
another
place,
and
this
is
something
that
we
had
an
issue
around
in
cap
controller
to
brainstorm.
E
C
G
Let's
roll
back
to
the
prior
point
before
that
we
started
working
on
a
cap
controller
issue.
It
is
tracking
it
as
like.
It
has
multiple
issues
that
span
multiple
tools
and
there's
like
an
overarching
issue.
There.
We
started
working
on
the
mechanism
to
allow
cap
controller
to
cache
and
do
not
have
to
communicate
so
many
times
with
the
registry
by
caching
images,
and
we
started
this
week
to
do
the
implementation
of
this
caching.
G
So
that's
that,
for
cap
controller
and
for
image
package
kind
of
finished,
the
pr
that
I
was
doing
for
some
time
now
that
previously
image
package
allowed
you
to
copy
images,
cosign
images
that
are
associated
that
are
signatures
for
particular
oci
images.
It
allows
you
to
copy
them
from
one
registry
to
another
when
you
did
image
package
copy
with
this
pr.
When
we
get
this
merged,
it
changes
the
flag,
name
and
also
changes
a
little
bit.
The
behavior.
G
So
from
this
point
on
image
package
will
allow
you
to
copy
all
the
artifacts
that
cosine
knows
about.
So
I'm
talking
about
s
bombs,
I'm
talking
about
attestations
and
signatures.
So
if
you
have
any
of
these
three
that
were
created
using
cosine
and
attached
to
an
image
using
cosine
image
package
will
be
able
to
copy
them
from
one
place
to
another.
Also,
this
includes
the
describe
command
when
you
describe
bundle
you'll
see
all
these
artifacts
being
displayed,
so
those
are
two
things
that
have
been
happening
here
this
week.
D
Yeah
so
this
week
we
primarily
sort
of
incorporated
a
lot
of
tiny
tweaks.
A
lot
of
users
brought
up
when
they
took
kc
title
out
for
an
early
spin
other
than
that
we
sort
of
made
it
easier
for
users
to
ask
the
package
installed
to
just
stop
consuming
a
secret
that
was
applied
to
it,
like
the
user,
won't
have
to
sort
of
supply,
an
empty
values
file
and
then
have
a
secret
lying
around
the
cluster
for
no
reason
other
than
that.
A
E
Boom
slides
tricked
you
there.
That
is
just
funny
enough.
I
don't
think
I
have
any
other
picture
creation
software
aside
from
the
the
the
powerpoint
or
whatever
the
google.
What
is
it
called
google
presentation
or
something
anyway?
We
have
some
friends
from
twilio
on
the
call,
and
one
thing
that
they've
asked
recently
is:
can
we
provide
a
little
bit
more
historical
kind
of
a
context
into
some
of
this
tool
creation
and
maybe
how
that
also
influences
maybe
some
of
the
future
ideas
and
whatnot?
E
E
If
one
might
say,
I've
been
working
on
various
configuration
management,
infrastructure
management,
container
management
solutions
for
a
long
time,
and
so
over
the
years.
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.
E
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.
There's
obviously
downsides
that
come
with
such
design
decisions,
and
so
it
was
kind
of
an
interesting
design
kind
of
a
journey
to
taking.
E
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.
I
think,
or
maybe
it
is
one
of
the
experimental
boxes
and
it
still
kind
of
continues
to
be
experiment.
E
This
was
actually
a
little
a
little
journey
that
I
was
taking
to
to
just
play
around
with
networking.
How
do
you
actually
bridge
the
the
network
on
the
cluster?
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.
E
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.
Like
certain
you
know
aspects
of
how
do
you
actually
converge
your
system
right
been
working
with
declarative
systems
for
some
time,
and
so
there
was
a
kind
of
a
bar
of
experience
that
I
was
reaching
seeking.
E
But
I
wasn't
really
getting
right
and
obviously
you
know
we
have
tools
like
cube,
ctl
and
few
other
tools
that
help
you
do
it,
but
I
was
trying
to
see
if
we
can
iterate
on
that
experience
and
make
that
you
know
make
that
experience
a
little
bit
more
transparent.
You
know
I've
always
had
the
challenge
trusting
tools,
especially
in
the
production
environment
at
2am.
E
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.
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.
E
E
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.
E
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.
E
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?
E
Maybe
something
that
you
have
to
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
those
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,
ytt
does
not
know
anything
about
kubernetes.
E
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
a
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.
E
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
a
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.
E
E
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.
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.
E
E
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
don't
quite
don't
quite
give
you
what
you
want.
E
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.
How
do
you
actually
build
the
image
and
throw
the
image
into
your
yaml
and
whatnot?
E
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.
You
know
docker
build
packs,
basel
all
kinds
of
tools
right.
E
We
want
to
really
help
the
user
solve
a
problem
that
they
have,
that
they
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.
E
We
have
that
shared
format,
for
what
is
this
set
of
resources
right,
and
so
you
know,
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.
E
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.
E
E
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.
Well,
you
know
what
let's,
let's
actually
store
other
types
of
content
that
you
may
use
in.
E
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.
E
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.
E
We
want
to
be
able
to
take
the
software
that
we
built
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.
E
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.
I
want
to
do
that
and
so
app
cr
concept
in
cap
controller
really
evolved
rapidly.
E
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
it
right?
So
this
concept
or
this
pipeline
that
you
might
be
running
in
ci,
you
could
also
decide
hey.
You
know
what
let
me.
E
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
app
cr
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.
E
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.
E
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.
E
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.
E
E
What
I
mean
is
the
controller
needs
to
create
the
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.
E
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.
E
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
concept
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
two
different
tools
right.
It's
actually
an
example
of
secret
gem
versus
cap
controller
that
came
up
in
the
earlier
section
was
secret.
E
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
controller
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,
just
say,
okay,
so
this
this
was
all
kind
of
where
we
are
how
we
got
here.
E
You
know
the
principles.
I
think
that
we've
tried
to
abide
by
within
within
the
tools
and
just
within
the
apis
and
concepts
right.
We
believe
they
are
maybe
universal
or
maybe
universal
is
actually
maybe
a
bad
word,
but
they
are
solid
enough
to
keep
on
building
additional
types
of
maybe
tools
or
additional
types
of
experiences
on
top,
and
so,
as
we
proceed
into
the
future
right,
we're
obviously
looking
for
how
do
we,
for
example,
polish
this
workflows
in
particular
right?
E
E
We.
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?
E
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.
H
Totally,
just
I'm
really
glad
that
you
did
this
presentation,
dimitri,
I
think
good,
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
subproblems,
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.
E
H
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
it's
unique
honestly,
like
I
think
a
lot
of
times
when
you
like,
find
popular
solutions
in
the
cloud
native
space
right
now.
H
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
deus,
which
is
no
longer
a
thing.
H
E
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
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.
H
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.
H
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.
H
A
A
Okay,
all
right!
Well,
thanks
everyone
for
joining
today's
community
meeting,
if
you're
watching
this
from
home
and
if
you
have
any
and
have
any
feedback
or
comments
regarding
anything
that
you
watch
today,
please
feel
free
to
reach
out
to
us.
We'd
love
to
hear
from
you
and
we
would
love
for
you
to
join
us
live
at
our
next
meeting.
So
again
we
meet
every
thursday
at
10
30
a.m.
Pacific
time,
so
we
hope
to
meet
you
and
see
you
soon
thanks.
Everyone.