►
From YouTube: Kubernetes SIG CLI 20200226
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
February
26th,
not
March.
My
name
is
Margie
and
I'll,
be
your
host.
Today,
I
have
a
one
quick
announcement
before
we
jump
over
to
the
main
topics.
The
code
freeze
is
March
5th
from
what
I
was
checking
earlier
today,
which
basically
means
we
have
about
two
weeks
from
tomorrow
to
merge
our
fixes.
A
If
you
are
waiting
for
reviews
from
myself,
Shawn
or
anyone
from
the
sig
make
sure
to
ping
them
on
slack.
I
do
remember
that
I
owe
at
least
debug
and
events,
reviews
and
I'll
hope
to
get
it
get
to
this,
either
later
today
or
tomorrow,
but
make
sure
you
get
the
attention
of
the
people
that
are
responsible
for
your
reviews
so
that
we
can
gather
the
feedback
and
address
it
before
the
feature.
Freeze
gets
him
to
get
to
get
it.
It
is
effective.
Sorry
does
anyone
else,
have
any
other
announcements,
Shawn.
A
The
first
one
I'm
not
gonna,
open
the
links,
because
I'm
gonna
crappy
mobile
Internet,
so
it'll
take
ages
to
load
already,
but
the
gist
is
basically
that
if
we
do
cube
cuddle
describe
a
resource
not
always
but
oftentimes.
We
are
fetching
additional
information
for
resources.
In
that
particular
case
that
I
linked
here
it
was
about
services
and
endpoints
and
and
back
and
back
ends
as
well,
and
somebody
was
trying
to
figure
out
whether
we
should
be
putting
a
partial
errors,
which
basically
means
if
I'm
filling
in
the
describe.
A
For
a
particular
resource
and
I
failed
to,
for
example,
load
events
or
failed
to
load
some
partial
information
about
the
resource
so
far,
the
approach
that
we've
been
taking
is
we
will
just
print
nothing
in
that
place.
There
has
been
some
ideas
that
maybe
we
should
be
giving
some
information
about,
that.
We
encountered
error,
retrieving
that
additional
information,
so
instead
of
having
empty
value,
you'll
see
a
short
error
message
and
I
was
curious.
A
That
is,
that
is
exactly
what
it.
What
the
problem
is,
if
you
encounter
an
error
fetching.
The
additional
information,
like
the
simplest
use
case,
is
every
single
resource
that
we
described
has
events
attached
to
it.
You
do
if
we
fail
attack.
If
we
failed
retrieving
the
resources,
will
it
print
a
short
information?
Oh
I,
it
doesn't
mean
that
there
is
no
events,
but
it
means
that
there
was
an
issue
and
we
can
additionally
present
what
kind
of
information
currently
the
approach
that
we
are
taking
across
the
board.
A
C
You
know
I,
think
that
makes
sense
when
we
have
to
make
sure
that
there's
a
good
way
of
printing
the
information
for
one
of
these
partial
errors.
So
maybe
the
goal
should
be
that
if
the
information
is
optional,
then
each
individual
described
function
could
have
a
way
of
not
displaying
an
information
and
then
instead
displaying
in
the
air
in
its
place,
but
displaying
your
estimate
letting
some
of
the
information
write
is
going
to
be
not
optional
right.
C
If
you
fail
to
fetch
the
thing
you're
describing,
for
instance,
that
would
be
not
optional
and
then
I
guess
like
if
you're
describing
an
ode
and
you
fail
to
fetch
some
of
the
pods,
but
not
others.
For
instance,
do
you
do
you,
throw
an
error
and
show
none
of
the
like
summary
information
or
it?
It's
probably
there's
probably
gonna
be
a
lot
of
case-by-case
basis,
so,
like
it's
probably
gonna,
be
four
specific
ones
like
ingress.
A
B
A
That's
fair
I
guess
I
mean
there's
also
other
problem
that
is
somewhat
connected
with
this
describe.
Is
that
the
serve
in
the
current
way
when
we
print
the
resource,
you
might
get
information
about
difference
between
status
and
aspect,
and
that
is
coming
not
from
there
on
the
server.
But
the
fact
that
you
just
stumbled
upon
in
the
middle
of
the
reconciliation
loop
in
the
controller,
but
currently
the
way
we
print
the
resources.
We
don't
print
the
additional
information
that
your
current
state
does
not
reflect
reflect
the
spec
or
your
deployment.
A
Have
observed
generation
versus
the
generation
inside
of
the
spec
of
our
resource,
but
we
don't
expose
that
information
when
you
do
OC
get,
for
example
deployments.
So
you
might
stumble
upon
an
incorrect
state
of
the
resource
which
is
not
incorrect.
Is
that
you
don't
have
to
full
information
presented
correctly
and
the
get
described
and
get
description.
C
And
the
other
thing
we
can
do
is
the
two
examples
listed
seem
like
quick
read
of
them
is
that
it's
like
fixable,
something
about
annotations,
not
being
sorted
and
looking
through
them.
Some
of
the
comments
seems
like
the
code
could
be
fixed
to
not
encounter
this
error,
and
those
are
both.
The
two
issues
linked
are
the
same
one
though,
and
I'm
not
opposed
to
creating
the
partial
layers.
You
know
great,
essentially,
it's
better
error
handling,
but
we
can
also
just
fix,
maybe
that
it
might
be
possible
to
fix
the
one
I
mean.
A
C
A
A
D
D
Just
gonna
give
like
a
short
overview
of
this,
but
yeah
so
I'm
and
Cornelius
recently
approved
the
multi
index
feature
proposal.
It's
a
lot,
like
brute
app.
If
there
any
homebrew
users
out
there.
So
there's
a
lot
of
similarities.
There
I
won't
go
into
too
much
details
about
it.
If
anyone's
curious,
they
can
check
out
the
future
proposal.
E
You
wanna
be
one
of
the
great
things.
Is
that
the
way
we
currently
planned
it?
It
is
such
that
it
probably
can
be
done
without
any
user,
visible
migration.
So
it
can
happen
transparently
in
the
background,
so
fingers
crossed
that
nothing.
No
obstacle
comes
up
there,
but
if
it
works,
that
would
be
really
great.
E
And
yeah,
the
big
last
fear
is
that
I
mean
keep
centralizing.
The
index
means
that
the
may
no
longer
be
the
need
for
a
coup
index,
so
we
can
discuss
how
coup
index
should
continue
and
at
the
same
time,
it
gives
companies
a
lot
more
flexibility
to
use
crew
to
distribute
plugins
into
internal
plugins,
especially
because
they
can
well
basically
distribute
crew
with
a
custom
internal
index.
So
I
wish
only
provides
their
approved
plugins.
E
A
Cool
I
haven't
had
a
chance
to
look
through
the
proposal
itself,
I've
only
seen
short
days
or
the
issue
that
was
linked.
I
think
last
time.
A
A
A
C
Know
I've
been
and
I
should
probably
throw
another
link
in
there.
It's
good
I've
been
starting
to
triage
the
customized
TRS
into
a
project
where
it's
just
like.
We
can
keep
State
on.
What
are
we
considering?
What's
in
progress
and
what's
being
actively
reviewed,
and
this
is
one
of
the
PRS-
was
for
essentially
having
per
per
generated
object
options.
So
customized
has
the
ability
to
define
generator
options
like
these?
C
C
Isn't
that
it's
not
breaking?
It's
just
it's
a
small
increase
in
API
service
area,
so.
F
C
C
C
All
right
looks
like
chance,
dropped
out,
I'll,
try
and
fill
the
dam
and
then,
if,
if
we're
able
to
get
chance
back
on
and
I'll,
let
them
speak
for
themselves.
But
the
reason
that
I
think
this
makes
sense
is
that
the
the
need
to
apply
different
annotations
are
different
labels.
Different
config,
Maps
I
think
we
all
is
not
particularly
controversial,
Jing
Fung,
mm-hmm
I.
Think
your
point
was
that
it
is
possible
to
achieve
this
and
result
in
customized
today
by
creating
say
to
customization
files
with
different
generator
options.
C
Yes
right
so
I
may
not
have
those
composed
rate
and-
and
my
argument
against
that
is-
it
really
increases
the
complexity.
Like
imagine
the
case
where
you
want
to
generate
six
config,
Maps
or
secrets
in
each
has
an
annotation
that
describes
something
about
it
right
like
it's
the
reason
it
is
generated
or
something
like
that.
That
would
seem
reasonable
right,
okay
and
so
the
approach
today
is.
C
You
would
have
to
create
seven
customization
files
in
like
seven
different
directories
right,
so
you
have
to
create
seven
directories
with
seven
customization
files
and
then
to
get
that
to
achieve
that
right,
as
opposed
to
just
having
seven
lines
in
a
single
file,
and
that
seems
like
not
a
desirable
representation
of
that
data.
To
me.
F
C
Level,
one
I
don't
think
we
should
ever
hate
them,
I
mean
we
have
examples,
so
I
think
we
have
patches
that
can
be
applied
to
multiple
resources.
Now
right,
yes,
right
so
I
think
of
it,
this
kind
of
along
the
same
lines
like,
should
we
deprecate
having
patches
that
only
apply
to
one
resource?
No,
like
that
makes
sense,
should
we
deprecate
having
patches
that
apply
to
multiple
resources,
no
I
think
that
makes
sense
too.
Okay,.
F
F
A
C
A
Have
an
option
to
specify
this
I
mean
specify
what
type
of
it
whether
it's
a
union
or
do
not
apply
global
in
case
your
variety
resource
or
yet
something
like
that
I
mean
over
I,
could
I
could
see
it
over
right
by
default
means
something
with
per
resource,
will
take
over
always
proceedings
over
at
the
global
ones.
So,
if
you're
setting
the
same
annotation
in
both
the
ones
from
per
resource
would
keep
would
take
precedence.
C
A
C
Awesome,
okay,
so
it
sounds
like
we
have
consensus
here:
I'll
send
an
email
out
to
the
six
CLI
list
just
to
capture
a
slightly
wider
net,
but
we've
discussed
this
here
and
have
the
PR
out
and
that
there
aren't
seem
to
be
any
injections
with
the
intention
or
concept.
But
we
would
like
to
nail
down
a
couple
of
the
implementation
details.
A
A
A
E
Okay,
thanks
yeah,
so
the
first
item,
I
move,
I
moved
down
from
the
topics
because
it's
actually
already
reviewed
so
but
I
was
just
want
to
mention
what
it's
about.
So
we
added
a
new
section
for
an
cubicle,
plug-ins
and
crew
in
the
get
booked
for
cube,
Caudill
and
also
a
short
notice
in
the
cue
card
like
in
command,
how
to
best
discover
and
work
with
plugins,
meaning
appointed
where
and
so
Kru,
basically
and
yeah.
E
How
many
and
I
plan
to
do
a
a
small
block
series
about
crew
on
the
Cornelius
blog
in
the
member,
the
main
block
and
the
first
one
of
those
has
been
sitting
ready,
basically
from
our
side
for
a
while.
Now
it's
been
language
reviewed,
but
none
of
the
technical
people
I
have
to
had
a
look
at
it.
So
I
just
wanted
to
know.
If
there's,
how
should
I
raise
attention
to
this?
Is
there
a
process.
A
C
C
A
C
D
A
A
E
E
Why
are
the
github
API
to
see
if
a
new
version
of
crew
is
available
so
because
we
found
out
that
many
people
are
using
quite
o
old
versions
of
crew
and
probably
also
of
all
the
other
plugins,
and
that
way
we
can
maybe
make
encourage
them
more
to
update
crew
more
regularly
and
with
that
all
the
other
plugins
and
yeah?
Finally,
we
are
also
on
slack
now
so
I
should
like
crew.
If
you
want
to
join
everybody's,
welcome.
A
I
Nick
Haven
yeah,
so
we've
our
big
goal
for
this
first
part
of
the
year
has
been
stabilizing
the
foundation
Docs
and
all
that,
and
so
for
the
past
two
weeks,
we've
been
shifting
a
lot
of
bespoke
HTML
code
over
to
react
componentry
and
that
work
will
be
done
by
the
end
of
today
and
when
that's
done,
we'll,
hopefully
be
able
to
lock
down
from
a
developer
perspective.
A
Okay
from
from
myself,
I'm
planning
to
putting
on
I
have
almost
ready
PR,
which
is
the
follow-up
to
removing
cube
cut
off
from
generators.
I
had
a
PR,
almost
ready
that
will
greet,
moved
and
deprecated
the
generators
flag
with
them
to
create
commands
on
a
simplified,
the
create
as
well
in
the
long
run.
A
I
still
have
the
amount
of
the
another
one
clean
the
directory
structure,
but
that
got
stuck
a
little
bit
over
the
past
couple
of
weeks,
I'm
hoping
to
return
to
this
one,
either
this
week
or
the
next
one
of
those
probably
Shawn.
Can
you
give
us
an
update
on
the
of
the
split
and
I'll?
Have
some
follow
up
for
you
with
some?
Maybe
good.
A
So,
with
with
regards
to
Arabic
I
was
talking
with
Sega's
earlier
today
there
is
a
chance,
but
I'm,
not
I,
can't
say
how
how
probable
it'll
happen
over
the
next
couple
of
days
or
weeks
that
the
sick
earth
will
be
able
to
help
us
with
letting
up
the
shirt
shared
items
between
Q
cuddle
and
API
server.
That
are
our
back
specific
that
are
blocking
us.
So,
if
and
I'm
crossing
my
fingers
hard.
B
The
so
that's
definitely
the
hardest
remaining
item.
The
convert
actually
should
be
straightforward
in
that
it's
just
going
to
be
an
extra
command
and
everything
for
the
convert
will
just
be
moved
under
that
command
all
or
that
that's
what
I
think
might
be
the
the
way
to
go,
but
actually
it
yeah
I,
don't
think
that
creating
a
binary
from
convert
is
going
to
be
a
lot
of
work.
Do
there's.
B
G
A
G
Yeah,
it's
definitely
in
right
now,
but
I
can
see
the
like
the
desire
to
be
able
to
do
both
I
think.
That
would
probably
require
like
a
bigger
discussion
since
I
think
like
overriding
makes
like
a
bit
well,
I
was
gonna
say
we
would
make
it
a
little
bit
more
complicated
from
just
like
understanding
but
I
I.
Guess
it's
no
more
complicated
than
merge
and
understanding
it
I
think
I
think
that
would
make
sense,
I
think.
A
There
are
three
cases
one
is
also
right.
The
other
one
is
Union,
which
is
override
is
a
sort
of
Union
kind
of
right.
The
third
one
is
I
want
to
apply.
Only
the
the
ones
per
resource.
Do
not
the
global
ones
right,
I
think
it
would
be
worthy
and
from
what
we're
talking
with
fill
will
be
warranty
to
figure
out
whether
this
is
a.
This
kind
of
approach
is
feasible.
A
C
To
describing
is
simply
a
superset
of
the
existing
API
and
it's
always
easy
to
extend
the
API
but
harder
to
change
it
once
you've
created
it
or
restrict
it.
Does
it
make
sense
just
to
take
the
PR
as
is,
and
then
create
a
follow-up
issue
for
figuring
out
exactly
what
that
part
of
the
API
would
look
like
and
what
the
options
are
that.
G
Personally
that
we
do
that's
to
both
we're,
like
you,
have
an
annotation
set
on
all
your
config
maps
and
then
one
of
your
config
maps
just
needs
a
different
one,
more
annotation,
but
that
none
of
the
other
ones
need.
But
I
think
we
could
discuss
that
in
the
PR,
and
that
sounds
reasonable
to
me.
Yeah.
G
And
I
wasn't
sure
if
it
I
I
heard
somebody
asking
while
I
was
on
the
road.
If
there
was
like
a
use
case
in
mind,
I
think
I
described
that
in
the
mr
or
the
requests
as
well
and
I'd
be
glad
to
go
over
that,
if
you
guys
want,
but
can
totally
do
it
outside
of
this
context,
if
it
makes
sense
outside
of
the
meeting
I.
G
C
G
C
G
C
A
A
If
the
initial
PR
will
be
always
merged,
which
is
what
I
would
imagine
being
the
default
in
the
long
run
then
follow
up
with
you
know,
the
extended
options
is
perfectly
fine,
like
Chen
said,
making
sure
that
the
default
that
we
pick
in
the
long
run
is
the
default
that
we
currently
have
implemented
and
then
follow
up
as
an
extension
mechanism.
Yeah,
that's
like
ideally
I,
would
say.
G
C
You
so
much
for
asking
that
question.
Oh
yeah
Doc's
are
important
document.
This
I
think
I.
Think
there's
like
the
way
like
probably
the
way
to
do.
It
is
add
an
example.
It
may
invoke
line
where
the
API
is
described
and
then
go
update,
that
I
think
we've
been
discussing
doing
some
Doc's
overhaul
and
customize
the
customized
site
and
so
just
doing
copying.
What
we
have
today
probably
makes
sense
and
I
can
send
you
someone
somewhere
cool,
sounds
perfect
thanks,
I.
A
H
I
was
wondering
if
there's
gonna
be
open
sourced,
but
I
realized
that
I
missed
the
demo
in-app
deliveries,
so
I
probably
need
to
go
ahead
and
catch
up
on
that,
even
though
the
video
isn't
uploaded
yet
and
I
was
also
wondering
if
it's
using
the
same,
get
ops
engine
that
are
go
workflows
and
flex,
or
recently
co-developed
and
relatedly
I'm,
trying
to
figure
out
how
to
come
up
with
an
install
for
our
our
suite
of
processes
when
we
have
different
things
that
are
like
of
a
global
nature
like
pod,
template,
specs
or
CR
DS,
and
how,
if
I,
have
two
deployments
in
two
different
namespaces?
H
F
App
control
is
not
open,
sourced
and
I.
Don't
think
it's
going
to
be
open
source
to
you.
If
you
want
to
try
it,
you
can
download
it
by
using
g-cloud
commands.
You
can
download
it
and
try
it
and
for
the
that's
the
engine
and
develop
a
cargo
or
some
other.
So
we
are
using
different
back-end
for
deploying
the
application
and
what
you
just
mentioned,
like
you,
have
another.
You
have
two
different
namespaces,
so
I've
controlled
different
namespaces
at
treated
as
different
environments.
A
A
A
A
A
Hearing
nothing.
Thank
you
very
much.
Folks.
Last
week
we
had
our
bug
scrub
if
you're
interested
in
what
it
looked
like,
there's
a
link
to
the
recording.
If
you
scroll
down
the
60,
live
meeting
a
little
bit
to
the
bottom,
we
will
be
doing
one
another
next
month,
big
thanks
to
Eddy
for
doing
those,
and
thank
you
very
much
for
today's
discussions.
That
was
very
fruitful
meeting
today.
So
have
a
good
one
and
get
the
code
merging
for
119
by
wait.