►
From YouTube: Kubernetes SIG CLI 20220119 Kustomize Bug Scrub
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
january
19th
customized
bug
scrub.
There
is
nothing
in
particular
on
the
six
cli
agenda
for
this
bug
scrub.
So
before
we
get
started
with
the
triage
board
as
usual,
I
just
would
like
to
put
it
out
there
that
if
somebody
is
bringing
an
issue
that
they
want
us
to
take
a
look
at,
we
can
do
that
at
any
time.
If
you
have
one
ready
right
now,
please
paste
it
in
the
chat
and
we
will
go.
Take
a
look
at
that.
First.
A
Otherwise,
we'll
just
get
started
with
the
triage
board.
So,
let's
see
what
we
have
here,
we
are
sorting
make
sure
I'm
sorting
by
a
logical
way
here.
A
A
A
A
A
A
B
A
A
It's
super
weird,
because
common
labels
is
label
transformer
right,
so
maybe
they're
having
trouble
finding
the
default
configuration
that
they
actually
wanted.
I
don't
know,
but
you
raise
a
good
point,
that
this
yeah
solution
to
their
actual
problem
is
probably
that
other
field.
Would
you
mind
commenting
about
that.
A
Oh
yeah,
you
did
okay
yeah
this.
This
is
in
my
queue
as
well.
I
was
thinking
about
that
and
yeah
I
I'll
get
back
to
them
as
well.
I
think
I
guess
just
to
comment
on
briefly.
I
telling
them
like
we.
You
could
get
around
this
by
using
exact
functions,
but
we
really
want
to
encourage
people
to
use
containerized
functions.
I
think
it's
better
for
our
users,
it's
better
for
security.
A
So
if
we're
going
to
end
up
weighing
the
sort
of
ideological
priority
of
not
allowing
any
environment
variables
versus
forcing
people
into
the
solution,
that's
less
good
for
the
end
users,
aka
exec,
where
they
could
be
using
containers.
A
I
I
think
learning
more
about
why
they
need
to
use
m
specifically,
and
they
can't
use
mount,
would
would
be
useful
because
if
it,
if
it's
super
legit,
then
then
we
should
probably
consider
keeping
in.
After
all,
I
think,
that's
less
bad
than
than
making
containers
not
work
for
really
important
use
cases.
B
Yeah,
I
think
their
use
case
was
just
that
they
want
to
pass
credentials
to
the
container,
which
is
typically
done
through
end
variables.
So
I
suppose
they
could
also
mount
something
with
the
credentials
into
the
container.
A
Yeah
they
in
the
original
comment
here
they
do
say
variable
or
volume
amounts.
So.
A
That
makes
sense
yeah.
So
I
I'll
I'll
respond
it's
already
in
my
queue
to
respond
with
maybe
a
follow-up,
but
if
they
they
have
a
strong
preference.
There
sounds
good.
B
A
A
C
Yeah,
it's
more
about
supporting
more
generic
output.
I
think
natasha
she's
actually
working
on
related
items.
The
design
dock
is
that
true,
natasha.
C
So
basically,
we
expect
the
customized
field.
The
standard
output
can
support
the
format
locking
resource
list
so
as
it
can
integrate
with
other
tools
that
also
support
this
kind
of
config
pipeline.
B
C
A
I
think
this
is
an
interesting
discussion
that
we
could
have
now
or
or
later
I
see
you
know
the
the
value
of
interoperability,
but
at
the
same
time
we
really
have
a
policy
of
not
having
flags
that
affect
the
output
to
customize
build.
Maybe
that's
an
implementation
detail
and
this
could
be
driven
by
field
instead.
B
I
wonder
if,
instead,
we
could
just
have
a
separate
command
that
takes
a
stream
of
resources
and
converts
it
to
like
a
a
resource
list
so
that
you
could
pipe
the
customized
build
into
that
and
then
pipe
that
into
other
tools.
C
I
think
the
concern
of
having
a
different
command
will
be
that
the
execution
about
analyzing
the
files
and
the
resources
need
to
be
happen
will
be
duplicated.
Oh
that's
right.
B
B
Want
the
like
internal
like
file
path
and
index
annotations,
they
need
those.
C
Yeah
and
the
the
concern
about
adding
that
as
a
customization,
the
ammo
field
will
be
a
user
that
may
want
to
have
different
output
differs
to
different
scenarios,
so
it
means
they
are
required
to
change
the
customization.yaml
every
time
they
change
the
output
format,
and
I
don't
know
what
happens
if
some
of
their
customization
yamo
has
this
field
like
this
configured,
this
output
configured,
while
some
others
that,
like
nested
in
in
the
same
base
overlay
structure,
doesn't.
A
Yeah,
would
you
mind
actually
u.n,
since
you
originated
this.
A
Would
you
mind
adding
more
detail
about
the
justification
you
mentioned,
because
currently
it's
just
saying
sort
of
on
principle.
We
we
originated
this
format.
Why
aren't
we
compatible
with
it?
But
if
there,
if
there's
a
more
specific
and
compelling
reason
for
behind
the
feature
request,
it
would
be
good
to
have
it
outlined
because,
like
on
principle,
we
actually
don't
want
the
build
output
to
be
changing
ever
based
on
flags.
A
C
Yeah
sure
I
I
found
this
a
while
ago,
I
will
re-evaluate
as
well
so
the
so
currently
the
two
options:
one
is
wire
flag,
which
is
not
preferred
because
it
affects
it
has
some
side
effect
for
the
execution
type.
Is
that
correct?
The
other
one
is
basically
adding
a
field
to
the
customization.
B
A
B
A
Yeah,
okay:
this
is
an
old,
an
old
issue.
The
data
isn't
structured,
so
we
shouldn't
be
doing
anything
within
the
values
of
the
configmap
that
we're
generating.
We
have
a.
A
A
B
A
Yeah,
I
think
we
probably
shouldn't
do
it,
because
the
data
in
there
is
going
to
have
some
sort
of
structure
like
in
this
case
it's
yaml
and
just
tacking,
some
ammo
onto
some
other
gamble,
like
it's
quite
space
sensitive.
That
could
go
wrong
and
I
feel
like
if
we
supported
that
it
would
be
pretty
buggy.
A
You
know
what
I'm
just
gonna,
instead
of
watching
maybe
type
this
somewhat
complex.
Instead,
I'm
gonna
try
to
find
that
other
issue
again,
so
I'm
gonna
sign
it
to
myself
and
then
respond
in
more
detail
later.
B
B
A
What
do
you
think
we
should
recommend?
In
the
meantime,
it
sounds
like
the
security
flag
is,
what's
actually
causing
problems
for
them
itself
and
that
won't
be
required
in
the
containerized
version.
Do
you
think
at
this
point,
we
should
just
explain
what
the
plan
is
going
forward
or
even
point
them
to
the
kept
version
of
the
function,
to
try
out.
B
Should
we
add
it,
I
mean,
I
think
I
think
we
can
just
tell
them
where
we're
gonna
make
home
a
third
party
extension
and
here's
a
version
of
it
that
we're
planning
to
publish
under
six
ccli
soon.
A
Yeah
as
if
they,
if
they
are
able
to
try
that
out
and
let
us
know
any
obstacles
that
they
face,
that
could
be
useful
since
the
existing
containerized
function
is
going
to
be
the
basis
of
the
sig
sponsored
one.
A
It
sounds
like
exactly
what
we're
working
on
in
the
camp.
A
Oh
right,
this
is
the
one
that
I
had
been
talking
to
and
I
did
point
them
to
the
so
there
isn't.
If
anyone
is
interested
in
this
there's,
a
cap
update
open
right
now
ready
for
review
with
some
more
details,
including
based
on
the
feedback
that
we
got
in
this
issue.
B
Oh,
this
is
something
I
was
gonna
bring
up
in
one
of
our
contributors
meetings.
Maybe
I
forgot
oh
yeah.
I
think
we
need
to
discuss
what
we're
going
to
do
for
vars
when
they're
used
in
strings
and
they're
not
delimited
by
anything
in
those
scenarios,
replacements
can't
be
used
instead.
So
if
we're
going
to
recommend
replacements
instead
of
vars,
I
think
we
need
a
firm
stance
about
those
use
cases.
A
C
A
A
Yeah
there
is
a
matrix
of
the
flags
that
you
need
to
use.
A
In
one
of
the
caps,
it's
pretty
complicated,
like
some
flags,
go
with
some
versions
of
the
plugins
and
not
others,
and
some
other
available
customers
and
not
others,
but
yeah.
They
exist
it's
sort
of
like
you
have
to
have
a
pairing
up
of
what
the
containers,
what
the
resource
says,
the
container
needs
and
what
the
person
running
the
command
is
actually
authorizing
to
happen.
A
So
we're
going
to
use
catalog
to
do
that.
Ultimately,
but
currently
that
is
still
how
the
feature
works
or
is
supposed
to
work.
B
So
scrolling
down,
I
realized
I
I
did
respond
to
this
person
and
at
the
time
one
of
the
caps
said
we're
going
to
deprecate
storage,
mount
options
which
I
think
has
since
been
updated
to
say
we're
going
to
keep
it,
but
for
one
I
should
probably
let
them
know
that
that's
been
changed.
A
That
would
be
if
somebody
wants,
like
you
know,
if
it
does
reproduce.
That
sounds
like
the
first
actual
bug
that
we've
run
into
in
this
bug.
Scrub
would
be
something
someone
could
work
on.
A
A
A
A
Oh
just
start
scrolling
down
and
see
if
we
have
responded
more
recently
than
the
thing
says:
nope.
Okay,
this
one's
actually
new
lazy
component
transform
after
overlay,
transform
questions.
So
this
is
probably
support.
Let's
see
what
they're
saying,
oh,
let
me
link
it
as
well.
A
A
B
When
somebody
uses
components
like
I
know,
we
have
something
in
the
code
that
just
says
like
accumulate
components
or
something.
How
does
that
work
like?
Does
the
component
have
access
to
all
the
resources
that
have
been
accumulated.
C
B
A
B
A
That's
that's
just
how
it
that's
just
how
it
works.
I
wonder
if
we
explain
that
in
the
docs
anywhere,
like
the
sequence
of
of
generators
and
transformers.
B
B
Oh
wait.
Sorry,
that's
not
true!
It's
the
ordering
of
resources,
never
mind
but
yeah.
It
is
on
the
in
the
docks.
It
says,
build
stage,
first
processes
resources,
then
generators,
then
transformers,
etc.
Okay,.
A
The
reason
it
doesn't
work
to
define
a
moment
that
is
meant
to
operate
on
a
config
map
you
find
in
the
same
player
that
generators.
A
Runs
the
resources
and
components?
Could
you
link
me
to
the
doc
that
you
just
read
from
in
the
chat,
so
I
can
include
that
in
a
response
here.
B
A
B
B
I
don't
see
why
not,
since
we
allow
our
more
remote
resources
and
remote
bases.
A
I
wonder
if
this
would
be
if
somebody
actually
took
advantage
of
it
very
much
if
it
would
be
very,
not
performant,
resources
and
bases
are
always
sort
of
generating
this
starting
point
for
customization.
Where
this
is,
you
know
part
of
the
core
customization
operation
itself.
A
Feature
is
supposed
to
be
more
of
a
prototyping
phase
thing,
not
a
thing
that
you
continue
to
use
in
production,
because
technically
you're
not
difficult
depends
on
what
you're,
what
you're
doing
exactly
like
you
could
be
referencing,
a
very
specific
commit
that
doesn't
change
over
time,
in
which
case
the
output
of
your
customization
run
stays
deterministic,
but
most
people
using
the
feature,
probably
aren't
doing
that,
which
means
that
the
remote
customization
is
a
source
of
variance
that
goes
against
the
way
that
we
want
customized
build,
or
we
want
to
encourage
people
to
use
customize
in
the
way
a
customized
build
should
work
by
default.
A
This
is
curious
too.
I'm
not
sure
what
why
crds
and
admission
web
hooks
are
being
mentioned.
I'll
assign
myself
to
follow
up
with
maybe
a
bit
more
question
and
explain
what
we
just
said
about.
A
A
A
A
Yeah
they're,
proposing
that
we
have
a
annotation
on
an
individual
resource
that
basically
exempts
it
from
being
touched
by
a
particular
transformer.
A
I'm
gonna
have
to
assign
this
to
myself.
It's
gonna
take
some.
I
think,
experimentation
to
make
sure
that
I
understand
their
case,
and
it
could
be
that
the
solution
is
an
alternative
structure
or
something
like
that.
A
This
is
the
exact
same
problem
that
we
just
answered
the
question
about
yeah
since
they're
explicitly
requesting
reordering.
A
It
occurs
to
me
that,
theoretically,
the
composition
resource-
that's
all
this
for
them,
because
it
allows
you
it
considers
everything
a
transformer.
Even
if
it's
like
it,
it
uses
transformers
in
generic.
It
could
be
a
transformer
validator
or
a
generator,
and
it
lets
you
using
the
full
krm
spec,
which
is
more
verbose
than
anything
that
they'd
be
dealing
with
now,
but
it
lets
you
order
in
a
completely
arbitrary
way.
A
The
problem
is
that
the
way
that
both
resources
and
components
are
implemented
right
now
is
not
encapsulated
right.
So
there's
a
significant
amount
of
work
that
needs
to
be
done
before
composition
can
actually
be
merged.
B
Yeah,
that
makes
sense.
So,
if
you
would
you
convert.
A
Yeah
exactly
it
could
be
we
first.
We
already
know
for
sure
that
we
have
to
extract
resources
into
a
generator
and,
if
I
remember
correctly,
component
is
kind
of
a
subset
of
the
functionality
of
resources
like
it.
Just
has
one
behavioral
change
with
how
they're
accumulated,
so
I
don't
know
if
it
would
actually
be
a
different
generator
or
not.
We'll
have
to
figure
that
out
it
could
be
component
generator,
it
could
be
a
flag
on
the
resources
generator.
A
I
don't
know,
but
in
any
case
like
this,
this
would
work
with
with
the
composition.
It's
just
like
not
landing
imminently
because
of
the
extreme
amount
of
work
required
to
get
it
in
got
it.
B
Yes,
that's
the
one
that
came
up
next
for
me.
We
probably
need
to
discuss
maybe
offline,
what
we're
going
to
do
about
these
cases
where
replacements
can't
replace
vars.
A
Is
this
one
where
it's
a
subportion
of
the
field
that
can't
be
structurally
delimited.
B
A
A
Okay,
all
right,
since
you
already
have
that
on
the
agenda
somewhere
else
we
can
move
on,
but
like
vars
part
of
the
problem
with
them
was
that
they
allowed
unstructured
edits.
That's
part
of
what
we
didn't
like
about
it,
and
we
thought
was
a
mistake
about
the
feature,
so
it
might
actually
legitimately
be
the
case
that
we
want
replacements
to
have
a
smaller
feature
set
than
than
vars
did.
B
Yes,
but
at
that
point
like
we
have
to,
I
don't
know,
there's
a
bunch
of
users
who
have
vars
in
these
specific
ways
that
they're
using
it.
So
I
would
like
to
have
some
sort
of
recommendation
for
what
they
can
do.
A
Maybe
we
could
exclude
kind
feature,
I
think,
for
a
bug.
Scrub
it'd
be
more
productive
to
land
on
more
that
are
actually
bugs
or
perspective
bugs.
But
let's
see.
B
A
A
A
That
has
this
different
structure,
or
are
you
thinking
that
we
could
actually
like
attempt
to
parse
it
as
a
map
find
out
or
like
attempt
to
parse
it
two
different
ways
and
see
which
one
it
is?
I
don't
know
if
that's
maybe.
B
Not
we
could
also
wait
until
we're
ready
for
customization
v1
and
then
just
change
it
in
that.
B
A
So
for
for
this
one,
I
think
I
think
we
can
certainly
reopen
the
issue
and
the
real
issue
and
close
this
duplicate,
and
it's
a
good
point
about
customization
v5.
It
might
be
kind
of
complicated
to
support
because
we
can't
sorry
not
customization
v1,
rather
not
v5.
We
want
to
be
mindful
of
how
complex
our
code
pass
will
be
while
we're
supporting
both
the
v1
spec
and
the
v1
beta1
spec.
A
All
right,
well,
there's
only
one
minute
left
so
with
that.
I
think
I'll
call
it
a
day
and
thank
you.
Everyone
for
coming
to
this
customized
bug
scrub,
hope
to
see
you
at
the
next
one
and
if
there's
any
issues
that
you
would
like
us
to
take,
a
look
at
in
the
meantime
feel
free
to
drop
them
in
our
channel
and
give
us
a
ping.