►
From YouTube: Carvel Community Meeting - January 13, 2021
Description
Carvel Community Meeting - January 13, 2021
Meeting information and notes can be found here:
https://carvel.dev/community/
A
Awesome
should
we
post
in
our
slide
channels
real
quick
to
notify
people
that
our
community
meeting
is
currently
happening.
A
Well,
while
that's
happening
we'll
go
ahead
and
introduce
everyone
around
the
room,
this
is
the
first
community
meeting
of
2021
and
we're
happy
to
be
here
as
the
carnival
team.
A
So
first
I'm
garrett,
I'm
the
facilitator
for
today
and
I
am
just
a
maintainer
on
the
carmel
tool,
suite
team,
so
we
have
carrie
so
raise
your
hand,
as
I
say,
your
name,
carrie
she's,
also
a
maintainer.
You
have
john
ryan
dennis
leon,
stephen
locke,
dmitry
daniel,
jo
aaron
and
helen
and
aaron
and
helen.
Are
our
team
lead
in
our
pm?
A
A
C
Yes,
my
name
is,
I
am
the
pm
of
the
packaging
and
package
management
team
awesome
well
great
to
meet
you
personally
happy
to
have
you
here.
A
D
I'm
happy
to
talk
about
cat
controller
yeah
treasure
what
yeah
please
go
ahead,
eli
who
actually
couldn't
join
us,
but
eli
has
made
some
changes
to
cap
controller
to
support
custom,
ca
certificates
and
custom
http
proxy
configuration.
So
that
is
a
global
setting
for
cap
controller.
D
A
few
users
have
asked
for
that
functionality,
so
that's
being
delivered
in
our
latest
zero
fourteen
odds.
That's
pretty
much
the
the
chunkiest
part
of
our
of
our
feature
set
there.
A
Thanks
dmitry
for
our
ytt
release,
released
version
0.31.0.
A
We
have
enabled
the
experimental
schema
support,
so
we
currently
have
that
feature
guarded
by
a
flag.
So
if
you
wanted
to
mess
around
and
see
some
of
the
feature
that's
coming
out
in
our
next
schema
work,
you
can
see
what
we
have
so
far
by
enabling
that
flag
was
there
anything
else
in
that
release
that
someone
wanted
to
call
out.
E
Yeah
there
was,
there
was
one
that
sort
of
this
ongoing
little
small
initiative
of
bringing
strucks
and
yaml
fragments
to
be
more
interface
compatible.
I
guess
is
what
you
might
call
them
they
just
that
they
behave
the
same.
This
is
the
next
step.
Now
you
can
iterate
over
structs
and
you
can
use
index
notation
on
them
as
well.
So
that's
much
closer
to
the
combination.
A
F
You
can
point
out
the
new
websites
too,
with
the
docs
integrated
inside
the
website
itself,
so
we'll
be
going
for
maintaining
mainly
the
docs
you
see
on
the
website
and
and
in
the
near
future,
not
sure
when
we're
gonna,
you
know,
remove
the
docks
we
have
in
our
each
of
our
repos.
A
Yeah
and
we'll
be
linking
the
new
docs
from
a
repo
yeah
thanks
helen.
I
think
we
can
move
on
to
our
tech
forum
and
for
the
tech
forum
portion.
I
can
kind
of
step
back
a
little
bit
as
a
facilitator
and
it's
much
more
an
open,
open
floor.
So
we'll
start
with
the
by
reading
off
the
topics
that
we
have
for
today
we
have
dimitri
with
a
an
issue
in
ytt.
A
G
Just
it's
sort
of
putting
this
out
there
45
days,
feels
like
a
little
too
long
for
me
for
an
issue
to
go
stale.
So,
if
we've
had
some
conversation
ongoing,
we
discuss
some
possible
solutions,
we're
waiting
for
more
responses
a
month
and
a
half
feels
just
too
much
for
for
it
to
fall
off
of
our
plate,
and
I
feel
like
at
that
point
or
perhaps
earlier
from
that
point.
G
We
should
be
alerting
the
user
that
hey
you.
We
need
some,
some
more
feedback,
some
more
details
or
a
working
example,
or
something
any
other
opinions
on
that
length
of
time.
H
I
think
in
general,
as
like
part
of
discussing
why
45
days
was
originally
chosen,
was
really
more
out
of
caution,
because
we
just
really
wanted
to
make
sure
that
we
didn't
pick
too
short
of
an
amount
of
time
so
over,
but
like
this
idea
came
up,
even
as
we
were
thinking
about
putting
in
place
the
triaging
process.
H
So
I
I
think
it's
valid
to
have
a
discussion
about
whether
or
not
45
days
is
too
long
and
if
we
want
to
even
bump
it
down
to
even
something
like
a
month
or
even
shorter
than
that.
If
people
think
that's
valuable.
But
I
think
the
amount
of
time
should
be
completely
open
to.
However
long
we'd
like
to
reduce
it.
E
E
E
And
then
like
do
we?
Is
it
easy
to
have
other
options
instead
of
saying,
okay,
we're
going
to
print
preemptively
close
this?
Unless
you
comment
again,
is
there
a
way
of
like
hey
if
nothing's
happened
in
a
couple
of
weeks
to
just
have
like
a
bump
that
doesn't
close
the
issue?
H
I
Yeah
my
take
on
this
is
45
days
to
me
means
the
community
pair
just
has
to
keep
looking
at
this
thread
and
then
just
reading
it
and
then
saying
all
right.
There's
nothing
left
to
do
here
and
that's
a
long
time
to
keep
doing
that
for
a
community
pair,
and
if
we
just
closed
it,
I
don't
know
seven
days
of
no
activity.
I
J
Number,
I
don't
feel
like
that.
The
community
pair
should
be
looking
at
these
stories
after
they
are
replied
to
or
if
we're
waiting
for
something
they
that
the
prior
community
pair.
That
reply
to
this,
like
there
shouldn't
be
like
an
after
until
there's
like
a
response
or
someone
that
gets
into
interests
on
the
issue
and
tries
to
talk
about
it
right.
J
But
it
has
notifications
as
well
right.
That's
like
the
second
thing
that
we
should
look
for.
We
shouldn't
just
randomly
read
all
the
the
ex
all
the
not
accepted
the
ones
that
have
like
carvel
to
forget
the
name
tag
on
it
right.
I
think
I
think
there
should
be
also
like
a
balance,
and
the
community
pair
should
be
aware
of
that
right,
like
if
there's
no
notifications
on
that
particular
issue.
J
J
I
Yeah
we
should
update
the
triaging
docs
to
leverage
that
notification
filter
that
you're
discussing,
because
the
way
I've
been
pairing
with
people
focus
mainly
relying
on
the
carville
tag,
and
that
does
have
issues
that
have
just
not
have
any
comments
responded
on.
It.
I
I
J
A
Yeah
next
topic:
we
could
talk
about
one
of
these
issues.
A
B
D
So
this
is
issue
251,
I've
written
it
up
based
on.
I
guess
this
little
description
or
the
little
problem
that
I
faced
when
working
with
ytt.
So
it's
a
supportive
way
to
replace
single
collection
item
with
multiple
items.
D
From
what
I
remember,
the
gist
of
it
right
is
that
we
may
have
so
we
have
a
way
of
how
we
can
replace
kind
of
the.
D
Well,
let's
actually
go
maybe
through
this
example
first
and
then
we
can
kind
of
actually
how
about
this
can
are
folks
familiar
with
this
thing.
Do
people
want
to
take
like
a
minute
or
two
reading
through
the
issue?
First,
just
to
get
on
the
same.
D
A
A
D
E
So
I
assuming
we're
all
we're
all
good
to
rock
into
conversation.
I
had
a
question
there's
a
way
to
do
this
today.
Why
is
that
insufficient?
D
E
Could
you
just
do
an
overlay,
replace
overlay
match
and
replace
that
dock
and
then.
D
D
Right,
so
that's
actually
I
I
kind
of
been
a
while
here.
So,
let's
see
what
because
I
believe,
there's
a
few
comments
here.
So,
let's
see
what
garrett
said
over
here,
johanna
attempted
to
tell
this
problem
experience
limitations
as
you
describe.
However,
we
still,
we
still
are
still
confused
about
the
use
cases.
The
kind
key
in
the
desired
output
yaml
come
from
kind
list
or
from
the
array
items
kind.
D
So
I
think
I
actually
changed
the
example
to
make
it
more
clear,
just
to
avoid
any
kind
of
duplicate
keys
or
anything
like
that
right.
So
exactly
saying
like,
if
we
have
this
document
set
right,
we
have
this
whatever
two
separate
resources.
D
Clies,
I
believe,
actually
server
as
well.
They
have
kind
list
that
effectively
allows
you
to
group
multiple
resources
in
the
list
right,
so
they're
not
separate
yaml
documents
right,
but
sometimes
you
may
actually
want
to
convert
from
one
thing
to
another
right,
and
that's
that's
actually,
one
of
the
one
of
the
use
cases
that
we're
talking
about
here,
but
this
case
is
just
kind
of
more
general.
I
think
the
other
use
case
that
somebody
was
asking
me
about
is
how
do
I
effectively.
D
I
have
a
bunch
of
yaml
saved
in
a
config
map.
I
want
to
take
that
yaml,
which
has
multiple
documents
in
it
right,
and
I
want
to
effectively
replace
all
of
my
documents
with
this
set
of
yaml
right.
So
it's
kind
of
like
how
do
I
unwrap
something?
That's
wrapped
and
kind
of
move
it
into
the
root.
If
you
will
all
right
so
then,
is
it
say
up
guessing?
D
Is
it
safe
to
assume
that
what
we
want
as
an
overlay
would
be
to
convert
into
your
experiment,
or
were
you
thinking
about
some
other
option,
so
I
mean
so
this
is
this
is
an
option
right?
I
was
thinking
a
little
bit
more
generic,
but
we
can
kind
of
you
know,
try
to
maybe
discuss
the
group
where
we
are.
You
know
what
are
the
pros
and
benefits
and
all
that
stuff.
D
Actually,
I
did
say
that
it's
more
of
the
same
thing,
yeah.
What
I
typically
hope
for
out
of
some
of
these
features
is
that
they
are
genetic
enough,
that
they
could
be
actually
applied
to
various
places
right
and
so
maybe
like,
for
example,
since
john
brought
up
by
the
temple,
to
replace
actually
there's
an
interesting
question
of
what
is
the
relationship
between
template,
replace
and
whatever?
This
feature
said
that
we
are
right.
D
So
at
least
my
personal
opinion
is
it's
good
to
avoid
one-off
features,
because
they're
not
really
kind
of
building
up
the
core
they're
just
kind
of
sprinkling,
the
kind
of
individual
things
that
don't
necessarily
don't
necessarily
get
used
together
easily.
D
So
I
guess
I
wanted
one
so
maybe
motivation
for
bringing
it
up
in
this
meeting
is
I
wanted
to
kind
of
get
some
well
one
get
some
visibility
on
that
from
you
all.
I
think
it's
an
interesting
problem
in
terms
of
enhancing
core
functionality
of
overlays
within
ytt,
so
it's
probably
an
area
that
we
should
kind
of,
invest
in
and
then
also
as
a
kind
of
a
side
thing.
D
I
brought
up
this
interesting
question
of
so
this
also
again
happened
in
various
cases
where
I
wanted,
for
example,
to
create
a
service
account
per
namespace.
That's
been,
you
know,
found
inside
our
configuration
right.
So
how
would
we
do
that
right?
How
would
you
achieve
that,
and
so
I
think
my
gut
feeling
is
that
somehow
this
problem
relates
with
this
the
top
level
problem,
but
there's,
I
guess,
probably
more
discussion
to
be
had
there.
E
So
I
need
to
make
sure
this
card's
on
the
table
in
this
discussion.
A
related
possibility
would
would
be
that
you
could
do
this
imperatively.
E
You
could
do
this
programmatically,
where,
instead
of
an
in
an
overlay,
if
I
could
get
access
to
the
document
set,
that's
part
of
the
evaluation
result
so
far,
so
what
I
mean
is,
if
I
strategically
place
a
template
at
the
end
of
the
evaluation
of
ytt
stuff,
like
I've
already
evaluated
a
bunch
of
yaml
documents,
and
then
I
had
a
library
that
I
could
get
access
in
the
same
way
you
can
get
access
to
data
values.
That
was
something
was
computed
and
it's
handed
as
a
module
to
to
templates.
E
I
could
get
access
to
the
docset
or
a
copy
of
it
thus
far,
and
then
do
him
do
imperative
work
on
that.
D
I
have
a
feeling
you
have
some,
what
do
you
call
it
there
behind
it?
What
what
what's
the
yeah?
What's
the
side
of
it.
D
E
Mode,
I
am
in
imperative
logic
in
in
starlark,
I'm
saying
here's
a
collection
iterate
over
it,
finding
a
thing,
maybe
even
being
able
to
replace
that
item
in
the
dark
set
with
something
delete
it
like
do.
Operations
over
the
dock
set.
D
E
D
D
State
of
the
world,
if
you
will
right
and
then
massage
it
a
little
bit
shape
it
to
whatever
you
know
thing
you
have
right,
so
it's
kind
of
like
it's
a
it's,
a
hatch
right
that
you
open
and
say
you
know
what
I'll
know
better,
what
to
do
with
all
this
stuff
versus
trying
to
maybe
write
more
overlay
like
code
right
so
yeah.
I
think,
programmatic.
I
guess
way
to
go
about
that
so
yeah,
so
I
could
imagine
that
that
feature
also
potentially
covering
this
not
sure.
D
To
be
honest,
I'm
not
quite
sure
if
there
is
a
benefit
to
having
this
lower
level
feature
to
solve
this
problem,
as
in
like
should
we
use
the
slow
level
of
each
solar
problem,
or
should
we
also
kind
of
have
a
different
way,
I'm
not
even
sure
what
are
other
ways
of
solving
this
problem
right.
So
maybe
I
think
that's
that's
kind
of
interesting
to
think
about
that
as
well.
E
E
Tempting
and
I've
even
heard
people
have
actually
specifically
asking
for
that
feature.
It
just
reeks
of
more
than
enough
rope
to
to
hang
yourself
that,
like
well
depending
on
where
that
thing
is
running
in
the
set
of
files,
you
may
or
may
not
see
the
full
dock
set
or
what's
the
scope
of
the
doc
set
like
it
would
have
to
be
managed.
Somehow,
perhaps
like
it's
an
overlay
with
a
matcher
that
has
special
behavior.
That
says.
E
D
Yeah,
I
mean-
and
that's
that's
somewhat
similar
right
to
the
behavior
of
overlays
themselves
right,
because
the
overlays
don't
act
within
a
context
of
a
file
right.
They
act
within
the
context
of
all
of
the
document
sets
within
a
library
right,
yeah,
I'm
not
sure
what
should
be
our
next
step.
I
think
it's.
It's
actually
a
great
issue
to
kind
of
have
various
you
know,
I
guess
option
presented
thought
through
at
least
I
don't
know.
D
I
I
think
it's
a
good
way
to
kind
of
get
better
understanding
or
kind
of
a
better,
maybe
kind
of
a
it's,
a
good
exercise
to
think
about.
If
we're,
if
we're
working
in
an
overlay
area,
so
yeah,
maybe
just
something
that
we
have
more
discussion
on
on
slack
or
separate
zoom
or
whatever
it
is
with
maybe
larger
time
available.
E
Yeah
one
more
angle
on
this
I
want
to
as
people
are
percolating
on
this,
as
I
see
you
hinting
toward
dimitri
one.
Other
angle
on
this
might
be
interesting.
Is
I
wonder
if
this
is
just
the
latest
of
a
number
of
symptoms
or
challenges
that
we
faced,
because
it's
hard
to
refer
to
a
parent,
it's
hard
to
refer
to
a
collection?
E
You
know
unless
you
use
the
literal
bracket,
but
then
that
that
limits
a
lot
of
what
you
can
do
with
ytt
and
it's
less
of
a
problem
with
maps,
because
I
don't
know
because
the
the
elements
are
named
but
for
arrays
and
for
doc
sets
it's
really
hard
to
reference
them.
You
can
you
can
do
it,
but
it's
a
bit
challenging
it's.
Actually,
you
can't
reference
a
doc
set
so
raise
at
least
you
can
like
reach
to
the
parent.
The
parent
is
at
least
there,
but
doc
sets
there
aren't.
E
So
I
wonder
if
it's
just
more,
even
deeper
of
a
fundamental
challenge
of
if
we
could
find
a
sensible
way
of
referring
to
a
parent
in
just
a
parent
and
maybe
like
the
collection
in
which
I
live.
Something
like
this.
J
J
So,
personally,
what
I'd
like
to
see
is
five
examples
of
what
we
want
to
accomplish
from
where
we
are
to
where
we
want
to
go
and
from
there.
I
think
we
should
look
at
it
and
say
like
is
this
one
solution
that
can
solve
all
these
problems
or
do
we
need
multiple,
smaller
solutions
to
solve
all
these
problems
that
we
that
we
want
to
try
to
address?
J
This
can
be
just
me
because
I
don't
understand
a
lot
about
ytt,
but
I
feel
like
that.
We
we
just
now
enter
to
like
a
very
deep
end
and
we're
talking
about
selecting
parents
and
selecting
this
and
there's
like
a
possibility
of
pushing
all
the
the
document
into
overlays.
It
feels
like
that
we're
trying
to
generalize
a
solution
when
we
have
just
like
one
example
and
for
me
it's
it's
hard.
E
D
We
have
we
have
one
example
here
we
have
one
example
here
I
to
be
honest,
a
lot
of
times
I
wish
we
did
have
like
a
place
where
we
had.
You
know.
D
Examples
that
I'd
like
to
do,
but
I
couldn't
figure
out
to
do
it
because
maybe
there's
no
available
feature,
maybe
I
couldn't
figure
out
how
to
do
it
place.
I
don't
know
if
that's
something
like
we
want
to
keep
on
github
or
or
elsewhere.
The
other
maybe
side
of
it
is
also.
I
do
agree
that
it's
always
nice
to
have
more
examples.
D
I
try
to
at
least
relate
to
the
what
I've
seen
before
like
in
random
places,
like
maybe
I
don't
know
when
I
was
deploying
my
own.
I
don't
know
kubernetes
app
for
fun
on
a
weekend
or
something
like
that
and
try
to
kind
of
relate
well.
Was
there
actually
a
combination
of
like
problem
that
I
had
that
actually
really
really
is
related
to
this
problem
right.
So,
for
example,
like
this
example
drawn
over
here,
create
a
service
account
profile.
D
Namespace
actually
comes
from
cf
for
kate's
work
that
we've
done
probably
like
a
year
ago
at
this
point,
but
there
is,
you
know
yeah,
I
guess
like
you
can
kind
of
maybe
be
at
least
I
try
to
explore
from
these
basic
examples.
What
are
the
some
of
the
other
examples
that
maybe
community
out
there
may
seem?
Sometimes
I
even
go
to
you
know
other
projects
to
see
what
similar
issues
that
they
may
have
faced,
that
you
know
may
not
be
addressed
by
those
projects
or
maybe
addressed
but
yeah.
D
I
think
it
would
be
good
to
and
maybe
add
some
more
examples,
I'm
not
quite
sure
what
they
might
be.
This
is
at
least
the
two
real
examples.
I've
seen
before
yeah.
D
H
Yeah,
I
I
think
that
this
could
possibly
as
far
as
maybe
not
like
specific
to
this
issue,
but
I
I
kind
of
liked
dimitri's
thought
along
the
lines
of
like
here,
are
all
the
things
that
we
have
not
solved
with
ytt,
and
maybe
this
is
like
an
opportunity
for,
like
our
discussions,
part
of
ytt-
and
maybe
I
don't
know
if
they
have
like
labeling
schemes
where
we
could
like
label
it
as
like
unsolved
and
kind
of
collect,
like
use
cases
and
potentially
develop
them
into
features
and
and
issues
that
we
could
eventually
work
on.
E
I
The
only
thing
I'd
append
is
maybe,
with
these
problems,
collection
of
problems,
add
an
attribute
how
painful
this
problem
is
because
I
was
on
the
test
for
kate's
team
and
I
definitely
worked
on
the
service
account,
adding
a
service
account
for
each
namespace
and
I
played
with
everyone
on
the
team,
and
it
never
was
a
pain
point.
Even
though
we
had
to
change
that
part
of
the
code.
If
there
was
a
better,
more
elegant
solution,
we'd
definitely
go
for
it,
but
in
terms
of
pain
point
it
was
in
terms
of
and
relating
it
to.
I
D
Well,
I'll
I'll
call
the
time
that
I
wanted
to
spend
on
this.
I
think
we've
chatted
at
least
about
the
issue
and
some
other
meta
work
around
it.
A
K
So
this
is
specifically
with
git
ops
in
mind.
Cap
right
now
has
a
command.
K
Called
cap
app
group
that
allows
you
to
deploy
a
directory
with
manifest
in
them
and
it
will
deploy
each
directory
as
a
separate
app
in
cap
based
on
the
like
a
directory
name.
K
K
If
we
were
to
support
something
like
this,
like
ytt,
would
have
to
know
a
lot
about
the
specific
directory
structure
of
its
inputs
and
where
to
kind
of
evaluate
like
or
like
how
to
evaluate
each
directory
in
its
own
context.
When,
given
only
this.
K
E
When
I
have
a
number
of
things,
I
want
to
have
effectively
I'm
if
I'm
reading
this
right
that
I
have
basically
three
ytt
runs
that
are
completely
isolated,
basically
just
iterating
and
looping
over
that,
for
when
I
get
to
that
point,
when
I
have
that
amount
of
stuff
that
the
tool
is
there
to
greet
me
with
that,
so
I've
got
that
on
one
side
of
the
fence
for
me
and
then
the
other
side
is
that
I
wonder
if
that's
enough
signal
to
take
on
that
additional
scope
where
it
it,
it
could
be
something
as
simple
as
a
for
loop
over
an
immediate
directory
structure
that
invokes
ytt
for
each
of
those.
E
That's
that's
not
completely
equivalent,
like
you'd,
have
to
work
away
if
you're.
If
this
is
part
of
a
pipeline
to
sort
of
merge,
all
those
results
together
somehow
so
it's
not
completely
trivial,
but
I
don't
know
it
doesn't
seem
like
a
slam
dunk
for
me
personally,
but
I
can
see
how
they're
it
it
can
be
compelling
from
our
overall
sweet
vision
perspective,
but
I
could
also
see
that
it
might
be
a
little
early.
D
D
Do
people
have
any
thoughts
about
what
are
the
challenges
with
providing
a
feature
like
that,
not
necessarily
like
implementation
challenges,
but
rather,
like
the,
I
guess,
challenges
in
I
don't
know
like
the
product
surface
area,.
I
I
see
there's
challenges
and
opportunities.
The
challenges
are
where
we
have
to
maintain
this
feature
that
may
not
be
adding
as
much
value
or
might
not
be
solving
as
many
use
cases
as
we
think
for
as
many
people
as
we
think,
but
the
opportunity
is
if
this
is
solving
a
pain
point
and
it
helps
ytt
integrate
with
cap,
because
that's
how
people
are
expected
to
use
for
some
reason,
the
opportunity
of
people
are
more
likely
to
use
it
just
for
transparency.
I
It's
not
clear
to
me,
and
so,
when
the
pair,
when
me
and
the
pair
picked
up
this
community
issue,
we
weren't
sure
either
whether
this
was
something
we
wanted
to
add
or
not,
and
so
we
just
added
a
story
to
say
all
right:
here's
a
bit
of
work
to
try
to
figure
out
whether
this
is
a
valid
use
case
or
not,
but
this
is
a
good
form
to
discuss
that
now
as
well.
D
D
The
reason
why
I'm
asking
this
is
I'm
thinking
of
very
particular
thing,
but
there
might
be
other
things
that
I
don't
know
this
group
may
come
up
with,
and
so
this
is
why
I'm
kind
of
being
in
the
league,
hoping
that
maybe
there
is
other
things
that
are
positive
or
negative
about
you
know
having
a
feature
like
that.
K
One
thing
that
I
see
is
because
each
directory
evaluates
in
its
own
context
and
like,
at
least
in
this
example,
would
like
output
a
file
with
the
rendered
output.
Ytt
would
no
longer
like
be.
K
Basically,
writing
to
standard
out
so
piping
it
into
another
tool
might
behave
differently
than
how
it
does
now
like.
I
can't
really
imagine
an
easy
way
for
us
to
be
given
multiple
directories
and
then
like
evaluate
them
all
in
their
own
context
and
then
pipe
all
the
output
to
another
program
when
the
output
is
separate
per
directory.
K
E
Yeah,
it
looks
like
that's
that
kind
of
mode
that
you
would
have
to
be
opting
into
when
you're
using
cap
with
the
app
group
commands
that
you're
naming
a
directory,
and
so
the
the
pipe
between
the
filters
in
that
use
case
becomes
a
directory
structure
as
opposed
to
the
standard
pipes
agreed.
I
Do
we
know
if
cap
app
grip
is
being
used
in
the
wild,
because
the
other
alternative
approach
I
think
kerry
touched
on
this
is:
do
we
want
to
continue
supporting
cap
app
group
like
this
ytt
app
group
seems
like
the
kind
of
kind
of
like
the
the
equivalent
to
the
cap
group.
The
value
here
is,
we
can
you
know,
work
with
cap
group,
maybe
a
little
bit
nicer,
but
there's
a
value
in
keeping
cap
app
group
to
begin
with.
D
I've
definitely
had
a
few
people
ask
questions
about
it
as
they're
using
it
now,
whether
that's
something
you
know
actually
semi
touch
on
that
in
the
in
the
thread.
Talking
about
seeing
cap
control
really
as
a
thing
that
codifies.
What
is
that
flow?
Look
like
right.
So
at
that
point
you're,
not
really,
then
you
know
you
wouldn't
be
using
cap
app
group
right.
You
would
be
using
more
cap
controller,
high
level
functionality.
D
One
thing
that,
since
since
kerry
kind
of
mentioned
it
so
the
thing
that
I
was
thinking
about
is
pretty
much
what
kerry
is
talking
about,
but
also
from
the
perspective
of
security.
D
This
functionality
is
saving,
probably
sensitive
configuration
to
the
disk
in
bulk.
If
you
will
right
so
one
thing,
that's
conceptually,
I
guess
it's
bothering
me
about
this
feature.
Is
this
you
know
as
soon
as
the
disk
is
involved,
then
now
your
secrets
are
touching
disk
and
that's
not
necessarily.
D
You
know
like
the
who
knows
where
this
kind
of
command
is
running,
I
mean.
Maybe
it
is
running
on
a
ram
disk
and
that's
not
really
a
big
deal,
but
maybe
it's
not,
and
so
there's
this
interesting
balance
of
like
well.
How
do
we
be
cautious
about
it?
I
Is
that
a
sort
of
is
that
in
favor
of
removing
cap
app
group,
because
my
understanding
is
kept
group-
expects
these
files
to
be
on
disk
so,
if
something's
consuming
it
is
the
hesitation
that
producing
the
sensitive
things
on
disk
is
the
security
vector
or
is
it
the
fact
that
something
is
depending
on
sensitive
information
content
being
on
disk?
Because
cap
app
group
expects
it
to
be
on
disk
somehow,
somehow
something
has
to
produce
it
right.
D
So
maybe
there's
well
at
least
in
my
head:
I'm
not
coupling
the
existence
of
cap
app
group
with
existence
of
like,
let's
say
ytt,
whatever
app
group,
or
something
like
that,
mostly
because
I
could
imagine,
like
somebody-
does
use
cap
app
group
in
particular
ways
that
are
not
necessarily
related
to
like
there's,
maybe
secrets
involved
or
something
like
that
now,
that's
that
could
be
true
for
ytt.
D
I'm
not
sure
you
know,
there's
that
balance
right
like
how
how
far
you
try
to.
I
like,
I
think
some
of
the
principles
behind
some
of
the
carmel
tools
are
we're
not
actively
trying
to
protect
the
user.
The
user
better
know
how
to
use
the
tools
you
know
in
a
good
reliable.
I
guess
whatever
secure
way,
but
we
also
don't
necessarily
want
to
encourage.
You
know
I
don't
know
like
possibly
bad
patterns
right
so
yeah,
so
I
I
know
yeah.
D
E
I
know
it's
not
a
great
stance
or
like
what
you
said
that,
like
it
could
be
sitting
on
some
kind
of
ephemeral
disk
that
generally
gets
cleaned
up
pretty
quickly,
so
the
the
actual
thread
is
a
little
less
then
this
would
be
you
know,
somebody's
dealing
with
a
larger
set
yeah,
I
don't
know,
maybe
those
are
mutually
exclusive
too,
like
if
you,
if
you
have
so
many
things,
that
you
need
to
have
a
tool
like
this.
E
In
order
to
do
this
work,
you
need
to
have
this
feature
in
order
to
like
manage
n
number
of
things,
then
maybe
maybe
you've
already
decided
that
secrets
are
not
a
problem.
You're
you're,
solving
that
in
a
more
aggressive
way,.
K
D
I
would
also
throw
in
one
quick
thing
around:
this
is
there's
an
interesting
question
of
architecture,
cutting
across
multiple
tools
right,
for
example,
like
well
white
ddt
produced
some
configuration
cap,
deploy
some
configuration
right,
there's
also,
potentially
other.
You
know,
tools
in
the
middle
like
k,
build
or
maybe
there's
like
image
package
beforehand.
Things
like
that
right,
and
so
one
other
interesting
design
question
here.
J
Right,
they
keep
main
features
around
right.
If
you
want
to
copy,
if
you
want
to
remove-
and
it's
something
that's
that
exists-
or
that
has
some
sort
of
permissions
and
everything
you
need
to
do-
a
minus
f
right
like
so
they
there's
a
sense
of
feature
parity
between
like
the
unix
tools,
where
there
are
certain
things
that
exist
everywhere
right
and
are
called
in
the
same
way
so
like
in
the
end
this.
This
is
not
like
a
new
pattern,
so
I
don't.
J
D
My
my
left
well,
the
the
equipment
that
I'll
say
make
in
terms
of
similarity
to
unix
tool
is
what
is
the
way
to
work
with,
let's
say
bulk
of
directories
or
something
like
that
right.
At
least
it
you
know
from
from
what
I've
seen.
Typically,
you
end
up
with
a
higher
level
orchestrator
tool
that
tries
to
do
this
kind
of
a
separation
of
like
you
know,
the
the
smaller
tool
deals
with
one
thing
at
a
time,
but
then
the
orchestrator
tool
just
gives
you
the
new
inputs
or
whatever
right.
D
Well,
it's
effectively
called
call
as
many
times
as
you
need
to
get
called
versus,
trying
to
put
in
functionality
of
a
orchestrator
tool
into
the
tool
directly,
and
maybe
that
is
kind
of
going.
The
way
of
like
well
should
actually
app
group
really
exist
in
cap.
Maybe
it
should
be
elsewhere.
Maybe
they
shouldn't
be
it
all.
D
A
Links
for
the
discussion
today,
everyone
really
great
community
meeting
stopper.