►
From YouTube: Kubernetes SIG CLI 20181010
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
welcome
good
morning,
good
afternoon,
good
evening,
depending
on
where
you
are.
This
is
another
of
our
weekly
meetings
for
60.
Li
today
is
October
10th
and,
however,
the
agenda
is
packed
with
the
items.
So,
let's,
let's
get
this
thing
going
so
before
we
dive
into
the
agenda
items
a
couple
outspends.
So,
following
up
the
discussions
that
we
had
two
weeks
ago
during
planning,
we
created
two
projects
in
the
cube,
CTL
repo.
Both
of
them
are
linked
in
the
agenda.
A
That
was
also
linked
to
the
chat,
and
you
can
also
see
that
on
the
screen,
one
is
tracking
the
items
that
we
are
working
on
for
the
current
release.
It
will
be
a
a
living
document
and
to
have
a
one
source
of
truth,
will
always
be
updating
this
document.
So
currently,
this
reflects
the
main
items
that
we
are
working
for,
113,
the
other.
The
the
second
project
that
was
also
created
is
tracking
the
major
books
that
we
have
for
for
cube.
Ctl,
I
hope
that
doesn't
require
further
explanation.
A
If
you
have
any
doubts,
suggestions
propose
for
positions
how
to
change,
modify,
update
those
feel
free
to
reach
out
to
me
or
Shawn
directly,
or
you
can
reply
to
the
announced
emails
that
we
send
out
to
the
six
year
like
mailing
list.
The
third
announcement
is
that,
over
the
weekend,
I
managed
to
restructure
the
cube.
Ctl
comment,
sub
directories,
so
currently
every
single
command
or
a
group
of
commands.
If
we're
talking
about
first
level
of
cube
CTL
commands,
is
living
in
its
own
directory.
A
This
should
simplify
development
for
people
that
are
improving
or
working
on
just
single
command,
in
that
they
will
be
able
to
limit
the
scope
of
their
tests.
Only
to
that
particular
piece
of
code
instead
of
running
all
of
the
tests
for
the
entire
for
the
entire
cube
CTO,
there
will
be.
There
will
be
further
changes
happening
in
the
upcoming
weeks.
We
want
to
ensure
that
the
cube
CTL
command
subdirectory
contains
only
the
commands
and
nothing
else.
A
The
next
item
on
the
agenda
is
the
test
grid.
I
was
taking
a
look,
I
was
taking
care
of
our
test
queue
for
the
past
few
weeks
and
thankfully
the
test
code
was
very
peaceful.
There
was
no
major
events
happening
with
the
6li
related
tested,
so
I
must
admit
that
was
very
peaceful.
Two
weeks
when
it
comes
to
updating
the
the
test,
the
test
document
I
haven't
got
to
that
one
yet
becomes
due
to
the
restructuring.
A
I
need
to
work
a
little
bit
more,
all
under
the
shape
of
the
current
document,
because
what
we
had
before
will
be
slightly
different
from
what
we
have
these
days.
Okay,
so
onto
the
topics-
and
the
first
topic
is
I'm
guessing
I
have
I,
don't
see,
is
your
on
but
Kendricks
around
so
I'm
gonna
I'm
gonna,
give
you
the
voice,
and
the
floor
is
yours.
Kendrick
thank.
B
B
This
is
because
there's
two
cube
cons,
plus
the
u.s.
holidays
that
are
all
coming
and
not
only
that
is
code
slush
actually
begins
on
November,
I,
think
11th
or
15th,
so
we're
already
in
the
one
month
countdown
for
essentially
getting
to
that
point.
So
the
idea
is
that
I
put
the
link
in
there,
so
you
can
see
which
features
are
assigned
to
sig
CLI,
there's
actually
quite
a
few
that
are
targeted
for
the
113
roadmap.
B
So
if
you
are
an
owner
of
that
particular
enhancement,
you've
probably
got
a
ping
from
me
earlier
this
week,
just
kind
of
looking
to
see
to
make
sure
that
you
feel
confident
that
this
can
still
hit
the
targeted
milestone,
dates
that
are
gonna
be
assigned
to
it
as
well.
So
if,
by
some
chance,
you
don't
think
it
can
go
ahead,
comment
on
the
enhancement
and
that
issue,
and
we
will
take
it
off
the
milestone,
take
it
off
the
sheet
for
tracking,
so
on
and
so
forth.
B
If
there's
anything,
I
did
also
sent
out
a
message
to
anything
that
had
not
been
tracked
in
the
milestone
to
see
if
it
was
going
to
be
there.
So
if
you
are
a
owner-
and
it's
not
going
anywhere,
you
can.
Let
me
know
that
it's
not
going
anywhere
and
we
can
just
give
you
a
thumbs
up,
but
really
113
is
really
geared
towards
a
lot
of
things
that
could
be
that
I've
either
slipped
from
112,
because
documentation
or
in
testing.
Anything
like
that.
A
Thank
you
very
much
for
the
update
for
the
information
like
Kendrick
said.
If
you
have
any
questions,
doubts
feel
free
to
reach
out
either
to
myself
or
Sean
or
to
Kendrick
himself
or
I
shot
with
regards
to
the
items
that
are
planned
for
1:13
release
from
the
quick
glimpse
that
I
had
on
the
list.
There
are
a
few
items
I
or
we
as
a
say,
we're
not
tracking
before
and
I'll
try
to
have
a
look
at
it.
A
A
D
Hello,
yes,
my
name
is
Michael
I
hi
everyone
nice
to
meet
you.
So
this
is
the
improvement
for
kube
CTL
locks,
which
allows
users
to
get
locks
from
multiple
sources.
For
example,
you
can
select
multiple
pots
by
label,
which
is
basically
the
main
reason
for
this.
I
will
try
try
to
give
you
like
a
impression,
like
sorry,
like
overview
of
the
my
changes,
so
basically
I
try
to
make
my
changes
to
be
like
as
much
similar
to
the
existing
code
base
to
existing
experience.
D
For
example,
currently
cap
CTL
logs
allow
you
to
receive
locks
from
multiple
sources
without
following
them,
and
it
it
fails
on
the
first
error,
for
example,
when
just
read
first
log
it
will
stop
reading
the
second
one.
It
will
not
read
the
second
block
if
there
was
an
error
in
during
the
radiance
of
the
first
airlock
source,
so
I
try
to
keep
the
user
experience
as
close
as
possible
to
the
existing
behavior,
but
at
the
same
time
I
did
add
the
ability
to
follow
logs
from
multiple
sources
in
in
a
concurrent
way.
D
So
there
are
some
open
questions
like
should
we
have
a
limit
for
concurrent
requests,
which
is
a
really
good
question.
Initially,
I
decided
not
to
introduce
any
like
synthetic
limits
for
four
days,
because
we
know
very
little
about
the
users
environment,
at
least
from
from
what
I
see
and
I
felt
like
I'm,
not
sure
that
what
the
reasonable
limit
should
be.
D
A
A
This
way,
we
would
ensure
that
the
server
will
not
be
DDoS
by
accident
and
and
at
the
same
time
we
will
tell
the
user
explicitly
how
to
fix
the
problem,
because
maybe
the
fact
that
he
is
selecting
20
parts
is
intentional,
in
which
case
he
should
also
intentionally
say.
Yes,
that's
the
limit
that
I
am
aware
of,
and
this
and
set
it
explicitly
on
the
QC
PL
call.
So
that's
that's
that
I.
A
A
A
Definitely
increasing
the
number.
The
default
will
be
easier
because
it
won't
be
a
backwards,
incompatible
change,
but
who
will
be
improving
the
user
experience
so
three
or
five
is
something
that
I
would
start
with,
and
then
we
can
always
increase
the
number.
As
we
see
that
a
lot
of
people
is
complaining
about
that
number
being
too
low,
then
we
can
double
it
or
something
like
that.
But
for
for
starters,
I
would
go
with
like
low
number
3
4
5
6
will
be
probably
the
the
highest
number
I
would
go
with.
E
I
have
a
quick
question,
so,
first
of
all,
I
think
this.
This
is
really
really
nice.
Did
we
ever
answer
the
question
about
how
to
interleave
and
whether
there
would
be
a
prefix
to
the
logging
and
so
that
we
can
understand
the
how
the
you
know,
at
least
to
have
some
visibility
on
what
the
interleaved
message.
Log
messages
look
like
so.
D
I
will
explain
the
interleaf.
There
was
a
question
about
interleaving
from
different
sources
plus
interfering
lines.
I
did
some
changes
to
prevent
locks
for
to
be
interleaved
in
the
middle
of
the
line,
but
I
didn't
add
any
perfection
or
like.
There
is
currently
no
way
to
say
that
these
locks
comes
from
this
boat.
D
A
Okay,
I
was
about
to
suggest
a
flag
that
will
allow
you
to
turn
on
or
off
the
prefix
Inc
we
could
I
can
imagine
both
approaches
being
useful
in
different
use
cases
there
will
be.
There
will
be
use
cases
where
I
do
want
to
know
that
this
log,
especially
for
example,
when
I
will
be
following
the
logs
and
grabbing
it
for
a
specific
pattern
and
I
will
want
to
know
on
which
particular
path.
A
This
lock
happened,
whereas
in
some
other
cases
I
might
be
only
interested
in
a
particular
log
pattern
and
I
don't
care
about
the
source
and,
as
you
probably
mentioned
in
the
cases
where
you
are
straightening
only
from
a
single
source,
the
prefix
will
be
will
be
just
a
garbage
that
people
will
not
want
to
see.
So
we
could
start
probably
and
that
won't
break
the
backwards
compatibility
with
with
the
perfect
flag
being
turned
off
by
default.
A
D
Cool
I
have
a
question
not
directly
related
to
this
one
I
think
it's
my
yes,
it's
my
first
meeting
with
you
guys
and
I'm,
not
sure
about
the
process.
Do
you
want
me
to
like
document
it
somewhere
in
the
pull
request
or
should
I
create
a
new
view?
Burnett
is
enhancement
proposal.
Oh,
how
do
you
call
it?
D
A
D
A
Some
commands
have
more
examples,
others
a
little
bit
less
in
your
particular
case,
I
think
it
will
be
worth
updating
the
examples:
how
to
log
follow
the
logs
from
multiple
containers
with
the
graphics
attached,
so
it's
definitely
good
to
have
those
over
there
and
then
also
look
into
the
official
Docs
and
update
them
accordingly.
Okay,
good
good.
A
C
Okay,
cool,
okay,
so
let's
say
I
want
to
create
a
a
new
deployment,
and
now
so
I
have
created
these
deployments.
It's
an
example:
it's
the
it's
actually
the
example
I
found
on
the
website
before
I
want
to
apply
that
and
I
don't
know.
What's
gonna
happen
if
I
apply
that
I'm
going
to
run
deep
and
see
what
would
happen,
in
fact
he
hated.
C
C
And
if
I
do
a
diff
again,
obviously
as
expected,
nothing
is
there.
Now
we
don't
have
a
difference
now,
I'm,
updating
my
deployment
and
Falak.
Of
course,
I've
created
a
daily
deployment
that
you
know
what
I've
done
is
that
I
changed
the
boat
name,
I've
changed
the
version
of
the
nginx
image
and
I
changed
from
the
strategy
already
now
to
Orion
up.
They
too
are
cliquey,
and
so
I
can
do
it
again
and.
C
It's
not
included,
though
it's
not
in
the
it's,
not
part
of
the
defense.
Okay,
we
can
see
it,
but
it's
not
changed
okay
and
we
can
see
every
updated
the
pre-cast
everything
this
might
not
be
the
most
interesting
example,
and
fortunately
because
nothing
has
been,
he
defaulted,
and
this
is
exactly
what
I
change,
but
at
least
we
see
what
is
going
to
happen
on
the
server
I
do
a
blog
which
I'm
doing
now
and
if
I
do
a
jiff
again,
obviously
it's
gonna
be
MJ
again,
that's
it.
C
In
my
opinion,
it's
95%
done.
I
want
to
improve
some
of
the
documentation.
Well,
we
see
in
the
documentation
people
saying
you
should
run
cube.
Ctl
apply
I
wanna,
replace
by
first.
You
should
run
QC
TLD.
If
you
see
what's
gonna
happen
and
then
run
keeps
each
other
black.
But
that's
that's
about
it.
Everything
else
is
ready.
In
my
opinion,.
C
D
A
C
A
Some
that
I
I
probably
am
guilty
of
myself
introducing,
but
we
are
silently
falling
back
to
the
previous
behavior,
depending
on
the
server
versions,
or
rather
about
the
availability
of
certain
features
yeah,
particularly
with
cube
city
Iran.
Depending
on
whether
you
have
newer
API
versions
of,
for
example,
deployment.
We
will
allow
creating
either
a
apps
v1
deployments.
Work
fallback
silently
well,
not
silently
because
we
are
gonna
say
that
this
is
not
supported
and
we
are
going
to
create
a
apps
V
1,
beta
1
or
V
1
beta
2
deployment,
for
example.
A
D
A
A
Okay,
that'll,
that
leaves
us
with
enough
room
for
an
on
topic
that
was
brought
during
during
restructuring.
The
cube,
CTL
Shawn
brought
a
good
question,
which
is
each
command
currently
lives
in
in
its
own
subdirectory,
under
cube
CTO
commit
so,
for
example,
delete
has
a
subdirectory,
create
a
knowledge.
Flavors
live
in
once
in
in
other
subdirectory
same
applies
for
attach
exactly
it
so
forth.
The
question
was
whether
we
want
to
allow
enter
commands
dependencies,
and
here
is
a
an
example
that
is
appearing
several
times.
A
Other
examples
include
attach
options.
I
think
that
exact
we
uses
parts
of
attach
command
in
its
own
code.
So
the
question
is:
do
we
want
to
allow
such
interdependencies
or
we
want
to
ensure
that
every
single
command
is
being
used
only
within
its
own
directory
in
cases
such
as
delete
attach
and
I?
Think
a
couple?
Others
deserve
a
util
package.
A
One
by
one
and
I
didn't
identify
them
and
talked
through
all
of
them
during
one
of
our
meetings
and
decide
whether
whether
it
is
okay
and
promote
that
particular
functionality
over
to
the
CLI
runtime
or
the
current
approach
of
having
the
inter
command
dependencies
is
okay
for
now.
But
do
we
want
to
tackle
that
at
a
later
point
in
time.
F
You
know
what
are
some
of
these
pieces
that
should
exist
within
the
generic
selling
options,
CLA
enzyme,
mainly
because
if
we
come
to
the
conclusion
that
you
know
these
pieces
basically
would
add.
You
know
to
the
existing
functionality
of
the
repo
and
would
benefit
others.
Then
you
know
basically,
why
not?
You
know,
why
not
add
those
benefits
to
the
rest
of
the
community
at
the
same
time,
you
know
I'm,
pretty
sure
we'll
have
other.
F
You
know,
inter
command
dependencies,
that
we've
all
come
to
the
conclusion
that
do
not
belong
in
the
CLA
runtime
package,
mostly
because
they're
cube
specific
or
they
address.
You
know
a
very
specific
problem
so
for
those
I
feel
like
they're,
okay
to
leave
as
they
are
they're.
Okay
to
leave
us
ensure
command
the
tendencies,
but
I
do
think
it's
worth.
You
know
identifying.
The
ones
that
you
know
should
belong
or
would
benefit
from
belonging
in
the
higher
level,
see
how
it
runs
every
good
and.
E
There's
a
there's
a
case
in
between
the
two
that
you
just
identified
of
just
leaving
and
moving
it
up
to
CLI
runtime.
We
can
also
pull
out
common
code
and
put
it
into
the
package.
Coop
cuddle,
you
till
yes,
so
so
I
want
to
actually
mention
a
fourth
up
possibility,
which
is
to
create
a
package
coop
cuddle
internal
directory,
which
would
define
what
is
common
to
the
to
coop
cuddle
but
cannot
be
exported
outside
of
coop
cuddle,
and
we
could
put
that
internal
directory
at
a
different
level.
E
We
could
even
put
one
it's
packaged,
coop
cuddle
command
and
then
anything
under
that
directory
would
be
usable
in
command,
but
would
not
be
usable
out
above
command,
yeah,
I
think
as
as
much
a
reorganized
this
last
weekend.
It
looks
so
much
better
and
and
I'm
not
worried
about
the
inner
command
dependencies
right
now,
but
I
think
that
it
might
be
cleaner
if
we
pulled
common
functionality
to
util
or
internal
and
then
further
look
to
see
if
it
should
be
promoted
outside
of
the
repo
to
CLI
run
time
later.
That
would
be
my
vote.
I.
A
A
I
think
that
having
just
noodles
where
we
keep
everything
that
is
being
shared
amongst
all
of
the
commands
is
sufficient,
and
you
know
I
hate
to
agree
that
extracting
those
common
functionalities
into
the
you
toes
and
then
maybe
figuring
out
whether
some
of
them
deserve
the
third
place,
and
this
year
like
run
time,
is
definitely
worth
it.
I
think
I
left
you
Sean
any
comment
about
that.
A
A
But
as
soon
as
we
split
to
a
separate
repo
I
think
we
might
want
to
go
back
and
revisit
the
utils
package
contents,
because
I'm
pretty
sure
that
that's
the
point
of
time
there
will
be
some
pieces
of
code
that
we
could
be.
We
could
easily
just
remove
because
they
are
not
not
being
used
or
or
unnecessary
anymore
or
or
or
they
just
causing
us
are
some
some
headaches
or
unnecessary
backwards
and
compatibilities
that
will
have
to
struggle
but
yeah
the
common
you
clothes.
A
A
Okay,
I'm
hearing
none,
so,
let's
head
over
to
the
final
to
the
final
step
of
of
our
agenda,
which
is
stand-ups
I'm
gonna
start
with
myself,
like
I
mentioned
I,
am
currently
working
on
restructuring.
The
cube,
CTL
subdirectories,
currently
the
biggest
work
that
I'm
doing
is
cleaning
cube,
CTL
command
package
so
that
it
contains
only
the
commands.
I
think
I
have
just
one
left,
which
is
templates.
A
It
should
be
pretty
straight
for
it
I'm
hoping
to
put
APR
later
today,
removing
that
one
out
and
then
there
is
also
packaged
cube
GTL,
which
has
quite
a
bunch
of
go
files
that
are
they're
connected
with
specific
commands
and
I.
Think
that
might
be
the
next
step
that
I
will
be
tackling
to
move
them
over
to
the
specific
commands
there
were
subdirectories,
but
I
think
that
others,
that
will
be
a
little
bit
more
a
little
bit
longer
because
it
will
require
some
more
thoughts
put
into
those
moves.
E
The
core
kubernetes
in
order
to
be
able
to
move,
could
cuddle
out
into
its
own
repo
and
I.
Think
that
we've
merged
quite
a
few
PRS,
and
so
we've
we've
gotten
that
there's
kind
of
two
different
buckets,
or
at
least
two
large
buckets
number
one,
is
the
bucket
of
dependencies
on
internal
versions
of
resources,
which
includes
like
legacy
scheme
type
of
dependencies,
where
coop
Codel
has
an
internal
version
of
a
reference
of
a
resource.
We've
gotten
rid
of
quite
a
few
of
those.
E
E
There,
to
be
honest,
so
surprisingly,
there
was
a
coop
cuddle
common
repo
until
about
a
month
ago,
and
it
was
created,
while
Bryan
grant
specifically
I,
think
for
this
for
this
purpose,
but
because
it
wasn't
used
because
we
hadn't
got
to
it.
I
think
that
Aaron
Quicken
burger
got
rid
of
it
within
the
last
month.
So
I
think
that
this
is
something
that's
already
been
on
their
mind
and
that
they
would
be
open
to.
E
A
Well,
I
I,
wouldn't
put
it
as
a
roadblock
I
would
rather
say
continue
with
the
moves
that
we
are
doing,
just
like
you
said
not
to
block
ourselves,
but
at
the
same
time
and
parallel,
we
could
start
the
discussion
with
a
Sikh
architecture
and
maybe
go
the
road
of
creating
the
common
repo.
Maybe
they
are
the
Sikh
architecture.
A
A
Even
if
it
were
unchanged
we
would
have
to
copy
it
over
and
modify
the
functionality
within
the
cube
city
of
itself.
It
might
be
so
for
majority
of
common
for
other
common
libraries.
Let's
call
it,
and
maybe
the
move
that
we
are
doing
just
is
sufficient
and
we
don't
want
to
go
the
path
of
creating
that
common
repo,
but
I
might
be
mistaken,
so
I
don't
want
to
vlog.
Don't
please
don't
understand
like
that.
A
What
I'm
saying
is
that
we
could
at
the
same
time
invest
some
time,
because
maybe
it
is
on
their
hats,
and
we
could
create
this
because
the
common
library
might
be
also
of
some
help
for
at
least
some
group
of
people
I'm
not
saying
that
all
of
us,
but
of
these
controllers
and
keep
CTL,
maybe
some
other
people
that
are
playing
with
the
built-in
cubes
kubernetes
resources
might
benefit
from
such
a
library
as
well.
So
it's
just
a
thought
and
it
can
be
guided
and
completely
in
a
parallel
to
your
efforts.