►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: CLI SIG - Maciej Szulik, Red Hat & Phillip Wittrock, Google
This "intro" session will provide basic information to facilitate new SIG CLI contributors. This session will present an overview of the "kubectl" code base, as well as the basics of the development process. We will give a short history of this project. We will leave a significant amount of time for Q&A.
https://sched.co/MPhC
A
Okay,
welcome
everyone.
My
name
is
ma
che
and
this
is
Phil
and
the
both
of
us
are
leading
the
6e
alight.
So
today,
I'll
spend
a
couple
minutes
introducing
our
sick.
What
we
do,
what
we
are
our
mission
in
short
and
then
I'll
jump
right
into
the
the
core
parts
of
the
cube
CTL,
meaning
how
to
develop
a
simple
cube,
CTL
plug
plug
in
command
or
basically
fix
a
bug
so
that
people
such
as
you
who
might
be
interested
in
contributing
to
the
to
the
cube
CTL
can
benefit
from
that
knowledge.
A
I
do
hope
that
this
will
help
you
get
started.
If
you
have
any
questions
at
any
point
in
time,
either
post-conference
I'll
leave
the
contact
details,
you
can
reach
me
out
on
on
slacks
and
first
Phil,
Twitter
and
whatnot.
Basically,
these
two
handles
work
throughout
slack,
github,
Twitter
and
whatnot.
So
what
we
do
so
in
general,
we
build
cubes
ETL.
What
is
keeps
ETL
keeps
ETL
is
the
main
kubernetes
CLI.
A
So
it's
a
client
for
interacting
with
kubernetes
cluster.
Of
course,
there
are
a
couple
additional
features
that
we
developed
over
time,
such
as
the
CLI
runtime,
which
is
a
set
of
helper
methods
for
building
cube,
CL
commands
or
plugins
if
you're
interested
in
doing
so.
What
is
important
is
that
the
CLI
runtime,
its
first
and
primary
consumer
is
cube
CTL,
which
guarantees
that
it
will
always
work.
A
The
additional
tools
that
we
adopted
over
the
past
six
months
to
twelve
months
is
crew,
which
is
a
plug-in
manager.
If
you
seen
our
talk
with
ahmed
two
hours
ago,
we
covered
the
tool-
it's
basically
a
plugin
by
itself,
but
it
allows
you
to
manage
and
install
plug-ins
for
your
environment
and
finding
customized
that
was
added
to
keep
seed
about
nine
months
ago
is
a
tool
for
declarative
workflow
for
improving,
declared
declarative,
workflows.
Think
about
apply
on
steroids,
with
some
additional
tweaks
that
he
want
to.
A
A
That's
myself
and
Phil
I'm
representing
Red
Hat
Phil
is
representing
Google
and
we
are
responsible
for
the
technical
leadership
in
our
sick,
which
basically
means
we
are
deciding
about
the
goals
for
the
next
couple
of
months
years,
where
the
sick
will
be
driving
and
we
are
ensuring
that
we
keep
the
track
as
is,
whereas
with
Shawn
Sullivan,
we
are
myself
and
Shawn.
We
are
responsible
for
organizing
the
sick
on
a
daily
basis.
A
That
means
running
the
meetings,
keeping
the
notes,
putting
the
recordings
of
all
our
meetings
into
the
YouTube
channel
so
that
you
can
view
them
afterwards,
if
you're
interested
in
what
happened,
as
well
as
keeping
the
notes,
I'm,
not
sure.
If
I,
like
the
notes,
what
are
the
couple
main
initiatives
that
we
are
working
on,
so
one
that
you
probably
have
noticed
if
you're
active
in
the
keep
CTL
area
is
that
we
are
moving
outside
of
the
main
repo.
A
Some
of
you
probably
stumbled
upon
kubernetes
/keep
CTL
repository,
which
exists
for
good
couple
years,
but
the
main
problem
of
that
repository
is
that
it
does
not
contain
the
cube
CTO
logic
nor
the
binary,
and
it
is
confusing,
even
though
that
some
parts
of
the
cube
see
related
code
exists
there
like
the
book,
which
is
the
documentation
parts
we
published
in
the
last
release,
thanks
to
awesome
work
from
Phil
and
his
team,
which
is
the
cube
CTO
book.
If
you
heard
about
that
one
lives
currently
in
keep
CTO
repo.
A
The
rest
of
the
contents
is
not
being
maintained
in
in
any
significant
way
and
actually
Shaun
sent
out
an
email
earlier
today,
or
that
was
maybe
yesterday
announcing
that
we
will
be
pruning.
The
contents
of
that
repo
and
all
the
important
bits
like
the
book
that
I
mentioned,
will
be
moved
over
to
the
main
repo
temporarily.
A
Also,
we
are
moving
quite
a
lot
of
functionality
over
to
the
server
one
of
the
major
refactor
that
we
did
in
that
area
in
the
past
months
were
server-side
printing,
so
meaning,
if
you
invoke
cube,
CTL
get
command
the
description
of
the
resources.
Are
your
C
and
your
CLI
are
not
actually
hard-coded
into
the
cube
CTL
itself
anymore?
Well,
rather,
they
are
coming
from
the
server.
This
ensures
that
any
consumer
of
the
API
can
have
consistent
output.
A
A
There
are
a
couple
of
others,
like
I've
mentioned
the
plugins
and
there's
a
lot
of
work
around
customized,
so
these
are
ongoing
projects.
If
you're
interested
I
completely
more
than
happy
to
see
you
all
on
our
bi-weekly
meetings,
our
regular
meeting
would
be
scheduled
for
tomorrow,
but
due
to
cube
con,
we
obviously
cancelled
that
one.
So
the
next
one
will
be
in
two
weeks.
These
are
held
at
6
p.m.
I
didn't
put
down
one,
but
it's
basically
6
p.m.
not
am
European
time.
It's
noon
for
the
u.s.
west-eastern
time
and
9
a.m.
A
for
the
Western
time
us
Western.
We
have
obviously
our
slack
channel
or
you
can
find
both
of
us
as
well
as
shown
as
other
members
of
the
6
Eli.
Who
will
be
more
than
happy
to
answer
all
your
questions?
If
you
have
some
PRS,
we've
used
issues
feel
free
to
reach
out
to
us.
If
you,
if
you,
if
you're
afraid
of
asking
this
publicly,
you
can
always
reach
out
privately
to
either
one
of
us,
and
we
will
be
more
than
happy
to
answer
your
questions
and
help
with
your
issues.
A
If
your
first
time
contributor
that
I'll
be
more
than
I'll,
be
more
than
happy
to
help
you,
and
actually
we
are
thinking
about
putting
together
a
mentoring
group
for
people
that
are
interested
in
contributing
to
keep
CTO.
Of
course,
there's
a
also
Google
group.
So
you
can
sign
up
on
that.
One.
So
you'll
see
the
information
about
what
is
currently
in
progress.
What
we
are
working
on,
it's
very
low
volume,
I,
would
even
say
once
twice
per
week:
there's
an
email,
so
it
doesn't
hurt.
It
won't
flood
your
your
your
inbox
in
any
way.
A
So
before
we
jump
over
to
the
cube
CTL
code,
baster,
which
I
do
hope,
will
help
you
to
get
familiar
with
the
code
base
and
I
know
that
there's
several
people
reach
out
to
me
asking
just
for
that.
One
and
I
gave
a
similar
tour
about
two
weeks
ago
during
one
of
the
contributors
meetings
on
YouTube.
Do
you
have
any
questions
at
this
point
in
time?
A
Okay,
so,
let's
get
into
the
tour.
So
the
entry
point
for
keeps
ETL
lives
in
cuba.
Kubernetes
comment
keeps
ETL
cube,
CT
I'll
go
and,
as
you
probably
you've
noticed
its
little
evil
very
minimal.
We
only
create
the
command
and
pass
over
the
entire
functionality
over
to
the
Cobra
command.
Cobra
is
a
CLI
library
created
by
I
can
remember
his
name
Frederico
SPF
13
is
his
github
handle
and
I'm
probably
saying
most
people
will
recognize
by
that.
A
So
SPF
13,
slash
Cobra,
is
how
you
find
him
and
the
library
on
on
github
and
basically
the
majority
of
the
go
based
code.
These
days,
that
is
CLI
based
will
be
using
his
library
because
it's
it's
pretty
cool.
So
let's
look
into
the
new
default,
keep
CTL
command,
what
it
does
it
actually,
aside
from
setting
up
the
functionality
and
commands
and
flags
it
registers
a
set
of
commands
all
of
the
commands
that
you'll
see
and
I'll
be
showing
you
in
a
minute.
A
We
group
the
commands
into
several
into
several
batches,
so
there
are
basic
commands
such
as
run
and
said.
There
are
intermediate
commands
for
getting
editing
and
deleting
resources.
There's
a
set
of
deploy,
related
commands
like
roll
out
scale
or
auto
scale.
There's
there's
a
set
of
cluster
management
command,
such
as
top
cluster
info
or
corazon,
anchored
on
notes.
A
There
are
troubleshooting
and
debugging
commands
such
as
attach
exec,
proxy
or
describe,
and
then
finally,
there's
a
set
of
advanced
and
settings
command
such
as
annotate
completions,
a
patch
apply
more
or
less.
That
I
do
hope,
that's
reasonable!
The
grouping
is
not
in
any
way
hard-coded.
We
can
always
change
that
one
if
we
see
the
need
for
it.
So,
but
honestly,
the
majority
of
the
code
that
I
showed
you
so
far.
You
will
be
rarely
attaching
I
can't
remember
touching
any
of
those
in
the
past
twelve
months
or
so
because
it
rarely
changes
well.
A
I
lied.
Of
course,
I
did
change
I
when
I
was
relocating
commands,
because
previously
we
didn't
have
good
code
organization.
I
did
changed
the
previous
file
that
I
was
showing,
but
honestly
it
won't
be
changing
that
fast.
So
the
main
part
and
where
actual
commands
live
is
inside
of
package
cubes,
ETL,
camed
and
then
inside
of
this
directory.
Each
and
every
single
command
will
have
its
own
directory,
except
for
some
few
rare
cases
such
as
API
resources
actually
has
two
command.
A
A
If
you
pass
server-side
print
false,
which
means
the
logic
that
was
hard-coded
in
cube,
CTL
will
fire
end
up
in
that
place
and
all
that
makes
the
get
command
not
as
easy,
as
you
might
think.
Also,
there's
support
for
whatching,
which
is
cube.
Ctl
get
the
watch,
so
the
watch
functionality
is
part
of
the
guys
command.
This
all
makes
the
get
command
grow
very
much.
So
if
you
want
to
start
fixing
I
would
discourage
you
from
touching
get.
A
It
is
complicated
even
for
us
current
contributors,
touching
it
it's
or
we
are
very
cautious
about
modifying
the
get
commit,
but
the
other
commands
are
very
simple.
As
take
the
API
resources
annotate,
they
are
usually
very
simple
and
let
me
show
you
how
the
annotate
command
works.
So
if
we
go
into
the
annotate
directory
before
I
jump
actually
into
the
actual
annotate,
they
usually
will
be
two
files.
Let's
ignore
the
build
file,
because
this
is
automatically
generated
for
the
basil,
which
is
one
of
the
build
process
being
used
inside
of
our
testing
infrastructure.
A
You'll,
probably
see
this
is
the
majority
of
cases.
There
will
be
two
files,
one
will
be
the
actual
command
and
the
other
one
will
be
the
unit
test,
sorry
and
the
unit
test
for
that
for
that
file.
So
looking
into
the
annotate
command
and
omitting
the
the
import
sections,
there
are
a
couple
important
factors
and
we
are
trying
to
enforce
this
pattern
across
all
of
the
commands
these
days.
A
Not
all
of
them
follow
this
patterns
and
get
is
one
examples
of
why
we're
not
following
get
is
one
of
the
examples
where
we
did
not
follow
to
the
new
patterns,
and
the
reason
is
that
it
would
cause
more
pain
for
us
to
rewrite
it
and
just
leave
it
as
is.
But
overall,
the
rule
is
that
we
followed
these
patterns
that
I'll
be
talking
about
more,
so
every
single
command
will
have
an
optional
structure.
A
The
option
structures
will
have
a
set
of
flags
that
the
command
exposes
you'll,
see
that
we
are
using
something
that
is
called
print
flags
and
resource
printer.
These
two,
these
two
object
that
are
at
the
top,
are
a
part
of
the
CLI
runtime
that
I
mentioned
before
that
we
are
maintaining
and
exposing
so
that
other
cube
CDL
common
writers,
plugin
authors
can
reuse.
We
are
reusing
the
same
inside,
of
cube
CTL.
A
These
provide
a
set
of
flags
which
is
the
first
one,
a
set
of
flags
for
printing,
so
if
you're
passing
Oh,
yum
or
JSON
or
whatever
this
exposes
that
functionality.
So
if
you
use
the
CLI
runtime,
this
is
what
you
get
for
free
and
then
the
resource
printer
is
the
actual
mechanism
responsible
for
printing
the
resource,
based
on
the
arguments
that
you
specified
before.
A
So
you
don't
have
to
handle
those,
because
if
you
can,
assuming
that
you're
only
writing
and
go
because
you
are
runtime
is
as
entire
could
keep
CTO
and
kubernetes
written
and
go
other
flags
are
for
filename
for
record
and
the
flags
for
actual
and
man
which
is
over
at
local
dry
and
whatever
not.
And
then
we
usually
put
a
set
of
helper
helper
arguments
that
we
want
to
pass
over
from
one
invocation
to
the
other
invocation
of
command.
A
Finally,
there's
the
I/o
streams,
which
is
an
object
that
is
just
holding
all
of
the
standard
in
out
in
their
streams.
So
after
we
have
the
structure,
I'm
gonna
skip
the
the
information
and
description
about
the
commanding,
because
I
do
hope.
It's
pretty
self-explanatory.
What
it
is
there
will
be
a
new
command
name
or
structure
named
option
structure
which
will,
by
default,
accept
IO
streams,
object
and
that
method
is
responsible
for
providing
the
default
values.
For
all.
Your
flags
that
you
are,
you
are
exposing
as
part
of
your
command.
A
In
that
particular
case,
we
are
setting
up
the
the
print
flag,
the
record
slacks
recorder
and
said
io
streams
or
whatever
was
passed
and
now
comes
the
actual
command.
The
actual
command
will
be
always
named
new
command
and
the
name
of
the
command.
It
can
accept
several
parameters,
we're
not
going
to
focus
on
them,
but
I'm
hope,
I
hope
that
they
are
self
explanatory.
At
this
point
in
time,
we
created
a
new
option
structure
that
we
just
discussed,
and
then
we
put
the
information
necessary
for
Cabra
library
to
create
a
command.
A
So
we
are
setting
the
usage
short
long
examples.
All
those
information
and
the
main
part
is
actually
the
run
command.
The
run
command
tells
the
code,
the
kobra
library,
how
to
execute
our
command
and
in
99%
cases,
you'll
see
three
invocations
as
part
of
that
run
command,
and
there
will
be
always
in
that
particular
order.
Complete,
validate
and
run
on
run
name
of
the
command,
and
let
me
I'll
cover
each
and
every
single
one
of
them.
A
In
a
minute,
then,
we
bind
the
flags
that
we
require
for
the
command
to
work
properly,
and
then
we
can
actually
jump
over
to
the
invocation
of
of
any
single
command.
So
the
first
method
that
is
pretty
much
required
for
every
single
command
is
the
complete.
The
complete
is
responsible
for
finishing
the
structure,
the
in
our
particular
case.
It's
annotate
options.
A
So
if
you're
invoking
cube
CT
on
annotate,
your
passing
resource
name
of
the
resource,
eventual
additional
flags,
part
of
the
complete
part
of
the
complete
invocation
is
to
parse
all
the
flags
that
were
passed
as
well,
as
do
initial,
create
a
client
set
up
setting
up
the
printers
and
invoking
complete
on
print
flags,
for
example,
or
recorder.
If
there
are,
we
are
also
creating
the
client
here
and
necessary
resources
for
the
command
to
actually
succeed
the
next
one-
and
this
is
that
depends
on
your
actual
command.
A
In
our
case,
annotate
option
does
have
validate,
and
the
validate,
as
you
might
probably
expect
from
the
name,
is
responsible
for
validating
this
structure.
That
is
why,
having
the
structure
is
very
important
because,
after
complete,
we
need
to
have
all
the
inputs
inside
of
the
structure
and
then
validate
ensures
that
the
structure
is
valid
and
let
me
step
back
and
explain
why
we
decided
to
go
with
the
structure
and
the
three
method
approach
beforehand.
It
was
very
hard
to
unit
test
each
and
every
single
command.
A
If
it
directly
accepted
STD
and
out
an
STD
error,
we
were
happy,
we
were
forced
to
either
mimic
the
or
it
was
not
easy
to
you
in
the
test,
each
and
every
single
command.
That's
why
we
figure
out
it's
better
to
have
a
structure
that
you
can
inject
whatever
testing
values
that
you
want
to
have
and
then
just
focus
on
the
actual
either.
If
you
want
to
test
validation,
fine
test,
the
validation
inject,
the
values
that
you
want
to
see
in
the
structure
and
verify
whether
it
is
working
the
way
you
expect
it
to
work.
A
If
you
want
to
test
the
actual
execution
of
the
method,
the
run
command,
you
provide
whatever
Flags
as
part
of
the
optional
struct,
and
then
you
just
run
the
run
method
and
verify
whether
the
X,
the
output
is
the
way
you
expected
it
to
be
so
after
validation
finishes.
Of
course,
at
any
point
of
time,
if
something
fails,
we
return
an
error
which
completes
the
execution
of
a
command,
and
the
run,
as
you
might
expect,
is
the
actual
logic
of
any
command.
A
So
in
the
majority
of
cases
the
run
is
the
matter
that
you
will
be
touching.
The
most
frequently,
of
course,
run
can
invoke
additional
methods
and,
in
our
particular
case
it's
very
simplistic,
there's
something
that
is
called
a
resource
builder
that
we
created
in
the
complete
method.
The
resource
builder
is
something
that
is
part
of
the
CLI
runtime.
The
resource
builder
is:
is
a
helper
function
responsible
for
reading
resources
from
either
a
file
or
remote
server?
A
That's
why
we
pass
over
the
client
to
it
so
that
it
knows
whether
he
wants
to
talk
to
a
client
and
how
to
reach
it
or
eventually
a
file
name,
because
it
there
is
an
option
to
pass
a
file
name
and
appending
on
how
you
pass
the
func
the
options
it
will
reach
out
and
get
the
object
that
you
requested
after
we're
done
and
we
have
the
resource.
We
invoke
a
simple
visitor
pattern
and
visit
each
and
every
single
object
on,
and
then
we
apply
annotation
per
user
specification.
A
That's
pretty
much
all
how
etch
each
and
every
single
command
will
look
like,
and
finally,
we
are
printing
the
resources,
unless
user
explicitly
asked
us
not
to
print
it,
although
I'm
not
sure
if
another
hit
has
some
questions,
there
are,
of
course,
several
halper
methods
I'm
not
going
to
dive
into
those
because
it
doesn't
doesn't
add
any
value
at
this
point
in
time.
So,
as
I
mentioned
before,
we
do
test
each
and
every
single
command,
and
there
are
three
possible
tests
that
can
happen
to
have
two
overall
keep
Cpl
next
to
every
command.
A
There
will
be
always
a
unit
test,
and
we
that
is
the
simplest
way
to
verify
if
the
command
functionality
is
is
executing
properly.
On
top
of
that,
there
is
a
test
command
inside
of
kubernetes
repo,
which
is
actually
a
set
of
bash
scripts,
which
are
invoking
cube.
Ctl
commands
against
a
sort
of
fake
cluster
API.
What
is
the?
Why
am
I
calling
this
cluster
API
fake,
because
we
are
setting
only
the
etcd
and
the
cube
API
server
and
that's
it?
A
There's
no
cube,
there's
no
queue
blood
running,
which
basically
means
there
will
be
no
pods
running
behind
it.
So
this
is
very
simplistic,
but
it
is
sufficient
to
to
verify
functionality
of
command
such
as
cube
CTO
label
or
cube
CT
Allen
Tate,
because
they
are
working
against
a
cube,
API
server
and
they
are
they
don't
need
the
cubelet
part
running
if
you
want
to
go
all
the
way
down
to
the
queue
blood
running.
So,
for
example,
you
want
to
verify.
A
If
cube
CTL
box
is
working
properly,
then
you
are
reaching
and
talking
about
end-to-end
tests,
which
are
part
of
the
test
e
to
e
there's
a
cube
CTO
sub
directory,
within
which
we
have
a
go
particular
that
ginko
and
Omega
based
test.
There
are
invoking
tests
against
a
fully
blown
kubernetes
cluster.
So,
for
example,
this
one
is
creating
cron
jobs
and
then
verifying
the
cron
job
is
actually
working
or
is
being
invoke
ated.
The
way
we
expected
it
to
be-
and
there
is
a
set
of
tests,
I.
A
Think
that's
pretty
much
the
majority
of
the
stuff
that
I
wanted
to
show
what
I
would
like
to
call
out
for
for
you.
If
you
are
interested
in
in
working
on
6
July
help
us
improve,
keep
CTO.
We
are
very
interested
in
changing
the
the
Bosch
written
test
into
a
testing
framework.
Sic
testing
wrote
an
amazing
framework
that
should
help
simplify
the
testing,
and
what
is
important
also
for
us
is
that
the
test
currently
can
only
be
executed
on
Mac
or
online.
It's
basically
anything
that
has
a
passionate.
A
A
So
if
you're,
curious
and
happy
about
working
on
that
part
of
the
project,
we'll
be
more
than
happy
to
accept
to
accept
PRS
slowly
moving
I'm,
not
saying
that
you
have
to
sit
in
one
shot,
we
write
the
entire
thing,
there's
a
lot,
a
lot
of
tests
and
the
tests
command
package.
So
if
you
want
to
do
it,
I
want
I
think
that
would
be
like
two
or
three
weeks
of
work
and
then
more
than
that
to
review
that
thing.
A
So
if
you're
interested
I
would
be
more
interested
in
having
like
filed
by
a
file
or
event
or
even
up
to
the
point
where
you
are
replacing
part
of
the
file
with
the
new
testing
I,
think
that's
the
majority
of
the
things
that
I
wanted
to
cover.
So
you
want
to
add
something:
okay,
so
does
anyone
have
any
questions.
A
So
the
question
was
whether
we
have
the
tests
invoked
on
every
single
PR.
Yes,
all
of
the
changes
to
govern
at
his
repo
and
eventually
to
give
you
keep
CTL,
have
a
very
broad
set
of
tests
that
as
being
invoked
as
part
of
the
test.
This
includes
both
the
unit
tests,
integration,
the
integration,
the
test
command,
as
well
as
the
e2e
tests.
A
A
Yes,
so
for
running
for
running
unit
tests,
the
simplest
way,
let
me
try
to
find
if
I,
if
I
have
basically
make
tests
and
then
you
do
you
what
and
then
you
can
pass
package,
keep
CTL
command
annotate.
That
will
run
the
unit
test
for
that
particular
for
that
particular
package.
Similarly,
you
can
write
yes.
A
Similarly,
you
can
run
test
command
and
then
specifying
wall,
and
the
wall
is
actually
that's
one,
probably
a
little
bit
more
tricky.
That's
not
the
directory
that
I
want
to
show
you.
So
each
and
every
single
test
in
the
test
command
has
follows
this
rule.
By
naming,
so
there
will
be
always
run
some
underscore
something
underscore
tests
and
that's
something
is
the
name
that
you
should
use
to
run
that
particular
test.
So
if
you
would
run
this,
that
means
only
this
function
will
be
run.
A
A
So
if
you
find
tests,
we
usually
have
a
documentation
above
a
particular
target
which
explains
wood
and
how
to
run
specific
stuff
the
same
for
test
command
and
what
is
a
list
of
tests
to
run
from
these
names
for
e2
East?
It's
a
little
bit
more
complicated,
but
basically
it
is
similar
to
invoking
ginko
command.
A
There's
no
make
file
script
for
for
running
particular
tests.
I
have
a
script
that
sets
up
my
local
cluster,
using
the
local
cluster
up
as
age
from
kubernetes
repo
and
runs
a
particular
test.
The
e2e
test
can
be
matched
narrow
to
only
a
single
e
to
e.
Just
passing
the
name
of
the
test,
which
is
usually
let
me
find
one
that
is
actually,
for
example,
cube.
Ctl
client
will
run
everything
that
is
part
of
here,
but
that
will
be
pretty
big.
B
A
B
True,
there's
other
commands
that
do
not,
and
so
how
what's
the
best
way
of
implementing
that
logic,
should
it
be
done
for
your
plugin,
so
scale
is
actually
done
through
a
stop
resource.
Now
you
can
specify
on
a
see
Rd,
which
replica
which
which
field
is
the
replica
field,
and
then
it
will
automatically
make
that
work
for
you
but
I.
Think
more
generally,
the
question
is
like:
if
it's
not
scaled,
that's
something
else.
B
What's
the
best
way
of
adding
that
command
and
I'd
say
right
now,
we
are
looking
at
a
way
of
publishing
commands
from
the
server
and
making
them
discoverable
as
forms
effectively.
So
if
you
look
at
how
web
browsers
work,
they
don't
compile
in
all
the
websites
in
the
world.
They
hit
a
server
and
then
ask
for
the
HTML
and
then
construct
a
form
based
on
that
the
user
can
submit.
B
Many
of
the
commands
include
control
are
a
similar
pattern
where
a
user
supplies
some
set
of
flags
to
fill
in
some
template
and
then
that
gets
sent
to
the
API
server
and
so
right
now
in
the
CLI
experimental
repo.
There
is
a
command
which
will
allow
users
to
publish
on
their
series
as
annotations,
arbitrary
commands
to
cout
control,
with
enough
data
to
to
create
a
Cobra
command
with
the
description
and
help
text
and
all
this
sort
of
stuff
and
send
requests
and
then
format
them
in
the
response.
A
To
also
add
a
little
bit
color
on
to
that
is
the
effort
that
we
have
with,
along
with
the
stick
API
Machinery,
is
that
a
lot
of
the
functionality
is
being
moved
over
the
server,
at
least
in
theory
as
where
we
are,
or
we
can
so,
for
example,
I
mentioned
earlier
today,
server-side
apply
so
the
end
goal
is
that
the
app
will
apply.
Logic
that
is
currently
hard-coded
into
cube.
Cto
will
be
moved
over
to
the
server
at
least
and
partially
so
that
other
consumers,
even
in
different
languages,
can
reuse
the
same
functionality.
A
I
also
mentioned
the
server-side
printing.
So
what
is
currently
keep
CTL
if
you
invoke
cube,
CTL
get
and
you
get
the
description
of
pot
or
whatever
resources
that
you
have.
This
is
provided
by
the
server
and,
if
you
in
case
of
see,
are
these
CR,
these
have
something
that
is
called
additional
print
columns
if
I
remember
correctly.
This
is
how
you
decide
what
will
be
those
columns
that
will
be
printed
aside
from
the
creation,
timestamp
and
the
name
which
are
printed
by
default.
B
I
guess
and
then
the
last
piece
is
the
way
that
scale
is
implemented
is
through
a
sub
resource.
Yes,
and
that's
how
the
client
is
able
to
discover
it.
For
you
know,
if
you
don't
know,
a
sub
resource
is
basically
like
a
method
on
top
of
a
resource,
so
it
allows
you
to
call
that
method
for
particular
resource,
and
so
there
is
discussion
now
about
what
sub
resources
makes
sense
for
CR
DS
right,
because
you
could,
you
could
build
them
as
web
hooks,
for
instance,
and
allow
arbitrary
sub
resources
to
be
published.