►
From YouTube: Kubernetes SIG CLI 20161214
Description
SIG-CLI planning the roadmap / goals for 2017.
B
Okay,
well
I
guess
we
have
some
planning
to
do
today,
but
well,
as
we
talked
about
in
the
last
meeting,
I
worked
during
this
week
a
little
bits
on
doing
some
triage
of
our
issues.
Like
Tony
said
in
the
last
meeting,
we
had
a
lot
specifically
around
180
issues
for
cube
CTL.
That's
the
ones
tag
tag
desk
chip
CTL.
There
might
be
others
not
specifically
at
tag
desk
in
detail
anyway.
B
I
did
a
triage
and
I
wanted
to
to
create
umbrella
issues
in
a
similar
manner,
the
to
the
one
you
did
to
keep
sekella
up.
Why
Phillip
so
overall,
during
the
triage
work,
I
found
that
you
know
most
issues
are
very
well
distributed
between
our
several
commands.
You
know,
they're,
not
one
major
topic
coming
up
like
a
lot
of
things
related
solely
to,
or
you
know,
create
anything
like
that.
They
are
overall,
very
well
very
well
distributed.
B
However,
what
I
did
found
was
a
large
number
of
issues
related
to
printers
and
describers,
so
that
kind
of
stuff,
a
good
number
of
issues
related
to
date,
laughs.
But
you
know
several
issues
related
to
the
printers
and
described
air.
So
I
created
an
umbrella
issue
for
those.
Let
me
actually
paste
the
link
here
and
chat.
B
Okay,
that's
it
so
that
was
you
know,
really
the
only
the
only
major
topic
I
could
found
a
big
number
of
issues
related
to
that.
So
I
created
this
umbrella
issues.
There
are
some
a
good
number
of
them.
Depth
are,
quite
rightly
I
mean
more
than
one
year
old,
so
it
might
be
worth
I'm
planning
to
do
that
as
a
follow-up
of
these
triage.
B
Stack
Overflow
things
like
that,
so
basically,
the
the
troubleshooting,
the
link
in
the
the
cube
website
I
closed
a
few
like
that,
and
also
some
some
some
issues
where
a
pro
request
merged
to
fix
that
that
issue.
But
the
issue
was
not
really
close
yet
so
well,
I
was
a
boy
able
to
call
something
like
that
anyway,
a
depth
that
umbrella
issue
could
be
a
starting
point
for
us
in
terms
of
working
on.
B
You
know:
improved,
establish
stability
for
1.6
IT
that
they're
a
good
number
of
issues
that
could
be
worked
and
closed
in
a
batch,
because
there
are
some
pretty
similar,
really
related
to
the
same
topic
and
the
same
areas
in
the
code
base.
So
having
that
in
that,
in
this
kind
of
umbrella
issue,
with
literally
helps
in
terms
of
well
Bonnie,
two
three
four
issues
are
really
related
and
I
can
probably
fix
them
all
at
once.
So
anyway,
Deb
that's
kind
of
a
follow-up.
B
B
Related
to
to
you
know
similar
bugs
are
some
really
related
to
the
actual
same
issue
alone.
Anyway,
that's
a
starting
point
in
terms
of
the
work
we're
planning
to
do
on
stabilization,
/,
1.6,
I'm,
not
sure
Phillip.
You
want
to
talk
anything
about
that
and
I
specifically
didn't
look
anything
in
terms
of
new
features
for
the
next
release
and
actually
for
for
2017,
like
we
talked
about
the
last
meeting
so
anyway,
I
pretty
much
work
a
little
more
on
on
tree,
I
began
working
on
on
the
issues
we
have.
B
That's
a
lot.
I
really
gave
more
attention
to
most
recent
ones
because,
as
I
said,
there
are
really
some
really
old
ones
even
related
to
the
cube,
see
child
bash
script.
So
you
know
I'm
pretty
sure
that,
as
an
extension
of
that
triage
we
could
be,
we
could
probably
close
a
good
batch
of
them,
but
anyway.
A
B
I
think
so
this
is
a
real
issue.
Gary
hope
it
yeah,
but
you
know
I
foresee
about
you
know
probably
close
to
50
issues.
Anything
like
that
that
are
potentially
you
know
able
to
be
closed.
So
I'm
going
to
do
that
anyway.
So
680,
that's
a
lot,
but
there
are
really
a
lot
of
old
stuff
and
things
that
really
no
longer
apply
to
what
the
scenarios
we
have
today.
We.
A
Should
come
up
with
a
like
goals
and
strategy
for
managing
our
issues,
like
I'm,
not
sure
right
now
what
our
intention
around
them
is
like?
Is
it
just
like
a
dropbox
for
messages
from
the
community
to
notify
us
about
things,
and
then
we
have
a
couple
umbrella
issues
to
track
things
or
I
or
do
we
want?
Do
we
want
to
have
something
like
no
more
than
50
open
issues
like
those
sorts
of
goals
or
like
buckets
of
issues
that
we're
working
on
I,
don't
know,
like
maybe
a
question
for
a
future
meeting.
B
Yeah
yeah
I'm
I'm,
also
not
sure
you
know,
because
this
umbrella
issues
they
help
a
lot.
You
know
heavy
like
this
umbrella
for
printers
and
describers
will
help
a
lot
in
terms
of
addressing
them,
but
they
are
really
hard
to
create
and
maintain
right.
So
we
should
probably
have
something
more
automated
I'm,
not
sure,
maybe
something
that
could
identify
the
pieces
involved
in
terms
of
the
code
bases,
I'm,
not
sure
yeah.
We
make
may
need
to
think
about
some
strategies,
but
yeah,
it's
I
mean.
B
A
Or
we
just
need
someone
constantly
thanks
period
yeah
for
the
full
time.
Okay
should
I
so
added
a
bunch
of
items
to
your
roadmap
after
I
think
the
pieces
that
you
had
worked
on
should
I
just
go
through
these.
Would
that
be
helpful
yeah?
I
think
so?
Ok,
so
these
the
intention
was
for
us
to
be
able
to
comment
on
these
in
decides.
I
guess
these
are
things
we
care
about.
No
they're
not
do
not
hi
I'm.
A
Looking
for
feedback
of
you
agree
or
disagree,
but
kind
of
broke
it
up
in
a
couple
different
themes
of
what
what
we
would
try
to
focus
on,
and
the
first
is
the
essentially
the
managing
the
life
cycle
of
the
applications
running
the
cluster
I
think
that's
a
large
part
of
what
controls
the
problem
is
trying
to
solve
it.
Also,
it
does
try
to
solve
a
couple
of
others
with,
like
I
think
boots
like
looking
at
node,
stop
and
some
cluster
Matt
lifecycle
management
stuff.
A
We
think
we
have
developed
to
control
as
a
tool,
largely
that
solves
some
very
specific,
targeted
problems,
but
the
the
narrative
we
provide
to
our
end
users
from
Anton
usage
of
like
okay,
so
now
you're
going
to
start
using
Cooper
Nettie's
to
your
whole
team.
Like
does
weekly,
pushes
it's
not
totally
fleshed
out
and
there's
I
think
some
some
pieces
of
that
puzzle
that
may.
B
A
Belong
in
coop
control,
but
it's
still
worth
defining
how
those
problems
are
solved
outside
of
control
right.
So
one
of
them
would
be
like
how
you
factor
your
configuration
files,
for
instance,
coop
control
applied
a
chef
you
can
put
on
directory
and,
and
it
will
manage,
the
art
will
apply
they
can
fix
in
that
directory.
A
But
how
you
factor
them
within
that
directory
is
I,
don't
think
we
have
a
great
story
for,
especially
when
you
have
maybe
like
five
deployments
that
look
almost
exactly
the
same,
but
have
two
fields
that
are
different
in
each
one
or
those
sorts
of
things.
So,
oh
and
the
other
things
like
do
you
like?
How
do
you
store
your
face?
Do
you
check
them
in
the
github
and
then
sync
from
there
like?
What's
this
prescribed
way
of
just
managing
the
release
process?
A
So
that's
something
I'd
like
to
just
explore
in
2017
and
then
the
second
half
of
that
is
just
making
sure
that
all
of
the
pieces
on
that
user
journey
will
say
are
correct
and
in
fully
functional
right.
So
I
think
that
plays
into
a
lot
of
the
coop
control,
apply,
fixing
the
bugs
and
in
making
sure
that,
like
the
set
and
view
commands
are
consistent
and
that
there's
their
cover,
the
right
set
of
commands
to
end
the
crate
commands.
A
If
you
look
at
could
control
crate
like
X
is
some
resources
are
supported,
some
researchers
or
not
the
extent
to
which,
like
flags,
we
support
for
setting
like
image
and
other
things
forward
to
those
resources,
is
not
consistent
across
all
of
the
resources
we
do.
Support
great
or
soap
would
be
nice
to
say
like
this
is
fully
well
supported,
instead
of
just
just
somethings
are
supported.
The
second
piece
theme,
I
kind
of
added
here,
was
support
for
extensions.
A
There's,
a
lot
of
work
being
done
in
corfu.
Benetti's
for
support
extensions
is
going
to
be
a
big
part
of
how
we're
going
to
be
able
to
sustainably
grow
the
project
and
what
the
system
can
do
and
Q
control.
So
right
now
doesn't
work
with
all
of
those
extensions.
For
instance,
third
party
resource
doesn't
work
with
apply
with
federated
API
servers,
I'm,
not
sure
if
it's
just
going
to
work
out
of
the
box
or
if
we're
going
to
need
to
add
support
there.
A
In
addition
to
know
supporting
the
existing
mechanisms
we
should,
we
should
also
be
able
to
extend
to
control
itself
others
design
doc.
For
this
thing
we
talked
about
it
last
time
and
it's
already
on
the
items
you
listed
fabiano,
but
calling
out
that
we
will
probably
want
to
be
able
to
extend
like
cooking
coal,
create
X
resource
for
the
third
party
resources
and
allow
people
to
do
stuff
like
that,
and
then
closely
related
to.
A
That
is
the
idea
that
we
need
to
provide
extension
mechanisms
for
things
that
aren't
their
own
command,
but
are
interpreted
within
coop
control
like
coop
control,
print
or
describe
well.
Maybe
those
would
actually
work,
I'm
not
sure,
but
I
think
there's
there's
certain
things
that
probably
we
need
to
think
more
carefully
about
when
we
think
about
things
as
apps
and
third-party
resources
being
applications,
so
developing
a
vision
for
how
to
allow
apps
to
publish
metadata
that
coop
control
is
able
to
use
to
print
them
and
describe
them
and
in
reason
about
them.
A
A
This
has
been
kind
of
an
ongoing
thing.
Thank
you
probably
want
to
continue
to
focus
on
it
has
to
do
with
documentation
in
error
messaging
and
all
that
sort
of
stuff
I
think
we
could
I
seen
a
number
of
github
issues
that
are
around
users,
just
not
understanding
how
to
use
the
system
and
how
different
commands
interact
with
one
another
like
a
big
one
would
be
using
coop
control,
create
on
a
resource
and
then
doing
coop
control
apply
on
that
resource
later
and
understanding
like
that.
A
A
So
just
the
having
kind
of
a
map
for
how
to
use
the
tool,
and
then
an
engineering
velocity
piece
which
is
a
technical
debt,
is
kind
of
what
it
mirrors.
But
it's
around
refactorings
in
some
stuff
like
getting
and
getting
to
control
out
of
the
manga
repo
would
probably
allow
us
to
manage
the
the
tool
a
little
bit
easier.
It
would
also,
besides
just
allowing
us
to
move
more
quickly
and
actually
have
more
ownership
over
the
issues
and
all
that
stuff.
A
Looking
at
fabiano
one
of
the
items
you
had
but
I,
think
of
it.
The
last
piece
would
be
coo
control,
as
it
is
a
platform
for
building
pieces
of
functionality
on
the
client
side
to
interact
with
the
and
interact
with
the
kubernetes
cluster,
and
so
there's
like
kind
of
in
debt,
find
a
tional
pieces
that
could
control
applies
that
or
that
kooky
full
provides
to
that
tooling
right
and
so
lonely
when
I
added
was
the
idea
of
preferences,
but
I
I
can
imagine.
A
A
B
A
B
Yeah
I'm
not
sure,
well,
a
document
works
for
me.
I
think
that's
how
another
seek
not
sure
if
it
was
apps
or
API.
This
is
already
they
just
use
the
google
document
that
works
for
me.
We
just
probably
have
to
improve
the
really
merge.
The
first
drafts
I
had,
but
I
think
all
of
them
are
already
covered
within
what
you
have,
but
I'm
not
sure
I
really
don't
have
a
strong
preference.
A
duck
works
for
me.
Maybe
a
wiki
page
or
a
markdown
document
all
also
works.
B
My
only
concern
is
that
if
we
need
to
take
those
and
make
some
of
those
items
but
become
individual
issues
in
our
backlog
on
github,
specifically
or
most
of
them
are
already
covered
by
issues
specifically
new.
The
new
features,
things
like
that
do
do
we
have
we
need
to
as
a
follow-up,
create
new
issues
based
on
that
yeah.
A
A
B
Yeah
again,
I
don't
have
a
strong
preference
but
I'd
say
well.
One
document
for
2017
goals
with
like
major
topics,
I
think
well,
yeah,
actually
I
think
separate.
Documents
is
better
because
we
can
keep
the
2000s
2017
goals
with
like
major
topics,
not
not
very
specific
topics.
So
we
don't
have
to
go
into
too
much
details
in
that
document
and
that's
a
document
that
will
probably
last
along
right
one
year
so
yeah
probably
separate
documents
for
for
the
quarter.
Okay,.
A
B
Yeah
wicked,
what
I
could
do
a
having
that
I
can't
take
that
document?
We
already
have
this
one,
you
were
you
pasted
the
2017
goals
and
turn
it
turn
it
into
our
2017
document.
So
I'll
pretty
much
take
the
notes.
I
had
make
sure
they're
all
covert
in
in
your
document
here
and
make
sure
it's
what
better
formatted.
So
we
have
only
one
listings.
B
A
B
Know
anything
you
know
I
sure.
Well,
first,
they
make
that
cleanup
work
and
after
that
maybe
I
can
first
share
it.
We
share
it
with
the
seek
a
mailing
list
so
that
people
in
the
industry
could
you
know
suggestin
comment
before
we.
Actually,
you
know
share
with
the
entire
Burnett
is
mailing
list,
but
anyway,
I
think
that's
something
we
have
to
do
right
at
some
point
share
it
with
the
the
open
list
for
the
entire
kubernetes
community
and
maybe
probably
even
inna,
in
the
community
meeting
right
yeah.
B
B
A
B
A
B
B
Yeah
I'll
be
around
until
thursday,
so
if
we
want
to
have
the
wednesday
meeting,
that's
good
to
me,
if
we
have
our
own
enough,
okay,
yeah
I'll,
be
there.
Okay,
yeah
sounds
good,
so
I
guess:
that's
it
not
sure
if
there
are
any
other
topics,
but
I
think
most
of
the
idea
today
was
still
you
know,
take
a
look,
take
a
look
at
what
we
had
in
terms
of
planning,
so
any
other
team
depths.
We
need
to
discuss.