►
From YouTube: Kubernetes SIG CLI 20190424
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
welcome
to
the
another
six
CLI
meeting
today
is
April
24th
2019.
My
name
is
machi
and
I'll,
be
your
host
and
a
few
announcements
before
we
jump
to
the
main
topic.
So
the
most
important
day
that
is
approaching
within
less
than
a
week
is
the
enhancements
freeze,
which
is
April
30.
A
If
I
remember
correctly,
that's
next
Wednesday
of
next
Tuesday
actually
so
make
sure
that,
whenever
you're
working
on
a
new
feature
that
it
has
an
enhancement
issue
filled
in
and
the
enhancements
repo,
as
well
as
a
linked,
gratis
enhancements
proposal
with
it.
If
you
need
guidance
on
the
process,
feel
free
to
ping
me
or
Shawn,
and
we'll
be
more
than
happy
to
help
you
or
answer
your
questions
with
regards
to
the
asset
enhancements
flow.
A
So
that's
probably
the
only
announcement
that
I
had
so
far
the
test
grid,
so
I've
been
doing
the
test
and
call
for
the
past
two
weeks
as
well.
It
looks
like
there's
some
problem
with
GTE
related
tests.
I
need
to
have
a
closer
look
at
it.
I
started
looking
at
poking
at
it
earlier
today,
but
it
looks
like
a
bigger
issue.
A
I
think
we
Phi's
those
tests
not
sure
if
they
are
still,
they
still
make
sense
at
all
in
the
first
place,
so
I'll
have
a
I'll
be
looking
at
it
still
if
you're
interested
in
actually
taking
the
role
of
the
test
on
call
make
sure
to
sign
up
your
yourself
in
our
document,
I.
Remember
correctly,
Sean
agreed
to
do
the
next
round
of
call
off
on
call
so
Sean
you're
still
interested.
B
A
A
E
So,
basically
you
you
can
now
sit
since
the
version.
1.14
I
think
you
can
combine
cube
CTL
logs,
Flags,
L,
L
and
f.
So
basically,
following
by
label,
is
now
possible
in
my
pull
request.
I
amazing
thing
happened
while
working
on
the
feature
I
usually
introduce
bugs,
but
I
intentionally
introduced
another
feature.
E
Selector
by
label
and
see,
which
is
to
select
specific
container
from
a
code,
so
it
works
fine
it.
When
you
select
multiple
ports
with
the
container,
let's
say
container
one:
if
container
one
exists
in
all
of
the
ports,
you
select
it
it
will.
It
works
fine.
The
problem
begins
when
you
run
your
selector
matches,
the
multiple,
multiple
pods
and
you
say,
I
want
to
see
logs
from
container
but
hold
one,
for
example,
it
contains
container,
but
the
second
one
point
doesn't
have
container
to
currently
keep
city
loads.
Just
prints.
E
Keep
the
Bitcoin
behavior
the
same,
but
for
users
who
want
to
filter
some
filtering
by
container
rain.
We
just
add
a
new
flag
like
skip
mist,
containers
or
something
like
that,
and
another
option
is
to
skip
containers,
do
not
ignore
the
errors
by
default
and
add
a
flag
to
error
when
the
container
is
missing
to
basically
be
opposite
I'm
in
favor
the
of
the
first
option
when
we
add
extra
flag
to
ignore
errors,
but
yeah
I'm
I'm,
probably
not
the
person
to
make
this
call
so
I.
F
So
I
guess
I
can
win
I.
Think
if
you
know,
if
you
agree
so
earlier,
I
think
a
few
weeks
ago,
I
made
up
your
introducing
and
ignore
errors
flag
to
the
logged
command.
So
maybe
we
could
leverage
that
flag
to
also
ignore
errors.
When
you
know
multiple
pause
are
matched
and
a
container
is
also
specified,
but
it's
not
found
on
one
or
more
pods.
So
if
you
have
ignored
errors
on
it
could
just
implicitly
ignore
errors
for
those
pods,
and
then
we
could
also
introduce
an
additional
flag.
F
A
A
So
I
would
keep
the
current
ignore
error,
as
is
without
touching
anything.
The
fact
that
we
are
currently
allowing.
A
A
E
Yes,
it
was
released
in
114,
but
it's
not
documented
anywhere
or
not
mention
it.
So
it's
like
undocumented
feature,
I
would
probably
not
even
bother
producing
warning,
but
I
think
I
can
totally
see
use
cases
for
this.
For
example,
you
might
want
to
look
for
your
logs
from
all
initial
containers
and
you
don't
care
if
some
ports
do
not
have
initial
containers.
I
can
totally
understand
users
demanding
this
feature
and
I
think
those
use
cases
are
valid,
so
I
would
suggest
that
we
introduce
this
feature,
but
we
allow
explicitly
ignore
missing
pods.
So
from
my.
A
Experience,
it
is
always
easier
to
add
features
then
to
maintain
them
further
down
the
road.
If
I'm
gonna
see
a
specific
use
case,
a
user
complaining
about
the
lack
of
that
particular
feature,
then
I'll
be
open
to
to
adding
that
this
behavior.
Until
then,
I
would
rather,
we
don't
come
up
with
possibilities
for
for
use
cases,
because
I
trust
me
I
can
come
up
with
every
with
with
so
many
weird
use
cases,
but
I
would.
A
A
So
the
API
is
there,
people
can
always
change
it.
This
makes
the
code
much
simpler,
I'm
still
in
the
process
of
fixing
some
of
the
old
issues
in
cube
CTL,
where
and
I'm
I'm
gonna
be
I'm.
Gonna
admit
that
I
feel
guilty
of
admitting.
Some
small
patches
that
are
currently
very
hard
to
me
came
because
of
consequences
that
they
introduced
by
adding
some
additional
feature
that
will
that
allow
expects
or
or
why
so,
for
that
reason,
I
would
prefer.
A
We
stick
with
simple
cases
that
are
strong
and
they're,
always
working,
and
going
back
to
to
the
fact
that
you
mentioned
that
this
is
an
odd
documented
feature,
even
if
it
is
not
documented.
The
fact
that
it
appears
in
cubes
ETL
logs
help
makes
it
a
documented
feature,
so
there
will
be
users
that
are
actually,
let's
start
actually
using
it.
For
that
purpose,
we
cannot
break
them
from
release
to
release.
We
need
to
go
through
through
the
middle
ground
of
warning.
A
A
In
our
case,
the
API
is
the
flags
are
the
commands,
unless
we
explicitly
set
that
this
is
an
experimental
flag
where,
where
we
literally
by
saying
experimental
next
to
the
flag
description,
then
we
can
break
that's
the
only
case
when
we
can
break,
because
we
clearly
state
that
this
is
an
experimental
flag
and
that
this
will
be
changing
over
from
release
to
release.
In
all
other
cases,
we
need
to
ensure
we
can't
break
people
from
release
to
release.
Does
that
make
sense?
Yeah.
E
It
makes
perfect
sense.
I
want
to
clarify
something
about
making
users
complain
about
a
lack
of
this
feature.
If
you,
the
initial
issue,
which
requests
this
combination
of
those
three
flags,
it
seems
to
be
quite
popular
request.
Do
you
what
do
you
suggest
we
introduce
this
warning
and
close
this
issue
and
see
if
it
comes
up
again
as
a
separate
issue,
or
how
do
we
go
do
this
with
this
existing
issue?.
A
E
A
B
B
So
so
yeah,
it's
it's
pretty
straightforward,
and
following
this,
when
we,
when
we
do
start
to
move
coop,
coop
control
completely
out,
we
have
several
other
issues
that
we'll
have
to
address
in
a
different
cap
having
to
do
with
what
are
we
going
to
do
with
versioning?
What
are
we
going
to
do
with
releasing?
What
are
we
going
to
do
with
testing
those?
We
didn't
want
to
open
up
a
Pandora's
box
in
order
to
get
this
part
plate.
So
this
is
just
you
know,
moving
this
particular
directory
under
staging.
B
A
B
C
A
Let's
set
it
out,
this
is
an
important
topic
that
will
literally
touch
every
single
developer.
Touching
kubernetes
Rico
I'm
gonna
tag
that
the
PR
either
way
after
the
meeting,
but
we
need
to
ensure
that
the
entire
communities
community
is
were
that
we
are.
We
are
actually
doing
this
move
so
that
nobody
is
surprised
when
he
sees
the
arse
moving
cubes
you
deal
over
to
the
staging
group.
Oh
got
it
cool
thanks
very
much
so.
B
A
A
G
G
A
Yeah
I
just
pasted
the
link
I
have
to
link
open
I'm,
hoping
to
have
a
look
at
it
either
later
today
or
at
latest
tomorrow,
but
on
the
first
day
I.
Don't
have
any
objection
to
merging
it.
I'm
aware
that
this
will
be
a
moving
target,
since
this
is
a
first
that
the
dynamic
it's
awesome
work
thanks,
Phil
and
Shawn
for
putting
this
thing
together
here.
A
A
Okay,
in
that
case,
let's
quickly
go
over
to
stand.
Ups
and
well.
Shawn
keeps
ETL
independence
and
the
progress
that
we
have
yeah.
B
So
that's
a
I
guess
the
previous
discussion
was
a
good
transition.
The
one
about
the
cap,
so
there's
three
areas,
three
more
difficult
areas
that
remain
in
order
to
dependencies
that
need
to
be
addressed
before
we
can
move
into
staging
and
I'll
just
give
a
quick
update
on
those
three
areas
so
converts
we
deprecated
it
back
in
113.
B
We
won't
be
able
to
completely
deprecated
it
to
117.
It
sounds
like
we
intend
to
make
coop
cuddle
converts
a
plugin
to
continue
the
functionality.
I
haven't
done.
The
the
I
haven't
made
any
progress
on
the
convert
plug
in
front.
The
second
front
is
printing
with
basically
the
human.
What's
called
the
human
readable
go
the
human
readable
printer,
so
I
had
a
PR
in
order
to
pull
that
functionality
out
of
kubernetes
core,
but
Jordan
pointed
out
that
some
of
the
functionality
is
server-side
and
some
is
client
side.
B
B
It
may
be
that
we
have
to
wait
until
116
in
order
to
get
the
client
side
we're
splitting
it.
So
we
could
get
the
client
side
printing
out
of
kubernetes
core.
We
may
have
to
wait
till
116
for
that
and
then
the
final
part
is
for
coop
control,
auth
reconcile,
which
is
that
which
depends
on
our
back
code
a
significant
amount
of
our
back
code,
which
is
in
kubernetes
core
and
the
answer
to
that,
after
we've
tried.
Different
avenues
is
to
pull
the
basically
all
of
that
common.
B
Our
back
code
into
its
own
repository
Jordan,
said
Jordan
Leggett
said
he
was
going
to
create
a
start
of
the
process
to
create
an
are
back
repo
and
I'm,
not
sure
exactly
where
that
stands
now.
But
those
are
the
three
areas
the
these
are
all
very
sticky
area,
sticky
points,
so
we've
we've
removed
probably
over
a
hundred
core
dependencies
and
we
have
a
about
seven
or
eight
left,
and
these
last
few
are
going
to
be
problematic
and
require
a
significant
amount
of
of
work
or
and/or
waiting
for
deprecations
to
happen.
D
D
D
Thanks,
okay,
so
so
we
yeah
so
I,
think
in
in
in
the
near
future,
beyond
learning
the
ropes
of
process
of
managing
the
processes
and
all
that
our
first.
Our
first
goal
is
really
stability,
so
showing
you
briefly,
we
have
here's
our
repo,
so
you
know,
but
as
part
of
that
learning
the
ropes
and
all
that
it's
very
on
how
we
wear
without
how
we
should
move
it,
what
the
steps
need
to
be,
who
should
be
doing
the
diligence
in
terms
of
you
know,
looking
over
to
make
sure
we're
meeting
the
minimum
requirements?
All
that?
D
That's
definitely
your
first
first
part
of
all
that
of
getting
the
ball
rolling
here,
but
in
addition,
just
on
our
own
front,
we
have
some
some
cleanup
work
that
still
needs
to
be
done.
As
you
can
see
there,
we
have
so
it's
a
typescript
project.
We
have
reasonable
typed
type
coverage
for
the
core
elements,
but
next
few
days
the
goal
is
to
really
bring
this
much
higher
is
75%
number
much
higher.
So
that's
this
gold,
like
that
or
really
are
on
your
term
goals.
We
we
know,
there's
my
priority.
D
Bugs
need
to
be
need
to
be
addressed,
and
one
of
the
main
things
we'd
like
to
have
is
just
to
give
a
sense
of
philosophy
in
motion
here
to
the
project
is
to.
If
we
can
auto
generate
a
table
which
gives
us
all
a
sense
of
our
coverage
or
test
coverage
and
future
coverage
of
the
coop
cuttle
commands.
If
you
have
any
pointers
there,
I
mean
I
would
love
to
be
able
to
auto-generate
at
8:00.
D
You
know
a
table
matrix,
which
shows
the
tests
we've
run
on
various
features,
whether
the
weather
is
supported
in
browser
mode
versus
standalone
mode,
and
all
that
do
you
have
any.
If
you
have
any
pointers
there,
we
can
take
this
offline,
but
I
thought
we
could
actually
think
about
auto-generating
such
tables.
So
we
can
track.
You
know
coop
Coto
releases
versus
Kui
coverage
and
then,
lastly,
for
the
first,
the
first
rung
all
this
is
approved,
documentation
just
for
both
Kui
devs,
but
also
for
two
users.
D
We
have
content
here,
but
I
think
we
need
some
more
and
then
once
we've
sort
of
you
know
gotten
throughout
the
grabber
call
really
stable
and
solid
and
all
the
process
management
stuff
in
place.
Then
we
can
think
I'm
moving
on
to
the
next
rung.
I
think
this
is
very
much
where
we
want
to
open
it
up.
You
know
to
everyone,
they
should
be
adding.
You
know
there.
Does
it
our
audit
to
this
list.
We
have
some
ideas
in
mind.
The
ophea's
code
has
a
terminal.
D
D
A
D
A
So
if
you
have
the
IBM
agreement,
then
the
next
step
would
be
to
to
create
an
issue
if
I
remember
correctly,
orcs
but
augment
you.
He
might
be
a
better
person
to
to
answer
that.
The
question
and
then
folks
from
sig
release
will
have
a
look
at
your
repo
because,
as
one
of
the
requirements
is
that
all
of
the
contributors
to
your
repository
has
to
have
CN
CF.
A
From
then
on,
it
will
be
an
actual
move
of
the
repo
under
the
current
e6,
that's
more
or
less.
In
short,
how
the
process
works.
I'm,
pretty
sure
that
Ahmed,
since
he,
like
literally,
went
through
the
entire
process
of
moving
crew
from
other
Google
cloud
platform
or
over
226,
will
be
best
person
to
ask
and
and
and
provide
you
with
guidance
over
the
over
the
steps.
I
know
that
well
Phil
and
I.
We
were
and
Shawn.
A
B
B
B
F
G
I
guess
I
just
add
something
to
that
which
is
with
crew.
We've
been
working
on
plug-ins
for
year,
maybe
one
or
two
years,
and
the
distribution
like
the
installation
and
stuff
is
something
that
I
think
he
wanted
to
have
a
clean
solution
for
and
fit
within
the
scope
of
the
problem.
We
were
trying
to
tackle
with
the
plugin
work,
and
so
it
had
been.
G
Developing
it,
and
at
least
talking
to
me
a
bit
as
he
was
doing
so
and
showing
demos,
and
so
it
made
sense,
certainly
from
a
scope
perspective
to
say
this
project
is
essentially
completed,
work
that
it
was
kind
of
something
we
wanted
to
have
anyway,
and
it's
written
in
go
in
a
similar
style
to
I
think
it
is
written
and
go
right.
I
thought.
G
G
G
Not
something
that
we
had
already
been
driving
and
so
I,
don't
think
we'd
be
capable
of
picking
cuy
up
and
continuing
to
drive
it
forward
without
without
you
all,
and
so.
For
that
reason,
I
think
it
makes
sense,
certainly
to
say
like
okay
well,
since
you
guys
are
going
to
be
fully
essentially
responsible
for
this.
G
We
have,
as
a
sake
towards
the
sub-project
before
accepting
it,
and
so
you
know
kind
of
roughly
I
think
what
Sean
and
I
and
had
kind
of
brainstormed
around
was
like
okay,
like
what
does
the
road
map
look
like
this,
and
are
we
on
kind
of
the
same
page
and
are
we
helping
drive
it
appropriately
in
that
stuff?
So.
A
A
We
don't
have
any
official
test
coverage
table
per
se.
We
used
to
be
updating
a
spreadsheet
from
the
go
test
coverage,
but
other
than
that
we
don't
have
anything,
maybe
as
part
of
the
CI,
that
is
around
grantees
grantees,
because
there
is
information
but
I,
don't
think
that
they
are
reporting
or
maintaining
information
about.
A
Coverage
for
specific
packages
well,
currently,
each
package
is
a
separate
command
so
that
transitions
nicely
to
test
coverage
against
commands.
Also,
aside
from
unit
tests,
some
commands,
or
hopefully
majority
of
commands,
has
a
set
of
bash
tests
and
on
top
of
that
only
small
amount,
but
still
we'll
have
a
full-blown
e
E
coverage.
But
that
depends
on
how
much
it
is
testable
on
each
stage,
because
units
are
very
super
limited.
A
The
the
test
command
framework
that
we
have
sets
of
a
gratis
cluster,
but
only
with
a
control
plane,
but
there's
no
couplet
running
underneath
it,
which
basically
means
we
can
verify,
commands
only
to
a
point
where
you
don't
have
to
have
a
running
pod.
So
all
the
operation
shuts
our
labeling
annotation
and
all
that
our
creations
they
are
tested
in
that
command.
A
D
A
A
H
I'm
Jin
from
I'm
working
on
customized
I
would
like
to
give
a
quick
update
on
customized.
So
several
weeks
ago,
I
feel
presented
the
cap
of
generator
and
transformer
plug-ins
that
we
plan
to
support
and
customized.
So
Jeff
and
I
have
been
working
on
that
for
these
weeks
and
basically
those
features
available
and
those
are
will
be
from
the
Hat.
So
what
they
support
is
that
you
can
write
your
own.
H
That
is
either
a
scope,
plugins
or
any
accessible
using
any
language
you
like,
and
you
put
them
in
the
specific
path
and
we
all
run
customize.
You
say:
I
want
to
enable
using
go,
plugins
I
want
to
enable
generator
transformers
and
then
customize
will
look
for
whatever
plugins
you
specify
in
your
customization
and
then
look
for
that
executable
in
the
in
the
past.
If
they
can't
find
stop
suckin,
it
will
run
it
and
know
the
output
as
the
resources
so
very
technical
usages.
H
You
can
write
your
own
plug-in
to
download
helm
cuts
and
render
home
charts
and
the
output
will
be
accepted
at
all
consumed
by
customize,
so
it
can
construct
to
the
rest
map
from
it
and
can
perform
its
whatever
transformation.
Customized
can
provide
so
right
now
we
are
about
to
release
a
new
version
of
customize
and
before
we
have
that
release
we'd
like
to
work
on
our
documentation.
H
So
we
like
to
provide
adequate
examples
and
documents
to
explain
how
this
works
and
how
it
can
best
work
best
for
you,
and
we
also
like
to
have
a
high
quality
on
those
Doc's,
so
that
when
we
render
customized
into
cube
control,
we
can
reuse
those
Doc's.
So
we,
if
anyone
is
interested
in
contributing
to
Docs,
please
let
either
Jeff
or
me
we
can
help
you
get
familiar
with
the
feature,
so
we
can
write
very
nice
Doc's
together.
Thank
you.
Any
questions.