►
From YouTube: Carvel Community Meeting - July 22, 2021
Description
Carvel Community Meeting - July 22, 2021
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
This week the team discussed roadmap updates, new processes, presented a demo on ytt schemas, and engaged with a user on how to become a contributor. More details here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw?view#July-22-2021-Agenda
A
Hi
everyone
welcome
to
this
week's
edition
of
the
carville
community
meeting.
It's
our
second
time
that
we
are
now
moved
to
every
thursday.
Previously
we
were
doing
every
mondays
for
these
cargo
community
meetings,
but
we
are
now
doing
every
thursday
at
10
30
a.m,
pacific
time.
So,
if
you're
watching
this
recording
from
home,
we
hope
that
this
new
day
and
time
works
out
for
you
and
you
can
join
us,
live
for
the
next
one.
A
A
Some
announcements
that
we
have
actually
just
one
in
particular,
we
have
a
workshop.
The
cargo
team
does
at
spring
one
the
registration
is
open
and
the
date
of
that
workshop
is
thursday
september,
2nd
at
1
30
pm
central
time.
It
is
virtual,
it's
not
attending
in
person,
so
you
hopefully
will
be
able
to
attend
from
wherever
you
are.
If
that
time
aligns
with
your
time
zone.
A
A
B
So
I
know
for
the
educational
material,
I
I
have
a
draft
of
a
tutorial
hosted
on
katakota
and
I
don't
know
if
maybe
it's
appropriate.
It's
it's
definitely
still
a
draft
and
I
wouldn't
want
to
spread
it
around
too
widely,
but
maybe
I'll
drop
a
link
in
the
chat
in
a
minute.
So
internal
folks,
if
if
they
have
time
and
desire,
can
offer
feedback.
C
B
So
it's
it's
still
a
bit
loosely
defined
at
this
point
and
we're
getting
a
lot
of
feedback
on
it,
but
yeah.
If
people
are
interested
in
just
learning
more
about
secret
gender
controller,
it
might
be
a
good
introduction
to
some
of
our
thinking
around
how
we're
going
to
handle
this
particular
use
case.
D
D
A
A
The
next
item
was
project
health
docs.
I
know
that
a
lot
of
us
have
been
in
the
docs
working
on
different
items
there
just
to
give
the
community
an
update.
We
previously
had
two
carvel
specific
repos.
We
had
at
one
that
was
karbal
community
and
then
we
had
carvel.dev,
which
was
focused
on
the
site,
but
since
then
we
have
merged
everything
into
one,
and
this
contains
all
of
the
site.
Information.
A
A
We
would
love
for
you,
you
know
anyone
from
the
community
to
still
look
look
through
this
we've
asked
for
folks
to
to
take
a
look
at
it
when
we
had
the
google
doc,
but
if
you
have
any
feedback
regarding
the
ish
issued
triage
process,
we
would
love
to
hear
from
you.
You
can
either
make
comments
here.
You
can
find
us
in
the
kubernetes
slack
workspace
and
the
carville
channel
or
on
twitter
at
carnival
underscore
dev
erin.
Do
you
have
anything
else?
You
want
to
add
to
this.
C
A
Next
is
we,
I
don't
have
the
link
a
link
up
for
this,
but
we're
in
the
process
of
adding
maintainers
files
to
the
main
cardboard
repo,
and
then
all
the
different
tools
will
also
have
their
own
retainers
files.
So
the
community
knows
which
maintainers
are
responsible
and
working
on
each
tool,
because
not
all
of
the
maintainers
that
are
under
cargo
work
on
all
the
tools.
We
have
focus
processes
and
focus
development
for
these
maintainers
and
some
maintainers
are
also
approvers
and
reviewers,
but
not
all
maintainers
hold
that
responsibility.
A
E
Morning
the
only
thing
I'd
mention
is:
I
spend
a
lot
of
time
working
on
triaging
issues
and
working
on
image
package
issues
on
slack
and
that
just
took
a
long
way
away
a
lot
of
time
working
on
actual
backlog
items.
That's
the
only
thing
I
probably
just
didn't
really
capture
in
my
slack
update
today,.
A
A
A
All
right,
we
now
are
moving
on
to
the
ytt
schema
demo,
but
before
I
do
that,
I
always
make
a
mistake,
and
I
don't
offer
up
if
you
have
anything
that
you
do
wish
to
discuss,
that's
outside
of
this
agenda
right
here.
Please
add
it
down
below
in
the
discussion
topics.
So
there's
anything
at
all.
If
you
have
any
questions
or
anything
that
you
want
to
share
with
the
team,
we
would
love
for
you
to
put
that
in
in
this
section
right
here
for
discussion
topic.
F
So
you
should
be
seeing
the
using
database
data
values
overview,
good
awesome.
So,
as
carrie
mentioned,
we
released
a
major
milestone
when
we
delivered
a
schema,
schemas
feature
in
ytt
version
0.3135.1,
but
it's
important
to
share
that
here
and
describe
what
our
schemas,
what?
What
is
the
impact
of
this
new
feature
on
ytt?
So
schemas
are
a
new
way
to
declare
data
values.
As
you
see,
in
this
documentation
page,
we
have
the
using
data
values
and
the
first
tagline
of
declaring
data
values
is
done
with
a
schema
file.
F
It
declares
then,
in
the
same
way
that
you
would
expect
data
values
to
be
declared,
except
it
has
one
extra
piece
of
information
and
to
see
that
we
can
see
it
declares
it
in
the
same
way
as
you
would
expect
a
data
values
file.
We
can
even
erase
this
schema
part
you
can
error,
but
then
the
exact
same
message
would
come
up
the
exact
same
outcome,
so
it
acts
the
same
way,
but
schemas
provide
type
information
to
your
data
values
as
well.
F
So
when
we
think
about
writing
a
schema
document,
what
you're
doing
when
you
declare
data
values
is
you're
declaring
three
parts:
the
name,
the
default
value
and
the
type
before
schemas.
When
you
would
declare
data
values
with
just
a
data
values
document,
you
would
only
be
declaring
a
name
and
a
default
value.
F
So
what
is
extra
about
this
type
information
that
makes
schemas
different,
make
schemas
cooler
or
better
or
more
useful?
I
think
it's
easy
to
see
that
more
in
an
error
case.
So
we
have
this
playground.
Exact
playground
example
kind
of
looks
like
the
one
before
we
have
a
data
values
file
and
there's
no
schema
here.
So
data
values
declares
some
keys
and
then
we
override
those
keys.
F
We
override
those
values
in
a
second
data
values
file
here,
and
you
see
we
have
one
two
instead
of
a
string,
but
what,
if
you
wanted
to
enforce
that?
P1
and
key2
were
strings
and
you
didn't
want
someone
to
be
able
to
override
with
integer
values.
Well,
you
could
make
this
first
data
values
file
a
schema
file
and
then
all
of
a
sudden
we're
given
some
problem.
I
think
I
have
a
there.
F
We
go
character
there,
so
we're
given
these
errors
that
key
one
was
supposed
to
be
a
string,
but
we
found
an
integer
and
in
comparison
to
previous
error
messages.
We
think
that
this
is
a
lot
better.
This
is
easier
to
read.
I
can
make
it
bigger
too
it's
easier
to
read
and
displays
the
information
and
all
your
errors
in
a
concise
easy-to-parse
way.
F
F
F
The
last
question
to
think
about
when
thinking
about
this
new
schemas
feature
would
be.
How
does
it
affect
my
current
usage,
as
I
showed
before
in
this
example,
if
you're
just
using
a
data
files
file
to
declare
your
keys,
then
adding
the
schema
part
really
doesn't
change
much
at
all.
Data
values,
files
and
schema
files
are
essentially
identical
when
it
comes
to
maps,
but
we
have
a
full
migration
guide.
F
Saying:
okay
right
now,
I
use
data
values
and
I
want
to
migrate
my
ytt
library
to
using
schemas,
what's
a
step-by-step
guide
and
how
to
do
that-
and
you
know
the
easiest
way
is
just
add:
the
dash
schema
to
your
data
values
file,
but
it
becomes
slightly
more
complex
or
iterative
as
we
introduce
multiple
data
values,
files
or
certain
private
libraries.
That
might
exist
that
you
know
your
root
library
or
your
main
library
could
have
a
schema
file,
but
your
private
library
could
not
and
those
would
coexist
together
in
harmony
so
yeah.
F
That's
the
introduction
to
the
new
schemas
files.
We
have
some
additional
information
on
annotations
that
you
can
add
into
these
files
to
either
relax
or
change
the
typing
information
and
defaulting
of
certain
keys.
So
are
there
any
questions,
or
did
I
miss
anything
about
schemas
that
someone
else
wanted
to
chime
in
on.
G
Couple
of
them
is
there
a
way
to
in
the
schema
to
define
what
type
of
values
can
be
constrained
like,
for
example,
when
you
say,
and
a
type
is
a
is
an
integer
or
a
type
is
a
string?
Can
I
limit
the
length
of
the
screen
string,
or
can
I
for
integers?
Can
I
limit
the
minimum
and
the
maximum
value
allowed,
or
things
like
that.
F
F
These
explicit
sort
of
annotations
to
say,
like
schema,
allowed
range
and
then
you'd
give
a
range
for
your
integer
or
we
could
do
this
like
schema
allowed
type
one
of,
and
then
you
can
list
all
the
different
types
that
this
value
can
be.
So
that's
in
the
future,
and
it's
just
not
how
it
is
currently.
G
Okay,
I
I
I
never
thought
that
it
was.
This
was
a
the
first
implementation.
I
thought
it
was
like
the
final
implementation
of
schemas,
so
I'm
happy
to
learn
that
this
is
just
like
a
first
milestone
on
the
schemas
and
then
the
other
question
that
I
have
is
since
I'm
using
the
new
package
api
a
lot
in
the
karma
packages.
I
was
wondering
I
saw
the
the
error
message
that
you
get
when
in
the
in
the
ytt
playground,
which
is
really
nice.
G
If
I
run
this
standalone
cli
in
my
in
my
in
my
terminal,
but
when
I
run
this
from
within
car
within
cut
controller,
I
was
wondering
whether
I
will
get
something
some
errors
like
this,
or
they
will
be
somehow
optimized
to
be
displayed
as
as
output
in
the
because,
as
you
know,
most
of
this
comes
in
the
status
of
the
package
object.
So
obviously
this
cannot
be
displayed
so.
B
I
think
it's
fair
that,
like
we
haven't
fully
explored
like
how
it's
going
to
look
in
the
status
currently
for
cap
controller
and
like
one
thing
that
we
might
be
able
to
do,
is
backfill
a
test
for
this
and
sort
of
use
it
as
a
way
to
like
drive
out
what
is
the
current
implementation
and
what
could
be
better
with
it.
But
my
thought
is
that
it
it
should.
B
You
know
just
we
do
have
our
way
of
like
separating
out
the
error
from
most
of
the
other
information,
for
instance
like
in
the
package
install
that
should
display
this
kind
of
standalone
but
yeah.
I
think
at
the
very
least,
we
should
have
some
way
of
understanding
how
this
error
is
gonna,
manifest
in
these
use
cases.
So
it's
a
good
call
out.
A
A
E
E
How
is
it
we
think
people
folk
are
using
image
packages
dash
image
flag
in
terms
of
copying
and
pulling
images
around
like
what's
driving
the
image
flag
like
there's,
like
a
background,
thought
that
came
to
my
mind,
which
is
that
might
help
the
discussion,
which
is
what
about
if
we
just
removed
that
flag
like
what
would
be
the
consequences,
I
can
think
of
some
benefits,
which
would
be.
We
would
maintain
a
lot
less,
but
yeah
so
I'll,
just
open
it
up
there,
like
it's
amazing
gathering,
use
cases
around
this.
If
we
know
of
any.
E
Specifically,
the
the
flag
test
image
and
just
making
bundles
not
only
a
first
class
kind
of
way
of
distributing
images,
but
the
only
way
image
package
handles
images
like
I'm
actually
just
thinking
out
loud
like
what,
if
that
was
the
only
thing
that
image
package
works
with,
which
is
just
bundles,
not
you
know
non
image,
bundles
non.
You
know
just
typical
oci
images.
G
We
should
try
to
like
drive
them
to
a
more
appropriate
tool.
In
this
case.
Probably
scorpio
is
that
is
the
most
appropriate
tool.
So
the
discussion
is
hey.
We
were
using
this
tool.
We
are
now
using
image
package
to
to
to
do
this
and
it's
failing
and
we
get
the
errors
and
it's
not
supporting
this
flag
or
it's
not
supporting
this
use
case.
So
maybe
maybe
that
is
what
I
was
expecting
to
clarify
in
that
issue.
That
does
that
make
sense.
C
Yeah,
I
think
like
like
one
other
thing
just
to
like
provide
context
is
like
the
image
flags
did
exist
prior
to
the
bundle
flag.
So
a
bit
of
this
is
just
the
evolution
of
the
tool
over
time
and
bundles,
as
jorge
mentioned,
are
certainly
more
of
like
the
primary
use
case
and
and
like
the
the
one
that
we
want
to
recommend.
C
So
I
don't
know
if
there
have
been
like
explicit.
I
don't
know
proposals
to
to
say,
like
you
know,
remove
some
of
this
functionality
yet,
but
I
think
some
of
it
is
just
still
around
just
just
from
the
evolution
of
things,
but
but
this
is
a
great
discussion
to
have,
as
dennis
you
mentioned,
like
yeah.
Maybe
this
is
an
area
where
we
reduce
scope
of
tool
to
ease
maintainability.
C
H
Well,
I
will
toss
out.
You
know.
Like
jorge
mentioned,
you
know
that
a
lot
of
people
use
image
package
to
copy
things
around.
I've
actually
done
that
for
a
number
of
people
and
just
copying
packages
from
like
what
is
it
like?
The
the
this,
like
the
staging
harbor
instance
like
over
to
like
you
know
to
like
a
more
production
harbor
instance,
you
know
so
that
packages
you
know
are,
I
guess,
visible,
a
little
bit
better.
H
G
What
I
was
mentioning
what
I
was
raising
is
that
that,
if,
if
your,
if
the
task
that
you
need
to
do
is
copy
an
oci
image-
and
specifically
it's
like
hey-
I
got
nginx
and
I
need
to
move
this
nginx
to
a
different
repository,
maybe
use
scorpio,
because
that
is
a
tool
built
for
copying
layers
in
an
optimized
way
from
a
registry
to
a
different
registry
right.
All
image
package
is
not
meant
to
copy
a
lot
of
layers
in
an
optimized
way
like
like
it
does
and
like
it
does
a
scorpio
image
package.
G
It
does
help
with
relocating
images,
but
then
there
is
additional
things
that
happen
as
part
of
image
package
right.
It
is,
it
looks
in
the
images
file
it
just
recalculates
the
new
image
location.
So
there
is
this
additional,
this
additional
things
that
happen
as
part
of
image
package
that
are
probably
not
useful
for
for
the
people
that
is
just
using
image
packets
to
copy
images
around.
G
So
my
my
point
was
in
the
discussion
that,
if
what
you
are
trying
to
do
as
part
of
your
continuous,
because
these
guys
they
were
doing
continuous
integration-
and
they
were
copying
images-
maybe
you
should
do-
you-
should
use
a
tool
that
is
purposely
built
for
copying
images
around.
That
will
help
you.
C
So
one
thing
I
might
try
and
clarify
here
is
like
a
a
bundle,
is
an
oci
image,
but
it
is
like
an
opinionated
type
of
an
oci
image,
and
so,
when
we're
talking
about,
I
guess,
bundles
and
images,
I
believe
that's
we're
referring
to
are-
are
the
opinionated
oci
images.
And
then,
when
we
say
image,
this
is
just
the
more
generic
oci
image
that
doesn't
follow.
The
bundle
kind
of
like
constraint.
E
Yeah,
just
just
in
case
there's
confusion,
I'm
gonna
clarify
one
more
thing,
which
is
when
copying
an
image:
it's
not
as
performant
or
not
as
optimized
for
copying
an
image
with
multiple
layers.
A
bundle
does
reference
images
that
might
have
multiple
layers.
A
bundle
could
reference
an
nginx
and
when
you
relocate
it,
not
only
does
it
copy
the
oci
bundle,
but
it
also
copies
the
nginx
that
has
multiple
layers
and
there
has
been
effort
to
make
it
copy
as
efficient
and
optimized
as
possible.
E
So
it's
yeah,
like
I
think,
as
aaron
said,
it's
very
much
just
an
opinionated
image
that
might
actually
reference
non-opinionated
images,
but
like
what's
the
ux
for
you
know,
for
for
people
interacting
with
image
package,
should
we
be
allowing
him
to
copy
both
types
of
images
or
just
the
one
and
understanding
the
trade-offs?
There
would
be.
A
B
I
just
wanted
to
throw
in.
I
don't
know
if
this
ever
formally
became
like
an
issue
that
we
have
with
image
package,
but
I
I
do
remember
there
were
some
discussions
at
least
along
the
lines
of
you
know.
Is
it
necessary
to
support
even
the
options
with
image
package?
As
far
as
like
minus
I
or
minus
b
from
a
ux
perspective,
and
could
image
package
in
and
of
itself,
just
infer
like
the
type
of
you
know
what
what
someone
is
actually
trying
to
push
or
relocate
there?
B
E
C
We
don't
have
github
discussions
anymore,
so
we
could
continue
them
either
in
an
issue
or
if
we
have
a
path
forward,
then
I
think,
or
if
someone
wanted
to
propose
a
path
forward.
A
proposal
I
feel
like
would
be
the
right
place
to
do
that
until
that
I
feel
like
the
github
issue
itself
is
probably
the
best
way
to
track.
This
makes
sense.
C
Yeah,
so
I
shared
that
this
was,
I
think,
in
draft
form,
maybe
last
week,
so
it's
been
moved
to
ready
for
review,
to
encourage
comments
mainly
just
wanted
to
take
a
moment
here
to
see
if
anyone
had
any
questions,
any
things
that
they
wanted
to
discuss.
This
is
a
bit
more
targeted
towards
maintainers.
So
I'm
also
happy
to
be
a
bit
more
brief
on
this
topic
and
move
to
things
that
are
more
community.
I
guess
widespread,
but
yeah.
Does
anyone
have
anything
that
they
would
like
to
discuss
on
here.
C
C
A
H
So
you
know
outside
of
my
official,
you
know
like
work
requirements.
You
know
I
would
like
to
you
know
just
try
and
you
know,
give
back
a
little
bit
and
get
a
little
bit
more
involved,
get
to
know
how
some
of
these
tools
work.
You
know
from
a
you,
know,
lower
layer
and
and
actually
see
you
know
what
kind
of
things
I
might
be
able
to
contribute.
H
No,
I
just
I
just
want
to
like
try
and
help
out
and
give
back
a
little
bit
so
any
I
guess
any
any
advice
on
how
to
get
started
with
that
or
or
you
know,
of
course,
if
I
or
if
I
just
don't,
want
to
just
start
dropping
stuff
all
over
the
place
and
you
guys
are
like
who
is
this
guy
like?
Why
is
he
doing
these
things?
You
know
you
know,
so
I
I'm
guessing
you
know.
H
Maybe
a
first
good
place
for
me
to
start
is
just
comb
through
some
of
the
issues.
Look
for
maybe
some
good
first
issues
and
and
see
you
know
see
if
there's
anything
out
there
that
I
might
be
able
to
tackle,
or
you
know
or
if
any
of
you
are
like
hey,
I
need
some
help.
You
know
with
you
know,
tracking
down
this
bug.
You
know,
you
know,
give
me
a
shout.
You
know
I'll
see
if
I
can
help
you
out.
C
Cool
this
is
this
is
awesome,
and
we
certainly
welcome
your
contributions.
I
well
as
you're
aware
carvel
does
have
quite
a
widespread
domain,
so
my
first
question
would
probably
be
like
well
where,
where
would
you
want
to
start?
You
know?
Is
there
a
particular
tool
or
domain
that
you
wanted
to
look
at
if
you
want
to
dive
into
docs?
C
I
think
we
have
plenty
of
docs
improvements
that
we
would
love
to
have,
but,
but
we,
I
guess,
like
my
primary
primary
ask,
is,
like
you
know
c
I
I
guess,
starting
from
the
tool
that
you're
interested
in
and
and
trying
to
follow
the
docs
that
we
have
out
there,
because
we
are
trying
to
make
it.
You
know
accessible
for
anyone
to
join,
and
if
you
do
have
feedback
on
the
getting
started
process.
C
We
would
love
to
hear
that
we
know
that
it's
not
in
in
the
ideal
state,
and
we
want
to
make
those
improvements.
As
you
mentioned
good
first
issues,
we
we
do
try
to
use
that
label
when
appropriate.
So
so
that's
that's
a
good
one.
Bugs
are
another
thing
that
we
label
as
as
this
duck
shows.
We
have
kind
of
like
two
two
primary
labels
that
I
would
just
draw
a
little
bit
extra
attention
to,
which
is
a
carnival
triage
and
carvel
accepted.
C
So
that's
just
like
one
one
thing
I
would
call
attention
to
just
so
we
don't
cause
you
to
do
any
wasted
work
but
yeah.
We,
we
would
also
be
happy.
You
know
to
to
make
sure
that
these
issues
are.
You
know,
well-defined
enough,
so
that
you
could
get
started.
We
want
to
make
them
accessible,
so
anyone
could
get
started
so
yeah.
I
don't
I
don't
know.
Do
you
have
any
thoughts
as
to
I
guess
like
which,
which
tool
or
tools
you'd
be
interested
in
diving
into.
H
Well,
I
you
know,
thinking
about
that.
It's
it's
like
what
are
the
tools
that
you
know
that
I
use
or
that
I've
you
know
personally
used
in
the
course
of
my
day-to-day
work
and
then
it's
actually
a
few
of
them.
You
know,
but
you
know
ytt
image,
package,
cap,
controller,
vendor
and
k-build.
You
know
so
I'm
I'm
seeing
that
they're
sort
of
like
five,
that's
pretty
much
most
of
the
tool
set,
but
it's
like
I
I
don't
know
it's
like
I.
C
Cool
cool
yeah
I
would,
I
would
maybe
start
then
like
like
so
as
nancy's
showing
right
now.
Our
zenhub
board
is
public
and
you
can
filter
it
down
by
something
like
good
first
issue
or
if
you
wanted
to
pick
something
in
our
prioritized
backlog,
that's
further
in
the
future,
just
so
that
there
is
some
of
that
padding.
That
would
be
cool
too,
but
yeah,
I,
I
would
say
we're
available
to
help.
You
know,
provide
any
context
or
help
you
get
started
on
any
of
these
things.
C
B
Okay,
okay,
I
volunteer
myself
specifically
as
the
sort
of
the
newest
member
of
the
team,
so
I've
I
I'm
honestly
still
in
the
process
of
onboarding
and
I'm
totally
happy
to
you
know.
Compare
notes
with
you
like
all
of
my
environment
set
up
is
is
very
fresh,
so
I'm
I'm
happy.
You
know
honestly
I'd
love
to
hold
your
hand
through
a
few
steps
and
honestly
I'd
be
pretty
interested
in
riding
shotgun.