►
From YouTube: Carvel Community Meeting - September 16, 2021
Description
Carvel Community Meeting - September 16, 2021
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
Full notes and agenda from this week's meeting can be found here: https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw?view#September-16-2021-Agenda
A
Hello.
Welcome
to
this
week's
carnival
community
meeting
today
is
september.
16
2021.,
if
you're
watching
this
from
home
come
join.
Us
live
every
thursday
at
10,
30,
pacific
time.
This
meeting
is
an
opportunity
to
listen
in
on
the
maintainers,
are
working
on
provide
live
feedback
on
our
tools,
ask
questions
and
get
live
help
with
any
of
the
tools
that
karma
maintains.
A
If
you
aren't
able
to
attend,
live,
find
us
on
the
kubernetes
slack
workspace
in
the
carville
channel
and
on
twitter
at
carville
underscore
dev.
When
you
attend
these
meetings,
please
just
follow
the
code
of
conduct
and
if
you
have
anything
you
want
to
discuss
with
the
team,
please
add
that
to
the
discussion
topics
section
at
the
end
of
the
agenda
right
down
here
looks
like
we've
got
a
few
things
today
when
you
attend,
we
ask
that
you
input
your
name
and
the
organization
that
you
represent.
A
A
A
All
right.
We
got
some
announcements
today,
so
reminder
carl's
going
to
be
doing
a
keynote
at
kubecon,
cloudnativecon,
north
america.
So
this
is
breaking
tradition.
The
future
of
package
management
with
kubernetes
by
shadow
rupa,
nandi
she's,
an
engineering
director
here
at
montanzu,
and
that's
going
to
be
on
friday
october
15th
9
40
to
9
45,
pacific
time
so
register
to
attend
kubecon.
B
I
just
added
this-
I
I
don't
have
a
ton
of
context
other
than
I
know
that
this
was
released
yesterday,
and
these
are
the
release,
notes.
A
A
A
There's
cap
enhancements
currently
in
progress
image
package
enhancements.
B
I
think,
maybe
just
like
the
general
metadata
context.
I'll
add
to
these
issues
is
that
I
don't
know
if
these
collection
of
issues
have
a
real
concrete,
like
theme
necessarily,
but
it's
a
collection
of
open
issues
that
we've
prioritized.
As
always,
you
can
check
out
the
zenhub
board
to
see
like
which,
which
issues
are
currently
like,
prioritized
but
yeah.
This
is
a
fairly
generic
way
of
just
capturing.
What's
going
on.
A
A
C
Yeah
I'll
call
out
the
schema
default
annotation
top
of
the
in
progress
column.
We
kicked
that
off
this
week.
It
is
the
first
story
in
the
open
api,
schema
generation,
epic,
so
kick
that
off
this
week,
and
we
have
to
get
this
done
before
we
can
start
before.
We
can
start
work
on
the
following
stories
that
will
actually
implement
the
open
api
schema
feature.
A
D
D
D
You
know
there's
like
a
few
different
ways
to
authenticate.
This
is
one
of
the
new
ways,
but
one
of
the
existing
ways
is:
you
can
provide
your
credentials
through
environment
variables.
One
of
the
environment,
environment
variables
is
the
hostname.
You
know
like
this.
Is
the
username
password
for
this
registry
hostname
now
we're
making
that
environment
variable
a
lot
more
flexible,
so
you
can
add
globs.
So
you
may
not
know
the
registry,
but
you
may
know
the
repository
and
image
name,
so
you
can
do
asterisk
repository
image
name.
D
It
also
now
supports
repository
and
image
name,
not
just
a
hostname,
and
so
once
these
two
pr's
gets
merged
in,
we
should
be
free
to
cut
a
new
release.
We're
actually
aiming
for
this
week
so
like
today
or
tomorrow,
but
let's
see
how
that
goes
and
there's
there's
two
other
pr's
in
the
ggcr
repo
and
one
of
them
got
merged
and
and
one
of
them
is
still
waiting
to
get
merged.
But
it's
not
blocking
the
release.
E
I'll
also
add
that
I
had
a
good
pairing
session
with
dennis
last
friday.
I
think
we
were
working
on
an
image,
also
image
package,
pr
for
improving
some
debug
there's,
there's
still
a
little
bit
left
to
do,
and
I'm
I'm
kind
of
determined
to
figure
it
out,
and
I
kind
of
want
to
figure
it
out.
On
my
own.
E
I've
had
a
couple
of
false
starts
where
I,
basically
we
want
to
create
a
logger
that
you
know
we
can
basically
just
like
say,
logger.debug
and
then
whatever
and
just
trying
to
get
some
of
that
to
work.
I've
yeah
I've
made
a
bunch
of
changes
and
then
completely
thrown
them
all
away
and
made
some
more
changes
and
thrown
them
away.
So
so
yeah
still
working
on
it.
A
Awesome
thanks
for
giving
us
that
detail
there.
Are
you
getting
all
of
the
help
that
you
need
right
now
sounds
like
you've
had
a
couple
of
pairing
sessions.
E
Oh
yeah,
dennis
dance
has
been,
has
been
great
to
to
jump
on
and
empower
with
me
at
the
moment,
though,
I
feel
like
I've
taken
too
much
of
dennis's
time
and
and
partially.
I
also
just
kind
of
want
to
try
and
figure
this
out
on
my
own
at
the
moment,
but.
D
A
Awesome
and
then
I'll
just
mention
the
story.
I
think
it's
come
up
a
few
times
community
meetings.
This
is
adding
some
metadata
to
an
image
package
or
sorry,
a
k
build
lock
file
still
working
through
this.
It's
in
review
right
now.
F
You
can
give
a
little
color
there
we're
super
close.
The
only
thing
that's
left
at
this
point
is
when
you
have
multiple
overrides,
how
they
merge,
how
they
play
with
each
other.
Once
we
get
that
we'll
be
able
to
finish
that
up
and
the
other
cool
thing
about
that
is
then,
then
we'll
be
able
to
cut
a
build
of
of
k,
build
so
a
new
release
of
k
belts.
We're
excited
about
that.
A
A
A
I
added
the
first
one,
the
ytt
open
api
feature
proposal
summary
and
decisions
made
this
would
kind
of
be
going
over
something
we
talked
about
a
few
weeks
ago
to
just
give
a
high
level
overview
of
you
know
where
we
landed
with
the
open
api
proposal,
as
we've
now
begun
work
on
it,
and
the
second
topic
is
schema
default,
behavior,
discussion
and
examples.
A
E
E
You
know
we
want
people
to
be
able
to
provide
packages,
and
you
know,
and
then,
when
you
install
that
package,
you
need
to
be
able
to
configure
it
and
with
the
current
cli,
it's
there's
no
means
to
like
just
get
that
values
file,
and
you
know-
I
think
I
might
have
mentioned
this
this
this
before
in
this
form,
and
we
might
have
talked
about
it
a
little
bit,
but
you
know
I.
E
I
know
that
that
the
jamal
contains
this
open
api
schema
that
that
can
list
all
of
the
configuration
values
that
are
available,
and
I'm
just
wondering
you
know.
Are
there
any
tools
like
in
cap
or
anything
like
that?
That
already
exists
that
it
could
basically
just
query
that
package
ammo
and
you
know,
for
the
open
api
schema
and
then
just
generate
a
file
like
with
all
the
config
items
in
the
default
value,
or
you
know
versus
somebody.
A
A
E
Oh
yeah,
I
didn't
think
about
sharing
my.
I
don't
know
if
I'm
ready
for
that.
G
If
I
have
to
chime
in
tell
me
if
I'm
not
understanding
it
correctly,
but
what
you're
trying
to
say
is
that
a
package
might
have
a
long
open
api
schema
in
the
package
cr
and
now,
as
a
user.
When
I
have
to
start
configuring
the
package
I
have
to
actually
go
to
the
open
api
schema,
somehow
convert
it
into
a
values.yaml
so
that
I
can
provide
it
while
installing
the
package
and
that's
not
a
straightforward
process,
there's
a
manual
step
request
right
there.
G
E
Yeah
and
actually
I
actually
yeah,
I
can
share
my
screen
just
to
show
a
quick
example
if,
if
carly,
if
you
wanted
to
okay
sure,
let's
make
sure
I
get
the
right
thing
so
so,
for
instance,
this
is
a
packyjaml
for
harbor
and
you
can
see
that
they've
defined.
You
know,
value
schema
and
there's
there's
quite
a
bit
of
of
different
options,
and
you
know
so
to
to
be
able
to
yeah
configure
harbor.
It's
like
I
need.
E
I
need
a
values.yaml
file
that
basically
contains
you
know
a
good
chunk
of
all
of
these
configuration
parameters
and
I'm
just
wondering
if
there,
if
there
is
any
sort
of
way
to
just
generate
a
yaml
file
from
this.
G
F
Yeah
I
it's
not
it's
not
exactly
the
same
thing.
It's
it's
said
that
this
request
was
made
for
ytt
itself
for
ytt
schemas,
which
brings
you
a
little
bit
closer.
If
you're,
using
ytt
as
your
templating
engine,
then
you'll
have
in
the
schema
definition
will
actually
be
pretty
pretty
darn
close
to
like
what
might
be
a
starter,
but
that's
not
the
same
thing
of
what
you're
asking,
which
is.
If
I
had
an
open
api
schema,
can
I
can
I
generate
that.
F
So
this
isn't
an
answer
to
your
question,
but
it
is
something
where
there
there
is
some
conversation
around
like
what
challenges
there
are
around
that
in
in
that
issue.
C
E
All
right,
but
it
doesn't
sound
like
that
there
are
any
tools
or
anything
that
exists
right
off
that
I
guess
that
would
do
exactly
what
I
want.
Okay.
A
Yeah,
definitely
chime
in
in
that
issue.
If
you
want
to
share
your
thoughts
on
how
this
could
be
done,.
G
A
All
right,
so
we
have
two
other
discussion
topics.
A
Yeah,
I
think
garrett,
the
other
one
was
yours
right.
So
do
you
have
a
preference
necessarily?
I
think,
at
least
for
the
topic
that
I
put
down
for
the
open
api
feature.
It
might
be
a
bit
of
a
recap
for
some
people
who
have
been
in
the
previous
discussion
for
open
api
proposal.
C
A
C
C
What
it
does
is
it
overrides
the
defaulting
behavior
of
certain
of
whatever
node
you
attach
it
to
so
there's
a
definition
here
as
like
the
second
point,
but
let's
first
remind
ourselves
of
how
the
defaulting
behavior
currently
is
without
the
schema
default
annotation.
C
So
if
we
provide
a
data
value
with
just
the
name
for
the
key
run
or
just
value
for
the
key
run,
then
the
name
field
will
be
automatically
filled
in,
so
the
data
value
schema
will
automatically
insert
any
item.
That's
missing
from
the
map
with
the
defaults
that
were
implicitly
defined
in
the
schema,
so
the
schema
default
annotation
is
the
way
to
explicitly
define
a
default
value
for
a
certain
node.
C
So
if
we
scroll
down
here
a
little
bit,
we
see
the
same
example
here,
as
you
would
a
similar
example,
but
with
the
schema
default
annotation
now,
so
we
just
have
one
file.
It
is
our
data
value
schema
and
above
the
node
job.
We've
defined
a
default
value
of
a
map
with
a
single
key
run
same
way
that
we've
defined
a
value
here
in
data
values.
C
C
C
D
C
Yeah,
that's
a
good
point.
So
when
the
values
are
scalars,
that
means
strings
and
floats
the
defaulting
behavior
for
maps
is
simple.
It's
implied,
and
it's
always
going
to
show
up,
so
you
could
always
just
change
your
schema
file.
If
you
wanted
to
change
the
default
value
where
it
really
comes
into
play
is
with
arrays.
So
if
we
ran
this
is
a
more
complex
example
where
we
have
a
database
with
an
array.
Arrays
by
default
are
empty
for
their
value.
C
So
if
you
want
to
provide
array
items
in
your
data
values
file,
they
would
then
show
up.
But
if
you
didn't
supply
this
data
values,
file
you'd
see
databases
in
an
empty
array,
so
this
would
be
helpful
for
someone
who's
writing
a
schema
file
to
actually
have
a
way
to
supply
defaults
without
writing
their
own
data
values
file.
C
So
you
know.
In
this
example,
we
have
a
array
item
with
a
map
that
has
six
map
items
and
in
our
data
values
we're
supplying
subsets
of
these
of
this
map
and
even
an
empty
map,
and
you
see
that,
like
for
the
empty
map,
all
of
this
is
filled
out
with
the
defaults
from
schema.
Otherwise,
like
uaa
should
be
overwritten
here,
but
the
rest
were
from
the
schema
defaults
and
then
scrolling
down
to
what
that
would
look
like
with
the
schema
default
annotation.
C
F
F
A
I
also
see
like
an
advantage
to
having
these
well
option.
Two,
the
default
values
filled
in,
in
addition
to
sorry,
the
the
merge
of
the
values
below
the
schema
default,
annotation
plus
what
is
in
the
schema
default
annotation,
like
the
advantage
of
that,
is
that
you
have
all
of
these
other
values
filled
in
and
you're,
making
an
assumption
that
a
reasonable
default
and
then
in
order
to
have
an
entry
in
this
array,
these
values
may
be
defaults
that
you
want.
A
C
Yeah,
it's
true
like
if
the
secret
ref
key
was
something
that
you
necessarily
didn't
need
or
wouldn't
be
used,
and
you
didn't
want
to
expose
anything
like
that.
You
could
add
the
nullable
and
you
wouldn't
have
that
key
anymore
if
it
wasn't
supplied
through
one
of
these
defaults
or
a
data
values
file,
okay,
yeah,
so
we
just
wanted
to
expose.
C
You
know
this
choice
that
we're
making
and
it
seems
like
we're,
really
leaning
option
two
here
and
you
know,
wanted
to
put
this
out
to
the
community
to
see
if
it
aligned
with
what
your
thoughts
might
have
been
when
hearing
about
the
scheme
of
default
annotation
or
for
the
first
time
or
not.
So,
please
feel
free
to
reach
out
to
us.
If
you
wanted
to
extend
this
conversation,
that's
good
carrie.
A
Cool
we
have
some
time
left
so
I'll
talk
a
bit
about
the
open
api
feature
proposal
summary
and
decisions
made
so.
A
As
part
of
the
proposal
for
this
feature
that
we're
doing
in
ytt
to
take
a
data
value
schema
file
and
generate
an
open
api
3.0
document
from
it,
we
made
some
decisions
on
how
we're
going
to
translate
that
data
values
schema
into
the
open
api
document,
and
I
just
wanted
to
give
a
little
bit
of
clarity
around
like
you
know.
How
did
we
decide
on
on
the
command
name
or
sorry,
the
flag
names?
A
And
you
know
why
did
we
choose
open
api
3.0
versus
3.1
and
these
sorts
of
things
that
I've
gotten
a
few
questions
on
lately,
just
to
kind
of
spread
awareness
and
also
like
open
up
this
for
discussion?
If
someone
is
like,
oh
did
you
consider
this,
you
know
now
would
be
a
good
time
to
bring
that
up
and
kind
of
hash
through
any
ideas
that
you
have
here.
A
C
A
It
also
takes
an
additional
flag
output,
open
api
v3
to
the
reasoning
behind
the
first
part
of
this
flag.
Is
it
follows
the
same
conventions
of
a
flag
that
already
exists
in
ytt,
so
there's
a
list
of
the
current
flags
just
down
here,
and
it
follows
the
same
format
as
the
data
values
in
spec
flag
that
exists.
Currently
what
this
flag
does
is
it
takes
your
configuration
inputs,
your
data
value
schema
files
and
your
data
values,
files
and
prior
to
those
data
values
being
inserted
into
templates.
A
This
is
helpful
for
debugging.
You
know
if
you're
something
templates
that
you're
like
what
how
did
that
get
calculated.
This
is
the
flag
that
you
use
to
determine
how
those
values
got
merged
together.
A
A
Merge
those
values
together
and
when
used
with
the
dash
o
open
api
v3
flag,
I'll,
put
those
merged
data
value,
schema
files
in
open
api
v3
format.
A
A
Additional
thoughts
that
were
put
into
the
dash
o
flag
was
currently
the
dash
o
flag
can
be
used
with
any
of
ytt's
output
any
other
flag.
You
can
use
it
on
a
simple
invocation
of
ytt,
ytt,
f,
config
dash
o
and
you
can
provide
either
yaml
or
json
and
it'll
change
the
output
format.
A
A
Okay,
cool.
The
other
thing
I
wanted
to
talk
about
was.
A
A
3.0.12
or
are
actually
all
the
same
specification,
just
different
versions
of
the
documentation
so
actually
have
no
functional
differences
between
versions.
You
know
3.0
point
x,
our
options
were
3.0
versus
3.1.
A
We
chose
3.0
because
there
are
quite
a
few
tools
that
support
3.0,
so
there's
this
website
here
that
lists
a
lot
of
open
api
tools
and
what
versions
they
currently
support.
So
this
was
helpful
in
the
decision
making,
because
we
expect
that
ytt
open
api
schema
will
be
used
in
a
variety
of
ways.
A
A
A
A
So
the
metadata
includes
information
like
what
version
of
open
api
you're
using
what
version
of
this
document.
This
is
a
title,
and
it
also
includes
this
paths
key
which
is
not
applicable
to
ytt,
but
it
is
required
by
the
open
api
spec.
A
Because
without
this
additional
metadata,
you
know
following
the
open
api
spec,
it's
not
a
complete
open
api
document
and
so
other
tools
that
will
be
validating.
This
document
would
see
this
as
invalid.
A
D
D
A
A
And
can
be
manually
changed,
I
think
in
the
future.
We
can
totally
expose
a
way
to
change
that
version.
I
think
that
that
would
be
a
great
idea,
it's
not
in
like
the
current
mvp,
but
I
think
it's
totally
a
reasonable
feature
that
makes
sense
cool.
D
A
Yeah,
okay,
I
think
that
makes
sense.
The
name
space
is
open
to
do
3.1.
So
I
think
that
makes
no
sense.
F
I
guess
along
those
lines,
was
there
any
considering
calling
this
one
version.
3.0.
A
So
I
chose
to
follow
a
similar
format
to
what
kubernetes
uses
in
their
configuration
for
crds.
So
I
think,
there's
an
example
in
here
somewhere,
so
so
yeah
I
mean
this
is
actually
a
cap
controller
package,
custom
resource,
but
kubernetes
has
a
very
similar
key
and
they
use
the
format
open
api
v3,
and
so
I
chose
to
follow
that
same
pattern.
D
I
wonder
without
knowing
too
much
about
the
details
about
what
kubernetes
is
doing
here.
I
wonder
if
you
could
give
it
a
3.1,
open
api
or
a
3.0
open
api,
and
it
just
knows
how
to
pass
and
deal
with
those
two
different
versions,
whereas
l1
is
very
specific
to
just
a
3.0
it's
you
know,
it
doesn't
know
how
to
generate
a
3.1
or
never
will
be.
D
F
Yeah,
I
do
know
that
there's
been
developments
in
the
kubernetes
community
in
adopting
3.1
like
making
work
to
move
closer
to
that.
So
I
wonder
if
there's
a
clue
there
as
well,
that
doesn't
withstand
your
point.
Then,
is
that
that's
a
consumption
side
selector?
It's
like
okay,
any
version
of
3-0,
we'll
figure
it
out,
which
is
different
than
the
generation
side,
which
is
where
we
are
at
producing.
Do
you
want
a
3-0?
Do
you
want
3-1?
We
could
do
either.
A
All
right
well,
thank
you
all
for
joining
today's
carver
community
meeting.
We'd
love
for
you
to
join
us
live
if
you're
watching
this
from
home.
So
please
do
join
the
meeting.
Thursdays,
10
30
pacific
time
until
next
week
take
care.