►
From YouTube: Kubernetes-SIG-CLI-01-31-2018
Description
This is the recording of the SIG-CLI bi-weekly meeting held on 31 Jan, 2018.
A
B
C
Hi,
this
is
Nancy
from
from
Red
Hat,
so
this
was
brought
up
last
week
over
this
week,
so
we
moved
the
entire
scale
link
over
to
the
server,
and
that
means
that
currently
there
is
a
generic
scale.
Client
and
every
source
that
needs
to
wants
to
be
scaled
actually
exposes
a
scale
endpoint
and
that's
fine.
For
majority
of
resources
such
as
deployments
daemon
sets
or
in
general
all
those
were
long-running.
A
C
D
C
So
initially
I
started
with
presenting
in
the
status
the
information
about
the
spec
for
the
job
that
was
just
modified,
which
both
Jordan
and
David
said
will
be
wrong,
and
I
was
having
lengthy
discussion
with
both
David
and
Jordan,
about
possible
approaches,
and,
at
the
end
of
the
day,
we
agreed
that
jobs
per
se
is
not
able
to
scale
properly
due
to
the
problems
that
I
explained
a
minute
ago.
That's
why
we
would
like
to
be
able
to
deprecated
this
scale
operation
for
job.
C
C
The
problem
is
towards
the
end
of
the
job,
because
if
you
set
a
number,
if
you
set
a
number
the
scale
which
is
translated
that
then
to
parallelism,
let's
say
we
would
set
a
a
part
ilysm
to
5.
There
are
only
three
more
pots
that
are
that
need
to
run
the
job.
That
will
never
be
a
created
five
pot
just
because
you
define
a
scale
of
five.
If
you
think.
B
We
think
about
it
in
the
other
direction
in
order
to
be
scalable.
If
there
are
a
few
pieces
of
information
that
that
must
be
present
and
a
few
semantics
that
must
be
obeyed
right.
If
you
look
at
the
scale
object,
it
expects
to
have
a
desired
scale
number
and
a
current
scale
number,
and
it
expects
to
have
a
pod
selector
that
can
show
you
the
current
number
of
pods
right
and
that's
what
the
scale
contract
is
about,
and
the.
B
D
C
B
D
D
B
D
C
D
C
B
D
B
B
D
C
B
A
A
Okay,
so
moving
on
to
the
next
item
so
the
last
meeting
there
was
an
action
item
for
publishing
1.10
goals
for
6cl
I,
so
I
took
a
stab
at
it,
and
I
basically
created
this
table
format
where
just
listing
so
the
main
items
that
were
captured
in
the
last
meeting
notes
and
just
put
it
out
there
so
I
don't
know
how
do
we
want
to
go
over
it
or
how
much
detail
we
want
to
talk
about
it?
Phil.
Do
you
have
any
idea
of
going
over?
The
one
thing
goes:
yeah
I.
D
So
I
think
an
action
item
to
everyone
in
cig
CLI
is
to
go
open
this
up
and
make
look,
is
your
name
and
an
owner
for
something?
And
if
it
is,
you
know
actually
confirm
that
and
then,
if
it's
not
and
there's
something
that
you're
planning
on
delivering
in
110
and
should
be
tracked
like
in
the
features
process,
make
sure
it's
on
here.
D
D
B
For
scale
in
particular
that
was
polynomial
he's
a
community
contributor,
so
as
credit
work
to
do,
and
the
other
commands
still
still
need
to
talk
in
API
machinery
about
it,
there
was
initial
resistance,
because
the.
Why
would
you
ever
want
to
look
at
a
log
for
replication
controller
they
can
have
more
than
one
log
is,
is
difficult
to
describe
to
people
who
don't
look
at
it
and
say
you
know
what
on
a
CLI.
That
is
a
super
useful
thing
to
be
able
to
do.
B
B
B
D
B
D
D
A
D
A
D
Or
so
building
out
a
really
clean
test
framework
for
any
recent
tests-
and
this
is
maintained,
is
for
it
to
be
used
by
anyone
developing
either
tools
or
extensions,
so
like
you're,
building,
series
and
controllers
or
if
you're,
building
other
other
tools,
such
as
food
control,
including
food
control.
It
brings
up
a
control
plane
for
you,
using
just
locally
within
at
CD
and
API
server,
no
nodes
and
allows
you
to
just
spin
those
up
for
each
test
suite.
You
can
spin
up
multiple
ones
in
parallel
and
all
that
sort
of
stuff.
D
So
if
you
are
building
any
tools
and
you
want
to
test
them
and
you
need
a
commander's
cluster,
this
is
actually
a
really
clean
lightweight
alternative
and
if
you're
developing
to
control
commands
I
expect
that
we're
going
to
be
moving
away
from
the
ete
tests
that
spin
up
a
full
three
node
cluster
for
for
most
things
and
move
more
to
this,
where
you
can
just
run
it
locally
on
your
desktop.
And
then
you
don't
actually
need
to
check
that
positive
running
on
nodes.
A
A
B
B
B
B
Think
that
all
that
information
logically
requires
a
server
to
be
present
or
conversion
logic
to
be
present
inside
of
the
client
itself,
and
so
at
a
code
level.
I
was
thinking
about
trying
to
separate
the
concepts
and
try
to
limit
the
number
of
commands
that
actually
assume
that
they
have
conversion
logic,
find
them
isolate
them,
maybe
eliminate
them
and
then
also
force
commands
to
tolerate
the
idea
that
our
rest
mapping
may
not
exist
right.
We
have.
D
E
Yeah
I
was
talking
to
David
about
that.
Moe
asked
me
something
about
this
last
night.
I
was
kind
of
explaining
the
history
like
this
predates
discovery
and
predates
it's
really
just
we
did
most
of
the
transition
in
1:9
actually
to
cut
the
use
of
it,
but
it
still
I
needs
the
final
snip
snip.
Okay,
because
we
made
the
mistake
of
not
making
schema
and
resource
name
match
so
that
you
could
always
submit
a
schema
to
the
server
and
the
server
could
say
this
schema.
It
doesn't
exist
as
a
primary
resource
object.
F
E
B
G
B
G
G
B
David
it
does
some
of
it
comes
down
to
do.
You
believe
that
a
metadata
access
ER
for
a
locally
run
command
is
a
thing
that
can
be
determined
reasonably
from
a
server
connection
and
I
guess,
on
the
whole,
whether
a
metadata
access
er
is
actually
related
to
the
rest
mapping
right.
So
so
the
metadata
that
you'll
get
trying
to
get
out
is
inside
of
the
deserialized
object
that
you
have
the
bytes
somehow
right
and
when
we
look
at
it
there
is
actually
well.
E
This
is
historical
to
that.
The
idea
originally
was.
We
were
gonna.
Have
these
go
types,
and
then
we
never
really
thought
about
okay?
Well,
what
happens
and
we
don't
have
to
go
types,
so
we
had
abstractions
in
the
code
like
metadata
access,
ER
and
rest
mapper.
They
were
based
around
assuming
that
you're
gonna
have
to
go
types
for
everything
and
obviously
that's
a
that
assumption
stopped
being
valid
the
moment
third-party
resources
showed
up
and
then
we're
further
as
we
move
down
this
path.
E
Yeah,
basically
kind
of
the
rule
of
thumb
in
the
codebase
today
is,
if
you
have
a
runtime
object
and
it
doesn't
implement,
object
meta,
it
doesn't
matter
it
like
we
just
treated
as
not
being
on
top
of
it,
though
someone
would
have
to
write
code
that
deliberately
didn't
implement
that
interface,
and,
at
that
point,
like
that's
a
coding
error.
Either
your
support,
object,
meta
or
you
don't,
and
we
really
haven't
gone
back
and
looked
at
like
unstructured,
doesn't
deal
with
us
at
all
yeah.
That
was
those.
G
G
E
I
mean
honestly,
all
that
that
helper
does
is
just
try.
The
cast
to
meta
object,
meta
to
see
whether
it
satisfies
the
interface
and
I
think
that's
kind
of
the
arc
that
the
code
base
in
practice
has
to
follow.
If
whoever
creates
the
unstructured
object.
Originally
there'd
been
a
thought
that,
like
we're,
gonna
Rev
object
meta,
so
we're
gonna
like
change
fields
and
all
that
and
every
time
we
run
up
against
that,
it's
come
down
to.
E
There's
really
no
value
to
it,
because
the
implications
for
the
whole
company's
ecosystem
would
be
so
high
that,
like
the
small
value
we
would
get
in
splitting
fields
or
renaming
them
will
be
overwhelmed
by
the
amount
of
work
and
change
they
would
cause
and
so,
for
the
most
part
object
meta
is
forward
compatible
only.
It
is
like
at
some
point,
maybe
in
the
far
far
future,
we'll
consider
changing
it
at
which
point
anybody
who's
generic
is
basically
broken.
So
yeah.
B
B
C
C
A
D
Give
context
to
my
questions
here:
what
you're,
looking
at
making
some
code
cleanup
changes
and
I
guess
I'm
wondering
is
new
developers
who
see
like
rest
mappings
in
the
code
like
we
confident
that
they're
not
going
to
introduce
these
same
sorts
of
problems
that
you're
describing
or
do
we
need
like
a
style
guide
or
something
like
that.
That
explains
appropriate
ways
to
use
fresh
mapping
and
where
to
do
what
I.
B
For
instance,
if
I
remove
an
object
converter
from
the
the
mapping
object
in
the
Builder,
we
would
all
notice
if
somebody
tried
to
add
it
back
in
terms
of
the
the
level
of
knowledge
for
these
particular
pieces,
know
that
that,
as
far
as
I'm
aware
is
not
written
down,
I'm
actually
impressed
that
I
don't
know
his
github
ID,
but
I'm
actually
impressed.
They
were
named
like
three
different
rest
members
movie
yeah.
E
I'm
three,
this:
this
is
something
we
should
do
more
good
document
at.
It
gets
to
like
some
of
the
abstractions
that
were
there
to
kind
of.
Let
us
be
somewhat
agnostic.
Some
of
them
probably
can
be
simplified
down.
Now
that
we
have
a
clearer,
are
they
getting
at
the
heart
of
that?
This
is
really
just
saying
now
that
we
clearly
are
going
to
have
more
less
hard
coding
or
less
deliberate,
go
type,
manipulations
and
a
lot
a
lot
more
generic
type
operations
and
cute
control.
Some
of
these
things
that
support
it.
E
F
F
B
I
think
that
the
answer
is
we
have
we
have
general
agreement
that
client
side,
things
that
are
dependent
on
conversion
should
should
be
segregated
and
that
things
that
rely
on
server
side
connections
should
only
do
so
if
they
actually
need
the
server
connection
and
everything
else.
That
falls
out
of
that
sort
of
flows,
right,
I'm,
probably
easier
for
people.
If
they
look
at
the
concrete
poles,
because
you
just
use
the
word
printer
four
times
and
fair
enough.
F
B
So
what
is
the
actual
item
here?
David
then?
The
next
steps,
the
next
steps
I,
think
that
either
myself
or
Juan
will
go
through
and
start
taking
a
targeted
look
at
which
pieces
of
the
rest
mapping
interface.
We
can
slim
down
and
usages
that
we
can
identify
as
improper.
We
will
start
poles
and
umbrella
issues,
tracking
individual
items,
okay
and
as
if
we
get
someone
has
significant
triples,
will
be
sure
to
get
a
wider
audience.
A
D
I'll
bring
up
one
thing,
which
is
that
in
the
steering
committee,
we're
looking
at
say,
governance
proposal
in
how
to
structure
roles,
and
so
I
expect,
maybe
in
the
near
future
that
we
will
want
to
look
at
that
and
bring
in
some
of
the
structure.
It
brings
specifically
at
looking
at
stuff
like
where
more
well
defined
roles
around
technical
leadership
and
also
the
operational
leadership
of
running
the
sig
in
meetings
and
stuff.