►
From YouTube: Kubernetes SIG CLI 20180829
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
So
welcome
everyone.
It's
sorry
for
not
recording
the
meeting.
We
are
having
some
technical
difficulties
with
zoom
today,
not
sure
I'm,
not
quite
sure.
What's
the
actual
problem,
I
know
that
I
for
myself
I
have
upgraded
the
latest
greatest
version,
which
is
currently
freezing
every
single
time.
I'm
trying
to
share
my
screen.
Ok,
quick
announcements
before
we
get
into
the
main
topics
is
that
we
are
now
officially
in
the
code
slash.
A
We
started
yesterday,
which
basically
means
that
only
high-severity
only
bugs
and
a
few
arts
that
were
approved
and
look
good
to
me
before
yesterday
can
lend
the
code
freeze
is
September
4th,
which
is
next
Tuesday
and
bar
for
getting
code
in
during
the
code.
Freeze
is
super
high,
which
basically
means
super
high,
very
issues
that
might
be
blocking
112
release
if
you
got
assigned
to
an
issue
that
is
such
a
bug,
please
handle
those
as
soon
as
possible.
A
Oh
and
one
last
third
announcement
is
that
we
are
going
to
change
the
zoom
number
for
the
60i
meeting
and
everything
everything
goes
well.
We
will
do
that
and
within
the
next
week,
so
you'll
should
get
a
calendar
update
with
a
new
number.
So
please
check
the
calendar.
The
calendar
invite
for
the
new
number
for
security
reasons
and
problems
with
malicious
users
are
joining
our
slacks
and
and.
A
A
Next
topic
on
the
agenda
is
a
test
grid.
I
thank
the
privilege
to
be
the
test
on
coal
for
the
past
weeks,
and
I
must
have
meant
that
for
the
past
weeks
the
queue
was
relatively
quiet.
I
haven't
seen
any
major
flakes
that
were
concerning,
or
problems
with
this
that
were
concerning
6ui
I
did
updated
the
the
test
coverage.
A
A
So
what
is
important
is
that
I
updated
the
instructions
likely
a
little
bit
because
as
part
of
the
work-
and
we
will
be
talking
a
little
bit
further
during
Stan-
that's
about
it.
We
moved
part
of
the
CLI
stuff
to
a
separate
repo
which
lives
in
the
staging
repository.
So
at
the
bottom
there
will
be
a
separate
section
for
the
CLI
runtime
repository
that
will
be,
and
yes
and
the
instructions
are
talking
about.
Running
tests
for
package
keeps
ETL
and
for
staging
source
tubes,
kate's
CLR
a
CLI.
A
B
So
this
should
be
short:
we've
been
bringing
up
the
six
ela
charter
for
for
several
meetings
now
and
the
steering
committee
finally
got
around
to
it.
We
actually
had
to
rebase
it
on,
since
they
had
a
common
template
that
that
was
greatly
simplified.
So
we
re
based
it
on
this
common
template
and
we
had
actually
let
me
bring
it
up
here,
real
quick
there
there's.
Actually
you
know
it's
pretty
short:
it's
that's
it.
This
is
just
one
page
of
our
charter.
B
Basically,
two
changes
to
the
SiC
governance
was,
is
that
we
had
sig
emeritus
leads,
which
I
think
we're
proposing
Tony
and
Fabio
there
I
don't
think
they're
currently
defined
as
those
roles,
but
that's
what
we're
will
be
implementing
shortly
and
then
the
other
important
change
is
the
test
health
maintainer
role,
which
is
a
member
of
a
sixty
line.
Member
and
it's
somebody
who
does
basically
one
of
these
rotations
in
the
for
you
know
two-week
test
health
maintainer.
That
person
will
be
a
sick,
CLI
member,
if
they've.
A
Think
what
it's
very
important
also
that
happened
during
writing
this
sake
charter-
is
that
we
modified
and
split
the
roles
of
technical
means
and
leaves
for
this
sick.
Currently,
there
are
two
technical
leads
for
sick
CLI,
which
is
myself
and
fill
it
with
drunk.
As
for
the
leads
which
are
responsible
for
organizing
the
meetings
and
taking
care
of
the
sick
in
general,
from
the
organizational
perspective
that
will
be
myself
again
and
and
Shawn
Sullivan,
so
that
is
very
important.
A
I
have
also
noticed
that,
since
one
and
I
we
pushed
together
yeah
the
CLI
runtime
and
the
samples
you
like
playing,
which
we'll
talk
about
shortly.
I
think
I
need
to
update
the
Charter
to
mention
these
two
explicitly
as
they
are
our
responsibility
now
and
they
are
and
they
imagine
hopefully,
when
I
get
an
approval
from
sick
architecture,
they
will
be
synced
to
a
separate
repositories
and
their
critics
organization.
A
C
So,
with
regards
to
sorting
currently,
we
do
not
support
sorting
in
tandem
with
server-side
printing.
So
what
that
means
is
whenever
someone
like,
whenever
a
user
executes
to
control,
get
with
a
sort
by
flag,
we
are
essentially
defaulting
back
to
the
old
behavior
of
using
baked,
invites
in
queue
control
so
rather
than
you
know,
taking
advantage
of
a
table
response
from
the
server
and
then
using
that
to
print
human
readable
results.
We
are
essentially
still
depending
on
internal
for
now
into
our
internal
versions
of
objects.
C
In
order
to
basically
know
what
fields
belong
to
a
certain
object
and
sort
by
that
field,
I
have
a
PR
open
and
that
attempts
to
solve
some.
What's
all
this,
it's
sort
of
a
hoping
it's
a
draft
for
now
that
we
can
improve
upon
in
the
near
future.
I'm
posting
a
link
to
the
chat
I
mean
just
behind
us
PR,
is
that,
unlike
the
old
behavior
of
get
with
table
sorting,
we
were
not
getting
a
flattened
list
of
resources,
but
rather
for
each
resource
group.
C
We're
getting
one
table
object
so
because
of
this,
but
we
can't
really
sort
how
we
used
to.
So.
You
know,
given
ten
objects,
each
of
those
objects
could
now
contain
it
say
n
number
of
rows,
for
you
know
the
amount
of
that
type
of
resource
that
exists
on
the
server
and
so,
instead
of
sorting
the
ten
objects
we
get,
we
essentially
have
to
you
know:
iterate
through
each
table,
object
and
sort
each
row,
and
so
what
this
PR
is
saying
is
it's
essentially
sorting
all
of
the
rows
on
one
table
object.
C
C
C
A
Think
what
it's
also
important
to
note
is
that
about
a
week
ago,
I
sent
a
proposal
to
both
Coverity
staff
and
sixty
like
mailing
lists,
with
an
option
to
is
hardly
duplicate,
the
sort
by
auction,
which
was
rejected
by
both
Brandon
and
Clayton,
because
they
are
saying
that
the
M
of
the
sorting
is
is
highly
required
and
very
desirable
feature.
So
we've
noted
and
I've
noted
in
the
email
several
problems.
A
A
So
from
the
discussion
that
we
had
both
of
the
PR
and
on
slack,
we
agreed
that,
for
when
you
are
requesting
sorting
sort
of
resources,
we
are
going
to
disable
the
chunking
to
ensure
that
we
are
not
returning
false
positive
in
any
way
when
sorting
resources,
because
obviously
we
could
test
sorting
with
smaller
amount
of
data
and
then
request
and
a
script.
A
bigger
chunk
of
data
and
get
an
unexpected
result.
A
So
for
that
reason,
and
we
because
earlier
we
considered
for
a
bit
a
warning
that
a
bigger
amount
that
may
might
be
causing
these
problems
and
explicitly
asking
user
to
set
the
the
chalk
size
to
a
unlimited,
which
is
possible
with
a
cube
CTO
flag.
But
all
in
all,
we
decided
that
we
will
just
disable
chunking
whenever
a
sorting
is
requested
other
than
that
I
I've,
looked
through
on
the
VR
that
who
one
had
in
in
place
and
it
looks,
looks
reasonably.
A
B
A
B
A
The
best
place
will
just
appricate
this
functionality
and
after
some
time
we
will
entirely
remove
the
printing
mechanism
from
keep
CTO
so
that
it
will
only
rely
on
the
server-side
returned
data
and
the
main
reason
for
going
this
direction
is
that
the
server-side
printing
does
not
require
QC
do
to
know
the
exact
types
it
is
printing,
because
the
server
is
providing
the
actual
data
about
the
resources
and
how
they
should
be
printed.
This
allows
for
either
aggregated
API
servers
or
CR
these
to
be
printed
in
a
consistent
way
as
the
building
types.
C
C
Looks
like
a
fun
part
in
common
I
guess,
improvements
were
given.
The
feature
is
what
was
initially
proposed
or
I'm,
restoring
a
chunk
that
enabled
which
is
just
having
the
client
collect.
All
data
humans
were
disabling
it
all
together
or
using
temporary
I,
wasn't
even
if
I
think
that
the
other
part
of
this
topic
was
sort
of
second
thing,
and
so
like
much
you
mentioned,
it
is
applied
to
linear
t-shirts,
entirely
reliable
instrument.
If
anything,
there's
no
fallback.
C
C
A
What
you
need
to
define
is
something
that
is
called
additional
printer
calls,
which
is
basically
button
part
of
the
first
yum
definition
by
default.
If
you
don't
specify
the
additional
printer
columns,
the
server
is
configured
in
such
a
way
that
it
will
return
the
name
of
your
CRD
resource
and
the
creation
time
step.
If
you
do
specify
additional
printer
columns,
we
only
inject
the
name
by
default
and
the
rest
is
coming
from
from
that
additional
printer
columns
definition.
A
Oh
Y,
which
returns
additional
calls
which
are
not
presented
when
doing
server-side
print
and
I.
Had
a
discussion
with
Clayton
with
regards
to.
If
the
priority
currently
is
an
integer
I
would
expect
that
client
decide
how
many
data
it
can
actually,
while
it
can
actually
insert
based
on
the
terminal
width.
Currently,
it's
a
binary
decision,
whatever
has
a
priority
of
zero,
will
be
printed.
A
Everything
else
is
just
left
out,
no
matter
if
it
will
be
the
priority
of
one
or
a
hundred,
it
will
always
be
omitted
when
not
printing
with
output
wide
so
and
we
had
a
discussion
with
Clayton
that
maybe
within
the
cube
CTL
get
mechanism
generally
within
the
keeps
you
do
printing,
we
should
be
considering
the
print
of
the
terminal
width
and
based
on
that.
We
will
be
behaving
differently
in
printing
the
data
differently.
A
With
for
a
call
aside
from
the
reasonable
change,
it
is
also
led
to
multiple
test
failures,
where
we
are
relying
on
the
width
of
the
minimum
width
of
the
output.
This
comes
handy
where,
for
example,
when
you
had
value
such
as
I,
don't
know
number
of
replicas
and
similar,
where
we
will
be
able
to
go
down
with
the
width
of
the
columns
that
are
returning
those
data.
C
So
I
guess
my
initial
thoughts
are
basically
what
would
be
the
complexity
of
of
having
the
clients
react
to
different
different
control
vessels,
so
I
guess
without
in
mind
how
expensive
would
be
to
maintain
for
how
complex
would
be
to
maintain
in
the
future.
What
we
do
is
just
forget,
or
would
just
be
something
that
you
know
implemented
forever.
It
meant
something
we
probably
made
first
generic
selections
with
respect
to
recommend
to
uniform
internal
it
and
then
also
I,
guess
I'm,
guessing
we're
providing
a
flag
as
well
to
just
dump
out
all
the
columns
regardless.
C
A
But
my
initial
take
into
this
would
be
rather
to
have
a
a
rather
generic
mechanism
that
could
be
reused
across
all
of
the
kip
CTO.
If
we
would
implemented
it,
it
would
be
a
seola
run.
Time
probably
help
her
see
that
pretty
much
every
command
or
plugin
could
reuse
their
functionality.
I'm,
not
sure
about
complexity
of
this
approach.
A
B
B
Print
command,
coop
cuddle,
get
pods,
there's
a
proposal,
yeah
change.
How
that
looks
now
the
Padre
Tina
skate
had
pretty
much
already
been
accepted.
That's
my
understanding.
This
proposal
is
how
are
we
going
to
surface
this
idea
of
a
readiness
gate
like
whether
will
will
surface
it,
and
you
know
what
that
surfacing
would
look
like.
Can
I
copy
this
and
put
this
down
into
the
one
of
the
topics
sure.
A
D
D
D
So
the
idea-
let
me
briefly
describe
I'd-
be
like
a
part
of
the
proposal
so
already
minutes
before
this
performance
over
the
pot.
Readiness
is
dictated
by
container
readiness.
So
if
all
the
containers
are
ready,
then
the
pot
is
ready
and
the
continuing
readiness
is
defined
by
readiness,
probe
and
also
tubular
internals.
So
the
pot
ready
was
first
performance
or
aims
to
add
expensing
to
like
allow
anal
feedback
into
the
plot
regulars.
So
the
API
works
like
this.
D
So
there
is
taught
readiness
gates
defined
in
the
pots
back
and
the
readiness
gates
are
pointing
to
are
specifying
the
condition,
types
and
third-party
components
and
use
patch
to
just
patch
the
con
status,
for
that
particular
condition.
So
cute
blood
will
evaluate
whether
the
conditions
are
true
or
false
to
decide
whether
the
pot
readiness
is
like
it's
ready
or
not.
Okay,
so
that's
the
basic
idea
of
the
proposal.
So
it's
essentially
this
expand
definition
of
pot
readiness
to
not
only
include
the
containers,
ready
and
also
the
conditions
are
specified
in
the
readiness
gates.
D
How
many
are
ready
and
like
referring
to
if
2
+,
2
/
2
is
already
then
that
this
part
is
ready
right,
but
with
this
already
plus
for
us
for
so
effectively.
This
is
that
this
does
not
like
fully
represent
whether
the
pot
is
ready
or
not,
because
there
is
a
readiness
gate
may
be
hidden
behind
like
in
the
pots
back.
So
when
user,
let's
say
in
some
kubernetes
Bitcoin
that
utilized
this
pod
ready
escape
feature
when
user
tried
to
debug.
D
B
D
Know
which
like
which
to
check
next
right,
they
some
people,
know
okay,
I
should
probably
check
the
endpoints
and
then
people
who
get
would
double
check
the
endpoints
and
see
okay,
the
endpoints
are
not
ready,
but
still
people
don't
know.
Why
is
it
not
ready
intuitively
unless
they
read
the
whole
already
plus
Russ
proposal?
So
this
this
doc
aims
to
capture
like
the
options
we
have
to
how
to
support
already,
plus
plus
in
cube
cuddle.
D
So
obviously
the
the
worst
case
is
that
we
don't
we
do
nothing.
We
just
keep
the
current
current
behavior
and
then
proposals
I,
hope,
I
capture,
most
of
like
the
options
we
have
so
yeah,
so
so
I'm
from
sick
network.
So
I'm,
not
a
UI,
UX
expert.
So
I
wanted
to
present
this
to
six
CLI
and
see
what
people
think
and
which
one
people
like.
D
So
this
is
up
to
the
community
to
decide
with
weather
like
which
column,
whether
we
add
a
column
to
like
Keuka,
don't
get
pods.
Obviously,
that's
quite
disruptive
like
as
Brian
already
pointed
out,
is
like
many
Docs
that
needs
to
be
yeah
needs
to
be
updated
to
her
to
reflect
this.
A
D
It's
already
the
main
mechanism
are
already
in
in
cubelet,
so
most
of
the
changes
are
in
cubelet
and
the
api
server,
so
the
changes
are
already
in
since
kubernetes
1.11,
so
the
kubernetes
111
is
already
in
most
of
the
mechanism,
and
then
it's
alpha
marquez
alpha
in
1.11
and
in
1.12.
We
just
switch
it
on
by
default
and
mark
it
as
beta
and
there's
not
much
change
in
1.12.
For
this
particular
feature
and
most
of
the
mechanism
is
already
in
place
in
1.11.
A
Based
on
the
comments
and
and
reading
the
dog
I'm
personally,
meaning
towards
the
second
approach,
where
we
would
leave
the
current
get
pods
as
is,
and
then
at
the
readiness
gate,
which
is
an
extended
feature
still
as
part
of
the
circle
to
wide
output,
which
means
by
default,
you
will
only
get
the
output
from
one
would
ask
for
extended
output
with
Oh
wide.
You
will
get
that
additional
information.
A
B
That
is
what
is
proposed
for
number
five,
exactly
what
you
said
just
just
so
we're
clear.
One
of
the
downsides
of
that
is
that,
once
these
readiness
gates
are
in
place,
the
default
output
is
going
to
show
that
it's
running
and
ready,
sometimes
when
the
readiness
gates
are
not
complete
and
not
ready,
and
so
instead,
if
you
have
to
do
the
Oh
wide,
it's
not
telling
you
in
a
default
manner.
What
is
the
true.
A
Condition
right,
but
it
also
the
readiness
gates
will
also
depend
on
what
is
being
specified
inside
of
your
pots
back,
if
you
don't
specify
anything
at
least
that's
my
own
setting,
if
you
didn't
specify
anything
as
your
readiness
gate,
there
will
be
no
additional
checks
from
the
readiness
gate
there
is.
It
means
they
won't
be
giving
you
any
additional
information
and,
from
my
understanding
this
is
not
a
required
field.
Your
basic
means
it
is
an
optional
functionality
which
is
not
required,
which
might
not
be
said,
which
basically
means
if
it's
not
required.
A
Only
that
it
does
make
sense
for
you
to
output
that
not
information
we
could.
We
couldn't.
Probably
that
is
a
good
middle
point
to
change
their
current
ready,
a
column
to
the
slightly
different
name,
to
express
the
difference
between
container
ready
and
the
readiness
gave,
but
still
I
would
go
for
the
readiness
gate
being
as
the
optional,
such
as
the
pod
readiness
specifically
spec
field
is
optional,
so.
B
B
For
that
particular
I
mean,
if
you
are
smart
enough
to
actually
do
the
oh,
why,
then,
you
would
know?
Oh
okay,
my
load
balancer
isn't
up
yet
that's
why
it's
not
getting
traffic
seems
like
there's
a
high
probability
of
confusion
unless
we
as
default
show
this.
This
extra
information
when
readiness
gates
are,
are
used
right.
A
What
will
be
the
output
off
well
obviously
contain
you
ready
listening
we're
talking
about
the
sample
pod,
which
is
to
pod.
The
readiness
will
be
always
already
column
will
always
hold
two
by
two
values.
What
will
be
the
value
of
readiness
gate?
That's
something
I
did
not
set
it,
which
means
it's
empty.
What
will
be
the
readiness
gate,
value.
E
B
A
A
I
would
rather
start
with
this
being
an
extended
column
and
as
we
see
that
the
community
is
reusing
this
over
and
over
again
and
they
are
requesting
this
field.
First
of
all,
this
is
promoted
to
GA
and,
as
we
see
that
does
require
this
field
to
be
present
by
default,
the
default
get
parts
output.
Then
we
can
consider
the
migration
from
extent
column
say
primary
column.
Let's
go
it
that
way.
Yeah.
D
A
A
A
I
would
have
a
look
at
what
we
have
and
based
on
that
I
would
try
to
come
up
with
a
name,
so
I
wasn't
sure
about
the
actual
naming,
but
it
does
make
sense
to
have
to
have
the
default
column
being
renamed
so
that
it
there
is
a
difference
between
the
container
ready
and
the
readiness
gate,
not
it.
That
is
a
fair
that
is
it
her.
E
D
A
A
D
A
The
most
important
thing,
I
think
that
we
have
from
our
side
is
that
we
managed
to
just
put
the
generic
CLI
options,
which
is
basically
a
set
of
toolkit
for
building
CLI
plugins
into
a
separate
repo
like
it
was
stated
several
times
before.
Currently
it's
part
of
the
staging
there's
a
CLI
runtime.
There
is
only
a
bunch
of
printing
related
mechanism
and
conflict
flags
parsing.
A
We
are
hoping
to
extend
the
functionality
of
the
CLI
runtime
repo
with
additional
stuff
that
we
decide
that
are
generic
enough
for
logging,
on
thirds
and
or
or
basically
people
who
are
interested
in
writing.
Chip
CTO,
like
tools
if
ice,
or
rather
as
soon
as
I,
get
an
approval
from
sick
architecture.
A
Additionally,
as
a
second
step,
we
also
created
a
sample
CLI
plugin.
It
was
stated
during
our
last
meeting
that
we
have
a
cut
for
plugin
mechanism
and
implementation
of
the
new
connection
is
I'm
very
happy
to
announce
that
we
merged
both
the
cap
and
the
mechanist
right
after
last
meeting,
which
basically
means
currently
for
you
to
write,
keep
CTO
plug
in
is
that
you
just
need
to
have
a
binary
that
has
a
prefix
of
cube,
CTL
and
whatever
will
be
after
the
will
be
the
name
of
the
plug-in.
A
A
There
are
some
helpers
that
will
allow
you
to
list
the
plugins
if
I,
remember
correctly
keeps
your
plug-in
list,
and
additionally,
we
created
a
dish,
one
another
station
repo,
which
is
sample
CLI
plug-in,
which
showcases
how
to
write
a
sample,
CLI
plug-in
and
built
on
top
of
the
functionality
of
the
CLI
runtime.
We
show
how
to
reuse
those
those
bits
in
a
plugin.
A
B
A
Yes,
I
did
seem
the
dry
run
thing
I
commented
them
that
I
would
like
to
see
the
dry
run,
functionality,
the
mekinese
behind
it
being
part
of
the
CLI
runtime,
because
I
think
that
this
type
of
functionality
is
what
we
created.
The
CEO
of
I'm
thankful
to
be
able
to
inject
people
with
a
common
set
of
functionalities,
how
to
work
with
a
dry
run,
either
a
local
drug
run
or
the
server-side
driver
yeah.
That
makes
sense.
C
Not
on
topic
but
match
and
I
will
be
demoing
in
the
sample
I
plug
in
tomorrow
and
the
community
meeting.
If
anybody
via
team
action.
A
Yeah
exactly
so,
if
you
want
to,
you,
want
to
learn
a
little
bit
about
the
sample,
CLI
plug-in
or
how
to
write
a
plug-in
come
by
it
and
and
see
our
tomorrow's
demo
during
cube
community
meeting.
Okay
with
that
I
think
we
can
close
the
meeting
additional
reminder.
We
are
changing.
The
six
year
lie
meeting
number
stay
tuned
for
a
calendar
update
and
she
in
two
weeks
on
a
new
number
thanks
all
bye.