►
From YouTube: Carvel Office Hours - May 13, 2021
Description
Carvel Office Hours - May 13, 2021
We meet every 2nd and 4th Thursday at 11:30am PT / 2:30pm ET. We'd love for you to join us!
This edition of office hours included discussion around GitHub Issue Triage, imgpkg Copy with rename, and kapp and Tekton working together (Thank you to community member, Charandas for joining and bringing this topic up!).
Full notes here: https://hackmd.io/5Bh2IXwTShSrA0YdBY4AGg#May-13-2021
A
We
do
record
these
meetings
and
add
them
to
our
youtube.
Playlist
we
meet
every
second
and
fourth
thursday
of
the
month
at
11.
30
am
pacific
time.
So,
if
you're
watching
this
from
home,
we
do
encourage
you
to
to
come
to
our
next
meeting
if
you're
not
able
to
meet
for
our
office
hours.
We
also
have
our
carville
community
meetings
and
we
meet
every
monday
at
11
30
a.m.
Pacific
time,
2,
30,
p.m.
Eastern
time
today's
date
is
may
13
2021.
A
Office
hours
are
broken
down
into
discussion,
topics
and
open
questions
and
help
needed.
So
first
up
we
have
some
discussion
topics
from
joe
wow
one
of
the
carnival
maintainers,
and
I
will
kick
it
on
over
to
him
to
discuss
the
first
discussion
topic.
Joelle.
Do
you
want
to
share
your
screen.
B
B
Yes,
cool
all
right,
so
so,
let's
take
a
look
at
our
agenda
today.
So
our
agenda
is
to
topic,
says:
nancy
said
the
first
one
we're
gonna
go
through
what
a
proposal
that
we
did
about
the
triaging
of
issues
of
our
github
issues,
a
little
bit
about
like
there
was
some
thought
put
into
it,
and
we
added
this
to
a
document
that
we
had
prior
that
contained
like
what
we
would
do,
while
triaging
the
issues
so
we're.
First
gonna,
take
a
look
at
that.
B
So,
very,
very
briefly,
so
this
is
a
document
that,
where
we
try
to
delineate
what
it
looks,
what
it
makes,
what
we
should
we,
what
are
we
doing
while
we're
triaging
the
proposals
and
there's
some
changes
to
this
document
and
the
major
change
is
around
the
triaging
process
itself.
What
should
happen
when,
when
you're
triaging
an
issue
so.
B
The
flow
that
is
being
proposed
here
is
for
the
issues
is
that,
like
somebody,
will
create
an
issue
right
and
that
will
get
two
labels.
One
is
carbon
triage
and
another
is
enhancement,
because
this
is
going
to
be
a
feature
we
have
a
a
little
bit
down.
Do
we
have
like
a
bug
triage
and
what
we
do.
We
do
things
a
little
bit
differently,
but
so
the
first
step
is
being
done
by
someone
that
is
an
approver
for
the
particular
tool
or
the
reviewer
for
that
tool,
and
we
are
going
to
previously.
B
We
had
a
community
pair
that
was
responsible
for
triaging
these
issues
and
moving
them
forward
or
not,
but
we
are
we
are
thinking
about.
Maybe
this
should
be
done
by
someone
that
is,
that
is
more
into
the
tool
that
is
working
more
nearer
the
tool.
B
So
the
idea
is
that
the
approver
or
a
reviewer
would
be
first
read
first,
read
this
issue
and
try
to
understand
it,
and
if
there
is
information
that
is
missing
or
it's
not
100
clear,
they
should
reply
to
this
issue
and
say
like
to
ask
for
more
information,
and
an
important
part
here
is
that
the
approver
or
the
reviewer
that
started
this
discussion
should
be
the
one
that
keeps
on
tabs
on
this
particular
issue.
So
we
don't
have
like
multiple
people
replying
and
having
to
gain
context
on
it.
B
If
the
approver
or
the
reviewer
understands
like
this
has
been
like
a
good
improvement,
something
that
we
want
to
have
in
our
tool,
then,
basically-
and
it
has
enough
context
if
the
information-
if
the
issue
doesn't
have
enough
context-
the
approver
slash
reviewer,
will
add
the
context
so
that
it
contains,
like
all
the
information
on
the
issue,
and
it
will
change
the
label
from
remove
the
carval
triage
label,
change
it
to
carvel
accepted
and
moves
the
issue
to
the
carnival
accepted
swimlane.
B
We
do
have
this
swim
lane
here
the
carpal
accepted,
so
the
story
should
be
moved
in
here
to
this
swim
lane
and
changed
it
to
be
carbon
accepted
and
we'll
see
why?
Next,
if
it's
not
a
good
fit
for
the
tool,
then
the
approver
or
reviewer
should
close
the
issue
and
have
some
information
explaining
why
this
doesn't
make
sense
for
the
tool.
B
In
another,
another
situation
here
is
that
if
the
reviewer
slash
approver
thinks
that
there's
there
is
no
need
to
add
like
acceptance
criteria,
or
there
is
something
that
it's
very
self-explanatory,
then
the
issue
should
be
removed.
The
label
carnival
triage
an
accept
coverall,
except
it
should
be
added,
but
it
should
be
moved.
The
issue
should
be
moved
into
then
prioritized
backlog,
swimlane.
B
So
an
example
of
that
is,
for
example,
like
this
issue,
where
it
was
kind
of
self-explanatory
that
we
just
wanted
to
make
sure
that
an
executable
flag
was
kept
into
the
into
the
file.
So
we
don't
need
to
create
like
a
lot
of
acceptance
criteria
for
this,
so
we
we
are
okay,
just
moving
them
into
ready
to
be
picked
up.
B
So
if
the
feature
is
a
bug,
then
it
should
change
the
label
from
enhancement
to
bug.
So
this
is
like
the
first
step
and
it's
all
on
the
approver
reviewer
step.
So
what
does
our
community
pair
is
going
to
do
on
their
day-to-day
or
something
or
every
other
day
to
every
other
day
work?
They
should
come
through
the
carl
accepted
swim
lane.
B
And
then
it
should
tag
whoever
approved
or
whoever
approved
this.
This
car
will
accept
it
tag
them
and
say
like.
Does
this
look
like
a
good
acceptance
criteria
and
also
make
sure
that
the
person
that
created
the
issue
also
is
aware
of
this
and
make
sure
that
the
acceptance
criteria
makes
sense
for
this
full
for
this
full
process,
and
if
it
gets
a
thumbs
up,
then
it
should
be
moved
into
2rn
prioritized
backlog.
B
And
last
our
blt,
our
product
plus
approver
blt,
is
our
balanced
leadership
team.
They
meet
once
a
week
to
try
to
prioritize
all
the
work
that
we
do
or
the
product
people
plus
an
approver
will
get
together
and
try
to
decide
if
there
is
something
on
the
end,
prioritize
backlog
that
should
be
moved
into
the
prioritized
backlog
for
us
to
pick
up
next
week
or
in
the
weeks
to
come.
So
this
is
more
or
less
like
the
change
on
the
process
for
feature
triage
for
the
bug.
B
Triage
is
a
little
bit
different,
because
what
happens
is
that?
Oh,
this
is
wrong
that
copy
pasted
this
clearly,
but
the
community
pair
is
going
to
be
responsible
for
trying
to
replicate
the
issue.
B
So
the
the
issue
should
have
enough
information
for
it
to
be
replicated,
and
the
idea
here
is
that
you,
we
add
another
tag,
another
label,
sorry
that
is,
can
be
replicated
and
that
information
should
be
enough
to
see
like
does
this
have
enough
information
for
for
us
to
proceed
with
the
bug
or
not,
and
then,
if
there's
not
enough
information,
then
it
should
follow
up
with
the
person
that
opened
the
issue
to
try
to
understand
if
it
makes
sense
like
if
they
can
provide
more
more
information
so
that
it
can
be
picked
up
later
afterwards.
B
The
approver
or
reviewer
would
would.
If,
if,
if
the
bug
was
not
touched
by
the
community
pair,
then
an
approver
or
a
reviewer
can
do
this
like
this,
the
same
part
as
above,
and
if
the
issue
already
has
a
can
be
replicated
label,
then,
if
it
is
a
real
problem,
then
it
should
change
the
carbol
triage
from
should
remove
the
label,
carbon
carbonyl
triage
and
add
the
carnival
accepted
to
it
and
move
this
move
this
issue
into
the
unprioritized
backlog.
B
If
the
scenario
is
not
going
to
be
solved,
it
should
reply
with
the
reason
why
it's
not
going
to
be
fixed
and
close
it.
And
if
this
scenario
is
it's
not
a
bug,
then
it
should
be
moved.
It
should
be
change
the
label
to
enhancement,
and
we
assume
that
it
is
not
a
bug
and
it's
something
that
we
we
want
to
do.
Then
it
should
be
changed.
B
Our
carbo3y
should
be
changing
to
kerbal
accepted
and
it
should
be
moved
into
the
carnival
accepted
swimlane
and
it
will
be
picked
up
by
the
community
pair
on
the
rest
of
the
triage
for
the
features
and
then
the
again
once
again,
the
blt
or
the
product
plus
approvers
would
check
in
these
issues
and
will
prioritize
them
when
it
makes
sense
so
like
this
is
somewhat
of
a
change
from
the
process
that
we
had
before,
where
basically
the
community
pair
would
be
responsible
for
triaging
all
the
issues
to
accept
them
or
not,
even
if
they
did
not
have
like
a
lot
of
context
on
on
the
on
the
tool
and
so
on.
B
So
like
this
is
our
proposal.
I
don't
know
if
anyone
has
any
questions
about
it,
but
this
was
something
that
we
would
like
to
eventually
try,
if
everybody's
okay
with
that
and
see
if
it
works
or
if
it
is
more
helpful
and
can
make
us
go
forward
quicker
than
we
were
doing
before.
C
I
have
a
question
more
like
clarification,
so
I
think
the
trend
is
that
only
approvers
or
reviewers
can
decide
whether
an
issue
will
be
done
or
not.
B
So
the
idea
is
so
the
answer.
The
quick
answer
is
yes,
and
why
is
that?
In
theory,
the
approvers
and
the
reviewers
are
the
people
that
are
working
more
actively
on
a
tool
and
have
an
idea?
What
the
like?
What
is
the
idea
for
this
tool
how
the
tool
should
evolve?
So
they
are
the
people
that
are
best
positioned
to
make
decisions
about.
Should
this
be?
B
Should
this
be
something
that
should
be
part
of
this
tool
or
not,
of
course,
and
also
they
have
like
a
bigger
advantage
that
the
time
that
they
will
take
to
triage
this
issue
is
going
to
be
much
smaller
than
someone
that
doesn't
have
like
the
full
context
of
this.
So
we're
trying
to
also
piggyback
here
on
the
knowledge
of
the
people
that
have
more
knowledge
on
this
on
the
on
the
tools
to
make
this
this
work
faster
than
it
was
before,
because
before
you
had
to
build
like
all
this
context,
and
so
on.
D
So
I
had
a
question
about
the
community
role
it
seems
like,
given
that
the
community
pair
would
enter
into
this
certain
swim
lane
and
try
to
add
acceptance,
criteria
or
try
to
replicate
a
bug
that
this
wouldn't
need
to
be
allocated.
As
often
do
you
think
that,
like
maybe
this
change
in
strategy
would
maybe
put
more
responsibility
on
the
approvers
and
reviewers
than
it
does
the
other
engineers
who
worked
on
the
community
fair.
B
Yeah,
that
is
somewhat
of
the
idea.
The
idea
is
to
lessen
the
burden
of
the
people
that
are
doing
community
and
to
eventually
even
reduce
the
time
that
we
are
using
right
now
to
triage
all
these
issues
right.
So
there
there
is
a
proposal
for
us
to
to
shorten
the
the
need
for
this
community
pair
to
be
maybe
eventually
like
twice
a
week.
B
Maybe
just
have
this
pair
work
on
community
issues,
like
maybe
twice
a
week,
for
example
like
tuesdays
and
thursdays,
or
something
like
that,
the
triage
day,
the
t
day
right,
but
that's
something
that
we're
discussing
still.
But
yes,
okay,.
C
D
B
A
lot
so
we
need
to.
We
need
to
ramp
up,
because
it's
not
it's
not
only
to
fulfill
the
needs
on
of
these
of
like
this
new
process,
but
also
because
sometimes
we
need
people
that
help
out
with
particular
issues
or
if
we
need,
for
example,
like
in
today's
meeting.
We're
gonna
talk
a
little
bit
about
cap
and
there's
no
one
in
in
here
right
now.
That
has
like
a
reviewer
or
approval
position
on
that
tool.
So
we
don't
have
like
the
full
context.
So
I
think
we
need
to.
B
We
are
hiring
right
now,
because
we
don't
have
enough
head
count
to
be
to
to
have
like
reviewers
and
approvers
in
all
the
tools,
but
by
default.
Dmitry
will
help
us
out
if
we
need
to,
but
yes,
we'll
be
relying
a
lot
on
dimitri,
but
we
need
to
ramp
other
people
up
in
different
tools,
and
we
have
a
problem
currently
on
the
tools
that
were
not
very
that
that
that
they
are
not
like
the
our
biggest
priority
that
our
cap
and
cable,
so
we
don't
have.
E
Cap
can
I
interrupt
here
for
a
second,
I
have
something
on
the
agenda,
but
I
have
to
leave
so
I'll,
probably
be
catching
up
on
the
recording
later
and
it's
just
I
wanted
to
clarify
the
issue
I
wanted
to
be
talked
about
is
on
cap
and
it's
the
issue
77
on
the
github
repo.
E
B
E
B
Cool
okay,
so
let's
let's
try
to
give
it
give
it
a
try
and
see
if
you
can
organize,
maybe
starting
next
week
or
something
to
see
if
we
can
bootstrap
this
this
process
and
see
to
see
how
it
how
it
looks
like
in
reality,
because
in
paper
it
looks
fine
but
we'll
see
how
it
looks
like
all
right
nancy.
A
A
A
B
Sounds
good
like
if,
in
the
end,
if
we
cannot
get
dimitri,
this
is
something
that
we
can
raise
and
we
can
check
it
out,
maybe
tomorrow,
during
stand
up
and
see
if
there's
if
this
is
something
because
if
this
is
impacting
people
right
now,
this
is
something
that
we
need
to
look
into.
So
we
might
prioritize
this
to
eventually,
maybe
start
this
work
or
something
maybe
next
week,
if
that's
something
that's
very
high
priority
as
well.
A
B
B
Okay,
so
the
other
topic,
the
other
topic
that
I
have
here
it
is
about
the
image
package
copy
with
rename
proposal,
and
it's
been
it's
been
open
for
some
time
to
be
fair
and
had
a
lot
of
space
in
my
my
to-do
list
to
push
this
forward
sooner.
But
I
think
that
at
this
point
we
have
two
issues
that
we
need
to
talk
about.
One
is
how
how
the
strategy
definition
would
look
like
and
another
one
is:
are
we
okay
or
not?
B
Two
do
not
have
overrides
out
of
the
bat
and
eventually
maybe
build
them
later,
but
not
as
like
something
that
is
required
to
get
this
feature
out.
So
I
think
those
are
like
the
two
major,
the
bigger
issues
that
we
have
here
to
talk
about:
okay,
hey.
B
B
Cool,
so
we
had
we
had
someone
sherandus
here
on
the
call,
and
he
wanted
to
know
about
this
issue
number
77
of
cap
cap
and
tacked
on
working
together
in
the
issue.
It
is
created
by
you
and
I
think,
jorge
also
opened
an
issue
on
tecton
about
it.
Do
you
remember
what
this
is
about.
G
Let
me
give
a
read
real
quick
put
your
article
with
the
user
when
texting
controller
replaces
metadata
annotations.
Cap
no
longer
believes
that
this
resource
is
being
directly
managed
by
the
user.
It
still
tracks
it,
but
as
a
cluster
created
resource,
so
that
if
some
controller
does
copy
over
annotations
from
other
resources,
why
there's
still
a
tactile
identity
of
the
oh?
G
Yes,
I
think
I
so
this
issue
was
related
to
so
if
a
user
has
so,
I
think
tecton
has
this
interesting
behavior
that
it
copies
over
annotations
from
one
resource
to
another,
and
so,
if
you
have
two
resources
inside.
G
Inside
your
configuration
file
that
you're
sending
to
cap,
then
tacton
so
cap
will
annotate
them
appropriately,
both
of
them
and
then
techton
will
copy
those
annotations
onto
one.
You
know
on
to
the
second
resource,
and
so,
if
actually
that
makes
cap
lose
track
that
hey
look,
this
resource
is
no
longer
being
kind
of
managed
by
the
by
the
system
it
it's
kind
of
it
loses
ownership,
and
I
guess
it
considers
that
this
resource
has
been
created
through
the
cluster
means
rather
than
created
by
cap.
G
So
there's
some,
I
guess,
vagueness
in
there
in
terms
of
what
actually
should
be
the
behavior,
because
it's
kind
of
fighting
the
tecton
is
doing.
One
thing
cap
is
doing
another
thing.
You
know
who
actually
owns
this
annotation
thing
and
there's
a
few
different
solutions
in
there.
None
of
them
are
that
exciting,
to
be
honest
but
they're
available.
B
G
Yeah
I
mean,
I
think
we
would
be-
I
mean
the
first.
The
first
stage
for
this
issue
would
be
to
figure
out
what
to
actually
do
and
then
the
next
stage
would
be
to
figure
out
who
does
it
right,
whether
it's
maybe
opportunity
for
anybody
to
contribute
the
proposed
changed
or
whether
it
would
be
the
core
contributors
contributing
in
this
but
yeah?
G
B
Okay,
so
maybe
what
we
can
do
about
this
is
see
maybe
tomorrow
morning,
to
see
if
anyone
is
interested
in
and
giving
a
go
on
this.
If
not,
if
we
have
a
hard
time
getting
people,
maybe
can
we
rely
on
you
dmitry
to
help
us
out
and
try
to
like
understand
this
a
little
bit
better
and
also
get
more
a
little
bit
deeper
into
the
the
options
that
exist,
so
we
can
create
like
a
proposal
and
move
forward.
This
issue.
G
B
Okay
sounds
good,
so
tldr
we
did
not
forget
about
you.
We
are
going
to
to
try
to
get
a
little
bit
more
color
around
this
issue.
Try
to
understand
a
little
bit.
What
are
the
options
and
then,
if
you
are
interested
in
contributing
code
into
this
issue
in
particular
issue
or
any
other
issue,
we
are
always
happy
to
get
contributions
so
feel
free
to
open
prs
against
our
repos.
G
Actually
one
one
thing
that
somebody
should
take
a
look
at
is
this
issue
still
happen,
because
I
do
see
that,
even
though
a
tecton
issue
was
closed,
there
was
a
few
other
issues
related
to
it
that
were
that
are
still
open,
like
precedence,
order
for
labels
and
annotations.
G
So
it
would
be
interesting
to
see
what's
happening
in
the
upstream,
not
saying
that
you
know
this
is
interior
general
problem.
That
could
happen
anywhere,
but
this
is
maybe
specifically
for
techton.
This
may
be
something
that
gets
fixed
actually
in
in
tecton
itself.
B
B
B
B
Okay,
so
it
looks
like
oh
thank
you
so
much,
whoever
added
the
notes
there.
So
I
think
we
don't
have
yet
another
question.
So,
let's,
let's
maybe
go
back
then
to
our
proposal
for
the
image
package
copy
with
rename.
B
B
But
the
way
we
were
proposing
our
strategies
to
work
was
that
you'd
have
a
name:
you'd
have
a
strategy
name
and
that
strategy
name
would
be
somewhat
of
like
a
big
name,
but
it
would
be
descriptive
trying
to
explain
what
each
strategy
was
going
to
do.
So,
for
example,
there
was
like
single
repository
on
it
that
would
copy
everything
into
a
single
repository,
and
then
there
was
relative
to
registry,
keep
name
space,
so
each
strategy
had
a
name
that
would
explain
what
a
what
that
strategy
was
doing.
B
So
we
have
another
proposal
of
way
to
do
strategies,
and
that
was
having
knobs
that
allow
the
the
person
that
is
creating
this
configuration
file
to
define
to
have
like
a
more
generic
strategy.
For
example,
we
want
all
the
the
copy
to
be
done
relative
to
the
bundle
and
then
you'd
be
able
to
say
okay,
I
want
to
keep
a
namespace
or
I
want
to
keep
the
image
or
I
want
to
keep
the
repository
or
I
want
to
have
the
namespace
dashed
or
something
like
that.
So
so
two
different
approaches
they
have.
C
I
remember
vaguely
what
we
had
before
in
the
proposal.
It
was
many.
I
think
three
different
strategies
does
this
sort
of
new
strategy
where
they're
separate
kind
of
map
to
like
the
same
end
state
as
what
we
had
before
in
just
a
different
way,
or
is
there
a
fundamental
difference
here.
B
So
this
there
are
more
things
now
that
can
be.
That
can
be
done
with
like
this
new
proposal.
Where
previously
we
had,
I
think
four
strap
strategies
on
it,
and
basically
the
strategies
would
do
some
of
the
things.
So,
for
example,
like
everything
is
copied
to
the
same
repository
or
copy
all
oci
images
to
a
new
registry,
but
maintain
the
original
repository
right.
So
this
could
be
done
by
turning
some
of
these
knobs.
B
So,
let's
imagine
that
the
bundle
is
in
registry
dot,
io
slash
my
slash
bundle,
so
all
the
images
would
be
placed
in
registry.io,
slash
my
slash
and
then,
if
you
said
you
want
to
keep
it,
the
namespace
you'd
keep
like
the
name,
spacing
you
create
from
there,
so
some
of
the
strategies
will
be
able
that
we
defined
in
the
beginning,
like
on
the
proposal,
we'd
be
able
to
be
done
with
these
knobs.
That
were
that
we
have
here.
B
Yes,
this
one
is
new,
it
would
be,
you
would
be
able
to
kebab.
Is
it
kebab
or
is
it
the
one
with
underscores?
B
B
So,
for
example-
let's
imagine
let's
imagine
so-
I'm
just
gonna
go
here
and
write
something.
Maybe
this
is
so.
Let's
imagine
that
we
have
reg
dot,
io,
slash
my
slash
image
or
my
team,
one
image
right.
So
the
namespace
for
this
particular
image
is
this
piece
here.
So
this
is
namespace
namespace
equals
to
that
okay.
So
if
we
did
keep
keep
namespace
and
dashed
namespace,
we
would
copy
everything
to
my
so,
for
example,
let's
let's
call
let's
say
that
our
bundle
is
inside
some.
B
B
B
E
B
That
there
would
be
like
another
one
that,
instead
of
being
like
relative
to
the
bundle,
it
would
be
like
relative
to
the
registry.
So
in
that
case,
if
you
have
like
a
strategy
that
is,
for
example,
relative
to
registry,
then
these
two
configurations
here
would
become
something
like
that
and
something
like
that.
D
Yeah,
so
I
guess
I'm
a
little
confused
of
why
you
would
keep
strategy
as
a
field
and
also
have
keep
and
dashed.
It
seems
like
all
that
strategy
is
telling
you
is
where
we're
going
to
be
relative
to.
D
So
maybe
I
see
something
that
instead
of
strategy
it's
like
relative
to
as
the
key
and
then
you
could
have
bundle
repository
similar
to
how
you
have
namespace
image
and
repository,
but
maybe
there's
a
subset
of
options.
D
Yeah,
it's
just
an
idea
because
I
find
that
the
strategy
key
a
little
bit
confusing
that
I've
defined
like
relative
to
bundle
as
my
strategy
and
then
I'm
also
defining
bits
of
my
strategy
and
keep
and
keep
and
dash.
B
B
Yeah,
I
I
do
feel
that
this
is
going
to
make
it
a
little
bit
harder,
like
the
the
major.
The
major
problem
that
I
see
with
having
like
all
these
knobs
here
from
now
on,
is
that
every
time
that
you
want
to
do
something
it's
going
to
make
it
harder
right,
because
now
you
have
like
a
lot
of
other
possibilities
and
to
be
fair,
like
I
was
thinking
about
this,
and
our
current
default
behavior
is
that
we
copy
all
the
images
into
the
same
into
the
same.
B
E
E
B
B
B
D
B
Right,
okay,
so
we're
assuming
that
the
bundle
is
in
some
bundle
right.
So
it
would
be
something
like
here.
H
B
B
B
The
problems
that
we're
trying
to
solve
is
to
allow
people
to
more
easily
understand
what
are
the
images
that
they
are
running
in
their
clusters,
for
example,
and
having
them
like
this
or
having
everything
inside
the
bundle
repository.
I
don't
know
if
it's
helpful,
so
I
would
be
tempted
to
on
the
keep
side
just
allow
you
to
keep
the
image
name
or
the
full
repository,
not
the.
B
B
To
start
off,
and
then
maybe
you
can
try
to
try
to
come
up
with,
like
some
scenarios
and
stuff
like
that,
to
see
how
this,
like
these
configurations,
would
look
like
for
like
different
options
and
see
if
they
make
sense
to
have
like
to
have
the
the
strategies
open
like
that.
Instead
of
being
just
a
name,
sounds
good.
B
I
should
be,
let's,
let's
feel
this
as
a
full
document,
so
the
the
proposal
that
I'm
doing
there
is,
since
we
are
going
to
have
much
more
specific
strategies
or
strategies
that
are
like
knobs
like
this
is
no
this
one
can
we
get
rid
of
the
overrides
so
instead
of
having
like
the
possibility
of
you
having
like
one
off,
I
want
just.
Is
this
one
image
to
be
copied
to
that
one
place?
You
can
set
a
strategy
and
have
all
the
images
copied
in
the
same
way
to
the
destination.
F
B
I
don't
think
so
like.
I
think
it
is
like
a
wise
first
step
for
us
to
just
give
people
strategies
in
some
way
and
then
see
if
people
you
want
to
have
overrides
and
there's
we.
I
think
we
talked
the
last
time
that
eventually,
maybe
the
the
only
override
that
we
really
need
is
this
one.
Here
the
mapping
function,
ytt
starlark,
where
you
would
just
say:
okay,
you
create
a
function
that
would
do
the
overrides
for
you
and
that,
instead
of
having
to
have
like
this
override
section
at
all.
F
D
B
I
don't
see
this
as
like
something
that
you'd
have
to
do
so.
This
is
going
to
be
a
file
that
is
going
to
be
optional,
that
if
you
do
not
provide
an
image
package,
will
still
copy
it.
It's
still
copied
the
same
way
it
does
today.
So
you
don't
need
to
have
this,
but
if
you,
if
you
want
to
do
something
special
on
when
you're
copying
and
you
have
to
want
to
have
more
control,
you
have
like
this
advanced
advanced
option
that
you
can
do
things
with.
D
Okay,
as
well
as
I
think
that,
like
a
a
new
user,
wanted
a
huge,
more
human,
readable
copy
output,
this
would
be
a
great
way
to
provide
it
for
them.
D
B
Cool
all
right,
so
we
have
consensus,
looks
like
so.
I
will
update
the
proposal
to
highlight
the
fact
that
we
are
at
least
for
now
not
gonna
do
overrides.
I
do
believe
that
let
me
just
check
if
we
split
the
overrides
into
a
different
section
or
not
so
the
first
yeah,
the
first
mvp
would
not
have
a
strategy,
so
it
was
already
thought
like
that,
and
the
second
mvp
would
include
strategies.
Maybe
we
can
hold
off
on
this
second
mvp,
and
then
we
have
the
third
and
final
mvp.
B
A
Sure
I
think
so
thank
you
for
joining
today's
office
hours
and
sharondis
if
you're,
if
you're,
watching
this
from
home.
Thank
you
for
your
question
regarding
cap
and
techton,
please
reach
out
to
us
in
the
kubernetes
workspace
in
the
carville
channel,
so
we
can
continue
the
discussion
and
get
more
details
to
work
further
on
that
issue.
As
we're
you
know
really
interested
in
and
get
getting
that
all
ironed
out.