►
From YouTube: Carvel Community Meeting - June 7, 2021
Description
Carvel Community Meeting - June 7, 2021
We meet every Monday at 11:30am PT / 2:30pm ET. We'd love for you to join us live!
This week's meeting covered the monthly Roadmap review, the release of ytt v0.34.0, and pointing to some backlogged items. Full notes here:
https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw?view#June-7-2021-Agenda
A
Hi
everyone
welcome
to
this
week's
edition
of
the
carville
community
meeting.
Today's
date
is
june,
7th
2021,
if
you're
tuning
in
from
youtube
and
watching
this
as
a
recording,
we
invite
you
to
join
us
live
for
these
meetings.
We
meet
every
monday
at
11,
30
a.m.
Pacific
time
the
zoom
link
is
found
within
the
agenda
and
the
agenda
should
be
posted
within
the
youtube
recording
description
as
well
for
easy
access.
A
If
you're
unable
to
attend
the
the
community
meetings,
we
also
have
carbo
office
hours,
which
are
every
second
and
for
thursday
at
11.
30
a.m.
Pacific
time
and
those
are
just
an
opportunity
to
bring
any
discussion
items
up
or
anything,
you
need
more
in-depth
help
on
from
the
team.
You
can
attend
those
to
bring
those
up
to
the
team
and
we
asset
when
you're
attending
either
to
read
and
abide
by
our
code
of
contact,
which
is
listed
here
at
the
bottom
of
the
description
for
the
community
meeting.
A
A
B
A
C
Yeah,
a
big
big
part
of
this
stuff
is
rounding
out
the
feature
set
for
getting
feature
complete
with
schema.
We
still
have
some
more
work,
we'll
talk
about
that
a
little
bit
later,
but
the
other
big
piece
here
is
a
new
feature
where
we
include
a
new
flag
in
order
to
accept
just
plain
yaml
as
data
values,
this
this
is
a
bit
of
a
like
a
little
pre-release.
A
B
We'll
certainly
chat
more
about
that
during
the
status
update
portion
of
this
meeting,
but
then,
as
for
what's
coming
next,
we
have
export
ytt
schema
as
open
api
schema,
and
this
is
really
so
that
users
can
export
the
ytt
schemas
into
another
format
that
is
generally
used,
I
would
say,
with
within
other
tools,
so
it's
a
way
to
increase
interoperability
and
within
the
karvel
scope.
This
definitely
makes
sense
when
thinking
about
cap
controller
and
packaging
apis.
B
The
next
item
on
here
speaking
of
cap
controller
and
the
package
packaging
apis,
is
that
the
plan
is
to
have
a
ga
release
a
a
published
release
in
july.
Things
are
moving
well
and
on
track
for
that.
The
next
item
is
it's
kind
of
one
I
just
slid
in
as
a
placeholder.
As
you
know,
once
we
get
this
kind
of
mvp
version
of
these
api
apis
out,
I
know
that
we'll
have
some
enhancements.
As
with
you
know,
all
our
tools,
just
some
some
regular
enhancements,
we
haven't
yet.
B
What's
not
really
captured
in
here
is,
is,
I
would
say,
like
a
lot
of
the
ongoing
work
around.
I
don't
know
smaller
bug,
fixes
and
enhancements
things
that
maybe
don't
fall
into
like
a
larger
narrative
necessarily,
but
those
are
always
ongoing
and
we
also
do
have,
I
would
say
some
more
general,
like
open
source
community,
slash
project
health
type,
things
that
are
going
on
behind
the
scenes,
which
also
aren't
necessarily
called
out
here,
but
things
that
are
still
top
of
mind
for
us.
B
B
B
C
B
C
Yeah,
so
so
what
does
it
mean?
What's
it
what's
from
here
to
done?
What
do
we
mean
when
we're
sort
of
there,
but
not
so,
there's
like
lots
of
documentation,
stuff
that
we're
doing
there's
nips
and
tucks
in
various
features
and
then
like
it's
saying
here,
we're
going
to
do
a
round
of
usability
testing
to
get
some
early
feedback
and
respond
to
that.
We're
pretty
excited
about
this
feature
and
we
wanted
to
to
iron
out
any
of
the
sort
of
the
more
obvious
inconsistencies.
So
that's
what
that's
all
about.
B
Cool
then,
the
next
item
we
have
here
is
the
package
manager
apis.
As
I
mentioned,
these
are
still
in
flight.
The
the
team
is
imposing
a
code
freeze
at
the
end
of
this
week
and
that
way
the
the
next
couple
weeks
with
then
will
be
spent
on
again
more
of
the
stability
and
testing
portion
of
of
the
work,
but
everything
is
moving
along
there
and
then.
The
last
item
here
is
image
package
enhancements,
and
this
was
just
a
way
to
capture
again
some
of
the
work
that's
been
going
on
in
the
past
week.
B
A
B
C
In
order
to
convince
yourself
that
we've
identified
the
most
common
steps
required
to
make
that
migration
happen,
and
the
whole
point
of
this
is
so
that
folks
don't
have
to
guess
and
say
well,
I
guess
I
need
to
do
this
and
then
maybe
that
or
you
know,
change
the
wires
there
or
or
somehow
try
to
be
led
by
error
messages
per
se,
be
nice
to
lay
out
ahead
of
them.
What
that
road
is,
but
we
we
don't
need
to
be
explaining
every
little
possibility.
A
C
D
B
C
E
I'll
put
down
a
one,
I
guess
I
didn't
really
see
a
lot
of
complexity,
meaning
these
seem
to
be
pretty
procedural
kind
of
rules
that
we
want
to
document
to
like
hold
someone's
hand
in
terms
of
using
schemas
instead
of
using
you
know,
c
data
values
and
just
data
values
all
the
way
through.
So
it
just
seems
like
a
very
procedural
approach
to
writing
documentation.
E
We
know
what
the
rules
are.
There's
nothing
to
learn
or
explore,
there's
an
alternate
path,
which
is
you
can
even
just
start
with
anything's
permissible,
and
we
can
gradually,
you
know,
help
them
along
their
journey
of
making
it
a
bit
more
realistic
or
specific.
So
yeah
I
put
one,
but
I
can
also
like
there's
a
lot
of
documentation.
There's
a
larger
volume
of
work
here
entailed,
and
maybe
that's
why
it
should
be
a
two.
But
that's
my
reasoning
for
one.
C
C
So
so
we
we
addressed
the
issue
where
we
wanted
to
at
least
report
that
we
had
a
tight
mismatch,
but
it
was
a
much
bigger
chunk
to
actually
somehow
calculate
and
capture
where
we
should
attribute
from
what
line
of
source.
Should
we
attribute
this
data
value,
that's
being
overlaid
in
so
that's
what
this
story
is
about.
C
C
So
that's
what
this
is
about
is
finding
a
way
to
attribute
this
value,
even
though
it's
not
been
parsed
as
a
piece
of
yaml
to
give
it
a
give
it
a
source
line
and
and
with
that
then
be
able
to
actually
name
the
file
from
from
which
that
source
line
comes
from.
So
hopefully
you
can
see
pretty
clearly
that
this
is
going
to
be
a
pretty
significant
improvement.
C
Do
we
have
more
than
one
example,
or
is
this
yes
and
then
so
then
this
other
scenario
is
in
not
as
not
as
bad,
if
you
will,
in
terms
of
the
user
kind
of
being
left,
wondering
scratching
their
heads,
so
we
do
at
least
name
the
key
value,
but
we
like
to
also
capture
the
source
line
for
when
a
value
is
being
passed
on.
The
command
line.
G
C
The
I
believe
it's
the
latter
garrett
that
and
I
think,
that's
the
heart
of
what
I
believe
the
improvement
will
be
is
until
schema
came
along.
There
was
no
need
to
be
concerned
about
whether
or
not
template
replace
was
injecting
a
full
set
of
ast
nodes,
but
with
us
type
checking
at
all
the
values
that
are
coming
out
now.
C
So
I
I
think
you're
cutting
getting
right
at
the
heart
of
what
I
believe
is
is
the
gap
there.
So
we
want
a
holistic
solution
to
ensure
that
any
value
that
gets
template
replaced
in
sometimes
that
is
from
parse
dml
and
it's
just
fine,
that's
already
ast,
but
sometimes
like
in
this
case.
The
key
part
here
is
it's:
the
combination
of
the
template
replaced
and
it's
from
a
value
that
wasn't
already
ast,
wasn't
already
nodes.
F
C
E
And
in
order
to
build
this
ast
structure,
when
we
you
know
for
our
star
interpret
interpolated
values
like
is
that
code
that
we
can
reuse
somehow
like
we're,
building
asts
and
non-star
like
cases,
can
we
reuse
that
code
or
is
it
pretty
much
customized?
It's
gonna
be
like
brand
new
code
to
build
this
ast
structure.
C
E
E
C
F
Yeah
and
remember
we
looked
into
this
in
a
previous
story:
we
did
some
work
around
adding
positions
for
overlaid
values
and
the
situation
came
up
where
values
to
find
in
starlark
don't
have
a
position
and
we
considered
changing
it.
In
that
story
we
found
it
was
non-trivial,
so
we
deferred
it
so
not
sure
exactly
how
difficult,
but
definitely
non-trivial.
F
C
So
what
do
you
say?
We
throw
two
different
points,
we'll
throw
points
on
this
first
scenario
and
we'll
that'll.
Be
then
we'll
narrow,
the
scope
of
the
story
to
just
that
first
scenario,
and
then
we'll
appointed
the
second
one
and
I'll
pull
that
out
into
a
separate
story.
So
we
can
have
two
smaller
stories
that
probably
would
be
addressed
independently.
C
F
C
So
the
the
essence
of
this
one
again
is
in
capturing
and
and
and
and
storing
in
that
a
little
bit
of
background,
hopefully
isn't
explaining
what
people
already
know,
but
when,
when
data
value
flags
are
being
processed,
they
get
converted
into
a
document
by
hand.
We
hand
craft,
actually
overlays
for
every
single
data
value
flag
actually
under
the
covers,
gets
converted
into
an
overlay.
So
there
is
a
spot
to
be
able
to
put
that's.
C
A
A
F
C
First
familiar
it's
the
source
that
hopefully
will
be
the
place
where
the
user
will
go
to
fix
the
problem,
so
an
idealized
world
would
be
where
somehow.
This
looks
like
the
command
line,
some
display
of
the
command
line
like
what
I
what
I
might
look
at
to
to
go
and
fix,
but
it's
a
little
bit
harder
because
at
least
here
we
have
the
literal
input
available.
C
C
Yeah
yeah,
I
just
wanted
to
show
an
edit.
I
I
realized
after
we
pointed
it
that
we
didn't
have
a
section
to
remind
folks
to
just
remove
mention
of
the
flag.
So
this
is
one
of
those
things
where
it's
like
changing
the
code.
You
want
corresponding
change
in
augmentation,
and
the
scope
of
this
is
very
small.
It's
just
if
we
mention
anywhere
the
enable
experiment
schema
flag.
This
is
just
remove
that.
C
B
E
We
need
to
be
somewhat
mindful
backwards
compatible
with
with
that
with
that
setup,
and
so
in
in
that
case,
essentially
the
newer
version
of
image
package
doing
a
pool
it
will
check
for
the
locations
oci
image.
It
won't
find
it
because
it
was
copied
with
an
older
version
of
image
package,
and
so,
in
that
case,.
E
E
Don't
yeah,
sorry,
if,
if
it
can't
find
it
as
a
slight
improvement,
if
you
can't
find
it,
it
hasn't
been
copied.
No,
don't
check
the
original
image
location
to
see
if
it
exists
in
its
original
image
location.
So,
instead
of
doing
two
calls,
it
gets
at
least
half
to
one-
and
I
was
thinking
also
in
the
scenario
where
you
have
a
newer
version
of
image
package.
E
Doing
a
pool,
but
it
was
copied
with
an
older
version
of
image
package,
provides
some
sort
of
ux
to
the
user.
Saying
hey!
You
know
if
you
want
to
improve,
if
you
want
to
basically
speed
this
up
next
time
copy
with
a
newer
version
of
image
package,
because
if
they
do
that
the
oci
location
image
will
exist
so
the
next
time
they
pull
at
least
will
be
an
operation
of
one
instead
of
n.
And
so
those
are
the
two
things
I've
outlined
in
this
comment.
C
Okay,
so
the
so
the
copy
receipt
was
that,
like
that
image
that
you
were
talking
about,
that
tells
you
where
everything
should
be
yeah
and
so
refer
to
that,
instead
of
trying
to
find
all
the
other
images
yeah
and
then
the
the
other
one
was
we
to
date
have
had
the
strategy
of
if
we
can't
find
it
in
the
current
location,
try
and
find
it
in
the
previous
location.
You
say
just
don't
do
that.
Second,
don't.
E
C
Yeah,
I
can
speak
to
that,
so
we've
been
making
an
effort
to
vet
out,
like
that,
some
of
the
decisions
that
were
made
there
are
making
sense,
and
so
far
so
good.
We
have
like
actually
quite
a
bit
of
our
existing
backlog.
That
needs
to
be
reworked
to
kind
of
conform
to
to
these
new
definitions
of
states
in
which
an
issue
can
be
in
most
notably,
is
trying
to
make
more
clear.
C
What
are
things
that
we
know
that
are
not
just
in
scope,
but
are
would
be
great
things
that
if
somebody
wanted
to
pick
up
and
contribute
that
that
is
a
obvious
and
be
that
they
can
feel
confident
that
it
would
get
merged.
I
mean
you
know.
We
have
a
conversation,
we
work
work
through
contributions,
but
but
the
spirit
of
it
is
definitely
wanted
and
that
we
have
some
reasonable
definition
of
done.
C
So
we're
trying
to
make
that
part
clear
so
that
it'd
be
easier
to
find
ways
to
to
contribute
to
the
project
as
well
as
just
making
it
clear
to
us
about
what
state
different
pieces
of
work
are
in,
and
we
have
a
one
more
to
do
around
this,
which
is
to
fold
in
these
changes
into
our
like
public
definition
of
how
we're
managing
our
backlog.
So
that's
in
the
I
believe,
the
community
repo
right
now
so
that
it's
it's
not
just
in
some
side,
google
doc.
C
A
So
we
encourage
you
to
to
join
us
in,
and
that
is
there
anything
else
that
the
team
wanted
to
discuss
for
this
particular
meeting
good
cool
all
right.
Well,
thanks
for
the
the
good
discussion
here,
and
we
hope
that,
if
you're
tuning
in
we
see
you
at
one
of
the
opportunities
we
have
available
to
join
us
live
community
meetings
happening
every
monday
at
11.
30
am
pacific
time
unless
it
is
closed.