►
From YouTube: Kubernetes SIG CLI 20200729
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
A
Is
that
a
good
saltish
impression
there
would.
B
A
A
Welcome
everyone
to
july
29th
edition
of
the
six
cli
meeting.
We
got
a
couple
items
on
the
agenda
here.
Add
your
names
to
the
attendees
and
add
any
items
to
the
topics.
I
think
we're
gonna
have
a
little
bit
of
a
light
day
today.
So
that'll
give
us
maybe
a
chance
to
dig
into
some
of
these
topics
a
little
more
than
we
otherwise
would.
A
A
All
right
moving
on
topics,
actually
I'm
going
to
move
off
matches
topic
here
because
he's
not
here
today,
eddie
you're
up.
D
Sure
yeah
at
the
last
bug
scrub
one
of
the
one
of
the
issues
we
looked
at
was
882,
which
is
implementing
cube,
cuddle
command
line
completion
using
go
instead
of
bash,
and-
and
this
is
really
taking
advantage
of
of
what
so
the
idea
of
originally
this
issue
was
taking
advantage
of
what
was
in
cobra
1.0.
D
Let's
see
last
meeting,
I
guess
philip
mentioned
that
you
that
there's
another
completion,
that's
being
used
in
in
customized,
called
postner
complete
and
that
it's
working
well
for
customize.
So
the
question
was,
you
know:
should
we
which
direction
should
we
go
in?
So
I
think
you
know
we
kind
of
said.
D
Let's
go
away
for
a
week
and
and
kind
of
look
at
look
at
this
and
admittedly
I
didn't
take
a
week
to
look
at
it,
but
I
did
look
at
it
a
few
times
during
the
week
I
mean
I
have
a
few
thoughts.
I
I
know
knight
42,
jean
zhang
is
looking
at
working
on
this
issue,
and
so
I
think
he's
gonna
he's
probably
looking
for
some
direction.
D
I
think
he's
working
on
the
cobra
version
of
it
right
now,
but
I
did
give
him
a
heads
up
that
we
talked
about
it
in
the
bug
scrub
and
that
we're
gonna
discuss
it
today,
so
anybody
have
any
thoughts
on
on
the
difference
between
like
cobra
and
and
poser
complete.
Besides,
I
mean
I,
I
have
a
few,
but
I'm
interested
to
hear
what
other
people
think.
D
C
D
Yeah,
that's
mark
kuzam.
I
think.
A
I
can
talk
about
the
like.
I
did
the
posner
one
for
customize,
and
so
I
can
talk
about
the
things
I
liked
about
it
now.
Those
might
not
be
this.
This
may
be
addressed
in
the
cobra
version
now
and
I
think
brian
and
I
got
a
chance
to
talk
about
this
offline
or
in
slack
the.
What
I
like
about
the
posner
completion
is
that
the
completion
all
the
completion
is
done
inside
the
go
binary
itself.
A
So
what
gets
added
to
your
bash
rc
or
your
csh
rc
or
whatever,
is
just
an
invocation
of
the
actual
command.
So
it's
like
control
coup
control
right,
and
so
this
means
like,
for
instance,
when
you
update
the
update
the
binary,
like
it
automatically
updates
the
completions.
A
The
completion
code
is
like
pretty
simple
from
the
perspective
of
the
bash
file,
like
there's
just
a
single
line
there
and
not
functions,
so
those
are
the
things
I
really
liked
about
it.
I'm
not
sure
what
the
latest
on
the
cobra
situation
is.
D
Yeah
I
mean
in
my
bash
rc
it's
a
one-liner
to
put
it
in
me,
I'll
I'll
paste
it
in
the
chat
window
here,
but
basically
I
mean
basically,
I
just
have
this
in
my
bash
rc
to
get
completion,
but
I
mean
I
know
what.
D
That
I
mean
because
this
really
just
spits
out
a
big
giant
bunch
of
bash
and
yeah.
I
mean
one
thing
that
I
forgot
to
mention
and
I'm
not
arguing
either
way.
I
really
don't
care
too
much.
I
guess
I'm
just
trying
to
make
the
case
of
whether
we
should
deviate
from
where
we're
at
now,
but
is
that
people
already
have
this
in
their
bash
rc.
A
I
see
because
the
new
cobra
one
just
uses
the
same
spit
out
a
bunch
of
bash,
but
but
it
does
it
using
the
same
command.
So
it's
like
kind
of
a
seamless.
A
A
Is
gonna
say
how
does
this
work
for,
like
writing
your
own
completions
right?
So
if
you
want
to
do
like
completions
of
like
the
pods
like
complete
autocomplete
pod
names,
complete
namespace
names,
where
it
reads,
it
would
read
the
name
of
the
or
would
leave
the
list
of
pods
from
the
server
like.
Is
that
supported.
D
Yeah,
that's
and
and
and
that's
supported
in
poster
as
well.
That's
the
predictions.
I
think
they
call
it
in
that.
But
with
and
that's
one
of
the
major
improvements
in
cobra
1.0
is
the
ability
to
write
those
dynamic,
completions
using
go
and
right
now
we
just
have
a
whole
bunch
of
custom
written
bash
that
we
have
in
the
cube
cuddle
project
or
in
the
the
cuco
part
of
the
project
that
spits
out
a
bunch
of
customized
handwritten
bash.
A
A
If
we
switch
the
new
cobra
one,
it
seems
like
a
clear
improvement
over
what
we
have
like
you
were
saying,
with
kind
of
a
backwards
compatible
approach,
and
we
can,
if
it
is
great,
then
leave
it
and
way
to
go
or
if
we're
like.
Oh
that,
you
know
maybe
down
the
line,
it
doesn't
do
quite
what
we
need
and
postner
does.
Then
I
think
we
can
like
swap
it
out
at
that
point
in
time
too,
it's
not
like
a
one-way
door
like
because
we're
not
breaking
backwards.
C
The
I
want
to
give
the
context
here
so
a
lot
of
the
bash
completion
has
currently
has
to
be
manually
implemented.
I
don't
know
if
any
everyone
knows
how
bash
completion
works,
but
it's
kind
of
like
magic.
You
basically
like
get
a
magic
bash
function,
call
during
a
completion
and
you
you
set
an
environment
variable
or
a
bash
variable
to
like
comp
reply
or
something
and
that
magically
populates
your
bash
completion.
C
So
it's
like
a
pretty
you
know,
inelegant
solution,
and
the
issue
is
that
a
lot
of
our
resources
have
to
have
custom
bash
functions
created
currently
to
do
that,
and
it's
it's
just
very
tedious.
It's
not
difficult
at
all.
It's
just
a
ton
of
like
bash
parsing
and
scripting,
and
so
I
think
that
the
the
reason
this
all
came
up
is
these
two
options.
C
Give
us
a
way
to
avoid
doing
all
that
in
bash
and
go
will
just
magically
generate
it
all
for
us
is
that
accurate
brian
yeah,
I
think
so
so
so
so
where
we're
at
is
like
we,
we
do
need
to
pick
a
solution,
because
people
keep
opening
random
issues
that
are
like.
Oh,
we
need
batch
completion
for
this
one
resource.
D
And
it's
actually
the
other
shells,
it's
the
shell
and
fish
that
that
are
driving
this
bash
bash
completion
actually
works
pretty
well
in
cube,
cuddle
right
now.
So
that's
the
other
kind
of
tricky
thing
about
this.
Is
we
want
to
make
sure
that
we
don't?
We
don't
break
it
for
the
things
that
are
working
well,
yeah.
C
D
A
Some
of
this,
some
of
this
stuff
is
going
to
be
complex
to
get
right,
for
instance
like
if
you
want
to
auto
complete
the
short
name
for
a
crd
and
control,
get
right
like
that.
The
only
way
to
do
that
is
look
at
the
crds
installed
in
that
cluster,
find
their
short
names
and
then
give
it
as
a
suggestion
right.
So
I
think
there's
going
to
be
like
a
long
tail
of
stuff
where
it's
it's
going
to
be
like
custom
and
one
thing
we're
trying
to
avoid
right.
A
A
It
sounds
like
that
is
the
that's
supported
in
both
approaches.
Then
there's
like
the
short,
like
there's
just
kind
of
the
fundamentals
of
stuff
that
people
should
work,
expect,
should
work
right
where
it's
like
the
built-in
commands
right
and
then
there's
going
to
be.
I
think,
stuff
that
is
kind
of
in
between
right,
like
the
values,
the
acceptable
values
for
a
flag
which
accepts
in
a
new
right
like
autocomplete,
whatever
the
numeration
of
that
flag
is
right
and
that
one
is
like
technically
statically
known.
A
So
it's
not
like
quite
as
hard
as
the
crd
case,
but
it's
probably
not
expressed
in
the
cobra
like
flag
right.
The
flag
itself
may
not
express
what
the
numeration
values
are.
So
it's
going
to
have
to
be
hard-coded
versus
like
the
command
names
and
the
flag
names
you
can
actually
just
look
at
the
cobra
structure
itself
and
you'd
like
cobra,
should
be
able
to
figure
it
out
for
you.
D
Well,
so
it
sounds
like
the
next
the
the
going
forward
for
this
would
be,
let's,
let's
try
to
use
what's
in
cobra
1.0.
D
D
Okay,
oh
yeah
yeah
don't
break
their
bash
rc.
I
guess
don't
don't
break
the
current
functionality
in
completions,
but
you're
right,
that's
another
one
too!
Don't
don't
don't
cause
them
to
have
to
do
do
something
manual
in
that,
because
if
they
use
multiple
versions
of
kubecuttle
too,
maybe
not
a
lot
of
people
do
that,
but
it
yeah.
Definitely,
if
you're
going
from
the
older
version
to
a
newer
version
and
have
to
worry
about
whether
you're
rc
is
set
up
right.
That
would
be
weird.
C
A
One
brian
one
thing
from
the
sourcing
approach
you
showed
and
this
may
work
and
it
may
not
like
I
can't
tell
from
what
it
generates
but
like
when
you
switch
clusters,
for
instance,
it's
like,
hopefully
the
it
gets
the
completions
for
whatever
cluster.
It's
talking
to
right
like
that,
going
back
to
the
crd
thing
so
like
I
don't
think
this
is
urgent
but
like
when,
as
we
just
look
and
we're
evaluating
just
for
like
our
own
context,
it's
it's
probably
worth
just
doing
a
check
to
see
like
does
this,
like?
A
Does
that
sourcing
shell
out
enough
dynamic
stuff
to
the
command
to
the
control
command
itself
such
that
it
will
get
the
crds
like
when
the
it
will
wreak
like?
Does
it
does
it
find
the
list
of
crds
like
when
you
source
it
and
then
so?
D
A
Well,
it's
not
critical,
but
someone
it
would
allow
us
to
preemptively
file
a
you
know
faq,
rather
than
than
waiting
until
someone
files,
an
issue.
If
it's
known.
E
So
this
is
a
interesting
point
by
the
way,
so
I
see
that
some
in
some
cases
we
want,
for
example,
discovery
to
be
cached
but
cleared
between
switching
contexts,
but
in
some
cases
when
we
after
completing
boards,
we
probably
want
to
do
this
for
the
completion
dynamically
every
time
or
not.
What.
A
Do
you
think
my
guess
is
like
if
we
might
be
able
to
get
this
from
the
open
api,
for
instance,
because
the
open
api
like
if
the
open
api
exists
for
crds?
And
if
that
information
was
part
of
the
open
api,
I'm
not
sure
that
it
is,
but
we
can
put
it
in
there.
For
instance,
the
open
api
is
cached,
so
it's
the
discovery
service
so
like.
Ideally,
we
would
just
get
it
from
an
existing
cached
piece
of
metadata
that
could
control
fetches
anyway,
when
it's
going
to
run
git
or
some
other
command.
A
B
A
Is
like
basically
a
lot
of
work
for
a
porcelain,
auto
completion,
so
I'm
guessing
that
none
of
us
here
on
this
call
would
prioritize
it
unless
we
felt
really
strongly
about
it,
but
we
could
at
least
create
the
issue
so
that
someone
from
the
community
could
pick
it
up
if
it
was
important
to
them.
C
D
A
Yeah-
and
I
think
what
we
landed
on
is:
let's
just
go
with
the
cobra
piece:
it's
going
to
absolutely
be
an
improvement,
and
it's
not
going
to
be
like
you
know,
quarters
of
work,
we'll
probably
learn
something
like
if
it's
not
ideal
and
we
want
to
change
it.
A
C
D
A
So
I
think
the
answer
is
the
direction
we'd
give
knight
42
is
to
try
and
follow
the
approach.
Helm
took,
use
the
cobra
1.0
supported
completion
you're.
Probably
that
means
you're
going
to
end
up
deleting
a
ton
of
code
and
custom
completion,
and
that's
intentional.
A
C
This
isn't
another
one
that
came
up
in
the
bug:
scrub,
it's
a
feature
request,
that's
been
opened
since
december
2018
and
we
added
the
agenda.
I
believe,
to
get
discussion
out.
Then,
if
it's
something
we
wanted
to
have
sounds
like
ben
the
elder
wants
it
because
he
froze
the
issue.
C
He
froze
the
issue
on
june
25th.
Okay,
does
anyone
have
any
feelings
or
thoughts
on
adding
a
cubeconfig
dot
directory?
C
So
I
get
context
for
for
in
unix
philosophy.
If
you
have
a
config.d
folder
whatever
is
you
know
the
the
program
it
will
source
everything
in
that
config.d
folder,
including
overrides.
I
think
it
prioritizes
overrides
right,
but
someone
is
asking
for
that
inside
cubecontrol.
A
C
B
So
when,
when
brian
grant
replied
on
this
issue,
he
pointed
out
there
was
five
or
six
different
previous
issues
and
there's
a
lot
of
history,
so
it
may
not
be
as
as
simple
as
as
just
a
brand
new.
It
has
other
consequences,
and
especially
since
there's
going
to
be
a
lot
of
other
libraries
client
go
that
rely
on
a
particular
parsing
of
coup
config.
A
C
Client
go:
can
it
has
the
different
loading
methods
right?
It's
been
a
while,
since
I
looked
at
that
code,
but
it
will
load,
it
has
an
abstraction
for
the
config
and
it
will
load
it
from
an
environment.
Variable
it'll
load
it
from,
and
this
is
pretty
closely
tied
honestly
to
the
base64
one
that
we
talked
about.
C
B
B
Maybe
it's
in
the
resource
builder,
but
there's
a
the
factory
that
we
use.
It's
actually
the
steel.
I
run
time.
I
think
staging
cli
run
time
where
the
factory
does
the
config
parsing
stuff.
A
A
If
they
happen
to
be
hooking
in
at
the
right
library,
but
would
really
just
pcli's,
then
the
like
the
alternative
suggestion
right
is
like
well
now
we're
fragmenting
the
way
that
you
can
specify.
Often
right
and
so
then
I
run
coup
builder
right
in
cube,
control
get
works,
but
could
builder,
you
know,
doesn't
work
right,
and
why
is
that?
And
now
I'm
confused
and
file
an
issue?
A
I
think
I
I'd
be
more
in
line
with
the
former
which
is
just
make
like
this
is
just
for
coop
control
and
maybe
like
other
cli,
that
want
the
same
behavior
like
just
providing
it
for
that
context
seems
like
a
better
trade-off
than
impacting
a
bunch
of
other
components
that
you
know.
This
may
not
be
a
great
thing
for.
B
It's
it's
one
or
multiple,
there's
code
in
that
same
place
under
the
cli
runtime
and
that
factory,
if
I
remember
correctly,
all
of
that
merging
and
the
the
different
priorities
of
you
know:
config
and
the
environment
variable
and
emerging
different
versions
or
different
ones,
different
config
files,
all
that
happens
in
one
place
and
the
cla
runtime
footer.
A
If
we
were
to
do
this,
we
could
do
it
as
an
alpha
feature
right,
and
so
we
could
fly
guard
it,
and
then
we
could
enable
it
and
saying,
like
you
know,
enable
config,
like
coupe
config
d
as
a
flag,
and
then
that
would
allow
like
folks
who
have
control
over
their
system
to
take
advantage
of
it
right
and
it
would
mean
like
integrations
like
spinnaker
and
like
if
helm
and
like
all
the
other
systems,
that
shell
out
to
it
or
use
these
libraries,
either
through
exacting
code
control
or
through
go
modules,
would
not
be
impacted,
which
is,
I
think,
is
what
we'd
want
right
when
we
roll
it
out,
it
would
be
opt
in,
and
then
we
could
evaluate
at
that
point
in
time.
A
You
know
make
it
the
default
behavior
or
just
leave
it
as
it
is
or
decide
that
you
know
it's
there's
bugs
like.
We
could
discover
that
like
actually
merging
these
things
is
difficult,
because
the
merge
keys
for
the
for
the
entries
in
the
coop
config
are
ambiguous
and
having
multiple
files
has
led
to
you
know
having
cluster
and
context,
mismatches
and
weird
ways
that
okay
cause.
A
Only
the
binaries
that
we
control
and
not
like
inadvertently
impact
other
other
components
right,
and
so
those
two
might
not
actually
be
aligned.
So
I
I
don't
know
the
answer
to
your
your
question.
I
guess
is
my
response.
F
Eddie,
can
I
ask
a
question:
why
is
I
couldn't
understand
the
need
for
the
basics
of
support
when,
let's
say
there
is
a
command
to
actually
pipe
it
directly
into
in
as
a
file
using
the
normal
environment?
Variable.
F
Can't
I
let
me
let
me
type
in
chat,
can't
I
do
this
and
I
just
basically
set
an
environment
variable
called
cubeconfig
and
then
I'm
missing
a
smaller
than
sign
there
before
the
parentheses,
but
I
can
just
dump
the
environment
variable
and
decode
it.
I
don't
think
we
should
probably
try
to
reinvent
this
if
this
is
already
there
right.
C
F
So
if
I,
if
you
sort
of,
let
me
replace
the
correct
one,
so
if
you
do
this,
you're
gonna
get
something
like
this.
You're
gonna
get
a
file
descriptor
and
in
that
case
that's
a
file.
E
A
I
guess
I
I
that's
actually
really
awesome.
You
know
if
I
was
to
think.
Where
might
not
this
work
like
if
you're
on
spinnaker
and
spinnaker
had
a
forum
and
they're
like
here's
an
environment
variable
then
like
would
spinnaker
allow
you
to
express
it
in
this
way
where
you
write
it
to
right,
where
it
gives
you
a
file
descriptor.
F
Well,
if
I'm
the
person,
configuring,
the
ci
cd
environment,
I
will
probably
set
it
this
way
and
as
spinnaker
developers,
if
they
support
queries
natively,
they
can
support
it.
This
way,
too,
the
problem
here
actually
would
be
re-reading
the
file
which
is
not
possible
because
it's
a
pipe-
and
you
can
only
read
it
once
and
you
cannot
write
into
it
and
we
tend
to
sometimes
write
back
into
the
cube
config
file
and
those
will
be
the
problems
that
I
can
see
happening.
F
I
would
say
this
is
like
a
definitely
a
more
exotic
use
case,
because
you
can
always
like
get
the
environment
variable
from
the
user,
dump
it
into
a
temporary
file
and
then
point
to
it
too
right
I
mean
I'm
actually
going
to
come
back
to
the
other
point
that
I
would
like
to
provide
my
opinion
about
the
cube
config
d
right
now
far
too
many
binaries
have
this
already
pre-compiled
into
them.
Like
the
cube
config
resolution,
steps
are
pretty
hard
coded,
so
now
imagine
I'm
coming
to
cubecontrol
it.
F
It
recognizes
the
config
d
and
then
I
go
to
another
program
which
I
know
used
to
work
with
control.
Just
fine
so
now
that
let's
say
I
run
a
disc
destructive
action
there
and
without
knowing
that
that
thing
does
not
support
config
d,
so
I
accidentally
target
the
wrong
cluster
right,
like
cube
control,
plugins
alone
probably
have
at
least
50
60
of
them
at
this
point
have
that
you
know
pre
existing
resolution
mechanism
already
hard
coded
into
them,
like
it's
built
into
the
binary,
so
it'll
be
like
a
little
franken
feature.
A
A
Would
we
fail
or
are
we
more
likely
to
fail,
or
are
we
like
more
likely
to
like
just
silently
use
the
existing
context
or
something
like
that
right
so,
like?
I
think,
that's
a
really
good
point
right
like
if
we
were
to
merge
the
default
context
like
you,
you
wouldn't
want
to
like
change
the
default
context
in
merging
right
because
exactly
like
you
say
that,
would
that
that
would
not.
A
That
would
result
in
maybe
a
non-failure
case
where,
where
it
would
just
continue
to
work
after
you
merged,
but
in
the
wrong
context
versus
if
you,
if
you
didn't
merge
like
the
default
context,
but
maybe
you
just
added
like
you
see
you
can
imagine
like
if
you
don't
do
overwrites,
but
you
add
additional
context,
then
the
end
result
would
simply
be
that,
like
the
the
plug-in
would
not
have
certain
like
context
in
its
coupe
like
in
its
configure,
thought
and
then
you'd
get
like
a
failure
right
and
then
I
guess
that's
another
reason
where,
like
the
flag
right
so
like,
if
the,
if
you
have
to
enable
this
with
a
flag,
then
like,
if
the
plug-in
is,
you
know
only
accepting
flags
that
are
valid,
then
it
would
fail,
for
instance
right
so.
A
That's
true,
I
think
I
think
there's
like
that,
but
that's
an
excellent
point
about
like
looking
at
the
like.
How
can
a
user
delete
all
their
production
workloads
by
accident
right
or
something
like
that?
Like
that's,
always
the
fun
one
to
explore,
and-
and
there
is
a
path
there,
where
that's
possible.
E
E
A
Or
maybe
then,
the
answer
is
this
could
never
be
the
default
until
we
did
like
two
control
2.0
and
like
just
wipe
the
slate
clean
or
something
like
that
yeah,
and
it
goes
back
to
like
the
motivation
right
for,
like
the
actual
consumers
that
really
want
this
thing.
Right
is
this
because
they
have
their
own
bespoke
system
right
and
they
control
crew
control
and
they
control
that
flag
and
they're
writing
out
these
cube
configs
or
is
it
because
is
it
they
just
want
this
in
spinnaker?
A
Maybe
an
alternative
right,
too,
is
that
we
could
simulate
this
right
in
a
second.
A
We
could
actually
create
a
second
command
when
I
think
about
it,
right
that
like
took
a
coup,
config.d
directory
and
then
merged
all
that
into
a
config
file,
doing
the
overrides
right
so
like
if
it's
like,
hey
what
you
the
experience
you
want
as
an
end
user,
is
to
be
able
to
write
these
things
out
to
a
config.d
directory,
we'd,
say:
okay,
you
can
write
them
out
to
config.d
directory,
but
before
you
after
you
write
them
out,
you
need
to
run
this
command,
which
will
then
like
merge
them
into
the
config
file.
C
C
A
Like?
Does
this
address
the
issue
for
you
and
then
we
can
like
explain
all
the
challenges
with
this?
Doesn't
it's
not
going
to
work
for
plugins?
It's
the
failure
case
for
plugins
is
suspect.
F
Funny
enough,
I
think
we
can
actually
make
the
plugins
work
much
better
than
out
of
three
binaries,
because
we
call
the
plugins.
So
we
can
detect,
there's
a
complete
directory
and
then
we
can
merge
it
into
a
again
like
any
either
an
in-memory
pipe
or
a
temporary
fight,
a
temporary
file.
And
then
we
can,
I
mean
we
can
basically
hack
up
a
new
config
environment.
Variable
that
you
know
is
column
separated,
and
then
we
can
pass
that
to
the
plug-in.
F
I
mean
we
can
still
resp
respect
to
the
user's
preference,
but
it
seems
that
for
plugins
at
least
we
can
hack
this
much
better
than
other.
You
know:
out-of-band
binaries,
yeah,.
A
C
C
C
A
B
Okay,
so
recently
some
senior
members.
B
This
came
up
and
they
asked
for
60
line
input
and
they
included
me,
and
I
wanted
to
bring
it
to
the
community
and
it's
basically,
there
were
some
instances
where
control
of
apply
was
happening
during
a
the
deletion
of
the
same
resource
and,
and
so
the
so
antoine
was
also
brought
into
this,
and
there's
actually
a
pretty
straightforward
way
to
address
this
to.
If
we
and
everybody
who's
been
involved
in
it.
So
far
assumes
that
this
is
something
that
we,
if
we
can
stop
it,
we
should
stop
it.
B
At
least
the
default
should
be
that
you
shouldn't
try
to
apply
something.
That's
in
the
process
of
being
deleted
and
daniel
suggested
that
if
you
null
out
the
deletion
timestamp
in
the
apply
that
when
you
apply
because
of
the
immutability
of
that
timestamp,
the
api
server
would
reject
and
return
an
error.
B
The
deletion
by
nulling
out
the
deletion
timestamp
before
applying
does
that
scenario
make
sense.
A
B
Yeah,
so
we
wouldn't,
we
wouldn't
be
putting
it
in
the
I'm
guessing
the
implementation.
Is
it
wouldn't
be
putting
it
in
the
last
applied
annotation?
It
would
be,
it
would
happen
like
directly
before
sending,
and
so
it
wouldn't
be
encoded
in
the
last
applied
annotation.
B
My
answer
was
for
the
client
side-
server
side-
I
haven't
actually
thought
about
it,
but
I'm
imagining
you
don't
want
to
claim
ownership
over
it.
B
B
A
B
B
B
Yeah
and
then
it
would
it
wouldn't,
and
I
don't
know
exactly
how
this
mechanism
would
work.
They
would
understand
the
error
code.
That
says
you
know
that
the
deletion
times
that
field
was
immutable
and
you
tried
to
change
it
and
would
give
a
error
message
to
the
user,
saying
you're
trying
to
delete
you're
trying
to
apply
a
resource.
That's
already
been
deleted.
A
A
B
Yeah
I'll
have,
let
me
put
that
down
as
something
to
try.
A
A
And
then
I
guess
my
other
question
is
like
if
this,
depending
on
how
we're
talking
about
implementing
this,
like
we're,
talking
about
server
side,
apply
right
and
you
know,
controllers
calling
server
side
apply
and
like
the
notion
that,
like
you,
don't
have
to
do
it
from
the
go
code
in
order
to
update
it.
But
if
we're
putting
on
the
client
side,
this
you
know
functionality.
It
seems
like
we're
creeping
back
into
the
world
where
it's
like.
A
A
Like
other
clients
can
set
this
field
too
right,
it's
it's
not
like
the
end
of
the
world,
but
as
this
grows,
there's
going
to
be
a
dock
right
that
says,
like
here's,
the
fields
you
need
to
set
or
something
like
that.
B
Okay,
yeah:
I
could
bring
these
issues
I'll
try
to
incorporate
these
concerns
back
into
the
the
issue,
to
make
sure
that
you
know
they're
more
widely
disseminated.
I
think
that
we
should
you
know.
Hopefully
we
will
come
to
a
thumbs
up
or
thumbs
down
on
whether
or
not
we
improve
this.
B
A
B
C
B
Doesn't
really
know
the
kubernetes
system,
this
is
tim,
hawkins
and
daniel
smith
and
antoine
so
so
I
don't
think
it's
something
we
can
dismiss
his
peripheral.
I
think
it's.
E
B
And
I
think,
as
I
said,
I
think
if
there's
already
efforts
underway
and
so
yeah,
I
think
that
relatively
soon
we'll
have
to.
B
There
was
an
email
thread
and
you
know
I
should
have
I
I
yeah.
I
thought
that
a
lot
of
that
stuff
was
only
going
to
be
on
the
issue
when
antoine
created.
It.
B
B
Judging
by
the
questions
I
haven't
really
presented
this
as
well
as
I
should
have
been
to
the
community.
Apologies
I'll,
try
to
individually
get
back
to
you
phil
on
more
context.
A
Yeah
no
problem,
I
mean,
I
think
this
is
like
from
a
high
level.
This
seems
right,
but
I
it
seems
like
there's
a
lot
of
edge
cases
that
are
just
not
explored,
at
least
in
the
description
of
the
issue,
and
it
would
be
great
to
capture
those
like,
for
instance.
If
I
want
to
delete
and
recreate
a
do,
you
delete
and
recreate
a
thing
like.
What
is
that
workflow
look
like
and
what's
gonna
happen
and
I'm
guessing
like
what
happens
right?
Is
you
delete
it?
A
A
I
seen
it
seems
like
the
behavior
we
want
like.
Does
that
what
happens
if
you're,
applying
like
five
resources-
and
you
know
the
one
in
the
middle
has
this,
do
we
want
to
like?
Do
we
want
to
fail
up
front
or
try
and
detect
this
if
we
can
up
front
or
is
it
fine
to
delete
in
the
middle?
A
I'm
not
sure
that,
like
the
way
we
the
way
we
fail
on
other
things,
is
we
just
kind
of
fail
in
the
middle?
Unfortunately,
so
that
seems
fine
for
now
and
we
can
differ
saying
like
let's
try
and
drive
on
everything
first
liked
it
later
or
something
like
that
like
we
should
I'd
like
to.
You
know
clearly
call
out
that,
like
deletion,
timestamp
will
not
be
part
of
the
last
applied
annotation
and
will
not
be
part
of
the
field
owners.
A
I
like
to
call
out
that
this,
like
how
is
this
going
to
impact
like
controllers
written
with
controller
runtime?
Will
that
be
built
into
those
libraries
as
well?
Is
it
being
done
at
a
layer
where,
like
is
it
be
dying
being
done
in
a
low
level
layer
like
client
go
where
it
just
automatically
will
get
applied
to
everything
you
call
when
you
call
pliers
is
only
impacting
could
control
apply.
B
I
think
that
this
is
only
good,
but
at
least
that
was
the.
Let
me
rephrase
that
the
to
suggest
what
daniel
was
suggesting
was
just
crude
control.
A
A
A
The
like
just
just
some
of
these
cases
for
for
my
own
context,
like
it
would
be
ideal
if
we
could
have
like,
I
think,
actually
like
a
document,
maybe
in
the
six
cli,
where
we
can
point
people
to
like
fact
about
apply,
or
so
you
want
to
do
apply,
because
I
think
this
will
impact
server
side
apply
like
I
was
saying
like.
If
someone
wants
to
use
server
side
apply
and
now
they
need
to
set
this
field
right
dude.
B
A
Right
that
would
be
helpful,
maybe
in
the
existing
apply
document
as
well.
Maybe
the
server
side
apply
document
should
be
updated
with
that
or
whatever
it
is,
but
great
good
fix.
It's
really
nice
to
be
tackling
this
edge
case,
and
it's
great
that
there's
a
solution
that
can,
you
know,
seems
relatively
conservative
in
its
risk.
B
Profile,
okay,
it
looks
like
I
have
some
ais
here
and
looks
like
we're
also
over
time.
Sorry
about
that,
I
guess.
A
B
A
A
It
looks
like
it's
enabled
by
a
flag
by
default,
so
that's
actually
very
conservative
right.
There
should
be
no
impact
to
existing
users,
but
we
probably
want
to
get
this
out
of
the
flag
as
soon
as
possible.
If
it's,
you
know
addressing
a
real
use
case
so
that
all
the
systems
that
shell
out
to
control
are
getting
the
most
correct
behavior
that
we
can
provide
them
by
default.
B
Well
I'll
try
to
circle
back
with
you
phil,
since
you
had
a
lot
of
good
feedback
on
this.
A
Right
on
all
right,
I
think
we're
over
time,
but
is
there
oh
there's
stand-ups
crew
cui?
Do
you
want
to
do?
Do
you
guys
still
want
to
do
the
stand-ups
I'm
happy
to
stick
around
for
a
bit
if
or
if
you
all
would
like
to
do
those
anyway.
A
A
Believe
excellent,
all
right!
Well,
thank
you.
Everyone
for
attending
and
look
forward
to
seeing
you
all
in
two
weeks
or
so
thanks
also.