►
From YouTube: Kubernetes SIG CLI 20211215
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
afternoon,
depending
on
where
you
are
today
is
december
15th-
and
this
is
another
of
our
bi-weekly
six
cli
calls.
My
name
is
matie
and
I'll
be
your
host
today
and
as
it
turns
out,
that
is
actually
the
last
goal
that
I'm
leading
as
a
chair
for
six
cli
as
it
was
discussed
in
october.
A
If
I
remember
correctly,
I
should
probably
have
checked
that
before
the
call
I
will
be
stepping
down
as
a
signature
with
the
end
of
this
year,
worry
not
I'll
still
be
around.
I'm
still
leaving
my
technical
lead
hat
on
so
I'll,
be
more
on
the
side
of
technical
arrangements,
discussions
thoughts
rather
than
the
organizational
side
of
things
we
have
amazing,
eddie
katrina
shawn
in
the
charge
of
the
six,
I'm
very
happy
that
that
they
are
running
the
sick,
actually
eddie.
A
I
will
be
helping
with
the
annual
report
and,
let's
not
forget,
I'm
still
running
another
six
sig
gaps
which
also
be
doing
the
annual
report,
so
I'll
be
there
for.
For
this
one,
still
from
the
announcement
side,
kubernetes
123
was
released
last
week,
which
means
that
the
code
freeze
was
lifted
so
feel
free
to
ship,
whatever
you
want
to
do
for
124,
which
is
also
related
with
the
first
of
the
topics
for
today's
discussion.
A
A
A
Free
hand
session
and
at
the
same
time,
an
important
thing
we
will
be
giving
away
contributor
awards
so
feel
free
to
tune
in
for
a
contributor
celebration.
This
friday,
one
last
announcement
kubecon
europe,
cfp
proposal
is
also
due
this
friday
midnight
and
I
think
that
midnight
is
pst,
although
I
might
be
wrong,
but
you
can
check
it
out
under
the
link,
if
I
remember
probably
sean
put
it
there
as
well,
so
the
sean
katrina
did.
I
miss
any
other
announcements.
B
No,
the
one
thing
we
can
bring
up
is
paris.
Pittman
who's
on
steering
has
been
pretty
adamant
about
getting
funding
for
things
from
the
cncf
to
help
the
project.
So
if
anyone
has
any
wild
and
crazy
ideas,
what
we
could
do
with
hiring
people
or
money
feel
free
to
share
those,
because
paris
wants
us
to
think
wild.
So
I
proposed
a
person
funded
by
the
cncf
dedicated
to
onboarding
new
contributors
and
see
how
that
goes.
A
We
should
definitely
put
that
thing
in
the
annual
reports.
We
can
go
crazy
and
usually
we
put
those
kind
of
information.
What
we
would
want
to
achieve
annual
report
seems
like
the
best
to
express
those,
so
I'm
hoping
that,
sometime
in
january,
we
will
be
reaching
out
to
you
and
we'll
do
either
some
kind
of
a
annual
report,
preview
review
with
possibilities
for
everyone
to
add
additional
inputs
for
the
report,
but
we'll
make
sure
that
this
will
be
announced
properly
upfront,
but
that
will
be
sometime
next
year.
A
There
will
be
some
other
interesting
things
happening
next
year,
but
we
just
need
to
crystallize
them
a
little
bit
more,
so
not
to
give
you
give
away
too
much
of
the
stuff.
Yet
do
we
have
any
new
folks
on
the
call
I'm
quickly
scrolling
through
the
list,
and
I
think
I
I've
seen
all
the
names,
but
I
might
be
wrong
if
you're
new
to
the
call
or
you
weren't
here
for
a
while
feel
free
to
pick
up
the
mic
and
introduce
yourself.
A
A
With
the
recent
discussion,
we
are
hoping
that,
with
the
help
from
sig
release,
we
will
push
forward
the
release
bill.
Slash
build
pipeline
such
that
it
will
be
possible
to
build
cube
cattle
out
of
the
separate
repo.
Is
that
correct,
eddie.
B
That's
the
plan
where
so
we're
working
with
nabaroon
on
the
cap.
I
think
mata
is
working
on
it
too.
So
yeah,
that's
the
goal.
A
A
Sean
put
together
that
he's
planning
to
work
on
making
server
side
apply
the
default
correct.
So
it's
the
server-side.
C
Apply
is
ga
and
has
been
ga.
The
biggest
hurdle
is
actually
migration
right.
So
if
there's
resources
that
have
been
applied
with
client
side
apply,
they
have
the
last
applied
annotation,
which
is
obviously
different
than
the
field
management
metadata
for
server
side
apply.
The
big
question
is:
how
do
we,
you
know?
How
do
we
migrate
this?
We
we
so
antoine.
Actually
so
I
put
this
on
for
antoine.
C
Antoine
has
started
vacation
and
I'll
be
working
on
this
as
well,
but
basically
we,
you
know,
we
need
a
plan
in
order
to
be
able
to
migrate,
and
we
we
kind
of
want
that
to
be
the
default
since
server
side
apply.
We
we
recognize
is
the
better
implementation.
C
This
would
be
the
kind
of
the
last
piece,
so
we've
been
working
or
not.
We
mostly
the
folks
in
api
machinery
and
antoine
have
been
working
on
server
side
apply
for
three
plus
years,
and
so
this
would
be
the
last
part
of
it
to
make
this
the
default
in
coupe
control.
A
I'll
play
the
devil
advocate,
are
we
applying
planning
to
get
rid
of
the
client
side
apply.
C
So
that
would
be
a
further.
You
know,
effort
to
deprecate
client-side
apply,
but
it
would
I
I.
I
know
that
the
first
step
would
be
just
to
make
the
server
side
apply
the
default
and
there
would
be
a
client-side
flag
instead
of
the
server-side
flag.
We
have
now
so
you,
so
I
think
that
we
should
eventually
deprecate
it,
but
I
I
don't
see
that
happening
honestly
for
years.
I
think
that
it's
going
to
just
be
changing,
which
flag
is
the
default
and
which
one
you
have
to
actually
manually
specify
on
the
command
line.
C
Okay-
and
we
have
some-
we
have
a
couple
of
the
experts
from
the
server
side
apply
here
as
well.
I
think
jared
and
cece
are
from
that
team
and,
and
so
I'll
just
ask
them
is,
did
does
what
I
just
said:
does
that
all
sound,
reasonable
cece
jared
kevin
yeah.
E
Okay,
all
right,
please
all
right,
so
one
thing
I'm
working
on
is
like
so
for
now,
clients
and
client
side
actually
have
a
limitation
on
object
size.
So
if,
if
a
cr
custom
resource
is
getting
too
large,
it
will
just
get
rejected,
but
now
for
service,
I
applied
there's
no
such
a
limitation
anymore.
E
C
Okay,
so
this
sounds
like
there's
one
more
hurdle
beyond
just
the
migration
thanks
thanks
jared.
D
Yeah,
I
think
I
guess
I'm
going
to
talk
about
it
later,
I'm
not
sure
if
it's
a
blogger
for
making
server-side
applied
default
or
not,
but
there
is
some
inconsistent
behavior
between
all
service
that
apply
and
the
client
side
apply,
and
we
can
talk
about
it
later.
If
you
want.
A
F
Yeah,
I
was
just
wondering
if
the
plan
for
the
changes
to
the
flags
such
that
we're
making
sure
that
people
are
making
the
transition
deliberately
or
it's
completely
set
safe
one
way
or
another.
If
that
plan
is
part
of
the
cap
already
or
if
that's
something
we're
adding
to
the
cap
as
part
of
this
work,
we'll
add
it
to
the
cab
cool.
I'm
curious
about
the
details.
A
Okay,
moving
on
to
the
next
one,
kevin
moving
open
api
validation
from
v2
to
v3.
G
Yeah,
so
I
came
out
here
probably
two
months
ago
to
discuss
that
server
side
validation
was
coming
to
alpha
in
123
and
it
landed
in
there,
and
you
know
I
discussed
kind
of
the
the
pros
of
server-side
validation
versus
client-side,
and
this
is
for,
for
example,
the
dash
dash
validate
flag
that
we
have
in
coop
control
and
some
of
the
limitations
that
we
have
client
side.
G
And
so
I
think
the
kind
of
feedback
that
I
got
was
we're
mostly
on
board,
with
defaulting
coupe
control
to
using
server
side
and
the
link
that
I've
provided
kind
of
gives
a
gives
the
details
of
the
of
the
syntax
of
how
the
validate
flag
is
going
to
work.
So
I
can
still
pass
it
validate
true,
validate
false,
but
it'll.
Warn
you
hey
we're
moving
to
server
side.
That
sort
of
thing.
The
big
controversial
piece,
though,
that
that
I
think
got
some
pushback
on
was
that
it
there's
we
want.
G
We
don't
want
to
validate
or
we
don't
want
to
deprecate,
client-side
validation
and
the
main
reasoning
there
was
that
there's
a
lot
of
use
for
when
you
know
we
have
the
open
api,
but
we
don't
have
access
to
the
api
server
and
just
giving
people
some
sort
of
way
to
know
you
know.
Are
they?
Are
they
misspelling
any
of
their
fields
before
having
hit?
G
The
server
did,
have
a
lot
of
value
and
isn't
something
that
we
can
just
deprecate
and
so
the
I
think,
the
the
question
that
that
so
we
went
back
to
the
drawing
board
and
kind
of
discussed.
Okay.
We
have
this
strong
desire
to
get
rid
of
open
api
v2.
We
don't
want
the
client
to
download
that
anymore,
it's
prone
with
a
ton
of
errors.
You
know
it
it
it
doesn't
it
doesn't.
Let
us
validate
crds,
they
use
schema,
features
that
prevent
us
from
publishing
the
open
api.
V2
there's.
G
You
know
no,
no
sense
of
of
the
validating
mutating
webhook,
so
there's
a
slew
of
issues
with
the
open
api,
v2
validation.
But
how
do
we
do
client-side
validation
going
forward
and
the
kind
of
proposal
that
we
landed
on
is
is
if
we
can
do
client-side
validation,
client-side,
open
api,
v3
validation
via
some
a
tool
like
cube
val?
Do
we
all
agree
that
we
can
deprecate
client-side,
validation
from
cube
control,
and
you
know
we
could
use
kubevale
as
a
plug-in
and
coop
control
or
something?
G
But
you
know-
and
you
know,
assuming-
that
we
can
present
a
a
valid
client-side
solution
to
validating
your
your
your
objects.
Does
that
then
free
us
to
deprecate
client-side
validation?
So
that's
kind
of
the
question
that
I'm
posing
in
the
discussion.
I
wanted
to
start.
A
A
A
A
Yeah,
so
that's
that's
also
something
that
you
will
not
be
able
to
replicate
on
the
client
side.
So
you
always
have
to.
You
will
always
have
a
difference
between
the
client
side
and
the
server
side,
because,
if
there's
a
logic
that
is
existing
on
the
server,
we
can't
replicate
that
through
open
api
definition.
C
So,
just
as
a
point,
an
item
there's
always
going
to
be
server
side,
validation
that
can't
be
done
on
the
client
side,
like
you
know,
for
instance,
if
there's
a
validating
web
hook.
So
so
that's
that
that
doesn't
really
yeah
I
mean
we're.
Always
gonna
have
stronger
validation
on
the
server
side,
no
matter
what.
G
Yeah
and
to
answer
your
first
question
about
default
to
ignoring
or
default
to
having
field
validation
off,
what
we
are
proposing
in
the
kep
is
having
field
validation,
be
warning
by
default.
So
we
have
this
option
now,
with
the
with
the
server
side:
validation,
where
we
can
do
the
validation
server
side,
we
can
pass
the
request
and
drop.
The
unknown
fields
like
you
would
with
validate
equals
false,
but
we'll
still
return
in
in
the
warning,
headers
all
the
fields
that
are
unknown
or
misspelled.
G
A
Cool
looking
forward
to
it,
the
next
one
is
eddie
and
mo
cube.
Rc.
B
Yeah,
this
was
just
kind
of
committing
to
it,
so
I
talked
to
mo
this
morning
and
mo
really
wants
to
push
this
for
124.
So
we
are
going
to
draft
up
an
initial
cap
and
get
some
rfc
feedback.
So
this
is
for
those
unaware.
This
is
separating
user
preferences
and
configuration
from
cube
configs.
A
Are
we
thinking
about
also,
including
as
part
of
the
cube
rc
file
preferences
for
plugins?
Was
this
that's
part
of
your
design.
B
B
This
was
the
kept
that
katrina
and
I
were
working
on
it
kind
of
stalled
out
after
a
few
different
ideas
and
iterations
I'd
like
to
pick
this
back
up
and
I'd
like
to
spin
up
that
mailing
list
right
again.
I
think
last
time
you
and
I
spoke
mache-
I
was
gonna-
do
a
proof
of
concept.
With
an
admission
controller,
we
can
see
what
we're
doing
there.
B
This
will
play
nicely
with
the
q
bar
c,
because
we
can
opt
in
using
that
by
default
right.
So
I
think
this
will
go
pretty
hand
in
hand,
the
flags
and
all
the
defaults
and
stuff
we
still
have
to
kind
of
sort
out,
but
if
this
lands
alongside
q
bar
c,
then
that
makes
it
a
great
nice
feature
to
like
show
off
q
bar
c
in
the
beginning,
so
yeah.
A
Okay,
the
next
one
exit
codes.
I
remember
that
ricardo
and
ross
were
pushing
the
proposal
forward.
I
would
really
want
to
see
this
one
getting
some
some
more
traction,
so
at
least
that
we
can
get
the
proposal
out
the
door
and
then
we
can
continue,
because
that's
definitely
something
that
will
take
some
time.
B
Yeah
cool
all
right
before
you
jump
over
this.
I
put
this
on
here,
not
assuming
you'd,
be
here.
So
I'm
glad
that
you're
here.
So
we
can
discuss
what
you
and
I
talked
about.
H
Yeah
yeah
yeah,
it
was
like
mostly
I
got
some
some
free
time
in
my
agenda
right
now,
so
I
I
have
started
passing
some
some
information
to
ross,
but
I
didn't
hurt
back
anymore.
H
Unfortunately,
so
I
will
I've
been
mostly
doing
ingress
stuff,
so
I'm
I'm
really
busy
with
those
ingredients
stuff,
but
I
am
planning
maybe
to
take
a
look
into
that
bag
during
the
hot
days
like
vmware
shutdown
last
week,
but
I
would
really
love
if
someone
wants
to
help
me
with
that,
because
I
have
too
much
stuff
on
my
plate
with
those
all
of
those
ingress
cvs
that
you've
been
watching,
and
so
people
discovered
that
now
we
have
cvs
in
ingress
and
I
have
every
week
I
have
one
email
from
cj
asking
me
to
pick
something.
A
A
H
You
left,
I
think
you
left
some
comments.
I
just
didn't
got
some
time
also
to
to
read
those,
but
I
will-
and
I
will
also
keep
bothering
people
inside
vmware
like
hey.
I
need
someone
to
help
me
on
this.
B
The
other
thing
I
was
gonna
pitch
was:
we
can
always
send
a
note
to
the
mailing
list
and
put
out
a
call
to
the
community
that
this
cap
needs
someone
to
kind
of
take
up
the
reins
and
push
it
forward.
So,
if
that's
something
you
want
to
do,
we
can
move
forward
with
that
too.
Ricardo.
H
B
That's
totally
understandable,
my
friend,
it's
more
like
you
paved
the
way,
and
you
kind
of
put
the
initial
thing
in
place,
and
now
someone
else
can
pick
it
up
and
push
it
over,
so
yeah,
no,
no
ill
will
against
you
at
all
totally
understand.
A
And
the
last
topic
I
put
it
here-
sean,
but
I
remember
you
were
working
on
this
before,
which
is
the
keep
cuddle
metric
being
sent
over
through
headers.
C
So
it's
it's
in
beta
it's
in
default!
Now
it's
they're
being
sent
the
next
steps
actually
have
to
do
with
the
api
server
in
order
to
make
sure
number
one
that
they're
being
surfaced
in
the
logs
and
two
excuse
me.
C
I
also
heard
I
think
from
daniel
that
he
wanted
to
send
them
over
to
the
validating
and
mutating
web
hooks,
so
they
could
be
used
there
as
well
yeah,
so
that
that's
where
that's
at
now,
I
think
it's
I
think
most
of
it
is
actually
out
of
our
hands,
but
I
could
let
me
let
me
take
an
action
item
to
to
bring
that
up
with
the
sig
api
machinery.
A
Yeah,
I
remember
that
the
current
blocking
thing,
because
there
are
two
options
that
we
can
do
from
here,
either
we
will
add
a
server
side
in
both
our
api
machinery,
either
we
will
add
a
server-side,
a
consumer
that
will
expose
those
metrics
through
the
official
mechanism
like
we
do
with
all
the
rest
of
the
metrics
or,
alternatively,
we
we
allow
validating
or
mutating
web
hooks
to
have
insights
into
the
headers
that
are
being
sent,
because,
if
I
remember
correctly,
the
issue
currently
is
that
the
web
hooks
don't
have.
A
Okay,
cool
would
be
nice
to
to
push
I
I
was
actually
being
asked
about
a
similar
topic
in
the
lines
of
deprecating
some
other
functionality
within
with
an
open
shift.
So
it's
definitely
something
of
of
an
interest
for
me
as
well
got
it.
A
I
Hi
yeah
yeah,
thanks
for
inviting
me
here
so
for
this
we
have
added
the
support
for
server
side
dry
run
and
we
have
had
for
a
while
some
warnings
to
deprecate
the
empty
values
for
cube
control,
dry
run
and
the
boolean
values.
I
I
So
we
ended
up
reverting
that
and
cherry
picking
it
for
the
next
patch
release.
But
the
question
now
is
what
to
do
with
these
values
and
I'm
not
quite
sure.
Actually,
so
I
think
right
now,
it
actually
might
not
be
a
bad
place
because
the
intent
is
to
have
users
ideally
use
superside
dry
run,
but
I
think
I
mean
ideally,
I
think
we
need
a
plan
maybe
to
switch
the
default
to
server
side
dry
run.
If
that
will
work
for
most
users,
I
think
that
the
problem
is
for
people
who,
like
generate
objects.
I
Yeah,
I
think
I
wanted
to
get
feedback
on
whether
we
want
to,
if
we're
sure
we
want
to
make
the
default
server
slider
run,
and
if
so,
then
we
probably
want
a
proposal
for
doing
that.
C
Julian
I
I
just
had
a
quick
question:
I'm
I'm
just
trying
to
to
understand
where
we're
at
so
so
for
the
patch
release,
which
is
going
to
happen
right
now.
What
is
the
proposal.
I
Yeah
for
the
patch
release,
we
just
reverted
the
original
change
so
that
we
reintroduced
the
values,
so
any
users
who
we
broke,
who
were
using
the
empty
value
or
the
boolean
values
those
should
start
working
again.
I
think
people
will
see
errors
that
those
aren't
valid
values
on
the
otto
release,
but
if
or
when
they
upgrade,
those
values
will
be
back
and,
along
with
the
deprecation
warnings,
thanks.
A
So
yeah
123
is
already
cherry.
Pick
was
also
merged.
Jordan
reached
out
to
me
about
that
particular
one
katrina
pointed
me
out
earlier
today
when
we
were
talking
that
in
the
original
proposal-
and
I
could
probably
find
it
out
where
the
original
proposal
there
it
is,
it
was
mentioned
that
we
will
not
have
a
default,
or
at
least
that's
how
it
was
stated
before.
A
I
Yeah,
that's
right,
yeah!
I
I
think
that
the
intent
was
to
allow
users
to
like
to
switch
or
to
specify
client
or
server
actually
yeah.
So
I
do
like
that,
but
maybe
that
isn't
fair
to
you
know
there.
It
seems
like
there
probably
is
a
lot
of
automation
that
uses
like
keep
control
create
with
the
dry
run
flag
to
create
to
generate
objects.
Besides
probably
the
like
primary
use
case
for
like
previewing
an
object
and
it
yeah.
I
I
think
that
maybe
revisiting
the
plan
is
a
good
idea.
A
F
I
guess
some
two
thoughts
that
I
have
around
this
would
be
that
maintaining
all
of
those
different
flags
might
be
a
source
of
confusion
for
people
indefinitely
like.
Why
do
we
have
so
many
flags,
some
of
which
do
the
same
thing?
What
does
true
mean?
F
Is
it
their
server
and
client,
like
that,
adds
complexity
to
the
tool
and
definitely
if
we
do
nothing
about
it,
so
I
am
in
favor
of
doing
something
and
the
original
plan
I
see
is
like
it
is
inconvenient
to
force
somebody
to
like
to
force
everyone
to
go
and
modify
their
invocation
to
specify.
F
There's
no
case
where
you
know
that
that
it's
suddenly
going
to
do
server
side
driver
and
not
do
what
they
what
they
thought
it
was
going
to
do
and
what
it
has
done
indefinitely,
because
we
just
flipped
a
default
instead
of
going
through
something
that
makes
them
aware
that
that
there's
a
change
happening
very
explicitly.
F
A
I
mean
if,
if
we
were
to
switch,
I
would
imagine
that
you
would
basically
get
more
information,
because
I
would
require
us
printing
the
error,
similarly
to
how
we
print
that
you
should
be
using
dryron
with
client
server
or
not,
and
that
would
just
print
additional
information
that
in
the
next
release,
dry
run
will
be
switched
or
in
the
two
releases
it
will
be
switched
over
to
server
by
default.
A
A
But
going
back
to
the
topic
of
ship
rc
yeah,
that's
that's
where
the
qrc
could
help
us
with.
Actually,
in
the
long
run.
F
So
you
think
we
go
back
to
potentially
the
boolean
values.
Well,
it
can't
be
boolean
values
like
at
some
point.
If
we
don't
have
the
boolean
anymore,
then
we're
still
going
to
run
into
this
problem,
whether
we
have
qrc
or
not
so
either
we
have
five
flags
or
we
have
to
change
something.
F
I
guess
yeah
definitely
some
discussion
to
be
had
here,
as
you
can
see,.
I
I
Oh
sorry,
my
my
internet
dropped
for
a
minute
but
yeah,
I
think
probably
the
original
plan
doesn't
make
sense
anymore,
but
yeah.
Maybe
what
I
can
do
is
it
seems
like
like
moving
to
server
side
as
the
default
might
not
be
bad.
I
can
look
into
if
that
would
actually
be
viable.
Maybe
another
option
is
like
making
the
default
bb
client
for
now
or
in
the
short
term.
I'm
not
sure
if
that
would
make
sense
yeah,
but
I
I
can.
A
I
A
I
A
Yeah:
okay:
it's
not
clear
to
me
how
to
best
approach
the
switch
from
client
to
server
which,
with
the
overall
direction
of
switching
to
the
server
by
default,
I'm
I'm
inclined
to
say
that
it.
It
does
make
sense
to
push
that
one
as
well.
J
In
the
same
vein
of
the
cube
rc
thing,
I
wonder
if
there's
some
opportunity
to
like
have
a
an
environment
variable
or
something
that
allows
it
like.
If
you
really
want
it
to
keep
that
current
behavior,
you
have
to
set
this
environment
variable
so
that
things
work
otherwise
you're
going
to
get
this
new,
more
restrictive,
behavior
that
we
want
so
like
at
least
it
would
give
people
an
out.
J
F
However,
but
yeah
it's
just
like
how
much
are
we
going
to
carry
the
complexity
of
all
these
slides
and
definitely
this
is
the
question:
can
that
be
part
of
a
transition
plan
so
yeah?
We
really
don't
want
to
break
people's
workflows
and
we
want
to
move
our
tool
forward
at
the
same
time
and
consider
the
user
experience
for
people
who
are
newer
in
addition
to
the
people
who
have
these
things
hard
coded
everywhere,.
A
Yeah,
that
would
be
probably
the
the
best
because
we
would
allow
people
to
well.
I
want
to
use
the
legacy
behavior,
for
I
don't
know
an
additional
year
and
on
the
surface
we
would
have
the
new
behavior
already.
A
Okay,
let's
move
on
to
the
next
topic.
This
is
definitely
something
that
we
will
be
reconsidering
again,
so
I'm
not
sure
how
to
pronounce
your
name.
D
Cc
is
that
correct?
Yes,
you
see
yeah
just
call
me
city.
Thank
you
and
yeah.
The
topic
I
propose
is
actually
we
just
delivered
a
feature
in
the
past
release,
which
is
adding
a
new
validation
rules
in
certain
cr,
with
the
expression
language
called
cell,
and
while
exploring
I
found
that
there
are
some
potential
concerns
here.
The
first
one
would
be.
D
There
is
an
inconsistent
behavior
between
server-side
apply
and
client-side
apply,
which
server-side
apply
will
so
the
in
the
the
I
guess
the
initial
idea
is
like,
whatever
how
many
validations
there
we
want
users
to
get
all
the
possible
failures
back
in
my
shot,
so
user
can
like
address
them
together,
but
the
server
side
apply
will
stop
processing
when
meta,
for
example,
the
type
mismatch
issue
and
stop
processing
to
the
further
validation
which
behaves
different
than
client
side
apply.
D
There
is
an
example
I
pasted
there
so
for
server
side
apply
when
they
met
the
type
mismatch
issue.
They
just
stop
there
and
return
the
errors
without
processing
to
the
further
say
cell
validation.
D
I'm
not
sure
if
that's
something
we
want
to
address
or
like
it's
okay
to
leave
it.
This
way
and
another
concern
is
for
the
returned
error
message:
when
server
side
apply
fitting
and
error,
they
will
try
to
return
the
whole
object,
which
caused
basically
two
concerns.
One
is
shared
by
as
similar
as
what
jared
proposed.
The
object
might
be
too
large.
Second,
is
it?
D
It
includes
some
gold
specific
structure
in
the
inside
of
the
return
message,
I'm
not
sure
if
that's
something
we
want
to
address
or
it's
okay
to
leave
it.
This
way.
D
And
I
also
saw
some
previous
discussion
already
because,
like
the
initial
thought
is,
maybe
we
should
marshal
to
json
for
metal
somehow,
and
then
I
saw
some
previous
discussion
already
raised-
concerns
related
with
this,
so
yeah,
that's
just
for
reference.
A
I
would
want
to
somehow
focus
users
attention
and
simplify
the
error
so
that
it
is
possible,
because
the
biggest
worry
is
that,
from
a
regular
user
point
of
view,
that
is
not
a
developer.
A
He
might
not
necessarily
be
aware
what
the
ampersand
value,
value,
unstructured
and
and
the
rest
means
for
from
his
point
of
view
from
his
or
her
point
of
view,
beneficial
would
be
to
say:
oh
expected,
a
string
got,
I
don't
know
and
try
to
somehow
correlate
the
type
or
expected
an
array
got
integer
or
got
string
somehow
suggest
the
error
rather
than
just
throwing
it
at
him.
D
Yeah
that
yeah-
maybe
that's
going
to
be
my
proposal.
Maybe
it
makes
more
sense
to
return
the
type
instead
of
the
whole
object
for
some
specific
case
like
the
type
of
mismatching,
because
that's
what
the
previous
validation
kubo
api
did.
They
didn't
return
the
whole
object.
They
only
return
the
type.
A
Eventually,
focus
in
the
object
provide
the
field,
the
path
to
a
field,
and
then
the
value
of
that
particular
field,
so
that
it
is,
it
is
easier
for
a
user
to
understand.
This
is
what
we're
complaining
about.
A
Here's
how
to
get
to
this
particular
resource
in
the
regular
validation
flow
you
we
usually
include
the
path
how
to
get
to
a
specific.
I
don't
know.
If
that's
let's
say
a
name
is
wrong
or
annotation
is
wrong.
We'll
say
that
it's
metadata
dot
name,
so
that
the
user
can
actually
somehow
find
it
easier
or
more
understandable.
What
the
what
the
problem
is.
D
Yeah,
that
makes
a
lot
of
sense,
so
yeah.
The
part
of
the
reason
I
read
this
is
also
I
want
to
know
if
that's
a
potential
blocker
to
making
the
server-side
apply
default
or
like
we
want
to
address
them
before,
making
the
service
ladder
apply
default.
A
I'm
inclined
to
say
that
none
of
those
is
a
blocker.
It
is
pretty
obvious
that
in
both
cases
there
will
be
some
differences.
A
Maybe
writing
a
blog
post
explaining
those
differences
would
be
beneficial
for
users
that
we
can
link
to
those
even
from
the
from
the
warning
message,
because
I
assume
that
we
would
have
a
some
kind
of
a
heads
up
for
the
users
that
we
will
be
switching
the
default
from
one
to
the
other
in
the
near
future
and
only
after
two
or
three
releases,
because
if
I
remember
correctly,
it's
a
ga
flag,
so
the
usual
deprecation
period
will
apply,
which
is
the
year.
Our
three
releases.
D
And
also
like
do
we
want
to
address
this,
to
make
it
on
the
server
side
apply
the
way
server
side
apply,
validation
align
with
the
client
side
apply,
behavior,
which
is
like.
Instead
of
stop
processing
to
further
validation,
we
trying
to
hold
the
errors
and.
A
I
don't
a
force,
push
a
solution
that
will
be
harder
to
maintain
and
it
will,
in
the
long
term,
cause
a
lot
more
friction
when
trying
to
fix
something.
So
I'm
a
big
fan
of
simple
things.
So
as
long
as
the
the
the
user
experience
will
be
comparable,
which
doesn't
mean
identical,
I'm
okay,
with
with
a
change.
F
I'm
understanding
correctly
that
this
server
side
apply
version
is
returning
incomplete
validation,
information
in
these
cases,
because
I
think
that
is
a
meaningful
user
experience
problem.
F
If,
if
I'm
understanding
that
correctly
and
if
it's
just
for
the
new
validation
rules
that
are
themselves
in
alpha,
I
would
agree
that
it's
not
a
blocker,
but
this
does
seem
like
a
problem
that
we
should
solve
to
me.
If
I'm
understanding
correctly.
D
F
A
I
mean
there's
still
the
case
of
it'll
before
we
change
the
default
from
one
to
the
other,
we'll
have
the
message
for
the
next
year,
assuming
assuming
that
we
will
do
it
right
now.
So
during
that
year
you
have
this
much
time
to
figure
out
how
to
fix
it.
Basically,.
D
And
also
that's
tricky
here
because,
like
the
server
side
apply
still
catch
the
type
mismatch
error
which
will
cause
the
cell
validation
failure
later
anyway
and
use
users,
and
we
cannot
get
all
the
if
there
are
potential
same
validation.
Rule
failures
following
but
users
still
not
able
to
see
those
failures
until
they
fixed
the
type
mismatch
issue.
D
So
that's
tricky
because
it's
enemy
caused
by
the
same
reason
and
user
not
lose
much
lc,
because
the
enemy
have
to
fix
this
first.
So
it's.
F
Yeah,
I
I
don't
see
a
problem
with
it
from
an
inconsistency
point
of
view.
Only
from
like
information
point
of
view.
If
the
information
is
complete
and
useful,
then
that's
fine.
It
doesn't
need
to
match
exactly
I
wouldn't
say,
but
if
it's
not
complete
and
we're
missing
something
that
we
should
be
telling
the
users,
then
we
should
fix
that.
A
Cool
thanks
a
lot
eddie
you're
up
next
for
namespace
and
contacts
nvar.
B
So
there's
crazy,
wind
outside
right
now
my
power
already
went
out
once
so.
If
I
drop
that's
why
this
was
so
these
these
two
issues
this
in
the
next
one
came
up
on
our
bug
scrub
last
week,
and
we
thought
that
we
should
open
this
for
a
discussion
here.
B
A
No,
I
both,
I
I'm
pretty
confident
that
we
also
had
one
about
namespace,
where
I
was
hesitant
to
add
a
namespace
environment
variable,
because,
if
you
need
so
you
should,
the
alternative
is
to
use
an
alias.
A
From
my
own
experience,
I
at
least
myself,
I'm
switching
namespaces
very
frequently
that
I'm
not
keen
on
using
environment
variables.
For
this,
it's
too
tricky
for
context.
I
could
be
persuaded,
but
in
both
cases
you
can
easily
embed.
Well,
maybe
not
necessarily
for
context,
but
for
context.
I
would
use
an
alias
and
namespace
can
be
easily
explicitly
specified
within
the
cubeconfig
that
you
don't
have
to
pass
the
the
namespace
with
every
single
command,
and,
if
I
remember
correctly,
our
sample
cli
plugin
does
this
for
you
too,.
A
If
that's
the
approach-
and
we
have
a
similar
approach
in
openshift,
where,
if
you
switch
to
a
particular
namespace,
all
the
commands
from
that,
then
on
we'll
always
use
the
default
namespace
that
you
specified
so
that
you
don't
have
to
always
specify
the
namespace
flag.
So
that
would
be
my
preferred
approach.
F
I
I
think,
if
I'm
understanding
the
issue
correctly,
I
empathize
with
the
workflow
that
they're
going
for,
because
I
actually
used
to
do
that
myself
at
one
point:
a
bunch
of
different
terminals
where
I'm
trying
to
work
in
one
context,
one
in
another
context
in
another,
and
I
want
that
to
be
persistent
within
the
terminal
itself.
F
But
then,
if
you
modify
your
cube
config,
obviously
it's
not
so
then,
then
you
end
up
with
the
flags
every
time
like
they're
saying-
and
I
had
this
this
crazy
thing
that
I
was
doing
where
when
I
opened
the
terminal
it
actually
cloned
the
cube
config
to
give
it
a
unique
cube,
config
per
terminal
that
it
was
using,
which
you
can
already
do
with
the
the
q
config
environment
variable.
So
it
is
possible
to
implement
this
workflow
today.
F
C
I
I
would
I
second
that
as
well
katrina,
I
I
think
there.
This
is
a
test
of
you
know
what
what
we
get
versus
the
amount
of
possible
ways.
So
so
they
the
number
of
new
ways
that
people
are
going
to
be
able
to
to
break
their
their
talking
to
their
cluster,
where
they
thought
they
were
talking
in
this
name
space,
and
but
you
know
they
had
this
other
environment
variable.
C
I
think
that
the
safety
issues
should
should
be
the
you
know:
the
the
primary
issues
versus
extra
functionality.
B
Yeah
I
so
I
I
agree
on
the
name
space
front,
I
I
wouldn't
add
an
environment
for
the
name
space.
The
context
one
is
interesting.
I
I
would
lean
more
towards
doing
that.
If
we
did
any
and
as
far
as
context
goes,
I
think
that
safety
is
a
problem,
no
matter
what,
because,
unless
you
have
your
shell
prompt
telling
you
what
your
current
context
is.
You're
usually
running,
commands
blind,
and
I
know
a
few
people
on
this
call
have
told
me.
B
A
The
basically
the
this
nicely
follows
the
discussion
that
you
brought
up
for
delete
months
ago,
where
you
accidentally
removed
something
because
you
didn't
know
that
or
you
invoke
delete
all
because
you
didn't
know
that
something
was
or
like
a
context,
was
predefined
through
an
environment
variable.
So
I'm
definitely
not
in
favor
of
namespace
context.
B
Yeah,
well,
I
will
link
to
this
discussion
on
that
issue
and
we'll
see
if
the
author
has
any
thoughts
or
feedback.
Try.
A
B
A
Okay,
with
three
minutes:
do
you
wanna
go
through
the
keep
cuddle
div
or
you
wanna
push
that
over
to
the
next
time.
C
So,
actually,
I
think
I'm
gonna
close
that
that
issue.
I
think
that
it's
the
issue
that
they
were
talking
about
is
actually
get
deaf
and
they
should
in
in
the
best
case
scenario
in
the
canonical
scenario,
they
should
have
their
configuration
under
source
code
control,
which
would
give
them
this.
The
diff
of
the
last
applied
configuration
through
just
a
git
diff.
B
Yeah,
I
think
so
I
put
this
on
the
agenda
because
I
think
that
there's
a
discussion
we
need
to
have.
We
don't
have
to
have
it
today,
but
we
obviously
want
to
push
users
towards
server-side
everything
and
configuration
management,
and
so
this
feels
like
an
anti-pattern
like
sean
said
where
you
know
your
last
applied
should
be
the
truth
and
like
to
get
the
difference
of
the
last
applied
would
be
the
diff
from
your
file
to
that
yeah.
A
Yeah,
that's
her
okay,
one
final
question:
how
many
funks
will
be
around
next
week
for
customized
box
crop?
Because
let
me
give
you
some
some
background.
A
A
If
there
will
be
sufficient
amount
of
people,
we
will
run
it
if
most
folks,
which
I'm
suspecting,
because
that's
like
three
days
before
holidays,
two
three,
depending
on
how
you
count,
if
majority
will
be
out,
we
are
inclined
to
cancel
that
one
as
well,
so
speak
now,
one
way
or
the
other.
F
I
also
had
the
thought
that
it
might
be
not
be
a
terribly
valuable
bug
scrub
in
the
sense
that
if
people
are
about
to
be
off
then
committing
to
something
and
then
forgetting
what
it
was
for.
A
few
weeks
is
maybe
not
the
best
approach.
A
Yeah,
I'm
personally
I'm
in
next
week,
but
I'm
personally
in
favor
of
just
closing
whatever
is
there,
so
I
guess
with
not
that
many
objections.
I
will
go
ahead
and
cancel
all
the
meetings
till
the
end
of
this
year.
So
with
that,
thank
you
very
much.
All
it's
top
of
the
art
already
it
was.
It
was
a
pleasure
to
be
your
sig
chair
for
three
four
years.
I
think
I'm
still
here,
I'm
leaving
I'll
be
just
looking
at
the
technical
side
of
things.