►
From YouTube: Carvel Community Meeting - September 28, 2022
Description
Carvel Community Meeting - September 28, 2022
We meet every 2nd and 4th Wednesday of the month at 9am PT. We'd love for you to join us live!
This week we went over a plethora of releases and what the team is working on, as well as several different discussion topics. Check out full agenda and notes here:
https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw?view#September-28-2022-Agenda
A
If
you're,
watching
this
recording,
we
encourage
you
to
come.
Join
us
live
we
meet
every
second
and
fourth
Wednesday
at
9.
00
a.m.
Pacific
time,
regardless
of
which
time
zone
you're
in.
If
you
are
here
today,
please
add
any
agenda
items
to
our
wonderful
community
meeting
agenda
available
at
all
the
finest
hack
I
o
MD
locations
nearest
you.
A
What
else
we
got
if
you
aren't
able
to
attend,
live,
that's
cool!
We
got
slack
channels
on
the
kubernetes
slack
workspace,
hashtag,
Carvel
channel.
You
can
email
us
GitHub
Twitter,
we're
around!
We
love
talking
to
you.
When
you
attend
these
meetings.
We
ask
you,
please
read
and
abide
buy
our
code
of
conduct,
which
is
in
the
agenda.
A
Additionally,
we
ask
that
you
input
your
name
and
any
organization
that
you
represent
so
that
we
can
keep
track
of
you
and
reach
out
to
you
and
learn
more
about
your
use
cases
and
your
concerns,
and
now
today's
agenda,
the
announcements,
all
right
good
done
with
the
announcements.
There's
it's
an
empty
bullet
point.
Does
anybody
have
anything
they
would
like
to
announce
any
important
announcements.
B
Yeah,
so
we
released
the
validations
feature
last
to
last
week,
and
this
is
a
blog
post
just
to
have
some
introduction
and
what
what
problems
we're
trying
to
solve
with
this
kind
of
feature.
So
we
all
you
all,
are
encouraged
to
visit
this
blog
post
I
have
I,
have
updated
the
link
in
the
chat
box,
it's
under
car,
build.day,
blog
and
ytt
validations.
So
yeah,
that's
the
validations
blog
post.
Let
us
know
what
your
thoughts
are
and
any
any
feedback
that
you
have.
B
C
A
B
A
Excellent,
thank
you
and
now
oh
yeah,
wait
I'm
supposed
to
say
you,
the
community.
We
want
you
Uncle
Carville,
wants
you
to
share
stuff,
we'll
send
you
a
t-shirt?
Maybe
you
don't
own
one
yeah,
but
you
could
we'll
send
you
a
t-shirt
if
you
sign
up
and
write
us,
a
blog
post
sit
in
your
blog
post
to
Dear
Old
Uncle,
Carvel,
okay
and
then
you
get
a
t-shirt
releases
on
to
the
releases
starring
everybody's
favorite
only
other
person
to
talk
so
far
in
this
meeting
varsha.
B
Yeah,
so
basically,
this
this
release
had
the
major
major
feature
that
we
have
been
talking
about:
data
value
schema
validations
and
earlier
it
was
released
as
an
experimental
feature.
Now
the
experimental
flag
is
removed
and
it
is
generally
available.
So
try
it
out
and
let
us
know
if
you
have
any
questions
any
feedback
on
this
schema
validations
I
have
also
included
I
mean
I.
Can
I
have
included
a
blog
post
as
well
as
there
are
some
resources
that
we
have.
We
have
preview
on
the
schema
validations.
B
A
D
So
wow
do
you
want
me
to
give
it
a
shot?
I
can
give
it
a
shot.
So
what
is
so?
Video
was
released.
I
thought
to
be
fair.
I
thought
like
this
was
already
talked
about
on
the
last
community
meeting,
but
apparently
released
after
the
community
meeting.
So
there
we
go.
We
could
not
be
talking
in
the
future,
but
apparently
vendir
was
released
version
no
31
and
it
has
like
two
things.
D
Even
though
I
wrote
just
one,
one
is
just
like
a
nice
thing,
but
from
now
on,
you
are
able
to
tell
vindir
to
cash
images
and
bundles
for
you
right
like
how
awesome
is
that
so
by
providing
a
flag,
sorry,
an
environment
variable.
You
can
now
tell
vindir
to
just
cache
me
in
this
particular
folder,
the
the
images
in
bundles.
So
there's
some
information,
there's
a
link
there
for
the
documentation
on
how
to
use
this
feature
and
I
know.
D
Y'all
are
tingling
and
saying:
oh,
my
God
is
this
gonna
go
to
cap
controller,
it
is,
and
we
already
have
a
PR
for
that
that
will
enable
this
behavior
in
cab
controller.
But
there
you
go
so
another
pretty
exciting
thing
that
comes
with
this
video
release
is
that
video
now
uses
image
package
as
a
library,
unfortunately
not
on
everything
that
it
does,
but
for
this
particular
feature
it
uses
it
as
a
library,
and
the
next
thing
that's
going
to
happen
on
on
on
vendor
is
going
to
be
to
integrate
the
rest.
D
There's
like
one
more
call
to
image
package
as
a
binary
that
still
exists,
but
I
believe
from
version
032
forward.
Vendor
will
not
require
you
to
have
image
package
installed
anymore
in
your
computer
when
you
are
using
vendor
and
I.
Think
that's
like
a
huge
thing,
because
now
it
also
it
means
that
we're
starting
to
have
some
some
API
points
that
people
can
start
looking
at
and
start
using
if
they
want
to
use
Carvel
as
a
library
and
I
spoke
too
much
already
so
back
to
you,
cap
controller.
A
We
do
get
a
lot
of
questions
about
our
our
programmatic
apis
and
integrating
with
us
as
a
library,
so
I
think
it's
a
wonderful
opportunity,
as
they
say
to
dog
food,
our
own
apis,
okay,
cat
controller
version,
0.41.2
ignore
the.2
there.
There
isn't
any
other
releases
before
it.
We
just
had
a
bumpy
release.
Process
should
I,
not
say
that
on
the
recording.
A
E
Think
of
a
brief
synopsis.
Great
the
templating
phase
and
cap
controller
now
has
access,
if
you
give
it
the
right
field,
when
you're
configuring,
your
fetch
your
template
stage,
we'll
now
have
the
cap
controller
version
that
is
currently
running
on
your
cluster
and
the
kubernetes
class
version
that
is
running
if
you're
using
an
external
cluster.
E
So
if
your
Helm
chart
has
a
templating
section
with
capabilities
and
one
of
those
capabilities
is
to
make
decisions
based
on
the
kubernetes
version
that
gets
enabled
as
part
of
this,
if
you
turn
it
on
so,
if
your
Helm
chart
uses
capabilities,
you
don't
need
to
do
any
messing
around
to
get
those
versions
in
any
other
way.
It's
not
part
of
the
default
account
capabilities.
A
We
should
have
called
it
CAD
controller
Oda,
41
capable
capybara.
You
remember,
like
all
those
Ubuntu
releases,
anyways
good
job,
thanks
Neil
and
there's
a
there's,
a
long
list
of
other
smaller,
less
interesting
features
in
cab
controller.
We
also
released
at
the
same
time
the
K
control
cap
controller
client
not
to
be
confused
with
cap.
Don't
don't
worry
it's
cool.
F
C
A
C
C
Awesome,
thank
you.
So
we
have
added
the
ability
to
like
apply
as
many
changes
as
possible.
So
even
if
one
of
the
change
errors
out
other
changes
which
are
not
dependent
on
that
change,
you
can
still
go
ahead
and
apply
them
and
there
are
two
flags
available
to
enable
this.
Behavior
one
is
for
applying
changes
and
one
is
for
the
waiting
stage
and
also
another
feature
that
we
have
been
working
on
is
to
include
the
resource
name
spaces
and
fall
back
allowed
namespaces.
C
So
if
we
don't
have
permissions
to
list
namespaces,
then
the
current
the
existing
Behavior
was
to
use
the
namespace
provided
with
hyphen
and
flag,
but
now
we
would
also
be
using
the
resource
name
spaces
which
are
saved
in
the
app
metadata
during
deploy.
Also,
there
were
some
other
improvements
like
fixing
a
few
bugs
and
back
bash
completion
and
the
app
metadata
file
output,
and
then
some
ordering
issues
for
service
accounts.
A
D
Yeah
I
think
that
part
is
just
like
more
for
the
roadmap,
like
the
road
map.
I,
don't
think
it
changed
in
the
last
couple
of
weeks,
so,
okay,
we're
just
gonna
bounce
to
the
backlog
itself,
which
kind
of
is
me
but
yeah,
but
I
think
that
I
think
the
road
map
has
been
stable
and
eventually
somewhere
in
the
future,
like
next
couple
of
them
weeks
or
a
month
or
something
like
there
might
be
some
updates
there,
but
for
the
backlog
that
we've
been
working
on
this
week,
we've
been
working
on
cap
controller.
D
To
add
the
the
caching
feature
that
we
talked
about
prior,
that
was
created
on
veneer
and
it's
going
to
be
activated
on
cap
controller.
Hopefully,
in
the
next
release
we
already
created
the
pr
for
that
and
gracefully
all
tests
fail,
which
is
always
a
good
sign
when
you
push
things
to
CI
but
I'm,
assuming
that
somewhere
in
the
next
week
or
something
we'll
be
able
to
get
this
out
and
yeah.
This
is
going
to
be
pretty
huge,
especially
because
what
is
like
the
biggest
Advantage
here,
the
biggest
Advantage
is
for.
D
If
you
have
like
a
red,
she's,
three
OCR
registry,
that
is
flaky
cap
controller
would
be
able
to
keep
reconciling
applications
that
are
already
there
and
package
installs
a
package
repositories
as
well
that
that
you
provided
without
having
to
talk
to
the
registry.
So
that's
that's
pretty
cool
feature
that
will
make
your
life
much
better.
If
you
are
an
registry
owner
maintainer,
so
that's
that
for
cap
controller
I,
don't
know
if
anybody
else
says
anything
to
add.
A
B
B
B
There
is
a
change
log
as
well
as
bug
fixes,
so
we
all
encourage
you
to
upgrade
to
this
new
version
and
then
the
blog
post
that
I
was
talking
about
the
hidden
cost
of
misconfiguration.
It
also
tells
us
about
all
the
things
that
you
need
to
get
started
with
this,
so
we
were
working
on
this
Post
Release
activities
and
blog
posts
during
this
last
week.
That's
it
from
White
City
side.
C
So
we
would
want
to
switch
to
a
new
certificate,
let's
say
after
six
weeks,
so
we
can
just
mention
an
annotation
which
would
help
us
create
either
create
a
new
version
of
the
resource
or
update
it
after
that,
duration
has
been
passed,
so
obviously
you
will
be
relying
on
tap
controller
to
do
that
periodic
deployment,
and
so
we
are
almost
I
think
done
with
this
and
then
another
I
would
say.
Epic
that
we
have
been
trying
to
pick
up
is
some
more
performance
enhancement.
So
we
did
work
on
it.
C
C
C
So
we
are
finalized
on
which
variations
we
want
to
work
on,
because
we
know
right
that
help
chart
they
they
have.
The
Liberty
is
too
much
with
respect
to
the
comments.
You
can
Define
the
comments
anyway,
so
we
have
identified
two
of
the
use
cases
which
we
will
be
handling
and
we
are
trying
to
work
towards
that
and
then,
apart
from
that,
there
is
some
cleanup,
very
small
which
we
want
to
do
so
we'll
be
focusing
on
that
as
well.
A
A
D
D
Is
just
for
for
the
community
to
be
aware,
even
though
I
did
provide
the
links
on
the
chat
just
so
everybody
know,
there's
a
proposal
there
like.
If
you
want
to
comment,
if
you'd
like
anything
to
say
about
it,
if
you
agree,
if
you
disagree,
just
go
for
that,
go
there
and
just
leave
your
two
cents,
and
eventually
the
other
leads
will
get
together
and
decide
if
I'm
worthy
of
that
position
or
not.
A
E
Yeah
no
I've
been
some
of
you
have
seen
my
face
before
I've
been
using
some
of
the
Carvel
tools,
mostly
in
in
some
just
little
personal
side,
products
projects
that
I've
been
working
on
and
I
posted
in
the
slack
Channel
about
vendir
just
a
couple
days
ago,
because
I'm
using
vendir
in
a
make
file
to
synchronize
some
external
dependencies.
That
I
don't
want
to
keep
checked
into
my
repository
just
trying
to
keep
things
tight
and
lean
and
I
noticed
that
vendir
will
write
to
its
lock
file.
E
Even
if
there's
no
changes
to
the
lock
file,
which
updates
the
timestamp,
which
tricks
make
into
thinking
that
somebody
modified
the
vendor
lock
file.
So
it
always
re-pulls
the
dependencies
every
single
time.
So
I
am
actually
in
the
middle
of
working
on
a
little
PR
that
simply
just
I'm
not
trying
to
be
too
clever,
I'm
just
simply
checking.
E
A
F
Okay,
yeah,
so
I
haven't
dealt
with
Carvel
that
much
no
yeah.
No
everything
is
going
well.
Writing
a
lot
of
packages
and
some
y2t
magic
and
having
a
good
time
with
it
so
far,
really
enjoying
the
schema
validations.
So
yeah,
the
one
main
one
that
I'm
hoping
gets
in
there
at
some
point
is
image
package
that
has
been
kind
of
pushed
off.
A
D
Here's
me
again
all
right,
so
I
decided
to
bring
this
to
the
community
meeting
because
we
were
like
it's
been.
It
has
been
like
a
month
or
something
like
that.
Then
we
cannot
get
to
a
conclusion,
asynchronously
clearly
so
I'm
trying
to
get
some
consensus
about
this,
so
we
can
create
a
PR
into
form,
so
there's
a
thread
that
I
that
I
linked
there,
but
I'm
gonna
just
give
you
like
the
Spiel
of
what
what
we're
talking
here
about
so
image
package
on
the
latest
release
of
image
package.
D
We
change
the
behavior
on
how
key
chains
are
used
on
image
package.
Previously,
image
package
was
activating
all
keychains
by
default,
and
people
are
like
looking
confused
at
me.
It's
like
keychains,
which
are
you
talking
about
so
when
you
are
running,
for
example,
like
image
package
inside
a
gke
cluster,
you
can
talk
to
their
service
to
get
a
token
and
then
to
authenticate
to
the
to
the
Google
image
registry.
D
With
that
token,
so
there's
like
some
niceness
that
can
happen
when
you're
running
inside
gke,
AKs
or
eks
right
and
those
key
chains
were
active
by
default.
So
if
you
were
in
a
registry,
if
you
are
like
running
in
a
kubernetes
cluster,
that
was
in
one
of
these
three
platforms,
image
package
would
try
to
talk
to
the
services
on
the
platform
first
and
then
go
into
like
the
the
backup,
the
backup
right
that
is
basically
just
using
your
regular
username
and
password
right
that
you
provide.
D
So
this
Behavior
was
changed
because
we'd
like
make
it
made
a
sweep
change
on
the
on
the
keychains.
That
was
something
that
was
bothering
us
for
like
a
year
now,
so
we
changed
that,
but
this
has
like
some
ramifications
on
cap
controller,
so
cap
controller,
assumed
by
default
that
all
the
keychains
were
active.
D
So
this
behavior
is
no
longer
true,
so
we
have
a
couple
of
options
on
how
to
proceed
on
cap
controller
side.
So
this
would
not
be
like
a
major
problem,
except
for
one
particular
use
case
in
that
particular
case
is,
if
you
install
openshift
on
top
of
gke
it.
The
cap
controller
rule
using
image
package,
will
try
to
talk
to
gke,
but
openshift
cut
the
connections.
So
there's
there's
a
timeout
there
that
happens
in
in
boom.
D
D
So
what
are
the
options
that
we
currently
have
for
cap
controller?
So
one
option
is
to
by
default
like
just
put
on
the
yaml,
the
activation
string
and
the
behavior
will
be
as
it
was
before.
Right
like
nothing
changes,
we
change
the
ammo
that
and
add
all
the
keychains
and
everything
is
there
right.
So
this
is
like
the
least
invasive
solution.
D
The
only
caveat
is
that
for
openshift
on
top
of
gke,
we
would
have
to
to
remove
that
flag,
as
we
were
doing
with
the
the
flag.
Previously,
the
other
option
is.
We
do
not
provide
anything
on
the
yamos
for
cap
controller,
but
the
user.
If
they
want
to
activate
the
keychains,
they
will
have
to
have
the
environment
variable
on
their
on
their
cluster,
like
on
their
deployment
of
of
Gap
controller
right.
So
these
are
the
two
options
that
I
think
are
like
the
more
like
conceptually
virtually
like
the
easiest
to
do.
D
There's
like
a
third
option
that
I'm
not
100
sure
if
it's
feasible
or
not,
because
that's
I,
don't
know
enough.
Kubernetes
shouldn't
know
this,
but
if
cap
controller
has
some
way
to
know
if
it
is
running
in
gke
or
AKs
or
or
eks
cap
controller
could
activate
the
the
kitchens
for
you
without
you
having
to
explicitly
setting
things
up
like
I,
said
the
railings
up
right,
so
that
would
be
like
an
option
that
I
think
we
can
explore
in
the
future
and
see
if
that,
that's
even
possible.
D
So
I'd
like
to
for
us
to
get
to
a
consensus
or
like
what
is
the
best
approach
for
cap
controller,
is
to
keep
things
as
they
are
right
now
and
enable
all
the
enable
all
the
keychains
by
default
or
do
not
enable
keychains
by
default,
but
tell
the
users
that
they
have.
They
need
to
enable
the
keychain
that
they
care
about.
C
A
The
truth
is,
most
users,
don't
want
to
care
about
keychains
right,
like
I,
don't
even
want
to
care
about
keychains,
so
it
feels
like
another.
One
of
these
cases
where
the
best
user
experience
is,
is
the
one
where
everything
just
works
by
default.
Even
if
you're-
and
it
sounds
like
the
only
the
pathological
case-
is
openshift
on
gke
right.
A
D
Like
that,
that's
a
problem,
the
problem
of
openshift
on
gke
is
a
problem
that
is
like.
You
have
to
remove
the
you
cannot
use
the
keychains.
Nevertheless,
like,
for
example,
if
you
are
in
in
gke
yeah
and
you're
trying
to
get
an
image
that
lives
in
an
akr,
the
keychain
will
kick
in
and
it
will
try
to
connect
and
it
will
try
to
connect
to
the
services
of
AKs
and
it's
going
to
fail
and
it's
gonna
go
and
it's
gonna
work.
D
But
there's
like
a
delay
there
right
like
because,
if
you're
trying
to
if
you're
in
a
in
a
particular,
is
and
try
to
get
images
from
other
ISS
that
Registries
that
are
in
other
ISS,
then
it
will
incur
in
a
little
bit
of
a
of
a
penalty
there.
Nothing
that
we
like
it
was
happening
before
already,
but
yeah.
So.
A
If
we
get
that
version
string
and-
and
that
like
that,
that's
something
that
I
could
imagine
plumbing
through
in
cap
controller,
I
I
think
we
could
do
that
from
from
day
one
like
or
like
I
think
we
could
do
that
out
of
the
gate.
With
this
feature
that
we
could
just
say
you
know,
specifically,
we
can
tell
when
you're
in
gke-
and
we
can
optimize
for
other
is
later,
but
because
that's
the
most
problematic
one
and
it's
the
easiest
one
to
identify
that
seems
I
don't
know.
Does
that
sound
crazy?
A
When,
when
we
first
ship
it
is
gke
so
like
we,
we
write
the
plumbing
for
cap
controller
to
be
a
little
smarter,
but
we
only
handle
with
the
first
release
of
this.
We
only
handle
the
gke
case
so
because
that's
the
one
that
breaks
anyways
and
that's
the
easiest
one
to
handle
so
that
we
say:
okay
for
the
other
ones,
you're
going
to
be
paying
a
very
small
performance
penalty
that
you've
been
paying
all
along
and
that's
fine
and
for
gke.
We
know
how
to
identify
the
we're
in
gke
and
turn
the
key
chains
off.
A
D
A
D
It's
fine
so,
like
so
I,
think
like
your
your
your
suggestion
is
to
enable
all
all
of
them
by
default
and
then
create
an
issue
to
see
if
it
is
possible
to
make
cap
control
a
little
bit
smarter
and
make
it
like
make
it
make
it
like
select
the
key
chains
yeah.
Does
that
make
sense
like
being
like
a
double
step
thing
here,.
A
It's
just
in
particular,
I
think
the
as
the
the
team.
That
means
honestly,
very
selfishly.
The
team
that
maintains
cap
controller
will
pay
a
penalty
if
we
create
a
situation
where
Cap
controller
needs
special
configuration
right
like
the
it's,
it's
less
work
for
our
users
and
for
ourselves.
If
cap
controller
works
by
default
in
every
environment,.
D
F
So
I
think
the
one
other
option
that
I've
seen
down
in
other
tools
as
well
is
I.
In
the
end,
the
release
artifacts
that
you
put
on
GitHub,
you
could
easily
have
just
different
yamls
as
the
cap
controller
releases,
with
the
have
a
eks
one,
have
a
gke
cap,
controller,
minus
gcp,
because
it's
Google
Cloud
platform
or
whatever
have
an
ocp
one
that
turns
them
all
off.
Having
AWS
one
have
an
Azure
one,
have
a
all
keychains
and
have
a
no
key
chains
like
whatever,
whatever
those
different
permutations
are.
A
That's
really
smart.
That
feels
like
a
Smart,
Middle
Ground
honestly,
because
that
that
way
and
that
way,
there's
a
file.
We
can
point
somebody
to
of
like
you.
Oh
you
want
this.
This
config,
you
want,
you
know
the
even
if
they
can't
find
it
to
themselves,
we
can
point
it
to
them,
and
rather
right
rather
than
explaining
like
oh,
you
need
to
take
out
your
soldering
iron
and
flip
the
bit
on
line
64.
D
D
F
F
You
were
talking
about
as
well
and
then
that,
but
until
that
happens,
having
a
middle
ground
of
hey
use,
your
specific
I
as
one
may
be
a
good
temporary
solution
until
that
gets
more
ironed
out
into
what
that
would
be,
and
maybe
that
could
be
like
cashed
so
like
you
would
make
a
try
when
cap
controller
starts
to
the
different
keychains.
If
one
of
them
times
out
and
fails,
it
can
be
caches.
Don't
retry!
This
basically
like
to
in
memory,
stop
the
keychain
so
yeah
the
first
time
it's
still
going
to
run
and
fail.