►
From YouTube: Carvel Community Meeting - April 12, 2021
Description
Carvel Community Meeting - April 12, 2021
We meet every Monday at 11:30am PT / 2:30pm ET.
This week's meeting included discussion around ytt and imgpkg backlogged issues and various status updates across the Carvel tool suite.
Details found here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw
A
Hi
everyone
welcome
to
this
week's
edition
of
the
carville
community
meeting.
This
meeting
is
being
recorded,
so
please
read
and
abide
by
our
code
of
conduct
when
attending
these
meetings.
We
do
meet
every
monday
at
11.
30
am
pacific
time,
2
30
pm
eastern
time
and
for
anything
that
we
don't
get
to
during
these
meetings
or
if
there's
anything
that
that
arises
from
the
team
or
from
the
community.
We
do
have
office
hours
as
well
that
meet
every
second
and
fourth
thursday,
also
at
11
30
a.m.
Pacific
time,
2,
30
p.m.
A
A
So
if
you're
interested,
if
you
know
anyone,
that's
looking
for
this
opportunity,
you
know
we
really
encourage
you
to
apply
and
also
free,
feel
free
to
reach
out
to
us
again
at
the
on
the
kubernetes
public
slack
workplace
in
our
in
our
channel.
And
if
you
have
any
questions
about
the
physician,
we're
we're
happy
to
help
guide
you
in
the
right
direction.
A
The
next
thing,
our
announcements-
we
do
have
a
release
that
happened
last
week,
cap
controller
0.18
and
the
release
notes
are
also
in
the
agenda
here
and
please
go
ahead
and
check
that
out.
If
you
have
any
feedback
to
share
with
us
on
that,
you
know
again
directing
you
over
there
to
the
public
kubernetes
workspace,
the
car
will
slack
channel.
A
B
C
Yeah
we're
definitely
making
progress,
there's
a
number
of
ways
in
which
we're
maturing
how
some
of
the
like
data
values
are
being
handled
as
we
are
pushing,
as
the
schema
feature,
is
pushing
up
against
that.
We
believe
making
it
better.
So
we're
we're
in
the
process
of
taking
on
that
some
of
that
refactoring
work.
So
we
we
think
it's
actually
not
just
adding
the
schema
feature
but
sort
of
improving
the
tool
overall.
C
B
Cool
thank
you.
Now
we
also
threw
up.
Schemas
v2
is
actively
being
defined
right
now.
So
a
couple
links
there.
One
is
a
proposal:
that's
in
progress,
the
unannotated
mos
data
values
and
then
the
other.
The
second
one
there
support,
exporting
open
api
from
ytt
schema
is
another
piece
of
work.
That's
actively
being
defined,
so
feel
free
to
click
and
learn
more.
Anyone
want
to
share
anything
further
on
those
right
now.
C
Yeah,
the
unannotated
yaml
is
in
part
supporting
like
an
integration
situation
where
there's
a
upstream
tool
that
wants
to
use
ytt
to
process
templates,
but
it
doesn't
want
a
demand
of
its
user
that
they
need
to
somehow
know
about
white
ytt,
internals,
so
providing
just
plain
yaml
as
inputs
yeah,
and
that
that's
going
along.
We're
actually
like
seeing
like
potentials
for
improving
how
data
values
are
handled
overall,
so
stay
tuned.
B
I
think
image
package
was
the
initial
tool
that
motivated
some
some
additional
tooling
here,
but
from
some
light
observations
and
slack,
it
seems
like
we
might
have
some
some
release
tooling
to
do
that
around
a
few
of
the
tools
I
know
stephen
or
dennis.
If
there's
anything
else,
you
all
want
to
add
right
now
cool
and
then
kept
controller
side.
E
F
Yeah,
I
think
the
key
piece
there
is
really
one
of
the
things
that'll
be
interesting,
is
being
able
to
get
people
to
issues
that
arise
with
with
the
packaging
crs
to
errors
a
bit
quicker.
I
think
right
now
we
sort
of
have
some
very,
very
simple
statuses
for
these
resources
and
we're
hoping
that
some
of
the
improvements
that
we've
made
for
apps
themselves
can
just
be
shown
directly
as
part
of
the
packaging
status
or
the
packaging.
B
B
D
So,
just
like
the
sorry,
the
proposal
for
the
renaming
of
image
package,
I
said
it
in
slack.
We
postponed
the
day-to-day.
The
due
date
was
last
week,
but
there
was
a
new
scenario
that
came
into
light
and
we
postpone
it
to
this
friday.
So
we'll
have
one
more
week
to
comment
and
to
ash
out
the
last
parts
that
are
still.
G
G
G
H
G
I
believe
our
first
pass.
Implementation
of
this
was
not
completely
correct.
There
were
a
few
cases
where
we
were
type
checking
the
document
prior
to
overlaying,
so
we
never
captured
some
of
the
errors
that
you
would
see
from
overlays,
and
then
we
went
through
some
refactors
and
then
came
up
with
another
solution
and
decided
to
just
postpone
this
work
completely
until
this
story.
Since
it's
it
wasn't
closely
related
to
the
like
work
that
we've
been
doing
so
far.
G
G
G
D
D
B
C
So
to
me,
there
there's
just
this
point
of
really
trying
to
think
through
all
possibilities.
I
don't
mean
it
like
that
intense,
but
like
there's
like
the
whole
round
realm
of
things,
the
other
one
is
in.
We
were
just
talking
just
prior
to
coming
on.
The
community
call
that
there
there
might
be
some
like
overlap
between
the
data
values,
the
like
that
unannotated
data
values,
proposal
that
we
talked
about
in
the
in
the
prior
section.
C
D
C
C
So,
more
more
more
precisely
if,
if
it
turns
out-
and
it's
not
clear-
it's
not
100
certain
yet
but
like
we're
tossing
around
the
idea
that
by
default,
a
user
would
provide
data
values
as
a
raw,
yaml,
unannotated
whatsoever.
In
fact,
if
you
include
annotations,
like
sorry
that
there
be
this
flag,
that
we
say,
data
values
file
and
that
the
thing
that
you
pass
into
that
flag
is
the
name
of
a
file
that
contains
raw
yaml,
plain
ammo
and
no
annotations
like
it's
an
error.
C
If
you
include
annotations
with
that
constraint,
then
the
cases
that
made
this
work
difficult
at
the
moment
we
were
like
how
are
we
going
to
pull
this
out,
actually
relieves
some
tension?
It
relieves
some.
It
actually
makes
a
number
of
cases
that
were
wrong
like
go
away.
That
is,
there's
an
interaction
between
hey.
If
I
included
annotations
overlay
annotations
in
my
data
values,
you
really
can't
tinker
too
much
with
that
inside
inside
ytt
itself,
and
that
was
part
of
the
trick
was
in
order
to
not
have
overlays
fail.
C
We
needed
to
have
them
be
more
permissive,
but
then
that
changed
the
meaning
of
some
of
the
annotations
with
within
that
overlay.
But
if
we
separate
it
and
data
values
are,
are
plain
yammel
and
then
you
continue
to
have
the
ability
to
overlay
on
top
of
data
values.
But
those
are
what
we
know
of
today.
As
data
values,
we
would
refer
to
those
as
data
value
overlays.
C
Well
then,
it
makes
it's
less
surprising
makes
more
sense
that
I
might
get
an
error
from
the
overlays
portion
from
the
overlay
mechanism
than
schema
because
I've
opted
into
overlays.
So
it
has
a
lot
to
do
this.
This
all
is
about
the
big
value
of
schema.
Is
that
we
would
we
can
provide
error
messages
that
are
much
more
actionable,
clear
and
direct
you
right
to
where
the
issue
is.
C
D
G
D
I
propose
not
doing
it
because
that's
like
the
next
story
on
the
backlog,
so
whenever
someone
finishes
ytt's
the
next
ydt
story
and
goes
for
this,
it's
gonna
pick
up
the
story
and
it
looks
like
we
don't
want
to
implement
this
until
we
have
the
other
story
done,
or
at
least
like
in
a
good
state.
So
I
would
not
point
it
and
just
put
it
down
in
terms
of
priority.
C
B
C
B
B
I
Yeah,
I
can
give
a
quick
overview
of
this,
for
everyone.
Purpose
of
the
story
is
to
confirm
that
we've
implemented
the
type
checking
of
including
data
values
through
the
command
line.
So
there's
six
scenarios
here
and
this
story
was
pulled
out
when
we
realized
that
there's
a
lot
of
similarities
between
private
libraries,
the
way
private
libraries
and
their
data
values
gets
checked
in
the
way
that
command
line
data
values
gets
checked,
but
that
wasn't
in
the
scope.
I
So
we
wanted
to
pull
that
out
to
ensure
that
we
are
covering
all
our
cases
here.
So
the
first
scenario
there's
six
different
scenarios.
The
first
three
are
all
in
your
root
library
scenario,
with
your
schema
and
your
data
values
all
relating
to
your
root
library
and
then
the
last
three
scenarios
are
all
in
a
ytt
library,
so
your
schema
would
exist
in
your
ytt
library
and
the
command
line.
Data
value
that
you're
providing
is
specifically
targeted,
targeted
at
that
library.
I
So
there's
scenarios
one
and
four,
which
are
both
conforming
and
scenarios.
Five
and
two
three
five
and
six,
which
are
all
non-conforming
and
a
nuanced
bit
of
information
here,
is
that
there's
two
different
ways
to
provide
data
values
through
the
command
line.
One
is
with
the
normal
data
values
or
data
values,
end
flag
and
then
there's
the
data,
values
yaml
or
the
data
values
environment.yml,
and
when
you
use
the
one
that
doesn't
have
the
yaml
at
the
end.
I
The
second
scenario
would
fail
because
it's
saying
42
as
a
string
doesn't
doesn't
match
the
same
type
as
7
as
an
integer
and
then
in
the
bottom
of
that
scenario
too.
You'll
see
that
if
you
use
datavalue.yamlflag
just
scroll
down
a
little
bit,
aaron
you'd
see
that
that
should
pass
our
type
validation.
I
I
B
B
Yeah,
this
is
a
good
one,
so
rename
this
is
for
image
package
rename
a
flag
from
include
non-distributable
to
include
non-distributable
layers.
So
additional
layers
is
providing
a
bit
more
preciseness
as
to
what
what
this
flag
does
and
we
prioritize
it
fairly
highly
fairly
high.
Just
because
this
feature
isn't
that
old
and
if
we're
gonna
introduce
any
sort
of
breaking
change,
and
we
just
wanted
to
try
and
do
it
as
soon
as
possible.
E
E
H
D
B
C
J
C
B
J
We
want
to
get
information
about
the
progress
of
that
image
being
written
and
right
now,
once
we
get
the
gtcr
released,
there's
a
way
to
know
how
many
bytes
of
all
the
images
or
every
image
has
been
uploaded,
and
you
also
get
information
about
the
total
amount
of
bytes
for
the
image
or
images
to
be
uploaded,
and
it's
just
a
matter
of
somehow
displaying
that
in
a
user-friendly
manner.
There's
the
libraries
out
there
that
will
easily
plug
into
this.
J
So
if
you
want
a
progress
bar
or
other
ways
of
doing
it,
just
like
libraries,
you
could
potentially
look
into
that
should
plug
in
nicely
this
person
was
asking
hey.
I
would
like
to
know
you
know
ideally
an
eta
as
well.
That
might
be
a
bit
trickier
to
do,
but
the
current
upload,
divided
by
the
total
uploaders,
is
really
really
trivial.
C
B
D
J
C
D
D
That
was
what
I
meant,
but
if
it
is
already
karma
accepted,
someone
should
pick
it
up
and
look
at
add
some
criteria
to
it
before
we
point,
because
I
think
that
might
skew
the
pointing
I
don't
know
if
you
really
want
to
have
like
times.
Maybe
that
will
skew
the
time
it's
like
the
hour,
pointing
I
don't
know.
B
D
So
if
anyone
wants
to
chat
about
the
proposal
for
the
rename
of
the
image
package,
since
we
have
some
buffer,
if
you
have
any
questions,
maybe
that,
like
now
that
we're
all
online-
you
can
just
choose
like
the
next
couple
of
minutes
to
do
that.
If
that's
something
that
you
all
are
interested,
if
not,
we
can
just
wrap
it
up.
B
C
C
D
Can
so
what
we're
draw
like
before,
like
the
story?
That's
up
there
on
this
on
this
particular
part,
we
are
talking
about
the
copying
when
you're
trying
to
copy
from
one
registry
to
another,
and
you
want
to
have
you
want
to
add
namespaces
and
subname
spaces.
That's
basically
the
part,
the
the
part
of
the
url
between
the
the
registry
and
the
name
of
the
image,
like
all
those
folders
like,
for
example,
ggcrli
to
have
a
bunch
of
folders
there,
while
docker
hub
only
allows
you
to
have
one.
I.
G
D
D
When
you're
copying
an
image
from
a
a
registry
that
contains
those
namespaces,
we
just
ignore
all
of
them
and
you
just
use
the
name
of
the
image
and
just
attach
the
name
of
the
image
to
the
registry.
So
basically
what
do
you
have
on
the
examples
that
that
we
can
see
there
so
an
image
that
it
comes
from
origin.io
slash?
My
image
would
be
copied
to
a
destination.ios
my
image,
while
an
image
that
would
come
from
origin,
dot,
io,
slash,
sound,
slash
path,
slash.
D
My
image
would
be
copied
to
destination
dot
io
my
image
so,
as
you
can
see
there
like,
there's
a
squashing
squishing
of
that
and
the
name
of
that
strategy
that
would
enable
this
by
default,
but
we're
talking
about
by
default,
behaviors,
not
behaviors,
that
you
can
then
overwrite.
So
this
is
what
the
tool
will
do
for
you
by
default
by
by
default.
D
Without
doing
you
doing
anything
so,
and
the
name
of
that
strategy
was
called,
maintain
origin
repository
and
then
we
talked
about
like
what
does
repository
mean
and
unfortunately,
the
oci
spec
does
not
define
what
a
repository
is.
So
there's
there's
places
where
repositories
the
name
of
the
image
there
are
places
where
their
repository
is:
the
full
name:
space
namespace,
one
name,
space,
two
slash
image
name.
So
there's
no!
D
There's
no
like
a
current
way
to
talk
about
this,
so
this
this
also
makes
it
made
it
a
little
bit
more
complicated
to
define
and
that's
there's
a
comment
in
from
eli
some
places
below
that
talks.
Exactly
about
that
so,
but
this
is,
this
was
basically
what
we
were
talking
about,
the
the
area
and
the
proposal
that
john
made
there
was
to.
C
If
there's
any
problem,
we
go
to
write
an
image
and
let's
say
that
target
registry
turns
out
not
to
support
namespaces
and
it
complains,
or
just
some
other
error
relating
to
like
a
failed
copy
that
we
that
we
degrade.
We
have
a.
We
have
a
a
fallback
where
we
go
back
to
the
the
today
behavior,
which
is
okay.
Well,
it's
going
to
land
in
the
same
in
in
sort
of
a
like
hub
repo.
C
So
so
the
suggestion
is
have
a
fallback
strategy.
We
know
we'll
work
so
that
the
copy
will
succeed
and
then
tag
this
thing
that
had
to
have
that
fallback
treatment
with
enough
information
that
you
could
potentially
recover.
If
you
want
to,
for
some
reason,
like
I
don't
know,
if
like
do
arena
whatever
it
is
like,
you
would
at
least
get
that
human
readable
information
attached
to
the
image,
even
if
it's
in
a
repo
that
you
know
is,
isn't
that
and
then
you,
you
would
gain
back
the
benefits.
C
C
D
Proposing
okay,
so
personally,
I
think
it's
an
interesting
proposal.
I
see
a
big
con
to
it
and
that
is
we
will
be
scattering
the
images
to
be.
I
see
two
cons
of
it
on
it.
We
will
have
a
scattering
of
the
images
and
we'll
have
an
unreliable
and
eventually
non-reproducible
way
to
copy,
because
then
you
could
have
for
the
same
bundle
images
in
their
word
or
the
place
that
they
should
be
by
the
strategy,
and
there
will
be
other
images
that
would
be
underneath.
D
D
That's
not
that
doesn't
give
us
enough
information,
because
we'd
have
to
consult
the
registry
to
see
all
the
all
the
tags
that
that
particular
image
has
in
order
to
find
out
what
the
image
is,
so
that
in
the
end
I
think
it's
it's
a.
It
would
be
good,
but
in
the
end
nobody's
going
to
use
that
tag
for
anything
and
it's
hard
for
people
to
find
that
out
the
tag.
So
so
those
are
like
out
of
the
bat.
Those
are
like
two
things
that
I'm,
like,
not
100,
sure.
C
Yeah,
I
think
somebody
I
think
we
were
trying
to
figure
out
okay.
What
happens
when
there
are
like,
let's
say,
you're
going
merrily
along
and
you're
copying
images
over
everything's
cool,
and
then
you
hit
on
one
where
for
one
reason
or
another
it
it's
not
gonna
work
like
we
were
exploring
like
okay.
Well,
do
we
want
to
roll
back
like?
Could
you
even
roll
back?
Do
we
even
want
to
like
be
in
the
business
of
like
what
would
roll
back
mean
and
so.
C
J
Yeah
I
was
making
the
assumption
that
the
tag
wasn't
for
the
operator.
It
wasn't
for
an
operator
to
say.
Oh,
this
is
an
image
that
lives
in
a
base
in
a
root
repo,
but
really
it's
a
reaper
that
originally
had
a
namespace.
I
thought
it
was
to
address
your
first
issue
with
the
joao,
which
was
the
non-reproducible
aspect.
J
I
thought
it
was
a
way
to
if
you
copy
the
registry,
a
docker
hub,
you
don't
you
lose
the
name
space,
but
you
have
that
a
bit
of
meta
data
information
to
say
it
was
meant
for
it
was
meant
to
have
a
namespace,
not
just
a
repo,
and
then,
if
you
copy
to
gcr,
you
don't
have
a
tag,
but
you
could
you?
Could
you
could
copy
from
docker
hub
to
gcr
look
for
the
tag
to
see
if
it
has
a
namespace
and
then
in
gcr
save
it
with
a
namespace
and
repo?
C
J
C
J
C
Maybe
another
this
is
just
a
minor
thing,
but
I
think
this
might
be
useful,
steady
state.
This
kind
of
operation
is
ideally
automated,
so
I
think
in
general,
I'd
find
it.
I
don't
know
I
just
throw
this
out
there
see
if
this
sticks
like.
I
think
it
would
be
more
helpful
that
an
operation
would
this
kind
of
operation
would
succeed
in
an
automated
environment.
D
D
D
J
You
can
push
a
blob
with
an
incorrect
digest
and
then
it's
going
to
fail,
but
you're
not
going
to
get
a
401
or
403
I'm
just
kidding.
I
mean
the
thing
about
this
composable
nature
of
the
proposal.
Is
you
know
if
we
just
decide
to
go
with
the
strategies?
Just
called
maintain
origin
image?
Name
like
that?
That's
a
strategy
that
says
all
right.
I
just
care
about
the
artifact
name.
D
So
another
change
that
we
have
here.
I
know
that
we're
getting
up
in
time,
but
another
change
that
I
added
friday
was
on
the
when
you're
doing
the
overrides,
and
you
have
your
destination
there,
there's
like
a
subtle
change
there,
where,
if
you,
when
you
do
your
override,
if
you
start
with
a
slash
it,
it
works
like
the
the
the
file
system.
If
you
started
it,
slash
assumes
that
the
image
will
be
the
location
is
going
to
be
the
registry.io
slash
in
the
place
that
you
put
there.
D
But
if
you
do
not
start
with
a
slash,
it
assumes
it
is
a
relative
location.
So
what
happens
is
that
the
image
will
be
placed
in
the
same
namespace
if
namespace
exists
as
the
as
the
the
bundle
itself.
So
if
the
bundle
is
inside
register.io
slash
a
slash
b
bundle
and
when
you
do
the
overwrite
do
not
put
the
slash
and
just
put
image
name
one:
the
image
name,
one
is
going
to
be
in
registry:
slash
a
slash
b,
slash
registry,
one
image
one.
D
So
that's
like
also
a
change
that
eventually
could
be
an
interesting
add-on
to
like
a
third
strategy
where
I
just
say,
like.
Okay,
just
put
everything
into
this
particular
place,
or
something
like
that
that
could
solve
some
of
these
problems
but
yeah.
I
I
like
the
idea
of
eventually
just
renaming
the
strategy
and
just
creating
the
possib
leaving
open
the
possibility
of
adding
more
strategies
that
that
could
be
could
help
in
different
scenarios.
A
Okay
thanks
everyone
for
joining
us
for
this
week's
edition
of
the
carville
community
meeting.
If
you're
watching
this
from
home,
we
would
love
to
have
you
join
us
for
a
live
rendition
of
this.
We
meet
every
monday
at
11,
30
a.m,
pacific
time,
2,
30,
p.m.
Eastern
time
we
also
host
carnival
office
hours
every
second
and
fourth
thursday
of
the
month.
At
the
same
time,
11
30
a.m.