►
From YouTube: Kubernetes SIG CLI 20200422
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
Good
morning,
good
evening,
good
good
afternoon,
depending
on
where
you
are
today,
is
April
22nd,
and
this
is
another
of
our
bi-weekly
six
CLI
meetings.
My
name
is
Matty
and
I'll
be
your
host.
Today
our
agenda
is
packed
today.
So
let's
get
let's
get
the
ball
rolling.
A
quick
announcement,
119
release
dates
has
been
announced.
There
are
some
discussions
around
changing
those
a
might
shift
by
a
day
or
two
sooner
than
the
ones
that
I
put
in
the
agenda.
So
I
put
the
link
to
the
release,
119
repo.
A
You
can
follow
it
on
your
own
and
see
what
the
actual
dates
are.
Also
the
changes
were
announced
in
cubed
F.
If
I
remember
correctly,
Stephan
Augustus
sent
an
email
on
Monday
about
their
above
the
PR
which
will
be
modifying
those.
So
that's
the
most
important
announcement
and
with
that
we
can
move
to
the
main
topics
and
first
one
will
be
Jordan
with
mechanisms
for
worrying
about
API
changes.
C
So,
as
you
can
see
on
the
agenda
item,
there's
an
issue
regarding
how
we
can
have
composition
customized
for
those
who
are
not
familiar
with.
What
is
this
issue?
Basically,
the
the
TLDR
is.
This
customized
has
supports
self-contained
application,
customization
logic
into
overlays,
and
you
can
stack
this
overlay
as
you
can
change
them.
You
can
compose
them
as
you
build.
The
thing
is,
though,
that
if
these
overlays
have
the
same
base,
then
the
may
the
customization
may
not
apply.
C
C
My
question,
regardless
seizures,
is
something
that
is
acknowledged
as
a
problem
in
customized
I
mean
how
you
can
put
logic
into
overlays
and
then
compose
in
some
way,
and
if
it's
acknowledged
as
a
problem,
is
this
something
that
there's
a
PR
that
fixes
that's
proposed
a
solution
for
it?
This
is
PR
towards
right
direction.
Does
a
customized
core
team
have
a
different
way
to
solve
this
issue,
and
that
question
goes
mostly
to
Philip
with
drunk.
E
D
D
All
those
are
covered,
and
in
that
way
we
can
let
it
take
up
the
rest
of
the
meaning
watch
hey.
What
do
you
think
about
that?
Just
because
I
know
that,
like
when
we've
done
this
in
the
past,
usually
we
get
in
we
get
into
a
good
technical
discussion
and
then
have
to
kind
of
cut
it
off
halfway
through
to
address
the
other
items.
C
A
Perfectly
that's
perfectly
fine
and
we
like
to
have
technical
discussions
and
I
see.
There
is
another
customized
topic
from
chance
towards
the
end.
I
I'm
pretty
sure
that
Julian
Antoine
they
want
to
announce
the
changes
to
the
server
side,
apply
up
coming
in
at
1:19
time.
I
hope
it'll
be
reasonably
quick
unless
Jordan
is
ready
with
his
announcement
about
the
warning,
api's
yeah
I'm,
ready.
Sorry
about
that
sure,
no
worries.
Okay,
let's
try
to
share
your
screen.
B
All
right
into
it,
yep
cool,
okay,
so
just
to
walk
really
quickly
through
what
I'm
envisioning.
This
experience
would
look
like.
We've
had
a
problem
for
a
long
time
where
we
have
things
that
are
long,
deprecated,
that
people
don't
actually
realize
are
deprecated
or
they're
using,
and
they
don't
realize
it,
and
then
it
gets
dropped.
You
know
a
year
and
a
half
later
and
they're
surprised.
So
this
proposal
is
to
try
to
help
avoid
that
surprise.
B
This
is
a
it's
just,
a
header
that
comes
back
from
the
server
so
like
everything,
but
previously
succeeded.
Server-Side
will
still
succeed
and
old
clients
that
don't
pay
attention
to
these
wanting
headers
would
continue
working,
as
is
it
would
be
stuffing
client,
go
to
parks
these
headers
out
and
have
them
available
in
the
responses,
and
then
a
piece
and
cube
control,
specifically
that
would
handle
those
warnings
by
outputting
them
like
this,
and
because
it
happens
at
the
client
level,
it
applies
matter.
What
commands
you
run
so
if
you
want
to
get
command
or
if
you.
B
You're
doing
annotate,
like
whatever
you're
doing,
if
you're
talking
to
deprecated
end
points
and
you're
getting
back
warning,
headers,
you're
gonna,
get
these
things
out,
I
think
it
works
for
or
raw
output.
So,
if
I
exciting
I
talked
to
a
deprecated
API
again
because
it's
happening
with
the
client
level,
you
know
the
headers
come
back.
We
can
display
them,
so
we
can
do
some
clever
things
like
deduplicate
warnings.
You
know
for
a
given
invocation
in
control.
B
So
if
you
create
50
at
the
same
thing,
you're
not
going
to
get
the
same
message
50
times,
that's
just
silly
anyway.
The
the
cap
is
linked
from
the
agenda.
The
main
impact
to
sig
CLI
is
the
Q
control
piece,
which
is
how
we
decide
to
handle
these
warnings
inside
control,
and
so
my
proposal
is
deduplicating,
outputting,
2,
standard
error
and
coloring.
B
The
warning,
if
you're
on
a
smart
terminal,
David
had
one
request
in
the
cap
to
have
an
option
to
treat
warnings
as
fatal,
so
that
someone
who
was
running
in
CI
could
opt
in
to
like
running
in
strict
mode
or
whatever,
so
that
that's
kind
of
the
the
only
outstanding
thing
for
Q
control.
That
was
part
of
the
that
was
under
discussion.
D
Jordan
does
the
output
a
different
shape
between
like
this
is
a
warning,
and
this
is
like?
Does
it
have
levels
of
severity.
D
C
B
D
I
was
wondering
whether
the
last
thing
you
said
about
the
exit
code
like
I,
could
imagine
you
know
having
Mexico
like
emitting
just
to
standard
output,
exiting
zero
like
until
the
it
like.
Oh
it's
about
to
be
deprecated
or
something
like
that
or
like
Ike.
Imagine
different
behaviors
when
you
control
on
the
server
side,
yeah.
A
B
Good
warning
mechanism
is
a
general
mechanism.
The
first
use
of
it
would
be
around
deprecated
API
z--,
but
there
are
other
things
that
we
would
want
to
warn
about
things
like
you
sent
us
duplicate
fields
in
amo
file
like
we're,
ignoring
everything,
but
the
last
field.
You
probably
didn't
mean
to
do
this,
that's
probably
an
error,
but
we
can.
A
F
B
G
B
E
I
G
B
About
like
we
test
and
support,
keep
control
within
a
minor
version
of
the
server
I'd
like
to
see
that
widen
actually,
but
whatever
our
support
statement
is
like,
if
you're
using
a
version,
that's
one
or
two
or
three
or
five
versions
old,
like
rather
than
making
people
have
to
notice
squirrely
behavior
that
crops
up.
Because
of
that
and
then
file
an
issue
and
then
ice
tell
them.
Oh
yeah.
H
Definitely
I
guess
what
I
was
said.
What
I
was
saying
is
is,
if
you
have
you,
know,
clients
other
than
keep
you
know.
Does
the
server
need
to
know
anything
about
keep
control
to?
You
know
to
know
like
to
bake
in
something
that
says:
I'm
gonna
check
specifically
for
this
user
agent
to
see
if
it's
compatible,
but
there
may
be
other
other
clients
or
whatever
that
needed
a
test
there
yeah.
B
A
E
Awesome,
okay,
so
I
think
we
missed
one
done.
I
need
nineteen
planning
last
week
or
couple
weeks
ago,
but
we
just
wanted
to
announce
what
we're
planning
to
do
for
this
release
for
server-side
apply.
We
would
really
like
to
get
the
default
for
keep
CTL
as
close
as
possible
to
be
server-side
apply
so
that
two
important
pieces
there
are
the
upgrade
and
the
downgrade
so
we're
looking
for
early
feedback
on
the
cap
and
then
some
of
the
changes
or
what
we're
planning
to
do
and
then
eventually
actual
like
some
reviewer.
E
Ideally,
that's
the
same
person
yeah
and
maybe
some
briefly.
What
were
we
want
to
do
for
the
upgrade
is
make
it
so
that
there
aren't
conflicts
initially,
when
someone
wants
to
manage
an
object
with
server-side
apply
instead
of
client-side
apply
and
then
for
the
downgrade.
We
want
to
make
it
also
seamless.
E
A
E
A
J
You
know
I
think
I
want
to
I
want
to
add
something.
So,
especially
since
we
have
this
sick
release,
email
yesterday.
That
says
that
we
shouldn't
do
something.
That's
gonna
require
an
action.
There
is
a
little
difference.
That's
gonna
happen
when
you,
when
we
change
the
inside
of
lights
outside
apply
by
default,
is
that
now
we
can
have
conflicts
if
you're
trying
to
change
your
feel
that
somebody
else
owns
which
didn't
happen
before
so
I'm
thinking
about
the
CI
CD
system
that
have
our
youth
could
call
today
to
apply
files.
A
A
This
is
a
problem
and
either
a
link
to
a
blog
post,
a
bigger
documentation
or
if
it
fits
several
lines
that
you
can
put
in
in
the
air
it's
better
to
over
document
this
problem,
if
we
actually
will
be
seeing
these
problems
rather
than
rather
than
not
so
that
that
will
be
my
only
my
only
ask
about
that.
One,
but
I'll
I'll
have
a
look
in
the
cap
and
I'll
leave
the
comment
as
well.
There
sounds.
A
K
So
I've
been
working
through
trying
to
get
some
best
practices
together,
because
all
of
our
commands
do
things
differently,
every
single
one.
The
problem
is
that
there's
still
no
source
of
truth,
so
I've
been
throwing
questions
at
you
ma
che
and
Phil
and
Shawn
and
Brian,
and
everyone
so
I
think
we
need
to
figure
out
I'm
happy
to
take
the
charge
on
it,
but
I
don't
know
what
we
want
to
decide
on
so
I'm
happy
to
document
and
maintain
and
get
it
all
up.
K
But
it's
just
like
simple
things
like
you
know,
we
have
the
complete,
validate
and
run
method,
says
convention.
Should
those
be
exported
right,
like
they're,
not
really
usable
outside
of
calling
you
can't
can
never
use
validate
without
pulling
complete
for
it.
Otherwise
this
truck
will
be
set
up
right
so
like
not.
If
it's
really
useful,
unless
you're
running
through
everything
by
itself,
should
you
always
include
them
as
stubs
or
should
you
leave
them
out
if
there's
no
need
to
like
do
a
complete
or
something?
K
A
Yeah
I'll
be
definitely
in
favor
of
documenting
these,
because
we've
been
we've
been
repeating
those
over
and
over
through
several
sig
meetings
on
past
cube
cons
and
whenever
I
was
doing
a
code
overview
for
cube
Caudill.
These
were
definitely
one
of
the
most
important
topics
and
questions
that
I
was
answering
asked
for
the
the
three
methods
I'm
leaning
towards
no,
we
don't
have
to
have
them
if
it's,
if
you're
not
doing
anything.
So
it's
fine
to
I
I,
don't
see
any
reasons
for
every
command
to
have
empty
method.
Just
to
follow
the
pattern.
A
It's
it's
I
think
it's
useless.
The
fact
that
you're
you
will
be
exporting
them
is
for
other
people
for
other
consumers
to
be
able
to
reuse
the
command
or
build.
On
top
of
the
commands.
I
know
that
I'm
doing
this
and
I
know
we
are
doing
this
within
cube,
Caudill
itself.
For
example,
the
weight
command
is
being
reused
in
delete
and
some
other
place
and
I
was
recently
pointing
to
someone
how
he
can
reuse
the
weight
command
in
openshift,
I'm,
reusing
part
of
the
commands
and
building
on
top
of
them.
A
So
that
kind
of
a
pattern
is
is
very
helpful
because
you
can
easily
hook
into
either
completing
the
structure
or
validation
or
the
actual
execution
as
well.
It
simplifies
a
lot
unit,
testing
of
the
commands.
If
you
look
through
some
of
the
commands,
even
today,
the
unit
tests
that
some
of
them
have
are
super
complicated.
There
are
creating
the
entire
factory
and
everything
else
to
be
able
to
verify
very
simple
bits.
A
The
test
Factory,
instead
of
just
you
know,
fill
in
the
structure
that
you
care
and
run
either
validation
or
the
actual
command
with
fake
clients,
which
are
much
easier
than
setting
up
the
entire
test
factory,
which
is
usually
enormous,
and
you
end
up
implementing
fake
HTTP
requests,
which
is
at
the
same
time,
which
is
very,
very
cumbersome.
That's
why
I
would
lean
towards
yes
having
three
they're
not
required,
although
probably
complete
and
Enron
would
be
required
and
invalidate
will
be
optional.
That's
what
I
was
usually
telling
in
the
past.
A
I
would
keep
the
same
statement
here
and
made
sure
to
to
follow
what
Shawn
started
and
we're
talking.
Last
meeting
and
the
meeting
before
about
separation
between
the
copra
flags
and
the
actual
implementation,
those
bits
I
know
we,
we
don't
have
them
implemented
across
the
entire
code
base,
but
it's
definitely
something
that
we
would
like.
We
would
want
to
see
in
the
long
run.
K
Okay,
so
why
don't
we
do
this
so
I
pasted
a
link
to
the
the
PR
I
have
open
if
everyone
can
just
pile
on
with
all
the
nitpicks
and
everything,
and
we
can
like
figure
out
like
let's
make
this
PR.
The
perfect
example
of
what
a
command
should
look
like
and
then
from
that
I
can
get
a
dot
together
that
we
can
circulate
and
fill
in
the
unanswered
questions.
But
let's,
let's
use
this
PR
as
a
source
of
truth,
because
then
I
can
pull
out
all
the
best
practices
that
we
implement
from
there.
A
K
That
is
awesome
idea.
The
nice
thing
is
that
once
we
get
these
umbrella
issues
as
I've
been
waiting
to
open
the
umbrella
issue
to
refactor
all
the
commands,
like
we
put
on
1.19
roadmap,
and
so
once
we
get
like
the
best
practice
is
done
and
we
can
open
an
umbrella
issue,
mark
it
as
good,
first-time
contributor,
with
the
docs
and
the
guides
and
hopefully
get
a
bunch
of
new
people
contributing
on
that
work.
K
A
A
Let
me
find
the
PR
that
I
was
looking
at
because
I
had
it
open,
so
I'll
leave
out
the
ones
that
I'm
dropping,
because
the
those
people
are
not
present
anymore.
But
I
would
like
to
shout
out
to
Brian
and
Yahoo
because
they
will
they
are
nominated
for
reviewers
and
I'll
put
the
pr
to
get
her
later
today.
So
they
will
be
our
official
six
Eli
reviewers
I'll
link
the
I'll
link
the
PR
in
the
agenda
later
today,
as
well.
A
D
D
So
it's
trying
to
reconstruct
butt-fuck,
like
all
the
ideas
in
here
was
actually
a
bit
challenging
for
me,
and
so
I
want
to
make
sure
that
I
kind
of
understand,
like
kind
of
the
core
pieces
and
maybe
I'll
just
read-
reached
what
should
I
every
state
as
I've
read
it
or
Alex.
Would
you
like
to
kind
of
summarize
the
you
know
key
points
that
you
think
are
the
most
important
I.
C
D
A
abstraction,
almost
pattern
so
think
about
customized,
like
the
on
to
you
core
use
cases.
One
is
that
you
want
to
have
some
base,
which
is
like
my
spring
Java
back-end
service,
or
something
like
that
right,
which
defines
most
of
what
a
spring
Java
back
in
services
and
then
maybe
switch
out
the
config
navette
references,
the
image
name
and
the
like
resources
or
something
I
can
imagine.
And
now
you
can
stamp
out
like
five
different
back-end
services,
each
consuming
from
the
same
base
and
that's
kind
of
a
composition.
D
Your
you
have
a
composite
customized,
referring
to
each
one
of
those
bases
and
needing
to
patch
the
same
base
differently,
multiple
times
or
apply
different
images.
That
sort
of
thing.
The
second
pattern
customizes
used
for
a
lot,
is
this
sort
of
variant
approach
where
instead
of
composing
instead
about
composing
the
same
thing
many
times
and
kind
of
expanding
it
into
multiple
instances
that
are
different,
logically
different
on
running
next
to
each
other.
D
F
D
This
issue
was,
to
sorry
was
to
kind
of
add
a
layer
of
inheritance.
If
you
will,
where
you
apply
a
name
prefix
to
each
instance,
that
inherits
is
from
that
base
is
the
different
name
prefix
that
changes
their
IDs
and
then
that
they've
been
they
can
be
used
separately
and
identified
separately.
I
didn't
quite
get
from
the
issue,
if
that
case
bad
solution.
D
C
Yeah
I
think
you
have
approached
the
problem
very
well.
It's
it's.
The
first
case
that
you
stand
for,
but
I
think
it's
a
little
different,
the
actual
issue.
The
problem
is
not
that
the
tree
robbery
is:
let's
say
that
once
you
pass
the
same
service
and
thus
the
same
key,
the
problem
is
that
when
we
have
two
overlays
and
we
compose
them,
the
same
dais
is
multiplied
by
as
many
times
you
have
overlays,
it's
replicated
to
say
that
so
there's
not
just
one
key,
that
the
overlays
will
point
you.
C
There
are
two
keys
now
and
customers
can't
Hallberg
can't
handle
this.
As
you
said,
the
approach
was
to
when
customized
finds
to
novelist
a
point
to
the
same
base.
The
approach
was
to
replicate
it
and
thus
create
a
second
second
instance
of
that
application.
But
my
question
is
in:
in
which
cases
does
this
make
sense?
If
you
want,
you
have
two
separate
instances
of
the
application,
which
means,
for
instance,
two
different
deployments
with
two
different
name:
prefixes.
It
probably
creates
different
overlays
and
you
do
different
oopsey
to
apply
Kay.
C
C
Hey
that's
what
customize
does
right
now.
The
ideal
is
to
separate
two
over
this-
let's
say
an
overlay
for
authentication
stuff,
and
not
only
for
storage
stuff.
That
effect
that
edit,
that
alter
the
same
key
underneath
the
same
base
and
should
be
just
one
instance
with
those
two
stuff
incorporated
in
it.
I
don't
know,
I,
focus
more
sense
and.
D
C
C
D
D
D
Certain
transformations
so
I
know
he's
head
down
on
that
and
he's
been
really
cranking
that
out
I'm
guessing
it's
gonna
be
another
month
or
so
you
know
it's
kind
of
my
swag
on
that
one,
but
but
I
will
reach
out
to
him
about
this.
I
think
this
is
something
we'd
like
to
address,
or
this
is
a
problem
that
users
should
be
able
to
solve
without
forking
customize
that
that's
true,
we
looked
explored
within
the
reuse
case.
D
There
are
a
couple
even
sub
variants
of
that
case
within
the
like
sort
of
abstraction
case,
which
you're
describing
I
think
there's
a
couple
variants.
One
is
you
an
individual
owns
pretty
much
all
of
the
variants
and
bases
right
and
so
they're
trying
to
construct
a
sophisticated
system
using
customized,
which
kind
of
does
this.
They
build
this
graph
right
and
that
works
that
would
work
best
for
folks,
where
maybe
one
or
two
individuals,
or
maybe
even
a
team
of
individuals,
is
centrally
managing
a
system
that
has
this
means
those
needs
I
just
write.
Another.
D
This
is
where
it
gets
into
kind
of
the
packaging
world,
because
that
starts
to
look
much
closer
to
what
a
typical
packaging
solution
would
look
like
in
which
previous
discussions
have
led
to
not
being
a
problem
but
kubernetes
community.
The
q-
project
is
currently
looking
to
solve,
and
so
or
that
pattern
we've
kind
of
pushed
and
built
another
tool
for
doing
package
management
of
that
nature.
And
so
that
might
be
something
worth
considering
for
that
case.
D
If
thinking
about,
is
it
a
better
model
for
you
to
do
sort
of
a
model
where
you
pull
down
the
configuration
and
have
it
locally
and
then
maybe
customize
three
different
instances,
but
those
three
different
instances?
You
have
kind
of
pulled
down
from
a
source
versus
there,
pull
down
from
the
same
source
and
then
can
kind
of
be
updated
from
that
same
source,
but
they're
stamped
out
fully
and
fully
expanded
and
then
use
those
as
inputs
to
customize.
Or
do
you
do
that
case?
D
D
The
the
two
I'm
referring
to
is
capped.
Yes,
so
kepta
satori
said:
okay,
some
of
us
said:
okay,
that's
out
of
scope
for
the
project,
but
we
need
kind
of
a
way
of
doing
it,
and
so
we
built
that
well,
there's
probably
other
ones
for
doing
package
management
as
well.
That
I'm
not
aware
of,
but
maybe
use
a
similar
approach.
I
think
there's
one
called
kupack
back
in
the
day:
I'm,
not
sure
what
the
status
that
project
is,
but
but.
D
C
D
I
can't
say
that
it's
definitely
gonna
solve
your
problem.
I
can
only
say
that
in
my
it
might
be
an
alternative
approach
right
and
was
kind
of
written
with
this.
This
problem
in
mind
from
a
different
angle:
I
guess
that
said
you
may
you
may
look
at
it
and
say,
like
you
know,
actually
I
prefer
the
more
centralized
approach
to
this,
in
which
case
I
think
we
should
still
explore
this
problem.
We
can
I
think
it
makes
more
sense
to
die.
D
I
know
it's
been
a
year,
so
I
really
appreciate
your
patience
on
that
and
I
think
it
will
be
easier.
I
think
you
did
note
that
Jeff
dropped
off
on
attention
on
this
issue
and
that
I
think
it's
because
he's
been
focusing
on
that
other
key
problem
and
while
it
may
seem
like
just
kind
of
an
infrastructure
change
that
maybe
isn't
addressing
our
new
users
pain
points
right
because
the
to
what
extent
do
you
see
the
value
of
us,
you
know
rewriting
that
piece.
D
If
you're,
maybe
using
customized
directly,
not
control
and
say
it
will
actually
impact
how
things
are
written
for
going
forward
and
will
offer
more
capabilities
for
how
we
implement
transformers
and
how
transformers
are
configured,
and
so
by
doing
that
were
early
ahead
of
this,
it
means
that
this
work
can
be
built
on
top
of
that
architecture.
Instead
of
trying
to
figure
out.
D
D
D
Actually
so,
but
I
think
one
thing
that
would
help
and
there's
no
urgency
to
doing
this
would
be
that
if
we
could
maybe
write
this
from
the
user
documentation
perspective
like
I've
been
trying
to
envision
it
like
what
would
the
doc
that
says,
the
motivation
for
this
tool?
Is
this
feature
like
if
it
if
the
BI
were
to
be
moved
from
this
feature?
What
would
the
docs
look
like
and
using
that
as
kind
of
the
design
basis
outside
of
this
issue?
With
this
issue
captures
a
great
amount
of
history,
certainly
encounters
a
great
amount.
D
The
problem
from
a
technical
perspective,
I
think,
if
you're
trying
to
learn
about
the
problem
itself,
there's
a
lot
of
great
information
here,
but
focusing
on
just
like
what
does
the
solution
look
like
and
how
simple
is
it,
and
how
easy
is
it
to
understand?
Independent
of
this
would
be
maybe
a
nice
addition
to
help
us
I.
L
L
D
I
I
do
agree,
it's
in
the
it
is
in
the
issue.
It's
in
the
issue,
I
think
it
might
be
in
the
Miss
you
multiple
times
with
multiple
proposals,
or
maybe
there,
the
Seattle
to
variants
of
it
right
so
I
think
it's
not
about
like.
Oh,
this
information
doesn't
exist,
but
you
know
to
help
people
with
less
context
on
the
issue.
Maybe
just
pulling
out
like
which
of
these
things
in
the
issue
is.
It
is
the
one
that
we
decided
is
the
right
one
and
then
putting
that
in
on,
like.
D
L
F
L
I
couldn't
come
up
with
some
examples
to
probably
and
provide
them
somewhere.
I
just
need
to
know
it's
best
because
it
seems
like
there
was
already
a
lot
of
content
and
I
didn't
want
to
like
muddy
muddle.
The
waters
like
a
simple
example
is
just
like
I
want
to
disable
this
feature
and
I
don't
want
to
have
to
like
look
at
the
commit
history
to
figure
out
what
the
em1
needs
to
look
like
for
that
to
be
changed.
L
C
Examples
and
in
a
different
repository,
which
are
linked
in
the
PR
but
I,
get
what
you
say.
The
main
thing
here
is
that
the
issue
is
very
big
and
it's
very
difficult
for
new
users
to
navigate
into
it
and
the
whole
history,
so
I
suppose
I
can
distill
the
main
points
of
that
issue,
probably
to
let's
say
in
new
PR
that
that's
some
high
level
user
documentation
which
probe
is
not
correct,
but
so
case.
What
you
can
do
with
this
PR
with
composition,
yeah.
D
If
we
could,
if
we
could
just
agree
upon
the
eight
from
the
person,
who's
gonna
consume
this
perspective
first
and
then
have
that
in
like
just
like
a
markdown
file
right
but
like
from
the
perspective
of
like,
like
you,
could
almost
do
a
there's.
A
task
sort
of
documentation,
I
think,
is
one
of
the
patterns
right.
D
So
maybe
starting
out
with
the
tat
like
a
task,
doc
can
say:
okay,
you're
trying
to
add
to
this
resource
with
that
resource
and
then
just
goes
through
and
wood
has
the
same
format
that
if
we
were
trying
to
sell
this
feature
to
an
end-user
about
how
they
would
do
it,
which
I
think
there's
a
lot
of
stuff.
That's
really
close
in
here.
D
But
how
about
having
it
as
a
separate
markdown
PR
would
be
I
think
helpful
to
steer
the
discussion
around
that
sure,
and
then
this
has
been
around,
given
that
this
has
been
around
a
year
iterating
on
kind
of
that
API
piece
and
then
fully
focusing
on
it
once
the
rebase,
that's
in
progress
is
done.
I
think
would
be
like.
Does
that
seem
like
a
good
good
approach
to
you
like.
L
C
L
One
I
was
gonna:
ask
one
of
the
things:
I
was
thinking,
I
found
like
kind
of
nice
and
it's
what
they
did
with
issue
I
wanted
to
bring
up
next,
it's
just
like
having
a
future
fight
for
that.
Behavior
is
like
another
thing
would
be
really
solid,
I
think
because
it
would
mean
you
could
get
it
in
and
not
commit
to
stability,
but
how
people
try
it.
You
know
the
docs
that
are
being
offered,
especially
and
like,
if
it
sucks
and
it's
like
not
actually
doing
what
we
want
and
it's
like.
D
D
D
D
L
The
idea
is,
instead
of
using
transformers
to
adjust
values,
you
annotated
yields.
There's
some
echo
you
annotate
fields
with
comments
and
customize,
either
in
the
resource
or
in
your
customization,
amel
and
customize
can
then
use
like
customize
config
set
and
then
the
center
name
and
then
the
value
that
you
want
to
set
it
to.
L
So
you
get
templating,
no
templating,
but
you
still
have
the
ability
to
adjust
arbitrary
values
at
very
particular
locations
and
the
resources
or
customization,
and
so
I've
been
using
this
in
a
lot
of
the
ways
that
was
being
discussed
previously
is
like.
There
is
no
good
way
to
have
like
a
JBoss
base
or
like
a
Python
base.
That
is
just
super
reusable,
so
we've
been
creating
a
scaffolding
base
that
would
copy
and
then
use
setters
to
change
the
things
that
matter
like
the
default
namespace
or
the
name
of
the
resource,
the
Act
label.
L
And
then
we
use
the
same
approach
for
an
overlay
and
and
then
we
basically
have
a
pair
of
scaffolding
for
a
base
and
an
overlay
a
pair
for
everything
we're
doing
so
far.
This
is
going
well,
there's
still
caveat
so
setters
not
working
perfectly,
but
I.
Think
it's
a
good
start
and
I
was
wanting
to
know
how
we
get
it
from
like
an
alpha
to
a
more
stable,
State
or
beta,
because
right
now
it's
behind
a
future
environment
variable
before
you
can
use
customize
kind
of
fix
it.
So,
yes,.
D
D
In
their
own
binary,
okay,
we
can
be
built
as
well
and
that
one
will
be
up
to
date
as
well.
Whatever
release
I
think
one
thing
you're
asking
for
is
I'm
hearing
you
like
this
feature.
You
would
like
us
to
continue
to
invest
in
it
and
bring
it
to
be
like
a
formally
formally
part
of
the
customized
solution,
as
opposed
to
some
experiment
that
we're
evaluating
I.
L
L
D
F
One
thing
I'd
like
to
mention
is
for
a
lot
of
the
problems
that
Alex
was
bringing
up.
I
started,
making
a
little
POC
that
use
kept
and
setters
of
customized
to
kind
of
work
around
I
think
a
very
similar
issue
so
that
I
couldn't
apply
a
shared
set
of
patches,
so
I
also
I.
Also
like
the
Sutter
feature,
it's
it's.
What
I'm
using
to
replace
and
places
where
I
was
previously
using
variables,
so
it's
pretty
nice.
C
F
L
F
L
L
L
Cap
stocks
are
pretty
good
about
covering
this,
like
I,
pretty
much
used
it
as
my
reference,
but
without
kept
so
kept,
has
a
few
add-ons
to
the
futures
that
customize
doesn't,
but
you
can
mostly
make
it
work
if
you
read,
the
combination
of
the
hub
for
custom.
I
can
fix
that,
and
also,
if
you
read
the
ket
docs
on,
because
KPT
CFG
set
they're
built
on
the
same
libraries.
L
I
was
just
like
using
customized
and
like
handwriting
my
base
and
overlays
and
then
copy
jar
and
and
then
using
customized
config
set
all
from
a
readme.
So
it's
basically
toriel,
driven
onboarding
of
new
apps,
for
our
internal
teams
is
how
we're
using
this
and
it's
okay.
It's
not
amazing,
but
it's
not
like
terrible
either
just
there's
gaps,
the
setters
that
you
can't
use
it
on
a
non
animal
problem,
basically
in
some
ways-
and
that
can
be
a
problem
but.
D
I
think
did
you
mention
writing
a
camp
as
in
K
EEP
or
there
I
was
referred
to
camp
et
yeah
yeah
I
was
gonna,
say
the
probably
like
the
process
for
doing
this
in
the
project
is
to
write
kubernetes
enhancement
proposal.
Okay,.
F
D
L
So
I
just
go
something:
handsomest
repo,
like
everything
else,
the.
D
A
A
M
I
can
let
everybody
go
like
what
go
see
a
pointer
to
our
documentation.
The
wiki
link
is
there
in
the
in
the
zoom
check
it
out
mostly
done
there's
a
few
gaps,
but
it's
pretty
much
done
it's
all
in
pretty
good
shape.
We're
also
starting
some
some
initial
work
to
get
OpenShift
support
to
gear
it
up
and
so
that'll
all
be
coming
soon.
We
have
some
initial
support
in
there
already.
Okay.