►
From YouTube: Carvel Community Meeting - March 29, 2021
Description
Carvel Community Meeting - March 29, 2021
Details found here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw
A
A
B
Thank
you,
nancy.
Can
everybody
see
the
agenda
cool
great?
All
right,
hey
everybody!
Welcome
to
the
last
meeting
of
march
for
us
the
29th.
So
here
we
go
one
announcement,
we're
we're.
We
still
have
an
open
wreck
for
a
staff
engineer
if
you
have
know
of
anybody,
who'd
be
interested
in
the
kind
of
work
that
we
do
here.
Definitely
send
them.
B
B
C
B
B
D
Just
a
minor
note,
this
hasn't
been
released
yet
in
cap
controller,
but
I
believe
this
came
over
originally
from
a
ytt
issue
about
basically
including
file
marks,
basically
as
an
option
for
ytt
templating
as
part
of
basically
deploying
apps.
So
that's
been
added
to
cap
controller
and
will
be
available
in
the
next
release,
and
thanks
john
for
bringing
that
over
in
an
issue
to
us.
B
Cool
so
now,
cap
controller
will
soon
be
supporting
file
marks
great,
that's
great
stuff,
anything
else
in
terms
of
updates
or
announcements
there
about
that's
good
cool,
oh
yeah,
and
I
should
have
noted
ahead
of
time
hey
if
there's
anything
that
you
wanted
to
talk
about.
This
is
this
is
a
great
form
to
do.
It,
go
ahead
and
get
into
this
document,
and
let
me
share
this
link
and
then
you
just
edit
it
if
I
can
find
the
chat.
B
Oh,
is
it
already
there?
It's
already
there.
Thank
you.
Nancy
go
ahead
and
just
edit
right
in
there
and
put
your
topic
and
we'll
we'll
talk
about
that
cool
all
right,
so
sitting
down
there
right
this.
Second,
let's
go
ahead
and
jump
in
real
quick
to
to
check
out
our
plan
for
this
week,
so
in
terms
of
our
backlog
here
and
make
this
a
little
bit
bigger.
B
B
E
So
how
the
the
way
this
feature
was
built
till
this
point-
was
that
you
first
was:
they
were
able
to
create
recursive
bundles,
like
a
bundle
that
has
nest
bundles
on
it.
Then
afterwards
you're
able
to
pull
that
from
from
the
registry,
and
then,
after
that,
you
were
able
to
copy
it
from
place
a
to
place
b
being
a
tatar
or
a
registry,
and
all
of
this
work
was
done
behind
the
flag
that
was
called
minus
minus.
E
E
E
The
extra
thing
that
we
that
we
want
to
make
sure
is
that
when
we
remove
this
flag,
there's
going
to
be
code
that
will
be
removed
as
well,
because
we
had
like
these
two
types
of
behavior.
If
you
had
the
flag
or
not
the
flag-
and
this
will
also
allow
us
to
remove
some
of
the
code
that
was
processing
the
prior
usage-
that
didn't
have
the
flag,
the
prior
behavior.
So
basically
that's
what
the
story
entails.
B
B
B
C
I
feel
like
dennis
has
been
on
a
lot
of
these
stories
for
the
last
couple
weeks
and
for
him
who
has
been
building
up
all
this
context.
If
you
were
to
work
on
this
story,
I
feel
like
that
would
be
a
pretty
accomplishable
thing
for
one
point:
for
someone
rolling
on
and
like
trying
to
catch
up
on
all
this
context,
I
think
it
would
be
a
larger
story
and
then
I
didn't
really
refactor.
I
mean
I
didn't
really
factor
in
refactors
of
the
code
into
my
complexity
estimate.
B
B
F
F
But
that
one
do
we
have
yeah
plans
from
the
packaging
team
to
also
kind
of
refer
back
to
recursive
bundle
from
cad
controller
side.
Like
I
know
in
the
alpha
packaging
api
it
says.
Currently
we
only
support
oci
image
would
love
to
have
this
information
also
surfaced
up
that
they
can
use
bundles
of
bundles.
F
B
E
B
E
B
Puzzle
and
so
on:
okay,
okay,
yeah!
Sometimes
what
happens
is
the
idea
comes
up
in
an
issue
and
then
we
wrap
that
in
an
epic,
along
with
the
story,
work
and
so
you're
saying.
Well,
that's
the
one!
That's
the
issue
that
we
get
close:
okay
cool
all
right,
so
we
don't
necessarily
need
to
point
this
great
okay,
cool.
G
B
All
right
down
in
the
next
epic,
in
our
list
here,
which
is
schemas
for
ytt
so
currently,
as
we
were
talking
about
at
the
top
of
the
meeting,
we're
doing
private
library
support
for
data
values.
Next
up
is
uploading,
floating
supporting
floating
types
and
then
this
next
one
is
schemas
can
be
overlaid.
B
B
So
to
date,
we're
only
using
the
first
schema
file
that
you
give
ytt
we're
ignoring
the
rest,
and
so
this
story,
high
level,
is
about.
Well,
I
can
actually,
as
a
configuration
consumer,
provide
my
own
schema,
which
augments,
which
adds,
maybe
I
want
to
add
more
templating.
That
requires
more
variables
if
you
will
more
data
values,
and
so
I
do
that
by
providing
my
own
schema.
B
We'll
get
to
that
note
in
a
second,
so
so
that's
the
flyover.
So
in
terms
of
the
root
library,
this
is
what
it
would
look
like.
So
library
that
includes
its
own
schema
and
then
the
ability
to
actually
for
the
configuration
consumer
to
include
their
own
schema.
Here's
a
second
schema
file
and
then,
when
I
ask
for
the
data
values,
I
actually
see
both
of
them
with
their
defaults.
B
And
this
is
a
similar
kind
of
thing,
but
now
this
is
about
well,
if
I
have
a
private
library
that
has
a
schema,
so
we'll
go
through
these
one
at
a
time.
So
here's
that
library,
its
name
is
libby.
It
has
just
a
schema
and
a
template
and
then
at
the
root
library,
there's
a
root
template
in
another
file
called
more
schema.
B
B
That's
inside
the
library
and
then
back
out
to
the
root.
Here
we
have
is
the
schema
definition
more
schema
and
it's
targeting
libby
declaratively,
and
here
it's
saying
I
want
to
add
another
key
called
re
tofu
and
it's
going
to
be
a
string
default
value
of
empty
string
and
then
the
template
at
the
root
loads
up.
B
B
What
we
had
that
was
in
a
file
in
the
previous
example
is
now
captured
as
a
function
as
a
yaml
fragment
as
a
function.
So
we
get
the
library
we
set
the
schema.
We
set
some
data
values
just
like
we
did
in
the
example
up
above
we
evaluate
that
replace
it
and
we
are
expecting
the
exact
same
kind
of
output.
It's
just
through
this
machinery.
B
B
There's
actually
a
proposal
to
to
address
this.
So
even
the
approach
is
something
we're
exploring
so
anyway.
So
in
in
your
mind,
if
there's
a
part
of
that
that's
kind
of
bugging,
you
just
know
that
that's
something
we're
going
we're
going
to
provide
a
better
experience
where
you
won't
accidentally
break
something,
but
in
the
meantime,
have
would
without
this
story,
you
wouldn't
have
the
ability,
as
a
configuration
consumer,
to
include
your
own
templates
and
that's
just
not
not
gonna
fly.
E
Does
with
schema
already
exists,
no
awesome
when
I
personally,
when
I
read
that
I
read
it
as
please
use
this
schema
as
the
schema
to
check
the
values
against
and
that's
not
the
case
right
like
we
are
using
that
that
schema,
plus
the
one
that
is
there
before.
So
I'm
not
sure
the
naming
is
very
accurate,
at
least
the
way
I
read
it.
B
B
B
B
B
E
Schema
yeah
but
like
that
will
bring
us
to
like
the
next
part
right,
because
the
preventing
overlays
from
breaking
schema
contract
that,
where
it
kind
of
feels
strange
for
you
like,
if
the
idea
is
to
have
validations,
I
I
do
understand
that,
but
allowing
you
to
restrict
even
more
a
value
or
change
possibilities
like
set
of
values
that
the
variable
can
have.
I
don't
think
that's
like
a
good
thing.
E
H
H
So
the
way
that
I'm
thinking
about
it
is
there's
sort
of
two
parts
to
the
story.
One
is
supporting
multiple
schemas
in
the
real
library
or
in
a
private
library.
Then
the
second
part
is
supporting
that
with
schema
function
for
a
library
to
me,
those
seem
to
be
sort
of
separate,
and
I
think
that
part
of
the
implementation
will
also
be
separate.
So
I
see
this
as
like
sort
of
two
things
to
tackle,
might
add
some
complexity.
B
B
Great
all
right,
probably
enough
roadway
there
for
this
week,
all
right
and
then
we
we
do
have
on
the
cap
track.
We
have
a
explore
story
looking
into
what
does
it
take
to
incorporate
resources
that
are
applied
by
some
other
machinery,
not
by
the
pile
of
manifest
that
you
give
cap,
but
something
else
is
going
to
create
it.
So
there's
that
explorer.
D
We
haven't
touched
on
them,
but
if
we
just
want
like
a
brief
overview
of
like
what's
going
on
with
cap
controller,
a
lot
of
the
work
that
we
will
be
kind
of
focusing
on
moving
on
into
this
week
is
basically
supporting
trying
to
improve
the
experience
of
debugging
app
crs
that
are
created
by
a
cap
controller.
That's
been
a
huge
point
of
feedback
for
us
as
far
as
making
it
easier
for
folks
to
navigate
like
when
things
go
wrong
and
ultimately
resolve
whatever
errors.
They're
hitting.
D
G
Yeah
also
just
like
implementing
an
aggregate
api
server,
so
package
apis
will
have
some
custom
behavior,
that's
not
available
through
the
regular
crd
code
paths.
So
we
are
throwing
together,
like
a
created
api
server,
to
help
support
things
like
searching
for
specific
packages
like
various
listing
improvements
and
stuff,
like
that,
so
hopefully,
efficiency
as
well.
So
continuing
on
some
of
that
work
as
well.
B
B
H
Which,
when
you
run
cap
app
group
deploy
from
a
directory,
it
uses
the
current
directory's
subfolder
structure
to
deploy
multiple
apps
at
once,
so
so
say
in
the
current
directory.
You
have
three
subdirectories
each
one
of
those
directories
have
some
configuration
in
them
that
you
want
to
deploy
to
your
cluster
cap
will
deploy
each
directory
as
a
separate
app
using
the
directory
name
as
the
app
name.
H
Is
about
using
the
dash
f
parameter
with
cap
after
app
group
deploy
in
order
to
include
some
global
cap
configuration
along
with
your
deployed
apps,
so
like
with
cap,
you
can
include
a
cap
configuration
file
that
specifies
certain
configurable
features
with
cap
like
rebase
rules
or
like
ownership
label
rules
that
like
allow
you
to
customize
cap
deployment.
More
so
currently,
cap
app
group
deploy
doesn't
support,
including
a
cap
config
file
that
will
be
applied
to
all
of
the
apps
in
each
directory
that
you
have
with
this
command.
E
H
We
decided
not
to
move
forward
with
that
issue.
I
think
we've
talked
about
it
in
a
previous
community
meeting
actually,
but
we
didn't
make
any
decisions
on
whether
we
want
to
stop
supporting
this
feature
in
cap.
I
think
the
distinction
there
was
like
for
ytt.
It
doesn't
make
sense,
because
ytt
is
usually
piped
into
other
tools.
H
B
And
I
think,
there's
a
I
think
you
might
even
mentioned
it
carrie
at
the
time
that
there's
like
a
question
of
well
are
people
using
this.
I
think
dmitry
might
have
represented
it
as
a
kind
of
experiment
or
just
like
just
something
he's
poking
at
like
hey.
Maybe
this
might
be
a
thing
and,
and
the
question
is
whether
or
not
folks
are
picking
it
up
so
here's
a
data
point
where
that
is
happening.
H
B
H
H
I
think
there
are
also
like
alternative
ways
that
we
could
potentially
do
this
if
we
do
want
to
like
support,
deploying
global
config
like
one
being
use
a
similar
like
directory
structure,
contract
that
we're
using
for
this
flag
or
for
this
command
currently
like,
rather
than
sometimes
allow
using
the
dash
of
flags
for
for
certain
kinds
of
files.
Maybe
we
could
allow
cap
config
in
like
the
top
level
directory,
and
that
would
apply
to
all
of
the
sub
directories.
B
B
H
B
B
H
That
is
actually
really
interesting,
because
if
you
have
your
configuration
stored
in
a
specific
directory,
I
would
kind
of
expect
that
everything
that
you
need
is
present
and
then
so
if,
in
order
to
use
cap,
you
needed
an
additional
configuration
file
that
wasn't
included
in
your
directory.
It
could
be
surprising
it's
a
important
consideration.
Yeah.
B
B
E
E
So
if
you
all
have
some
time
just
read
through
it,
if
this
is
something
that
interests
you
that
you
have
a
use
case
for
this,
just
look
at
it
see
if
it
matches
your
use
case
if
it
works
for
your
workflow
and
also
at
the
same
time,
if
you
see
something
that
feels
strange,
just
let
us
know
and
yeah
so
we'll
we'll
try
to
get
this
ironed
out
by
next
week.
So
we
can
merge
this
and
start
preparing
the
work
that
will
be
required
in
order
to
have
this
feature
added.
B
B
E
It's
just
like
currently
image
package
when
it
copies
images
from
one
repository
to
another
repository
it
copies
them
copies
all
the
images
from
the
bundle
and
puts
them
inside
the
same
repository
in
the
in
the
destination.
So,
if
you
have
like,
let's
imagine
three
images
on
the
on
a
particular
bundle,
it
copies
the
three
images
inside
the
same
repository
with
different
charts
that
then
it
knows
how
to
retrieve
it.
So
this
is.
This
is
the
current
behavior
of
image
package.
E
What
this
proposal
is
trying
to
accomplish
is
allow
the
person
that
is
using
image
package
when
copying
images
from
one
registry
to
another
to
have
some
power
to
say
like
where
do
I
want
my
images
to
be?
Where
do
I
want
my
images
to
stay
instead
of
being
directly
inside
the
one
particular
repository
they
can
be
spread
out
and
this
proposal
it
creates
a
mechanism
for
you
to
for
image
package
to
for
the
users
of
image
package
to
tell
image
package.
E
Where
do
you
want
to
move
your
images
to
so
that's
more
or
less
what
this
is
all
about.
It
is
a
little
bit
big.
It
has
introduction
of
concepts
that
didn't
exist
in
image
package.
Some
configuration
files,
for
example,
like
the
configuration
file
that
that's
there
and
has
some
nuances
and
has
some
things
that
are
reaching
up
into
the
future
and
some
things
that
we
are
like
the
mvp.
In
order
to
move
this
forward.
E
They
are
not
really
delineated
here
on
the
proposal
like
this
separation,
but
then,
when
we
start
implementing
it
and
when
we
convert
this
into
stories
that
make
more
sense,
we'll
we'll
try
to
make
sure
that
the
things
that
are
nice
to
haves
will
be
added
in
a
later
period
and
the
things
that
are
really
required
for
this
feature
to
to
go
forward
to
to
be
added.
First.
B
E
E
There
you
go
so
there
are
like.
I
think
there
are
four
phases,
if
I'm
not
mistaken,
there's
like
a
prefe,
a
phase
zero.
That
just
is
something
that
needs
to
happen
before
we
start
working
on
this.
So
this
is
like
pre
pre-work,
then
there's
an
mvp,
a
first
mvp
that
will
allow
you
to
basically
copy
the
oci
images
between
registries.
E
Choosing
the
strategy
that
best
suits
your
needs.
There
will
be
like
two
strategies
to
start
with
and
it's
going
to
be
copy
everything
into
a
single
repository
or
maintain
original
repository.
That
will
keep
the
repository
names
there
and
also
on
the
mvp,
when
the
user
copy
a
bundle
and
do
not
select
the
strategy,
it's
going
to
copy
to
it's
going
to
maintain
the
current
behavior.
E
So
it's
going
to
copy
to
a
single
repository
and
when
you
pull
the
bundle
to
disk
and
you'll,
see
the
correct
locations
of
all
the
oci
images
on
the
on
the
destination
right,
because
now
they
can
be
in
multiple
places.
Currently,
when
you
pull
the
image
log
file
finds
out,
where
are
the
images
on
the
current
repository?
So
it
will
do
the
same
work,
but
now
it
has
a
little
bit
more
work
to
do
in
order
to
find
out
the
images
because
they
can
be
in
multiple
places
now.
E
E
I
want
to
have
like
this
particular
strategy
strategy
for
all
the
images,
but
there
is
this
one
image
that
I
want
it
a
little
bit
different,
so
this
second
mvp
introduces
the
concept
of
an
overwrite
that
will
allow
you
to
override
the
the
the
strategy
that
is
defined
and
you
can
override
that
by
using
direct
matching
like
the
image
repo
there
or
using
the
the
image
matcher.
So
the
matchers
match
the
matchers
used
in
k
build
so
that
we
have
an
experience
that
is
more
or
less
familiar
to
people
that
use
one
tool.
E
They
also
know
how
to
use
another
tool,
the
matching
tools
from
other
tools
and
the
final
phase
of
this
of
this
story
is
introdu
introduction
of
a
little
bit
of
more
of
an
advanced
tooling,
where
you
could
have
some
ytt
starlark
functions
to
do
the
selections
for
you.
So
instead
of
you
saying,
oh,
I
have
like
this
list
of
overrides.
E
You
can
just
write
a
little
bit
of
starlark
code
there
and
have
ytt
to
pre-process
this
for
you
without
you
having
to
define
like
a
list
of
all
the
owl,
at
least
of
all
the
the
images
that
you
want
to
override.
So
that's
like
the
the
thing
that
is
going
to
be
like
more
in
the
future.
I
think,
but
this.
B
E
More
or
less
a
proposal
of
the
phases
and
if
we
get
to
like
phase
number
one
real
to
mvp
number
one,
I
think
we'll
get
to
a
place
where
the
majority
of
our
requirements
are
met.
For
from
that
we
got
the
envied
p2
allows
you
to
be
a
little
bit
more
flexible
on
these
requirements
and
number
three
is
like
the
end
goal
of
something
that
we
will
talk
about.
Does
it
make
sense
to
for
us
to
do
this
right
now
or
not?
It's
not
something
that
is
like
mandatory.
B
Well,
that
was
fantastic
for
not
being
prepared
to
talk
about
it,
well
done
yeah
and
it
just
just
footnote.
I
know
that
we're
considering
we're
like
looking
at
the
possibility
of
providing
the
ability
to
wherever
you
need
an
expression
potentially
using
starlark
there.
So
this
is
one
of
many
places
we're
looking
at
that
possibility
as
well
download
down
the
road.
B
A
F
Yeah,
what
I
meant
by
that
was,
if
you
look
at
zenhub,
you
know
how
we
are
filtering
by
epics
there.
So
as
as
soon
as
we
have
all
those
stories
that
are
in
the
prioritized
backlog
are
completed,
which
we
don't
know
what
the
timeline
that
would
be.
That's
when
we
will
cut
a
release
once
that
entire
epic
is
delivered
or
developed.
A
F
A
E
F
B
A
Okay
thanks
everyone
for
joining
this
week's
edition
of
the
carvel
community
meeting.
There
wasn't
any
particular
discussion
on
topics
that
we
didn't
get
to
today,
so
we
won't
be
moving
anything
from
this
meeting
to
the
office
hours.
But
if
there's
anything
that
does
come
up
between
now
and
then
or
now,
and
the
next
cargo
community
meeting,
which
is
next
monday
and
the
office
hours
is
also
going
to
be
next.