►
From YouTube: Carvel Community Meeting - August 19, 2021
Description
Carvel Community Meeting - August 19, 2021
We meet every Thursday at 10:30am PT. We'd love for you to join us live!
Full details on this week's meeting here:
https://hackmd.io/F7g3RT2hR3OcIh-Iznk2hw#August-19-2021-Agenda
A
Hi
everyone
welcome
to
this
week's
edition
of
the
carville
community
meeting.
Today's
date
is
august,
19th
2021,
if
you're
tuning
in
in
from
home,
watching
this
as
a
recording,
we
encourage
you
to
join
us.
Live
we
meet
every
thursday
at
10
30
a.m.
Pacific
time
it's
an
opportunity
for
you
to
come
meet
the
team
you
can
lurk
in
and
just
listen
in
on
what
we're
working
on
or,
if
there's
something
that
you
need
help
with.
A
We
also
would
love
to
hear
from
you
regarding
that
as
well.
If
you
aren't
able
to
attend
any
of
the
meetings
live,
you
can
share
with
us
through
a
couple
of
other
options.
We
have
slack
and
twitter
kubernetes
slack
workspace
and
the
carville
channel,
if
you're,
not
part
of
the
kubernetes
select
workspace
you'll
just
need
to
request
an
invitation
to
join.
It's
really
easy.
A
We
ask
that
when
you
attend
these
meetings
too,
please
read
and
abide
by
our
code
of
conduct
and
add
your
name
and
the
organization
that
you
represent
here
in
the
attendees
section.
That
helps
us
understand
who,
outside
of
vmware,
is
attending
these
meetings
and
to
keep
those
lines
of
communications
open.
B
I
know
if
garrett
was
here:
he'd
have
some
details.
He
was
a
big
part
of
that.
I
think
in
general.
The
theme
here
was
improving
error
messages
that
are
coming
out
of
our
newly
ga
schema
features
and
a
few
kind
of
internal
cleanups
yeah.
So
these
these
are
some
follow-ons
from
from
that
scheme
of
work.
A
Great
thanks,
john
next
up
just
a
reminder
to
register
for
the
spring
one
workshop
that
we
have
coming
up
on
thursday
september,
2nd.
If
you
are
wanting
to
learn
more
about
carville
or
you
know,
you're
still,
maybe
just
using
a
couple
of
the
tools
that
want
to
learn
more
about
some
of
the
other
ones.
This
is
a
good
opportunity
for
you
to
get
more
hands-on
with
learning
how
to
use
all
the
tools
in
the
carvel.
A
C
C
What
I
would
consider
like
one
of
the
the
big
initial
hurdles,
which
is
just
kind
of
like
a
a
steel
thread
of
the
package,
install
experience
so
just
just
wrap
that
part
up
and
just
continuing
to
keep
keep
focused
on
this.
I
don't
know
joe
dimitri
anything
else
that
you
want
to
add
to
this.
C
C
Yeah,
so
the
the
second
one,
I
think
we
actually
have
a
discussion
item
to
go
over
the
the
proposal
for
the
exporting
ytt
schema
as
an
open
api
schema,
so
we'll
probably
chat
about
that
a
little
bit
more.
The
third
row
around
just
api
package
management
api
enhancements.
This
was
for
like
a
fairly
generic
placeholder,
and
we
should
probably
update
this,
but
nothing
specific
to
call
out.
There
is
just
like
general
ux
improvements,
and
this
page
was
less
updated
last
month.
A
Cool
thanks
erin,
and
will
you
be
updating
that,
should
I
put
down
an
action
item.
A
C
D
D
This
was
a
story
I
picked
up
a
few
weeks
ago
went
on
vacation,
so
it
is,
it
is
getting
attention
once
again
and
then
yeah
otherwise.
For
me,
just
working
through
the
open
api
proposal.
E
One
thing
that
I
worked
on
recently
and
actually
failed
to
let
nancy
know,
there's
a
new
vendor
release
that
included
a
few
collected
items.
One
of
those
items
actually
was
a.
E
Support
for
automatic
tag
selection
when
fetching
things
like
an
image
or
image
package
bundle
from
a
registry.
There
was
also
a
few
other
enhancements
done
by
the
community
members
that
are
called
out
in
the
release
notes
in
vendor.
So
that's
something
that's
something
to
take
a
look
at
if
using
that
too.
A
Thanks,
dimitri
yeah,
I
I
actually
saw
I
was
tagged
in
the
github
one
and
I'll
make
sure
to
tweet
that
out
that
that
release
happened.
A
Okay
onward
to
discussion
topics
and
again,
if
you
have
anything
that
you
wish
to
discuss
with
the
team
or
share
with
the
community,
please
be
sure
to
add
that
in
this
section
here
and
we'll
get
to
it,
first
item
is
something
that
I
added
in
here
wanted
to
bring
this
to
the
community.
We
are
calling
on
y'all
to
share
with
us
if
you're
using
carvel,
we
would
love
to
hear
from
you
first
off.
Thank
you
for
using
karvel.
We
want
to
hear
from
you.
How
are
you
using
it?
A
A
All
you
need
to
do
is
go
to
this
pinned
issue
and
share
a
comment
with
the
following
information:
your
organization
or
company,
the
link
to
your
website,
the
country,
your
contact
information.
A
A
D
D
I
would
love
to
get
others
feedback
on
what
is
currently
being
proposed
and
if
you
know
others
see
any
issues
or
have
alternatives
that
they
would
like
to
mention,
and
that
would
be
a
great
time
for
that,
and
also
like
feel
free
to
interrupt
me
and
ask
questions
about
the
proposal
as
I
kind
of
go
over
it
or
bring
something
up
if
you're
like.
I
don't
know
what
that
word
means,
or
you
know
something
like
that.
That
feel
free
to
interrupt.
D
E
D
D
So
the
current
proposal
introduces
two
flags,
so
the
current
ytt
flags
look
like
this:
there's
a
files,
inspect
data
values,
inspect
data
values
and
spec
text
and
that
show
json
to
change
the
output
format.
D
That's
specifically
this
flag,
when
you
use
it
with
dash
o
open
api,
there's
also
a
flag
for
just
viewing
the
schema
in
ytt
format
and
then
there's
also
a
flag
for
viewing
the
schema
in
open
api
full
format.
So
this
would
be
not
just
the
schema
portion
of
the
open
api
document,
but
also
including
the
headers
and
metadata
that
that
comes
with
that,
such
as
version
scroll
down
to
so
what
that
looks
like
that's
these
additional
fields,
open
api
version
and
info,
where
you
can
give
a
little
bit
of
a
description
about
the
document.
F
Just
a
clarifying
question
in
the
current
flag
set:
is
there
a
missing
space
that
last
one
ytt
data
values
inspect
dash?
Oh,
is
it
is
it
ojson?
All
is
one
thing.
E
Yeah,
because
the
show
takes
you
know,
takes
an
argument.
Cobra
is
smart
enough
to
understand
that
whatever
comes
next
is
for
their
show
now
for
booleans,
not
gonna
work.
F
Okay
thanks,
I
just
want
to
make
sure
we
weren't
introducing
inconsistency
thanks.
C
D
Okay
cool
so
now
that
you
have
sort
of
an
overview
I'd
like
to
talk
about
how
this
would
be
used
specifically
in
cap
controller.
So
cap
controller
is
one
of
the
users
of
this
open
api,
spec
or
open
api
schema
and
cap
controller
has
a
field
in
the
package
cr.
So
this
is
cap
controller
stocks,
there's.
D
D
So,
cap
controller,
being
you
know,
one
of
the
users
of
this
has
sort
of
a
specific
use
case.
So
in
the
proposal
there's
a
recommended
workflow
of
how
you
would
insert
that
the
open
api
schema
into
a
cap
controller
package
cr
and
that
workflow
is
fairly
straightforward.
You
know
you'd
create
the
schema
from
a
data
value.
Schema
file
might
look
like
this.
D
D
You
have
to
name
the
data
value
using
this
method,
so
call
it
open
api
schema
and
that's
what
this
syntax
is
and
then
in
your
package,
cr,
all
you
need
to
do
is
import.
D
D
D
And
so
the
reason
I
bring
this
up
is
because
you
know
this
is
what
we
believe
is
the
simplest
workflow
for
using
this
open
api
schema
with
cap
controller
and
I'm
curious
to
get
feedback
from.
Maybe
those
who
work
on
cap
controller
on
whether
there's
anything
about
this
that
you
know
doesn't
make
sense
or
would
be
you
know
a
rough
edge
or
you
know
anything
like
that.
Anything.
You
notice
I'd
love
to
hear
from
those.
E
I
think
this
is
a
fairly
fairly,
I
think,
good
attempt
and
how
we
can
insert
this.
You
know
this
chunk
of
yaml
into
into
another
chunk.
One
unknown
I
have
in
my
mind
is
this
is
something
that
we
haven't
really
firmed
up,
as
a
recommendation
from
the
packaging
team
is
how
does
one
actually
kind
of
what's
the
workflow
that
we
recommend
for
producing
and
storing
the
package
crs
right?
E
So
currently
we
just
say
produce
a
package
cr
and
then
you
know
include
it
in
your
repo
bundle
where
it's
going
to
get
used
by.
You
know
some
other
tooling
right.
We
we
don't
really
recommend
right
now
to
at
least
try
to
template
the
package
crs
right,
because
you
know
once
you
introduce
templating.
That
means
that
you're
kind
of
maintaining
a
live
set
of
you
know
of
configuration
versus
we
see.
Package
cr
is
more
like
a
record
in
time
right
like
once,
you
create
it.
It's
there.
E
You
you
shouldn't
probably
be
you
know,
messing
around
with
it
or
regenerating
it
or
something
like
that
right,
and
so
you
know,
I
guess:
how
does
that
relate
to
what's
kind
of
the
example
that
you're
the
example
workflow
that
you're
providing?
Is
that?
Probably
then
you
know
this
package
yaml
really
acts
as
that
starter
right,
and
then
the
output
of
that
ytt
command
would
be
like.
Okay,
here's
the
here's.
The
package
here
that
got
generated,
save
it
right,
save
it
into
the
git
repo
directly
right.
E
So
don't
don't
keep
on
regenerating
anything,
so
that's
definitely
a
viable
way
to
to
to
kind
of
glue
those
things
together
right.
You
know.
Obviously
you
know
everybody
has
access
to
bash,
so
they
can
try
to
glue
it
directly
in
bash
without
without
ytt,
but
that's
probably
not
ideal,
since
you
then
have
to
figure
out
to
indent
certain
things
and
whatnot
so
yeah.
So
this
this
is,
this
is
pretty
good
will.
E
Probably
this
is
more
what
to
do
for
the
packaging
teams,
we'll
probably
need
to
circle
back
and
actually
provide
some
general
recommendation.
We've
been
working
with
a
few
vmware
teams
that
are
consuming
this
packaging
format,
so
this
is
the
this
recommendation
would
probably
be
very
helpful
to
them.
D
Yeah,
that's
a
that's
a
great
call
out.
Like
you
know,
package
ceos
right
now
aren't
normally
generated
using
ytt
templates,
so
that
would
be
a
bit
of
a
different
workflow
than
his
current
yeah.
D
Yeah,
that's
interesting,
because
we
definitely
want
to
recommend
that
you
know
this
doesn't
get
regenerated.
If
a
ytt
data
value
schema
file
gets
updated
right
because
I
think
a
package
cr
is
like
a
tied
to
a
version
right,
so
it
doesn't
necessarily
get
updated.
E
D
E
Yeah,
this
kind
of
gets
back
into
a
question
of
what
is
that
system
that
people
use
to
keep
track
of
this
package
crs
right?
They
might
have
a
ci
pipeline
that
says,
okay,
this,
this
version
of
a
package
is
good,
we'll
publish
that
up
to
the
to
the
to
the
registry,
and
then
we
will,
you
know,
have
this
package
cr
dropped
in
into
some.
You
know
folder
in
a
git
repository
or
something
like
that,
and
so
I
think
actually
now
that
I
think
about
it.
E
You
know
the
other
pieces
in
the
package
here
are
like
a
version,
for
example,
need
to
be
inserted
in
right
or,
for
example,
the
reference
the
digest
reference
right
should
be
placed
into
the
package
cr
at
the
time
of
the
creation
of
the
package
cr,
so
there's
other
pieces
of
information
that
need
to
go
in
so
this
would
be.
E
D
Yeah
yeah.
That
makes
a
lot
of
sense
that
that
definitely
seems
like
something
that
maybe
you
know,
the
packaging
team
wants
to
kind
of
standardize
like
it
seems
like
this
templating
or
this
proposal
for
how
to
insert
the
open
api
schema
is
just
one
aspect
of
that,
and
there's
probably
something
larger,
that
that
could
be
done
for
like
the
entire
package
cr
document.
E
I
have
a
by
the
way-
I
don't
know
if
this
is
a
this
is
an
accident
here,
but
it
seems
like
the
indentation
disappeared
on
that
package
cr
for
some
of
the
things
I
don't
know,
if
it's
just
the
browser
bug.
B
E
I've
been
beaten
by
github
and
firefox
now
working
this
week
very
well
with
indentation.
So
I
don't
know.
G
E
I
really
like
this
question
because
it
it
poses
a
you
know,
should
we
be
actually
using
v3
as
a
suffix
in
the
generation
side
of
things
right
because,
let's
say
when
open
api
v4
comes
out
right,
what
is
dash
o
open
api
really
mean
right,
and
I
I'm
guessing
that's
where
you
were
going
at
yeah
the
generation
part
of
it
yeah.
E
Maybe,
as
a
side
note,
the
reason
why
we
picked
open
api
v3
is
this
something
that
kubernetes
uses
in
the
crds
as
a
key
as
well,
so
we're
trying
to
be
aligned
with
that,
but
yeah.
I
think
I
think
when
we
would
finalize
the
the
show,
let's
say
naming
right:
we
should
actually
be
more
strict
about
what
what
is
the
thing
that
we're
generating
here.
C
E
From
a
packaging
perspective,
one
reason
why
we
really
want
everybody
to
to
be
using
the
same
things
right
is
we
don't
want
the
clients
to
be
struggling
with
trying
to
figure
out?
What
are
the
you
know
tons
of
possible
variations
right?
This
is
a
similar
kind
of
like
you
know.
Originally,
you
know
there
were
questions
around
like
well.
Should
we
be,
you
know
exposing
the
ytt
schema
here,
but
maybe
for
packages
that
use
you
know
helm
template
underneath.
H
D
And
I
know
that,
like
the
open
api
version
between
v2
and
v3
is
really
different,
like
a
lot
has
changed,
so
it
seems
like
an
important
distinction
to
to
say
what
format
it
is.
D
Normally,
when
you
have,
when
you
have
an
entire
open
api
document,
it
includes
the
open
api
version.
Specifically,
however,
the
cap
controller
and
the
kubernetes
crd
only
includes
the
component
that
schema
section
of
that
document,
and
so
it
emits
the
open
api
version,
which
is
maybe
why
they
chose
to
inline
it
because
they
don't
include
the
entire
document.
There.
E
They
end
up,
they
end
up
generating
this,
as
like.
A
full
document
is
being
generated
at
a
particular
api
endpoint,
so
that
you
know
they're
in
control
of
you
know
the
actual
surrounding
other
information.
E
D
D
You
know:
how
will
other
people
be
using
this
open
api
schema
that
gets
generated
like
you
know,
do
they
need
to
know
the
version
that
was
used
in
order
to
create
the
open
abs
schema?
Because
it's
not
like
in
the
current
proposal.
It's
not
included
the
version
information
so,
for
example,
the
open
api
scheme
that
will
get
generated
looks
like
this.
D
It's
just
the
schemas
section,
so
it
doesn't
include
the
version
which
would
look
like
this
if
it
did
include
the
version
so
yeah,
if
somebody
was
just
outputting
this
to
a
file
to
use
as
like
documentation
for
their
ytt
configuration
it
wouldn't
it
would
not
include
the
open
api
version
or
anything.
Other
information
like
that
that
you
know
people
may
want
to
see
by
default.
There
is
a
command
proposed
to
include
all
of
the
headers
that
includes
a
version
using
this.
C
I
think
maybe
I
was
making
some
assumptions
from
this
conversation,
but
I
I
I
was
taking
away
that
we
would
update
the
flag
from
open
api
to
be
open
api
v3
and
then
have
an
open
api
v3
dash
full
as
well,
but
maybe
maybe
I
misinterpreted
some
things
earlier.
G
That's
what
I
was
going
with
it,
that's
what
was
my
thought.
You
know
when
v4
comes
out
and
they
want
to
use
a
v4
generator.
V4
schema
will
be
open.
Api
v4-4.
D
D
Cool,
so
we
haven't
really
come
to
an
agreement
on
what
the
flag
name
will
be.
I
think
there
are
a
lot
of
good
options
out
there.
The
one
that's
currently
being
proposed
is
like,
for
example,
in
this
scratch
pad
that
I
have
here
this,
the
the
ones
that
are
being
proposed
here.
D
This
command
kind
of
plays
off
of
the
command
that
we
have
right
now.
Data
values
inspect
the
way
that
command
works
is
all
of
the
data
values
and
schema
data
value
schema
files
that
you
input
into
ytt.
D
It
would
be,
it
would
also
include
the
annotations
that
are
present
in
a
data
value
schema
document
like,
for
example,
the
annotations
exist
right
now
are
like
pound
at
schema
type
any
and
schema
slash,
nullable
those
sorts
of
things.
That
document
exactly
like
what
the
schema
document
allows.
G
D
D
E
Yeah
there's
a
I
forget
what
we
do
for
data
values,
but
I'm
pretty
certain.
We
don't
go
on
and
kind
of,
recursively
show
that
information,
mostly
because
you
know
when
you're,
ultimately
working
with
the
root
library,
right
and
so
you're
trying
to
figure
out.
How
do
you
configure
it
now?
There's
obviously
some
use
cases
where
you
may
want
to
configure.
E
You
know
a
library
instance:
that's
been
instantiated
by
the
root
library,
but
it
is
today
we
don't,
we
don't
expose
it.
If
we
would
expose
that
information,
I
would
imagine,
then
we
need
to
have
a
more
general
way
to
select
which
library
you're
looking
at
right.
It
wouldn't
be
like
specific
to
data
value
schema.
It
would
be
specific
to
everything
right,
like
maybe
the
entire
output,
maybe
the
the
the
data
value
well,
not
maybe,
but
for
data
values
for
schemas
for
the
output
for
overlays
all
that
stuff.
D
B
It
also
doesn't
feel
like
it's
too
onerous
on
users.
If
you
want
to
see
the
schema
for
a
library,
you
can
target
your
ytt
invocation
to
that
library
and
include
this
flag
and
you'll
get
the
schema
for
that
library,
because
at
that
point,
that
invocation
will
see
that
library
and
its
data
value
schema
will
be
the
subject
the
root
and,
if
you're,
if
you
are
using
library
ref
to
provide
data
values
to
a
to
a
dependency
of
your
root
library
already,
then
it's
already
a
separate
file.
B
D
D
Now
there
were
some
that
use
the
word
generate
and
create
which
I
I
think
it's
a
great
idea,
but
does
not
follow
the
current
pattern
that
we
have
for
other
flags
and
following
the
same
pattern,
is
one
of
the
main
motivations
for
why
I
chose
the
data
value
schema
in
spec
command
because
it
mirrors
the
ones
that
already
exist,
but
I
am
happy
to
consider
ones
that
use
the
word
create
or
generate
more,
if
others
feel
strongly.
C
I
I
was
thinking
about
this
a
bit
because
inspect
feels,
like
you
know,
it's
retrieving
information
that
currently
exists,
whereas
we
do
kind
of
create
an
a
bit
of
new
information
from
existing
information.
So,
like
I
thought
about
it
a
little
bit,
but
ultimately
I'm
fine
with
it,
but
just
wanted
to
share
that
thoughts.
I
don't
know
if
it
resonates
with
with
other
folks
or
or
even
like
the
current
usage
of
the
existing
commands
and
flags.
E
One
thing
that,
on
the
side,
we're
discussing
with
john
is
kind
of
at
a
high
level.
What
are
we
like
is
there?
Is
there
some
how
you
call
it
a
more
holistic
way
to
look
at
this
stuff
right?
If
you're
going
to
kind
of
imagine
ytt
as
a
pipeline
right
where,
throughout
that
pipeline,
there's
the
schema
evaluation,
then
there
is
the
data
value
evaluation.
Then
there
is
finally
the
templating
and
there's
finally
the
overlaying
and
then
well
that's
the
end
right.
E
We
are
inspecting
a
schema
at
a
particular
point
right
at
the
beginning
of
the
pipeline,
because
it's
the
first
thing,
the
data
value
schema
specifically
not
just
journal
schema,
and
I
think
I
know
we
were
toying
around
with
kind
of
different
ways
to
really
think
about
it.
I
think,
at
least
in
my
mind
so
far,
what
I
have
is
we're
just
presenting
ytt
schema
in
a
different
format.
E
Now,
what
does
that
mean
to
use
dash
open
api?
Let's
say
in
a
different
context,
that
kind
of
gets
into
a
very
hypothetical
world
like
what
is
the
input
to
that
right?
Like
typically,
it's
ytt
schema.
But
what
is
the
input
you
know
to
the
other
thing?
If
you're,
I
don't
know,
maybe
maybe
you're
saying
you
see-
data
values
in
spec
dash
open
api.
What
does
that
mean,
but
anyway,
so
that
that's
kind
of
why
I'm
leaning
towards
inspect
is
because
we
are
just
inspecting
part
of
a
pipeline?
E
E
I
don't
know
post
templating,
that
kind
of
thing
right,
but
but
I
think,
if
we're
going
to
generalize
some
of
that
stuff,
then
we
should
probably
have
a
more
more
complete
view
of
what
we
actually
would
want
to
to
show
like,
for
example,
should
we
be
allowing
people
to
see
the
output
after
each
overlay,
for
example
right
that
kind
of
thing,
which
would
be
really
handy
if
you're
actually
seeing
it
like
after
this
overlay?
This
change
happened,
but
then,
like
you,
know,
click
on
the
next
button.
E
Here's
the
next
change
happening
on
the
next
overlay,
so
it
would
be
really
useful
for
debugging,
but
also
kind
of
consolidates
this
bunch
of
functionality
into
a
more
general
feature.
D
I
like
the
idea
of
having
a
generic
inspect
flag,
but
I
also
like
the
fact
that
they're
specific
to
what
you
want
to
inspect
since
it
allows
you
to
just
invoke
ytt
with
an
entire
directory,
and
you
can
just
get
only
a
specific
part
of
the
files
you
gave
to
ytt
in
that
inspect.
C
I
I
do
have
one
other
quick
question
that
might
have
been
addressed
in
the
proposal.
I
haven't
looked
at
it
in
a
couple
days,
but
the
flag,
I
guess
the
open
api
and
open
api
full.
C
I'm
curious
what
the
thinking
of
here
for
open
api
to
be
just
the
schema
versus
kind
of
like
the
full,
and
then
we
would
have
you
know
something
like
open.
Api
schema
for
just
the
schema,
and
my
thinking
of
that
is
like
open
api
as
like
the
default
option,
would
return
what
you
would
expect
from
an
open
api.
I
don't
know
what
the
output
is
format
or
document,
whereas
the
schema
itself
feels
like
that's
something,
that's
more
specialized
but
curious
to
get
thoughts.
There.
D
So
that's
one
of
the
reasons
why
I
decided
to
choose
it
as
kind
of
the
default
open
api
format.
It's
because
we
know
that
people
at
least
one
user
wants
that
right
now
and
I
don't
have
a
great
idea
of
if
you
know
other
users
will
even
really
need
the
entire
open
api
document
and
so
making
that
the
default
format.
D
You
know,
I
don't
want
to
add
additional
information
to
the
output
that
may
not
even
be
needed.
So
that's
kind
of
that's
kind
of
my
reasoning
behind
it,
but
yeah
curious
what
I
think
others
think.
F
I
could
offer
I
I
don't
think
of
cat
controller
as
a
person.
So
in
specifically,
I
think
cap
controller
gets
to
kind
of
hard
code,
its
own
arguments,
that
it
needs
somewhere
and
then
never
cares
again
if
they
were
wordy
or
long
right
versus.
I
think
a
human
who
stumbles
along
a
few
months
from
now
is
maybe
the
more
interesting
case
to
optimize
like
their
ergonomics
or
their
experience.
F
F
Yeah,
but
I
think
I
I
thought
cap
controller
was
directly
invoking
it.
So
if
it's,
if
it's
humans
in
all
cases,
that's
a
little
bit
that
I
think
that
negates
what
I
was
trying
to
say.
E
Is
there
is
there?
Is
there
open
api
terminology,
for
I
mean
there's,
obviously
a
term
you
know
the
key
that
they
use
schema
as
a
you
know,
as
a
key
for
that
section
right
I
don't
know
if
there's
a
open
api
terminology
for
the
entire
document,
maybe
it's
open
api
document.
I
don't
know
that.
E
Arguably,
maybe
cap
controller
should
have
actually
called
it
open
api
v3
schema
instead
of
you
know,
well
not
doing
that.
B
Yeah,
I
feel
like
this
question
was
a
was
a
bit
about
deciding
which
bias
to
choose.
I
like
the
way
that
you
were
describing
how
you
were
thinking
about
the
decision,
carry.
If
we
look
at
it
from
a
carvel
user,
then
they
already
know
they're
generating
schema
and
it
can
feel
a
little
bit
redundant
in
one's
mind.
If
I'm
saying
data
value,
schema,
inspect
open,
api-schema.
B
B
D
Yeah
yeah,
I
think
I
think
that
also
makes
sense.
I
think
we
should
dig
more
into
that
of
you
know
what
users
expect
from
this
command
or
from
this
flag.
You
know:
is
it
just
cap
control
or
is
it
you
know
to
users?
Have
other
needs
we're
out
of
time
today
to
talk
more
about
this,
but
this
was
extremely
helpful
and
thank
you
all
for
sharing
your
thoughts
on
this
and
asking
questions
hoping
to
continue
this
conversation
in
the
pr.
D
A
Thanks
carrie
for
bringing
that
up
for
discussion
and
thanks
everyone
for
joining
in
if
you're
watching
this
from
home-
and
you
would
like
to
provide
your
own
thoughts
on
this,
please
feel
free
to
drop
those
comments
in
that
doc
that
carry
shared
or
find
us
on
slack
or
twitter.
A
We
would
love
to
hear
from
you
and
also
just
a
reminder,
like
I
mentioned
earlier
in
this
meeting,
we
would
love
to
hear
about
how
you're
using
carvel,
so
please
go
to
that
pinned
issue
and
share
your
details
about
how
you're
you're,
using
any
of
the
cardboard
tool,
suites
tool
tools
and
the
tool
suite
and
with
that
have
a
wonderful
rest
of
your
day.
Thank
you.