►
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
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.
A
A
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
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
E
D
A
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
E
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
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.
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.
C
E
A
G
A
C
A
C
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
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
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
A
A
A
A
A
A
A
A
A
A
A
A
D
D
A
A
D
A
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.