►
From YouTube: Kubernetes SIG CLI 20210407
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
Okay
good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are
today
is
april
7th-
and
this
is
another
of
our
bi-weekly
six
diy
calls-
my
name
is
marcie
and
I'll
be
your
host.
Today,
I
forgot
to
put
my
name
in
the
agenda
of
the
organizer.
Our
agenda
is
pretty
packed
by
now.
So,
let's
get
on
to
the
business
announcements,
first,
we're
hours
away
from
121
release.
If
I
remember
correctly,
I
haven't
seen
an
announcement,
so
I
probably
have
haven't
missed
one.
A
A
I
just
earlier
today,
went
through
the
report
address
all
the
comments
so
make
sure
that
you,
if
you
have
some
time,
read
it
if
you
have
comments,
feel
free
to
leave
them
there,
and
if
there
are
no
comments,
we
are
hoping
to
merge
that
later
this
week,
so
eddie
sean.
Do
you
have
any
other
announcements
that
you
want
to
throw
at
the
table?
A
No,
oh!
So,
let's
move
on
to
the
introductions.
I
know
that
we
have
a
couple
of
new
folks
or
some
that
were
not
here
for
a
very
long
time,
so
I
will
start
with
nikita
because
I
know
she
hasn't
been
around
in
a
while.
I
know
her
a
lot
of
folks
know
her,
but
I
can't
remember
seeing
her
in
a
six
year
life
in
a
while
so
I'll,
let
her
speak,
who
you
are,
what
you're
expecting
from
6ui.
B
Hey
everyone
yeah.
I
think
I
haven't
really
attending
any
six
year
li
meetings,
but
it's
nice
to
see
all
I
think
I've
met
some
of
your
cupcake
and
other
places,
so
I'm
nikita
I'm
one
of
the
technical
leads
for
six
centrifugal
experience,
also
on
the
kubernetes
steering
committee
here
at
double
and
a
few
other
things
here
and
there
and
about
60
like
came
across
an
issue
about
adding
sub
resource
support
to
keep
ctl.
So
so
your
rash
will
smite.
So
you
both
decided
to
write
a
cap
for
it.
B
C
A
Okay,
am
I
seeing
anyone
new
also
on
the
call
feel
free
to
to
speak
up,
introduce
yourself
explain
what
you're
looking
for
what
you're
interested
in
with
regards
to
sexy
life,
I'm
scrolling
quickly
through
the
list.
A
A
Okay,
hearing
none,
so
we
can
continue
with
the
rest
of
the
talk
with
the
rest
of
the
meeting,
which
brings
us
back
to
nikita
and
do
you
wanna
share
your
screen
or
you
you're?
Just
you
just
need
to
have
the
the
enhancement
open.
B
It
I
could
kind
so
like
I
could
walk
through
a
little
bit
on
the
cap
and
then
I
should
probably
get
the
timer.
It's
a
good
shot.
D
B
Then
I'm
just
gonna
start,
so
we
had
opened
up
docpr
few
almost
a
month
ago,
at
this
point
to
get
some
initial
feedback.
The
usual
feedback
was
positive,
so
we
went
ahead
and
wrote
a
cap
for
this.
So
the
whole
point
is
that
proposes:
adding
a
new
flag
sub
resource
to
keep
cpr
so
specifically
to
the
get
applied
patch.
B
Command
store
for
specifically
for
getting
and
updating
or
patching
sub
resources,
and
at
this
point,
we're
just
looking
at
status
and
scale
sub
resources,
so
supporting
other
sub
resources
is
a
non
goal.
This
is
both
for
filter
types
and
for
crds
and
another
things
is
like.
Why
are
we
doing
this
so
right
now
there
is
absolutely
no
way
to,
but
you
can
you
can't
really
update
sub
resources
by
keepsake
here
you
can
do
that
using
a
girl
or
you
can
write
like
use
client
code.
B
You
can
distribute
the
client
directly,
but
it
isn't
really
possible.
Why
keep
ctrl
so
and
it's
kind
of
useful
when
you're,
like
scripting
or
debugging
or
testing
things.
So
this
whole
point
is
that
it
adds
sub
resources
as
a
first
class
option
in
cube
ctl,
so
that,
like
we
can
work
with
the
api
in
generic
fashion.
So
to
talk
a
little
bit
about
the
behavior,
the
I
think
the
most
important
point
is
this,
and
we've
called
it
out
a
few
times
in
the
capital.
B
I
had
like
someone
left
to
comment
on
the
pr,
so
I
will
expand
a
bit
more
on
this
in
the
calculator.
So
the
whole
point
is
that
when
you
update,
when
you
say
like
sub
resource
equal
status,
it's
supposed
to
be
updating
the
status
part
of
the
resource.
B
But
then,
if
you
have
a
controller
which
is
already
running
against
the
main
resource
that
reconciles
the
status
part,
then
the
status
field
is
not
updated.
So
this
ensures
that
there
is
no
arbitrary
data
data
and
status
and
that's
kind
of
what
we
want.
This
holds
true
for
both
built-in
types
and
crds,
but
if
you
don't
have
a
controller,
for
example
like
running
against
a
custom
resource
and
your
update
status
status
will
get
updated.
B
So
that
is
one
thing
and
I
wanted
to
check
if
that
behavior
makes
sense
and
if
there
were
any
concerns
around
that
behavior.
So
that
was
one
point.
Another
thing
was
around
how
like,
if
you
do
a
cube
ctl
get
on
sub
status.
B
What
is
like,
how
would
the
table
get
displayed,
so
we
are
like
we've
upgraded
the
poc
and
like
in
the
cap
to
just
display,
whatever
the
columns
would
be
for
the
main
resource
for
both
custom
resources
and
built-in
types,
but
we
could
update
this
too,
like
I
think
it's
a
little
bit
more
involved
for
doing
it
for
built-in
types
for
crs.
We
actually
did
it
and
then
reverted
it
back
to
ensure
like
it's,
both
consistent
across
built-in
and
custom
resources.
B
I
wanted
to
get
feedback
on
whether
and
how
what
would
be
the
expectation
around
how
this
would
be
displayed
and
just
to
cover.
I
know
we
have
like
other
things
on
the
agenda,
so
I'll,
keep
it
quick
too,
and
if,
like
you,
we
use
and
select
only
status
and
scale
sub
resources
are
supported.
So
if
you
specify
invalid
sub
resource,
you
give
an
error.
If
you
specify
a
sub
resource,
that's
not
supported
it'll,
give
a
not
found
error,
so
all
of
like
these
commands
are
supported
for
all
types.
B
Another
point,
though,
is
actually
someone
brought
it
up.
Recent
list
yesterday
was
supporting
a
listing
and
watching
for
sub
resources
too.
So
I
wanted
to
get
feedback
on
like
we
haven't
included
it
here,
but
we
can,
if
that's
desired
as
well,
which
sort
of
makes
sense.
So
I
wanted
to
get
feedback
on
that
so,
like
specifically
like
feedback
on
the
broad
idea
of
the
cap
and
specifically
on
updating
the
status
behavior
like
is
that
how
it
should
should
be
working
is
how
what
would
be?
B
What
would
be
the
expectation
for
the
table
display
and
should
we
be
supporting
listing
and
watching
what's
up
resources,
so
we
could
go
ahead
with
the
demo
or
like.
If
anyone
have
questions,
I
could
take
it
up.
Let
me.
B
Sure
I
will
then
stop
sharing
my
screens
so
you're
watching
sure
yeah.
C
Okay,
so
yeah
in
this
demo
we'll
actually
look
at
using
the
subresource
flag
with
three
commands,
especially
get
patch
and
apply
and
we'll
be
doing
the
same
for
both
built-ins
and
crt.
So
I
currently
have.
C
We'll
be
using
the
deployment,
as
as
a
as
an
example
for
the
building
type,
because
it
supports
both
scale
and
status
sub
resources.
So
I
have
a
deployment
called
engine
deployment.
So
let
me
try
to
patch
the
scales
of
resource
of
this
deployment
and
then
change
the
president,
because
two
two
right,
so
let
me
just
get
that.
C
So
this
basically
patched
the
cpl
patch
the
deployment
object
and,
as
you
can
see,
we
pass
the
surface
of
scale
object
and
the
json
path
then
specified
points
to
like
is
the
json
path
of
the
auto
scaling.
V1
scale
type
object
and
if
you
now
look
at.
C
But
if
you
use
sub
resource
scale,
this
one
actually
gets
the
scale
object
associated
with
that
corresponding
deployment,
and
we
define
new
column
definitions
for
the
scale
object
so
that
it
it
prints
two
columns
like
the
desired
replicas
and
the
available
replicas.
So
that
is
how
the
scale
and
subresource
get
and
patch
work
for
built-in
types,
and
this
is
exactly
how
they
would
work
for
crds
as
well.
I
have
a
crd
installed
already
on
this
cluster.
C
C
So
this
cr,
this
instance
of
cr,
does
not
have
any
status
information
present
in
it.
At
this
point,
and
let
me
also
mention
that
there
is
no
controller
associated
with
this
crd
right
now,
so
any
changes
that
you
make
to
the
crd
are
coming
through
cube,
ctl
and
not
from
any
other
place.
C
C
And
I
need
to
specify
the
sub
resource
equal
to
status.
This
makes
sure
that
the
update
is
actually
happening
on
the
status,
and
it's
also
important
to
note
that
in
while
we
do
this
call,
it
only
considers
the
changes
that
are
made
to
the
status
subsection
of
the
resource.
Any
changes
that
are
made
to
like
spec
or
other
parts
will
be
completely
ignored
and
only
the
status
changes
will
be
applied.
C
Sorry
and
that's
no
updated
so
if
we
actually
get
you'll
see
that
it
now
has
the
status
information
available
and
crds
also
support
the
same,
get
sub
resource
status
and
get
sub
source
scale.
So
if
we
do
status
we'll
see
again,
it
uses
the
exact
same
columns
that
are
defined
for
the
crt
in
additional
printer
columns.
C
We
don't
do
anything
anything
different
with
it
and
it
also
supports
scale,
so
it
again
prints
the
exact
same
column,
definitions
as
in
built-in
types
just
so
that
we
are
consistent
and
it
prints
the
corresponding
scale,
object
associated
with
this
character
with
the
crd
yeah.
That's
that's
the
end
of
the
remote,
so
we've
seen
how
apply
kit
and
patch
all
work
with
the
new
sub
resource
flag,
the
subresource
flag
actually
also
supports
replace,
is
supported
in
the
replace
and
edit
commands.
C
As
any
questions.
A
Okay,
I
have
one
question:
the
the
resource
that
you
applied
was
that
the
entire
resource
of
the
vm
set,
or
only
a
sub-resource
status.
I
remember
you've
mentioned
that
the
subresource
only
looks
at
the
sub
resource
bit,
but
the
question
is
whether
the
yelp
itself
was
entire
or
just
a
the
status
of
resource.
C
A
C
F
Okay,
I
have
a
quick
question
so
for
the
apply,
do
you
put
this
sub
resource
in
the
last
applied
annotation
for
client
side
apply?
C
Yes,
but
I
don't
know
the
answer
to
that:
I'll
have
to
go
back
and
check
if
the
actually
we
can
check
it
right
now,
right,
the
annotation.
If
it's
getting
offline.
F
Yeah,
if
you
yeah,
I
think
if
you
you
could
check
that
so
so,
if
it's
not
there,
then
it
will
be
difficult
to
impossible
to
delete
the
the
sub
resource,
I'm
not
sure
what
that
means.
A
Yeah
there
is
there's
a
logic
that
is
comparing
the
previous
step
with
the
current
state,
so
it
would
be
good
to
include
the
the
applied
changes
in
that
annotation.
A
Similarly,
to
what
the
normal
apply
does
so
yeah.
That's,
I
think
a
implementation
detail
nikita
you
had
a
questions
about
watching
and
getting
can
you
repeat
them
once
again.
B
Sure
so
I
so
like
for
context
the
stepped
up
when
I
was
starting
with
some
creative
developers,
so
they
have
very
big
custom
logic
where
they
try
to
watch
deployment
resources,
but
they
only
care
about
replicas.
So
what
they
wanted
was
a
mechanism
to
be
just
like
watch
this.
The
scales
are
resourced
for
deployments,
so
we
haven't
really
implemented
like
listing
support
for
listing
and
watching
sub
resources,
but
I
just
wanted
to
check
if
it
made
sense
and
that
should
be
supported
as
well.
A
I
think
if
the
api
server
allows
you
to
do
this
on
the
internet.
On
the
other
hand,
the
sub
resource
is
usually
invoked
against
a
specific
resource,
so
I
think
it's
okay.
If
we
initially
say
that
we
don't
support
that
and
we
can
always
revisit
the
decision
later
on.
I
think
that
will
simplify
any
of
that
the
implementation
initially
and
then
we
can
always
put
a
to-do
or
a
feature
directions
to
to
modify
the
the
cap
further.
C
Yeah,
so
I
just
checked
in
the
cluster
that
I
was
using
for
the
demo
and
the
last
applied
configuration
annotation
on
the
resource
does
not
capture
the
changes
to
the
status
subresource.
As
of
this
one,
as
now.
A
Yeah,
that's
that
will
be
probably
an
implementation
detail
to
solve
during
working
on
it.
The
other
question
that
you
had
also
nikita
was
about
updating
the
status
of
resource,
especially
for
the
built-ins.
Out
of
curiosity,
have
you
tried
what
happens
if
you
keep
cuddle
edit?
I
don't
know
a
deployment.
Is
it
possible
to
update
a
a
status,
I'm
pretty
sure
that
the
the
controller
will
pick
it
up
very
quickly
and
override
your
changes,
but
I'm
pretty
sure
that
the
the
server
does
not
reject
this
kind
of
update?
A
Yes,
yes,
so
I
would
probably
follow
the
same
guidelines
as
in
it's
possible
to
update
anything,
but
it
should
be
up
to
a
user's
reasonable
judgment
not
to
update
the
status
and
in
most
cases
the
controller
will
will
fix
this
status
shortly
after
getting
an
update,
because
usually
it
will
just
respond
to
an
update
with
reconciling
and
figuring
out
that
there's
a
difference
between
the
actual
state
and
what
the
status
says.
A
F
I
had
I
had
one
more
quick
comment.
Sorry
to
interrupt
so
so
on
super
server
side
apply.
We
now
have
the
force
conflicts
in
the
field
manager
flag,
and
so
I'm
guessing
you
want
to
be
if
you're
the
field
manager
or
the
owner
or
maybe
not
for
when
you
change
this,
you
know
say,
for
instance,
the
the
replicas
and
you
may
end
up
having
to
to
call
force
conflicts
in
order
to
to
not
collide
with
a
controller.
F
You
know
if
there
is
a
controller,
that's
in
charge
of
of
some
of
the
fields
that
you're
modifying,
so
so
what,
when
it
comes
to
the
server
side,
apply,
I
you
know,
there's
you
have.
I
think
we
have
to
take
into
account
the
field
manager
and
conflicts
like
who's
going
to
own.
That
field.
A
Right,
sean,
but
that
that
is
handled
internally
by
the
server-side
apply
mechanism
such
that,
if
you
try
to
even
edit
a
a
sub
resource,
you
have
to
explicitly
say
force.
That's
what
I'm
saying
apply.
You
would
have
to
explicitly
say
force
to
override
the
the
field
manager
and
take
ownership
of
the
field,
and
on
top
of
that,
I
remember
that
the
deal
is
that
all
the
controllers
will
always
work
as
force
force,
which
means
yeah,
which
means
they
will
always
override
any
changes.
There's
no
ownership
for
a
controller.
F
Any
applied
updates,
so
I
think
the
server
side
apply
would
fail
unless
you
actually
have
this
extra
force
conflicts
flag.
Yeah,
that
I
think
that
the
mechanisms.
C
Questions,
oh
yeah
you're
right
go
ahead,
yeah!
I
I
didn't
have
a
question.
I
just
want
to
confirm.
I
just
wanted
to
confirm
that
like
when
you
do
the
edit
action,
the
the
change
actually
goes
through
it
passes.
You
can
see
that
in
the
response
that
this
value
is
changed,
but
then
the
controller
quickly
reconstructs
it
back
to
the
original
value.
So
if
you
do
a
get
immediately,
you'll
see
that
there
was
no
change
observed
and
that's
the
behavior
that
is
happening
right
now.
A
Yeah,
so
that's
that's
pretty
much
what
I
would
expect
as
well-
and
this
is
literally
what
you
should
be
also
allowing
it
it'll
be
simpler
for
you,
if
you
don't
have
to
have
any
special
exceptions
for
oh.
We
don't
have
to
take
this
because
we
thought
that
it
won't
be
good,
so
I'll
keep
it
simple
and
we
can
always
revisit
the
decision
afterwards
and
and
change
them
if,
if
there
will
be
requests
coming
from
the
community
last
core
last
call
for
for
questions.
A
E
E
Do
I
didn't,
did
any
any
demo
or
nothing
yet,
but
I
have
an
idea
of
how
to
start
this,
but
as
we
delegate
every
every
ever
check
to
a
a
function
in
in
common
virtues,
maybe
it's
worth
to
instead
of
using
that
that
function
right
in
a
new
one,
because
we
have,
we
always
will
have
at
least
two
to
three
steps
in
each
comment:
right,
that's
the
complete
the
validation
and
the
run
so
completely
validation.
As
far
as
as
I
I
got,
they
only
run
on
the
client
side,
so
we
can
assess
like
okay.
E
There
was
a
validation
error,
I'm
gonna
exit
with
this
code.
Two
there
was
a
complete
error,
I'm
gonna
is
it,
is
it
called
one
and
that
and
you
can
like
early
early
drop
right,
but
the
run
error
is
one
that's
pretty
hard
to
assess
and
and
if
you
take
a
look
into
that
function,
that's
a
that's
a
six
year
old
function,
the
the
the
check
or
one.
So
probably
it's
worth
to
discuss.
E
If
we
can
improve
that
function
or
move
to
a
part
like
big
movement
to
another
function
that
can
assess
like
if
it
was
an
api
error
or
if
it
was
like
a
local
waiver.
The
horror
was
forbidden,
so
I
have
proposed
that
we
at
least
start
writing
the
expected
error
codes
that
we
think
like
separating
from
one
to
64
being
like
client
side
levers
and
from
65
to
127
from
server
side
and
the
128
to
moving
forward.
E
It's
like
some
external
common
or
occurring
so
like
if
diff
returns,
an
error
code,
it's
going
to
be
the
cube
ctl
return
code
will
be
something
like
128
plus
the
error
code.
From
from
this,
so
you
can
at
least
know
which
was
the
error
code
from
different,
not
not
from
from
ctl,
so
also
it
can.
It
can
help
with
plugins
and
so
on.
E
E
How
can
we
migrate
the
functions
from
each
each
of
the
comments
to
use
like
the
new
check
ever
function
or
if
we,
if
actually
we
want
to
break
this
thing
also
or
if
we
want
to
have
like
some
some
sort
of
flag
to
change
the
behavior?
If
we
are
like
changing
the
ac
codes
or
not,
so
we
can
also
allow
the
users
to
have
time
to
migrate
their
like
their
ci
or
something
like
that,
because
probably
they
are
not
expecting
somebody
or
to
appear
in
validate
or
they
are
going
to
say.
E
Okay,
everything
is
green,
even
if
validate
is
failing,
but
I'm
not
getting
like
or
called
zero
or
like.
If
a
namespace
is
not
being
found,
a
research
is
not
being
found
so
in
the
future.
If
you
do
a
keep
city
I'll
get
namespace,
it's
going
to
return
an
exit
code,
so
you
need
to
like
to
say:
okay,
I
want
I
want
this
to
happen,
but
I
tried
to
put
everything
that
I
thought
in
in
this
gap.
A
And
that's
that's
it
so,
first
of
all,
and
probably
the
most
important
one,
none
of
the
changes
from
this
particular
cap
should
affect
the
current
way
of
working
with
cuddle.
So
if
any
given
current
command
fails
with
a
non-zero
exit
code,
it
should
still
fail
at
a
non-zero
exit
code
after
the
change,
so
I
wouldn't
expect
suddenly
validate
or
run
to
fail
where
it
wasn't
previously
failing
so,
and
this
basically
means
we
need
to
maintain
the
backwards
compatibility,
and
currently
nobody
is
relying
on
any
particular
exit
codes.
A
So
the
only
guarantee
that
we
currently
give
is,
if
we
succeed,
we
return
zero
as
any
regular
process
or
we
return
non-zero
if
we
fail,
but
we
don't
specify
the
exit
codes
yet
so
that's
the
first
important
distinction
between
about
maintaining
the
backwards
compatibility
with.
With
regards
to
to
failing,
I
really
like
the
idea
of.
A
A
He
will
only
care
about
oh
get
failed
and
we
need
to
be
able
to
explicitly
give
the
information
why
it
failed.
So
the
distinction
between
oh,
I
failed
because
there
was
a
problem
contacting
the
server
versus.
Oh,
there
is
a
problem
on
the
server
expressed
through
the
exit
code.
Yes,
that
makes
sense.
A
A
Before
we
actually
start
implementing,
like
you
just
said,
creating
I'm
not
even
saying
that
it'll
be
complete,
because
we
will
say
this
is
this
is
an
alpha
functionality,
so
it
might
change
it
will
change
over
the
the
several
releases,
but
still
slowly
try
to
ship
them,
but
identify
at
least
set
of
groups
and
what
you
propose
about
several
several
buckets
about,
whether
that
was
a
local
change,
a
local
problem,
because
I
don't
know
the
internet
is
not
working
or
something
like
that,
or
that
there
was
a
server-side
issue
totally
makes
sense.
D
A
D
A
E
A
Yeah
there's
a
very
thin
line
with
get
and
returning
and
error
when
you
can't
find
and
when
you
don't
have
access
and
when
something
does
not
exist.
A
If
you
would
get
information
that
you
don't
have
access
to
this
pod
or
a
namespace,
you
clearly
have
an
information.
Yes,
something
like
part,
a
or
namespace
a
exists
versus
you're,
getting
a
not
found,
which
means
you
either
don't
have
access,
it
might
actually
not
exist,
but
there's
something
else
and
with
those
errors
I
will
always
reject
any
questions
or
any
issues
that
will
be
pointing.
I
know
that
users
have
hard
time
figuring
out
if
you
do
a
small
typo,
but
this
is
basically
about
my
all-time
favorite.
A
Similar
issue
is
when
you're
trying
to
log
in
the
proper,
secure,
login
form
will
tell
you
that
the
user
and
or
password
is
incorrect
without
pointing
to
which
one
is
incorrect,
because
if
the
form
is
clearly
saying
oh
you,
the
password
is
wrong.
You
can
easily
tell
and
guess
the
username
and
then
just
iterate
and
focus
on
the
password
itself.
A
E
A
E
A
Okay,
that
would
be
my
best
approach
to
not
expose
too
much,
but
not
exposing
enough
information.
E
Okay
got
it
so
eddie
eddie
asked
about.
If,
if
I
I
have
some
some
sort
of
deprecation
path,
yeah,
so
I
somewhere
in
this
cab-
I
wrote
that
like
one
month
ago,
but
there
is
a
flag
that
if,
if
you
wanna
use
like
the
old
behavior
or
the
new
one
like
the
old
one,
is
not
not
not
keeping
like
not
not
not
is
not
basic
thing
with
like
the
new.
Is
it
codes,
the
new
one
right
and
the
old
one
is
like
keep
keep
the
way.
E
A
Headers
for
commands
that
will
be
a
global
information
and
that's
probably
the
the
most
consistent
way.
It's
easier,
also
yeah
exactly
and
then,
but
I
would
still
try
to
and
encourage
you
to.
A
You
know,
stick
with
the
current
mechanism
and
we
will
dissect
each
and
every
single
case,
one
by
one
and
figure
out
whether
we
want
to
change
the
behavior
of
a
particular
command
or
not,
and
and
only
then
you
know
go
one
by
one,
but
my
ideal
case
would
be
at
least
have
a
rather
global
view
of
all
the
commands
and
somewhat
identified
buckets
of
different
exit
codes.
Like
you,
like
you
described
earlier,
okay
sounds
good.
A
I
would
totally
suggest
to
write
an
email
to
both
six
cli
and
kubernetes
death
about
this
cap
that
here
you
have
open
make
sure
to
tweet
about
it
as
well.
I
have
no
idea
where
else
we
can
talk
about
it,
but
eddie
is
raising.
A
Probably
slack
as
well
try
to
reach
out
as
many
different
channels
as
possible
go.
D
Ahead,
eddie
yeah,
so
I
had
two
things
so
on
that
note,
I
think
that
this
is
a
good
opportunity
for
us
to
engage
a
lot
of
folks
who
aren't
in
the
community
and
get
their
feedback
and
thoughts.
A
lot
of
the
people
that
are
going
to
be
dealing
with
exit
codes
are
going
to
be
your.
D
You
know
your
system,
administrators
and
your
ci
cd
integrators
right
so
they're
the
ones
who
are
really
going
to
be
caring,
ci
cicd's,
a
great
story
there
to
actually
dig
into
like
what
do
people
want
to
see
in
their
jenkins
pipeline
so
yeah.
I
can
definitely
help
shop
that
around
so
I'll
talk
to
you
offline
about
that.
The
other
thing.
So
I
I
think
the
idea
of
adding
a
standard
code
to
the
plug-in
code
is
that's
actually
like,
really
clever
and
brilliant.
Is
that
like
based
on
any
prior?
E
Java
or
java
running
inside
kubernetes,
when
you
have
out
of
memory
you'll
get
a
network
call
that's
up
to
128.
I
can't
remember
eddie,
but
I
I
will.
I
will
figure
out
with
folks
from
my
company,
because
the
other
code
that
you
get
when
a
pod
exits
because
of
out
of
memory
is
the
sum
of
like
127
plus
plus
something
internal
but
yeah.
I
I
I
will
try
to
figure
out.
Where
is
this
written,
so
we
can
actually
have
like
a
prior
art.
I
am
not
a
genius.
Sorry.
A
Wrote
in
the
chat,
which
is
a
very
good
suggestion-
to
write
a
blog
post
for
kate's
for
kubernetes
blog,
where
we
can
discuss
that.
This
is
something
that
we
are
looking
at
at
and
we
would
like
to
gather
as
much
feedback,
because
this
is
something
that
it
will
be
very
hard
for.
Only
us
to
have
a
clear
information.
A
We
have
to
gather
a
lot
of
feedback
on
this
one
before
we
start
implementing,
because
the
the
feedback
will
be
the
best
source
of
information
about
the
the
exit
codes
that
people
do
expect
from
cube.
Paddle
commands,
then
any
kind
of
resources
that
we
can,
or
you
know
any
kind
of
man
pages
you're,
going
to
go
through
source
code
of
any
other
command.
So
yeah
as
many
as
possible
outreach
about
that
we're
working
on
it-
and
we
would
like
to
gather
feedback
is-
is
the
best
sure.
A
Okay,
we
still
have
about
13
minutes,
so
ricardo
you
had.
E
So
this
is
someone
asked
to
to
do
a
feature,
create
config
map
with
labels,
and
I
was
wondering
if
we
shouldn't
be
taking
care
like
of
having
how
they
create
comments
with
labels
instead
of
just
just
configmed,
because
labels
they
are
used
by
almost
anything
right.
So
you
have
labels
that
are
used
to
be
selectors
network
policies
and
so
on,
and
also
maybe
we
should
discuss
about
annotation
as
well.
E
So
there
is
a
last
comment
there
about
about
labels
and
if
we
should
take
care
of
of
annotations
as
well
and
being
these
like
a
a
global
function
that
can
be
used
by
any
any
create
create
common,
and
on
the
other
hand,
I
guess
there
was
a
some
somewhere
in
some
issue
that
I
I
think
sean
or
someone
else
told
that
we
should
probably
be
thinking
about
the
create,
create
comments.
E
Right.
I
don't
know
if
was
channel
or
if
was
few,
so
I
don't
want
to
bring
anything
that
can
be
like
deprecated
in
the
future
or
that's
not
something
that
we
don't
want,
but
as
a
user,
I
think
that
we
should
probably
be
thinking
about
having
the
labels
and
the
annotations
as
some
some
sort
of
flags
for
any
create
comment,
because
they
are
broadly
used,
and
they
this
can
be
really
helpful.
Like
I,
I
added
the
annotations
in
create
ingress
comment,
because
ingress
controllers,
they
use
annotations
for
almost
everything.
A
D
I'll,
let
other
folks
have
a
look
at
it.
We
recently
did
one
of
these
over
the
summer.
I
think,
actually,
we
added
annotation
to
something
and
and
phil
was
definitely
against,
adding
it,
but
gave
in
at
the
end.
I
agree
with
you
that
it
should
be
consistent
across
everything
if
we're
gonna
have
it
for
one
thing
it
we
should,
it
should
be
just
top
level
for
the
create
command
and
it
should
apply
to
every
resource.
E
Some
sorry,
but
I
know
that
some
folks,
don't
don't
vlog.
Oh
sorry,
go
ahead.
Yeah
I
am
with
italy.
I.
A
A
I
do
agree
that
something
like
that
seems
reasonable,
so
it's
just
about
how
to
wire
it
properly
and
yeah.
So
go
ahead.
What
you
wanted
to
say.
E
Yeah
I
I
I
was
saying
that
I
know
that
some
some
some
folks
are
really
against,
like
we
we're
using
annotations
as
like
some
some
sort
of
feuds-
mostly,
I
usually
argue
with
tim
hawking
about
that,
but
because
of
the
the
nature
of
at
least
ingress
controllers,
we
we
need
annotations,
but
maybe
we
shouldn't
be
relying
so
much
on
annotations
but,
on
the
other
hand,
labels
probably
at
least
labels.
We
should.
We
should
really
really
take
a
look
into
that
because
they
are
really
used
by
anything
here.
So
even
like
network
policy,
selectors
services
selectors.
A
Yeah,
I
totally
agree
about
that
approach,
especially
that
labels
are
the
the
most
important
primitive
for
organizing
resources
in
some
logical
groups.
D
My
my
hot
take,
there
is
either
we,
I
would
say
we
either
implement
it
at
the
top
level
or
we
deprecate
it
for
the
individual
resources
that
it's
enabled
for
under
create
because
it
it
if
it's
in
a
sub
resource
and
it's
not
in
other
resources.
I
get
the
confusion
for
the
users
and
it
also
it
makes
for
more
maintainable
code
if
we
don't
have
that
replicated
and
duplicated
for
every
single
sub
thing,
as
opposed
to
just
being
at
the
top
level.
So
that
would
be
my
take
on
that.
A
A
A
Yeah,
okay:
are
there
any
last
minutes,
yeah
cool
thanks
a
lot
ricardo.
Are
there
any
last
minute
topics
that
people
wanted
to
bring
up.
A
Okay
hearing
none
do
we
have
any
stand-up
updates
from
the
sub
project
or
from
folks
that
want
to
share
what
they've
been
working
on
over
the
past
weeks.
D
G
Okay,
should
I
write
should
I
suggest
like
what's
the
protocol
for
that.
D
If
you
want
to
alter
a
blog
post,
I
think
that's
awesome.
If
not
I'm
sure
we
can,
you
know,
write
one
up
and
figure
out
someone
who
wants
to
do
that.
G
Okay,
no
I'm
happy
to
write
it.
Who
what's
the
is
there
a
do
you
know?
Maybe
you
can
send
me
privately
if
there's
a
pr
process
for
that
yeah.
A
That's
that's
literally
what
what
is
required.
You
basically
create
apr
against
the
kubernetes
website
project.
There
is
a
subdirectory
which
is
literally
a
blog
and
then
then,
if
nobody
reaches
out
to
you
in
some
reasonable
time,
we
can
just
ping
the
necessary
folks
to
get
that
published,
but
you
basically
open
apr.
Thank
us.
We
review
and
then
the
the
content
management
team
handles
the
the
publication
date
for
us,
markdown
or
markdown.
Okay,
great
markdown
images
are
totally
acceptable.
A
I'll,
send
you
a
an
exemplary
vr
that
I've
been
working
with
with
with
a
co-worker
of
mine
for,
for
crown
jobs
for
121
release?
Okay,
great!
Thank
you.
It's
great
today,
thanks
eddie,
oh
chris
kim,
actually
posted
a
an
example
vr
from
coreleas
about
crew.
A
Okay,
hearing
none
I'll
give
you
back
about
five
minutes
of
your
time.
Thank
you
very
much.
All
that
was
a
very
productive
meeting
today
and
it
was
as
usual,
nice
talking
to
you
all,
have
a
good
one.
Take
care!
Bye,
bye,
see
you
folks,
bye,
bye
thanks.