►
From YouTube: Carvel Community Meeting - September 23, 2021
Description
Carvel Community Meeting - September 23, 2021
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
Full agenda and notes can be found here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw?view#September-23-2021-Agenda
A
A
A
A
A
Okay,
next
up,
we
have
announcements,
just
a
reminder:
we
do
have
a
keynote
at
kubecon
cloud
native,
con
north
america
this
year,
it's
a
five
minute
keynote
short
and
sweet
you're
welcome
to
attend
either
virtually
or
in
person.
We
have
blog
posts
that
we
also
posted
on
the
website.
That
goes
a
little
bit
more
in
detail
of
what
to
expect
for
this
keynote
and
a
little
bit
more
information
on
carville,
if
you're
new
to
carville,
as
well
as
how
to
attend
kubecon.
A
B
Yeah,
I
can
go
over
it,
so
018
0
introduces
yeah
another
way
to
authenticate
with
image
package,
specifically
if
you're
running
it
within
the
context
of
an
iso,
a
vm
or
even
you
know,
kubernetes
offering
on
ios,
and
you
have
you
have
a
setup
to
inject
your
service
account
or
your
credentials
through.
That
is
image.
B
But
now
you
can
provide
the
scheme
so
http
colon,
slash,
hostname,
with
the
port,
with
v1
v2
being
optional
and
now
supports
globbing
as
well,
and
then
18
and
then
19
is
just
yeah
bug
fixes.
Essentially,
when
we
introduced
the
is
it
kind
of
broke,
the
ordering
of
docker
config
over
cli
flags,
and
it
also
didn't
know
how
to
read
the
cred
store.
So
those
two
things
have
been
fixed.
C
Yeah
this
one
we've
been
kind
of
eagerly
awaiting
so
there's
a
couple
of
headlines
here.
Probably
at
the
top
is
the
inclusion
of
now
bazel
you
can
use
bazel
to
produce
your
containers.
You
can
integrate
with
cable,
to
direct
bazel,
to
do
that.
It's
very
exciting,
appreciate,
charlie
for
and
crew,
for,
contributing
that
and
then
also
there's
a
breaking
change.
To
note.
Don't
worry
it's
just
in
the
sections
that
that
were
annotations
on
any
resources.
C
It's
was
called
metas,
but
now
we're
using
the
term
we
feel
is
a
little
bit
more
telling
it's
called
origins
it's
describing
from
where
your
images
are
coming
from.
It's
not
a
guarantee,
it's
not
like
provenance,
but
it
is
definitely
a
record
as
best
as
the
tool
knows
where
images
came
from
and
then
that
leads
to
the
other
marquee
bit,
which
is
now.
C
We
ensure
that
that
that
information
is
included
in
your
image
package,
log
files
when
they're,
including
the
image
package,
lock
files,
we
make
sure
that
that
propagates
into
your
deployment,
so
the
resources
running
on
your
kubernetes
cluster,
now
enjoy
having
that
origin
annotation.
The
images
annotation
has
the
origin
information
in
it.
That'll
often
include
like
the
tag
if
it's
from
from
a
registry
or
even
the
git
shop,
it
was
built
from
source
from
a
git
repo,
so
very
excited
about
0.31
a
reminder.
C
D
A
A
D
D
I
don't
know
if
there's
necessarily
a
theme
to
all
of
those
prioritize
issues,
they're
just
kind
of
like
general
improvements
to
current
functionality,
as
well
as
addressing
some
bugs
regarding
cap
as
as
called
out
here,
the
cluster
fulfilled
resources
is,
is
a
next
feature.
That's
been
focused
on
for
the
next
release,
so
that's
an
exciting
one.
I
know
that
that's
one
that
we've
kind
of
had
an
eye
on
for
for
some
time
other
than
that
the
ytt
schema
as
open
api
schema
work
is
an
implementation
right
now.
D
I
don't
know
if,
if
there's
any
any
like
thing,
that's
that's
noteworthy
there
other
than
like
we
we're
kind
of
chugging
along
a
way
there
and
then
cap
controller
dependency
management
upgrade
scenarios.
We
are
about
to
kick
off
the
proposal
process
there
so
be
on
the
lookout,
as
we
you
know,
intend
to
draft
that
in
public,
and
if
you
have
any
thoughts
on
this,
we
certainly
welcome
your
contributions.
A
A
E
Okay,
yeah
sure
I
can
talk
about
that.
So
I
added
an
issue
for
image
package.
I,
as
you
can
see
in
the
title,
push
can
optionally
add
a
unique
tag.
Maybe
optionally
is.
It
could
just
always
add
a
unique
tag
as
dimitri
suggested,
but
basically
situation
that's
occurring
is
you
know
we
see
our
registries
can
perform
a
garbage
collection
process
where
any
untagged
image
is
basically
cleaned
up
and
deleted.
E
So
this
could
this
has
actually
bitten
us
recently.
You
know.
Basically,
we
would
like
push
a
package
out
and
tag
it
like
version
one
two
three
and
then
that
package
gets
linked.
Actually,
if
you
scroll
down
just
a
little
bit
in
here,
you'll
yeah,
there
we
go
if
we
have
a
nice
little
diagram
like
showing
like
what's
going
on,
so
we
create
a
package
and
it's
got
a
shot
and
then
we
reference
that
package
in
a
package
repo
and
then
it's
like.
E
Oh,
we
have
to
like
make
a
change
to
that
package.
So
we
we
change
the
package,
push
a
new
one,
and
then
we
re,
we
reuse
the
same
tag
like
version
one
two
three,
so
it
gets
moved
from
the
old
shot
to
the
new
shot.
But
our
package
repo
is
still
referencing
the
the
sha
from
the
original
package.
Well,
then,
garbage
collection
comes
along
and
cleans
up
that
original
shot
and,
and
then
anyone
that's
still
using
that
original
or
that's
using
our
our
package
repo.
B
Yeah
I
haven't
had
time
to
triage
it,
but
it
it
does
make
sense.
I
mean
when
we
do
a
copy,
we
already
have
a
tag
created
and
we
have
a
special
kind
of
suffix
that
goes
with
it
and
it
helps
like
it
helps
with
replication
logic
that
you
know.
Other
registries,
like
hybrid
depend
on
actually
yeah
this.
This
one
yeah
the
dot
image
package
with
dimitri
commented
so
always
doing
it
maybe
doing
something
similar.
B
C
E
D
Yes,
so
I
mainly
just
wanted
to
create
some
space
to
discuss
the
issue.
Triage
process
go
over.
Some
proposed
label
updates,
but
then
also
just
see
if
people
have
general
questions
around
this,
so
you
know
feel
free
to
drop.
If
this
is
not
interesting
to
you,
but
that's
that's
kind
of
what
I
wanted
to
discuss
here.
So
let
me
open
this
issue
triage
process,
so
this
is
captured
here
in
the
carville
repo
under
the
processes
directory
and
at
a
high
level
explains.
D
B
D
Got
a
couple
thumbs
up
some
other
all
right
three
thumbs
up,
so
maybe
I'll
just
try
to
breeze
through
some
of
these
things
so
generally
triaging
is,
is
the
way
that
we're
trying
to
review,
respond
and
organize
our
github
issues
and
pull
requests
at
a
high
level.
We
try
to
you
know
ensure
that
we
are
engaging
with
folks
that
are
creating
issues,
as
we
certainly
do
appreciate.
D
So
you
know
at
a
first
level
it
is
probably
just
like
understanding
you
know,
what's
being
asked
and
depending
on
what
that
is
just
labeling
it
appropriately
like
what
kind
of
type
of
of
issue
kind
of
issue.
This
is
like
a
bug
enhancement
as
well
as
trying
to
assign
a
priority
level
and
being
able
to
assign
the
priority
level.
I
think
you
know
is,
is
something
that
issue
tree.
Auditors
may
not
be
comfortable
with
immediately,
but
I
do
want
to
make
more
of
this
capability.
D
Like
spread
throughout
issue
triagers,
and
and
also
have
these
prioritization
discussions
just
generally
in
the
open
like
on
these
issues,
so
that
people
can
learn
more
about
like
how
we're
thinking
about
these
and
and
why
we're
making
the
prioritization
decisions
that
we
are.
So
I
guess
why
is
this
important
like
we?
We
want
to
promote
a
responsive
and
inclusive
community.
D
D
All
right,
so
I'm
going
to
drop
down
to
the
how
section
and
how
is
is
generally
kind
of
well.
Three
primary
steps
are
called
out
here,
so
the
first
one
is
responding
to
newly
created
issues
and
prs,
and
this
one's
a
bit
straightforward.
It's
it's.
You
know
responding
to
anything
new
that
comes
in
like
one
to
acknowledge
folks
for
their
contributions,
but
then
two
to
figure
out,
like
you
know
what
what
should
we
be
doing?
How
are
we
going
to
respond
to
this?
D
But,
but
generally
you
know,
there's
there's
a
couple
of
issues
that
are
called
out
here
of
moving
the
label
from
carville
triage
to
carvel
accepted,
applying
the
good
first
issue
label
one
and
when
appropriate,
but
yeah.
These
are
just
just
things
to
to
kind
of
check
the
box
through,
as
you
are
triaging
these
with
a
bug.
I
think
that
the
primary
difference
here
is
being
able
to
to
replicate
the
issue,
and
you
know,
as
as
long
as
we're
able
to
replicate
it,
then
it
kind
of
follows.
D
D
And
then
the
the
kind
of
final
step
here
is
defining
the
priority,
which
understandably,
can
can
be
a
challenging
thing,
especially
for
folks
that
haven't
done
a
lot
of
this.
Yet
so
we
tried
to
provide
descriptions
and
some
some
examples,
certainly
open
to
to
feedback
or
contributions
of
of
ways
that
we
can
clear
up
these
explanations.
But
we
have
these
five
categories
at
a
high
level.
There's
the
critical
urgent.
D
You
know
things
that
we
want
to
tackle
very
quickly
things
that
we're
probably
even
going
to
you,
know,
potentially
drop
what
we're
working
on
and
have
someone
assigned
to
it
important
soon.
I
kind
of
viewed
that
as
more
as
like.
What's
what's
up
next
in
our
prioritized
backlog,
it
doesn't
have
to
necessarily
be
be
dropped,
but
things
that
we're
probably
working
towards
in
the
next
release,
important
long
term.
D
You
know
that's
just
a
little
bit
further
out
so
things
that
we
are
planning
to
prioritize
for
the
the
maintainers
team
and
things
that
we
will
likely
get
to
say.
I
don't
know
within
a
quarter
or
two
on
prioritized
backlog.
These
are
ones
that
are
not
currently
planned
for
the
maintainers
team.
To
work
on,
but
we
do
see
the
value
in
having
these
things,
so
these
are
actually
like
really
good
things
for
you
know.
D
If,
if
someone
was
to
submit
an
issue
and
it
it
gets
the
unprioritized
backlog,
you
know
if,
if
you
question
the
decisions
that
are
made,
please
feel
free
to
have
that
conversation
in
the
github
issue,
but
generally
what
this
means
is
like
we.
We
agree
that
this
is
useful.
It's
just
not
something
that
is
is
going
to
be
prioritized
immediately.
So
these
these
are
things
where
we
would
welcome
contributions
on
and
then
the
last
one
is
awaiting
more
evidence.
D
So
this
is
one
where
kind
of
like
label
says
we're
we're
not
yet
sure
if,
if
this
is
something
we
want
to
bring
into
the
tool
or
we
don't
yet
know
enough
about
the
request,
so
it's
it's
more
of
a
placeholder,
but
you
know
it's
it's
a
bit
of
a
it's,
not
quite
a
commitment
that
it's
something
that
we
would
accept,
even
if
a
contribution
was
was
given,
so
I'll
pause
there
and
see.
If
anyone
has
any.
I
don't
know
general
questions
about
this
process
or
thoughts,
feedback.
D
Cool
cool,
I'm
taking
that
as
it's
it's
clear
and
people
understand
and
then
yeah.
It
looks
like
about
a
month
ago
started
thinking
about
kind
of
like
our
next
iteration
of
just
like
making
label
updates
to
to
make
these
issues
just
like
easier
to
filter
and
sort
and
track,
and
I
kind
of
have
like
a
another
like
aspiration
of
like
building
out
more
specific,
like
dashboards,
to
make
these
things
even
even
easier
to
track
outside
of
zenhub.
D
So
this
is
specifically
talking
about
kind
and
right
now
we
just
haven't.
We
don't
have
this
prefix.
So
with
things
like
enhancement,
bug
support,
I
believe,
already
exist.
Ops
is
a
new
one,
and
this
is
more
to
capture.
Like
the
engineer
focused,
maybe
non,
you
know
product
value
type
of
work,
so
that's
one
that
we
wanted
to
introduce
and
also
this.
This
is
a
bit
more
consolidated
because
we
also
proposed
that
we
would
include
the
dependency
bumps
under
enhancement,
whereas
currently
we
do
have
a
separate
dependency
label.
D
John,
and
I
had
some
good
discussions
about
potentially
talking
about
state
of
an
issue
and
I
think,
there's
a
lot
more
conversation
that
can
be
had
there.
So
we
just
kind
of
tabled
that
for
right
now
and
trying
to
lean
more
so
on,
like
the
these
zen
hub,
like
lanes,
columns
and
such,
but
but
that
is
definitely
an
interesting
conversation.
I'd
I'd
like
to
continue
in
the
future,
but
these
feel
like
a
little
less
controversial
controversial
but
wanted
to
see
if
anyone
had
feedback
on
any
of
any
of
this.
C
B
When
I
was
reading
about
the
when
I
was
hearing
you
talk
about
the
kind
label,
for
example,
kind
enhancement,
kind
bug
I
was
thinking.
This
is
something
we
apply
to
github
issues,
but
then
seeing
that
we're
thinking
about
including
this
to
depend
upon
bombs,
which
are
prs
wondering
what
the
value
of
assigning
these
labels
to
prs
are.
D
I
think,
like
one
another
aspiration
of
mine
is
to
have,
I
guess,
a
better
idea
of
like
the
investments
we're
making
as
a
team
and
like
the
work
that
comes
through.
So
we
can
kind
of
see
like
what
are
the
different
buckets
of
work,
and
I
guess
that's
where
I
don't
know
accepted.
Pr's
enhancements
would
take
up
this
particular
you
know
section
of
the
pie
versus
maybe
ops
work,
so
I
guess
that's
where
it's
still
work
that
is
in
the
pipeline,
but
and
work
that
we
have
done.
B
C
B
Yeah,
I'm
just
wondering
because,
like
it
just
takes
time
to
like
apply
the
right
label
to
the
pr's,
so
I'm
just
wondering
what
what
do
we
get
out
of
doing
that
by
you
know
doing
a
bit
of
additional
work,
updating
pls
with
the
right
label,
so
when
it
depend,
apart
from
depending
upon
ps,
come
in
updating
it
with
the
right
label,
I'm
wondering
like.
Why
am
I
doing
that?
And
it's
potentially
to
have
a
better
more
insight
about
where
we're
spending
our
work
from
an
engineering
perspective.
D
D
But
but
yeah
certainly
any
ways
we
can
automate
all.
This
would
be
great
if
you're
interested
in
seeing
how,
like
I
don't
know
like
kubernetes
the
way
that
they
do
all
their
triaging,
they
have
bots
that
are
very
well
like
customized
for
their
entire
process
and
I
think
it's
very
heavy
weight
compared
to
what
we
need,
but
that's
just
like
a
glimpse
into
like
ways
that
we
could
automate
bits
and
pieces
of
this.
If
we,
if
we
want,
if
we
find
this
to
be,
you
know
creating
a
lot
of
headache.
D
D
F
A
A
Nope,
okay!
Well
thanks
everyone
for
joining
this
week's
edition
of
the
carnival
community
meeting.
Again
we
meet
every
thursday
at
10,
30
a.m,
pacific
time,
and
we
would
love
for
you
to
come
and
join
us,
live
and
provide
feedback
and
ask
for
help
we're
eager
to
meet
folks
from
the
community
and
would
love
to
have
you
join
until
next
time.
Thanks
everyone
bye.