►
From YouTube: Carvel Community Meeting - February 8, 2021
Description
Carvel Community Meeting - February 8, 2021
Meeting information and notes can be found here:
https://carvel.dev/community/
A
All
right,
hi,
everyone
welcome
to
the
second
monday
version
of
the
carville
community
meeting.
We
have
some
exciting
updates
to
discuss
today.
Just
a
reminder
in
this
meeting,
please
adhere
to
the
code
of
contact
which
is
listed
at
the
top
of
the
agenda
page,
I'm
going
to
add
this
to
the
chat
so
that
everyone
has
it
on
hand.
A
And
I'm
gonna
kick
it
over
to
aaron
hurley
to
go
over
all
the
agenda
items
and
share
a
screen.
So
we
see
what's
what's
on
the
agenda.
B
So
yeah,
we'll
just
do
some
very
brief
updates,
run
through
this
week's
plans
and
then
cover
any
discussion
topics
today.
So
please
feel
free
to
add
a
description,
discussion
topic
if
there's
anything
that
you
would
like
to
discuss
so
for
updates,
we'll
we'll
keep
it
a
bit
more
brief
this
week,
since
we
did
a
deeper
dive
last
week,
but
the
image
package
include
non-distributable
layers
track
has
wrapped
up
and
we
released
a
version
of
image
package
that
provides
functional
functionality.
B
Last
week
we
do
have
one
remaining
item
before
we
completely
close
this
effort
out,
which
is
to
consume
ggcr's
next
release,
assuming
that
that
has
our
upstream
contributions
that
we
provided
there.
B
Next
up,
ytc
schemas,
that's
still
in
progress,
we'll
take
a
look
at
the
zen
hub
board
to
see
where
that's
at
and
then
the
kind
of
next
areas
of
work
that
we
have
which
we'll
cover.
Today
we
have
image
package
enhancements,
so
these
are
just
some
of
the
issues
that
have
been
selected
as
the
ones
that
we
want
to
prioritize.
Next,
we
have
some
image
package
performance
related
investigations
that
we're
planning
to
do
image
package.
B
Recursive
bundles
is
there's
currently
a
proposal
out
there
and
we're
planning
to
write
stories
later
this
week.
B
I
guess
other
updates
just
to
mention
we.
We
did
have
a
few
releases
last
week.
I
didn't
list
them
here,
but
I
know
that
I
think
there's
a
vendor
release
a
k-build
release
shout
out
to
ben
moss
for
contributing
the
ability
to
build
with
co
the
image
package
release,
which
I
mentioned.
B
Then,
let's
see
for
schemas,
I
don't
think
there's
anything
new
to
discuss
here.
We've
pointed
the
stories
we
can
see
that
the
overlay
default
operation
on
array
items
is
append.
Story
is
in
flight.
B
The
include
non-distributed
layers
work,
as
I
mentioned,
that's
pretty
much
wrapped
up.
We
just
need
to
consume
upstream
changes
once
they're
available.
B
I
think
what
we'll
do
here
is
so
we
can
talk
about
the
I
guess
I'll,
just
pop
these
up
real
quick.
We
as
a
team
have
already
discussed
and
pointed
these,
but
these
are
are
in
our
our
backlog.
Now
so
for
image
package.
We
have
this
issue,
which
is
support
and
key
chain
for
registry
auth,
mainly
just
just
sharing
it
here.
B
I
don't
think
we
need
to
discuss
further
and
then,
after
that
story,
is
the
image
package
tag
list
digest
as
false
by
default
instead
of
true
again
context
is
in
the
issues,
but
as
a
team
we've
discussed
these
before
so
continuing
to
scroll
down
the
prioritize
backlog
to
the
next
unpointed
story.
B
D
Yeah
sure
so
this
is
the
first
story
on
the
actual
implementation
steps
of
improving
our
overlay
error
messages.
We
did
our
first
round
of
user
testing
and
we
successfully
identified
an
improvement
to
the
error
messages
that
we
could
make
right
now
and
the
big
detail
of
that
is.
We
could
improve
these
error
messages
further,
but
we
wanted
to
have
an
iterative
approach
to
this,
because
we
never
really
know
when
we're
going
to
find
the
perfect
error
message.
D
So,
since
we'd
identified
something
that
makes
the
error
messages
easier
to
read
and
easier
to
identify
where
the
problem
is,
we
want
to
make
that
change.
However,
during
the
user
testing,
we
only
did
about
three
different
scenarios.
So
there's
a
lot
of
different
overlay
scenarios
that
were
not
covered
during
this
investigation,
and
that
is
the
purpose
of
this
story
is
to
identify
more
of
the
overlay
scenarios
where
we
could
fail,
and
how
can
we
apply
our
new
template
in
the
way
that
we
want
to
convey
the
information
of
the
failure
to
these
new
scenarios?
D
D
This
is
going
to
be
all
the
information
from
the
user
testing.
Oh
no,
so
this
is
actually
the
error
yeah.
Can
you
go
back
to
the
zenhub
board
and
then
in
the
notes?
The
first
link.
D
Or
that
should
have
some
information
about
why
we
accepted
what
we
did
and
what
the
next
steps
are
and
then,
in
that
other
hack
md
document
is
where
I
intend
the
work
for
the
story
to
go
is
essentially,
we
have
mapped
out
some
of
the
cases
that
were
already
covered
by
our
error
message,
but
we
need
to
make
sure
that
there
are
our
cases
that
we've
thought
of
and
that
we've
planned
on
how
we,
how
we
plan
on
presenting
that
error
message.
So
are
there
some
questions.
E
F
So,
garrett,
if
I
understand
correctly
earlier
the
first
heck
md
document
that
aaron
pulled
up
and
embedded
in
the
acceptance
criteria,
that's
this
is
the
heck
md
document
that
you
would
like
to
add.
More
scenarios
correct.
F
Yeah
so
then
the
goal
is
here
to
identify
as
many
error
scenarios
as
possible,
where
we
can
apply
where
we
could
possibly
apply
in
the
next
story.
The
template
error
template
message
that
we
have
identified
from
the
first
round
of
user
interviews.
B
B
G
I
feel
like
this
is
a
way
for
us
to
sort
of
reconcile
if
we
have
a
different
idea,
if
we're
getting
different
pictures
in
their
heads
of
what's
involved,
we'd
find
out
right
now.
If
we
sort
of
all
sort
of
put,
you
know
played
around
a
poker
game,
the
planning
poker
throwing
points
just
to
get
a
sense
for
what
we're
thinking
is
involved
and
have
that
conversation.
B
E
Maybe
I'll
start,
given
that
I
I
don't
see
technical
complexity
here
eventually,
I
might
go
to
one
to
because
of
like
uncertainty
of
discoverability,
and
I
would
not
spend
more
than
day
around
this,
especially
because
it
feels
like
that.
The
the
what
we
try
to
achieve
here
is
just
a
document
that
will
be
spun
into
stories
right.
So
I
don't.
G
Yeah
I
threw
two
because
I
I
think
that
the
complexity
involved
is
working
through.
I
think,
there's
a
bunch
of
stuff
that
we
can
unpack
with
what
we
know.
So
I
feel
like,
what's
what's
useful,
to
defer
is
what
you
need
to
learn
and
what's
useful
to
consider.
Now
is
what
you
can
know,
and
it's
just
that
there's
a
there's
just
a
number
of
things
to
kind
of
lay
out
and
that
there's
some
design
effort
here.
G
I
know
we
don't
do
necessarily
a
lot
of
thinking
about
ux
per
se,
but
that's
involved
in
this
and
call
it
call
it
technical
work
of
a
different
flavor.
But
that's
what
I
was
thinking
of
when
I
threw
it.
G
F
F
I
think
gary
pointed
out
earlier
that
improving
overlay
error
message
is
gonna,
be
an
ongoing
task,
which
I
don't
think
is
gonna
be
done
with
any
of
the
stories
here,
but
I
think
maybe
we
can,
but
I
think
we
could
scope
or
define
scope
for
like
what's
enough
air
scenarios
that
we
identified
as
part
of
it.
D
I
think
it
would
be
helpful
if
someone
who
picks
up
this
story
looks
into
the
code
to
try
to
define
that
this
story
doesn't
really
call
that
out.
That,
like
you,
might
want
to
spend
time
in
the
code,
but
that
might
be
helpful
to
identify
these
different
scenarios
that
show
up,
because
in
an
nlytt
overlay,
you
can
feed
it
a
function,
and
we
know
that's
a
very
large
space
of
the
different
ways
that
you
can
match
and
replace
and
all
that
in
a
function.
D
D
H
I'm
not
exactly
sure
what
the
research
has
surfaced
so
far,
but
I
assume
it's
something
like
we've
identified,
two
different
places
in
the
code
that
we
want
to
improve
the
error
message
for
like
something
some
number
of
places
that
we
want
to
improve
messages.
H
I
wonder
if
it
makes
sense
to
make
the
story
like
identify
x,
number
of
error
messages
that
we
can
improve.
H
D
D
E
So
should
this
be
a
one
day
story
to
do
that
research
to
understand
what
is
the
scope
of
the
work
that
the
story
is
trying
to
achieve
and
from
there
we
can
create
stories.
That
will
be
pointed
and
say
like.
I
want
to
change
the
message
in
this
particular
scenario
and
go
from
there
like
to
be
fair.
I
don't.
B
H
D
I
just
wanted
to
mention.
I
know
joe
allman
said
that,
like
we
can
identify
a
specific
scenario
and
then
like
implement
that
scenario
and
in
a
way
that
first
round
hackmd
document,
that's
supposed
to
be,
the
acceptance
criteria
is
supposed
to
be
that,
for
you,
the
one
on
the
left
so
like
we
would
have
the
doc
the
use
cases
which
are
the
inputs
below
and
saying
like.
This
is
the
case
that
got
us
to
this
error,
and
this
is
what
we
want.
The
new
error
to
look
like.
E
Thanks
is
there
any
particular
reason
why
we
want
to
do
this
in
a
document
instead
of
just
creating
the
issues
with
the
acceptance
criteria,
it
feels
like
we're
doing
two
different
work,
two
different
jobs
when
we
could
just
be
creating
the
issues,
because
they
will
become
issues.
B
So
yeah,
I
think
I
think
the
stock
is
like
a
an
artifact
for
the
engineers
to
ease
in
their
implementation.
If
you
wanna,
I
think
it
would
be
okay
to
capture
the
context
in
the
next
story.
So
there
is
this
following
story
which
is
implement
the
changes
that
were
identified
in
the
story.
We
just
discussed.
B
So
I
think
that's
a
good
consideration
is
we
we
could
just
update
this.
Does
that
make
sense.
B
B
E
H
B
Okay,
we'll
keep
this
here
as
a
placeholder,
assuming
that
I
guess
more
concrete
stories
will
will
come
in
with
more
guidance
on
how
we
plan
to
implement
it.
B
B
G
Yeah,
so
the
essential,
difficult
someone
is
sending
in
yaml,
usually
it's
from
like
a
third
party,
and
they
just
want
to
have
it
included
in
their
output.
G
It's
not
a
template,
but
by
default,
ytt
is
going
to
assume
it's
a
template
and
process
it
as
if
it
were
and
one
way
and
then
it
will
complain
if
there
is
a
comment
in
the
yaml
document,
because
it's
ambiguous
in
the
template.
If
you
provide
a
comment,
is
this
an
actual
comment,
or
is
this
you
meant
to
include
one
of
the
divs
or
an
or
an
annotation,
and
so
we
want
to
air
out
if
in
a
template,
we're
unsure
whether
or
not
this
piece
of
meta
is
is
ambiguous.
So
it's
like.
G
Is
this
coder
or
is
it
a
comment
so
after
much
talking
about
this-
and
this
is
this-
this
particular
issue
has
been
talked
about
for
well
over
a
year.
I
believe
we
came
to
the
desire
to
and
by
the
way
like
that,
there
is
no
short
version
of
that
flag
by
design.
It's
something
that
because
it's
turning
off.
G
And
so
that's.
The
essence
of
this
story
is
to
detect
when
a
particular
yaml
document
is
a
template
and
when
it's
not
and
when
it's
a
template,
parse
it
like,
we
normally
do
and
when
it's
not
treated
as
flame.
G
B
G
G
C
That
ignore
unknown
comments,
that's
not
deprecated.
Could
you
assign
it
a
boolean
value?
Could
you
say
like
false,
don't
ignore
unknown
comments,
or
is
it
just
always
just
a
flags
presence
is
always
true.
It's
a
bullying
today,
so
you
could
assign
it
to
false.
You
could
say
okay
and
that
just
goes
away.
So
if
someone
had
dash
dash
ignore
unknown
comments
set
to
false
meaning,
they
don't
want
to
ignore
unknown
comments,
but
this
site
goes
away.
C
Say
that
last
part
again
sorry
dennis,
if
you
know
this
eventually,
this
flag's
going
to
be
deprecated,
as
in
I
envisioned
this
flag,
just
not
existing
after
some
version
and
suppose
they
did
not
want
to
ignore
unknown
comments,
so
they
set
it
to
false
once
that
new
version
comes
in
that
doesn't
support
this
flag.
Is
there
any
way
to
support
that
old
way
of
using
the
flag
setting
it
to
false
in
the
new
world?
G
Yeah,
I
so
the
intent,
the
intent
was
no,
that
if
you
want
checking
on
a
particular
file,
then
you
would
use
a
file
mark
to
say
this
is
a
template.
Okay,.
C
G
E
E
I
With
ytt's
pound
hat
pardon
me,
pound
exclamation
mark.
B
H
This
will
essentially
change
the
code
from
being
an
explicit
like
explicit
way
of
of
knowing
whether
a
file
has
like
ytt
comments
in
it
to
an
implicit
detection
of
that,
and
so
I
wasn't
sure
if
we'll
need
to
like
change
the
way
or
the
order
that
we
process
our
templates
in
like
processing
the
templates
before
stripping
the
comments
and
sort
of
like
the
unknown
for
me
is
like.
Are
we
going
to
need
to
change
the
order
that
we
do
things
in
in
order
to
get
this
to.
I
Work
that
just
prompted
me
to
question:
should
we
start
adding
another?
I
guess
I'm
going
to
call
it
a
debug
flag
whereby
we
output
what
type
of
file
we
are
interpreting
each
file
that
we
that
is
given
as
input
sort
of
like
a
reverse
file
mark.
Where
tell
me
here's
all
the
files
I
provided
it,
how
is
ytt
using
those.
G
G
B
All
right
so
that,
after
pointing
that
story,
we
should
have
a
significant
runway
for
not
just
this
week,
but
likely
next
week,
though,
we
might
have
the
recursive
relocation
stories
too
to
discuss
then.
B
I
think
the
only
other
thing
to
mention-
I
guess
from
a
carnival-wide
perspective
is
like
is
that
we
do
have
another
epic
here
package
manager,
api
mvp.
B
We
took
a
first
pass
set
at
drafting
these
stories,
so
this
is
work
being
done
on
cap
controller,
not
planning
to
go
into
these
right
now,
but
mainly
just
wanted
to
surface
awareness
that
this
is
upcoming.
Work.
A
Yeah,
I
just
wanted
to
remind
everyone
that
we
are
hosting
a
cncf
webinar
tomorrow
at
10
a.m:
pacific
time,
1,
p.m.
Eastern
time
just
follow
the
link
there
to
register
to
attend
other
than
that.
Thank
you,
everyone
for
joining
today's
community
meeting
this
will
this
was
recorded
and
will
be
uploaded
to
our
youtube
playlist
if
you're
watching
the
recording
from
home
later
on.
We
hope
that
you
do
join
us
live
for
the
next
meeting.
We
host
these
every
monday,
11
30
a.m,
pacific
time,
2,
30,
p.m.
A
Oh
good
good
point:
we
will
not
be
meeting
next
week.
It
is
a
holiday
here
in
the
united
states,
so
we
are
canceling
next
week's
meeting.
So
we
will
see
you
the
following
monday
and
I
don't
have
my
calendar
in
front
of
me
on
the
exact
date
that
will
be.