►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Kubectl Plugins 101 - Jonathan Berkhahn, IBM & Carolyn Van Slyck, Microsoft (Intermediate Skill Level)
Learn how to add custom commands to kubectl and write your first plugin. If you have written a bash script that extracts data from kubectl output, then you are already halfway there! Plugins can add powerful new commands to interact with Kubernetes, saving you time and keystrokes. This session will showcase lessons learned from our development of a kubectl plugin for the Kubernetes Service Catalog. Whether you are a Kubernetes user looking to script common commands, a developer building custom Kubernetes resources, or a provider looking to encapsulate specific functionality for your users, come learn how to write your own custom commands using kubectl plugins.
"About Jonathan
Jonathan is a current contributor to the Open Service Broker API and the Kubernetes Service Catalog project, working with contributors from many companies Previously, he was a core Cloud Foundry contributor for several years, working on components ranging from the controller, the backend runtime, routing tier, and frontend. He has previous speaking experience at Cloud Foundry conferences in the US, Europe, and China.
About Carolyn
Carolyn is a software developer based in the wilds of suburban Chicago, working remotely on the Microsoft Azure Containers team. Her passion is developer tools, and automating all the things with a sidecar of containers. She is a maintainer for the Go dependency manager (dep), a Kubernetes contributor, and Service Catalog SIG member. As an organizer for Women Who Go, she regularly hauls her cookies across the world to share her love of Go, Kubernetes, and excessive emoji with her peers."
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
B
B
A
A
What
that
looks
like
and
then
Carolyn's
gonna
go
over
a
bunch
of
simple
plugins
and
some
more
complex
plugins,
to
show
you
sort
of
the
problems
base
of
what
you
can
write,
what
you
can
do,
we're
gonna
go
over
some
beef
tips
for
writing
your
own
plugin
and
then
we're
gonna
talk
about
the
future
of
plugins
cuz.
It's
currently
under,
like
I,
said
active
development.
It's
very
much
sort
of
in
the
works
at
the
moment.
A
Ok,
so
why
are
we
here?
Why
should
you
listen
to
us?
So
we
both
work
on
Service
Catalog,
which
is
an
extension
project
for
kubernetes,
as
an
extension
project,
implements
a
whole
bunch
of
custom
resource
types
since
it's
kind
of
an
older
project,
so
it
existed
before
CRTs
or
even
a
thing.
So
we
have
our
own
API
server,
our
own
resource
types,
our
own
controller,
and
it
can
be
kind
of
cumbersome
to
interact
with
our
resources
using
just
cube,
create
cube
edit
coop
apply.
A
How
did
we
end
up
solving
this
problem?
Carolyn
had
been
already
working
on
sv
cat,
which
started
life
as
a
standalone
sea
life.
Just
for
interacting
with
service
cataloging
has
a
whole
bunch
of
commands,
some
of
which
are
sort
of
reimplementation
zuv
kubernetes
commands
such
as
get
some
of
which
have
nothing
to
do
with
core
kubernetes
commands
and.
A
To
turn
that
into
a
plugin
it
currently
exists
today
you
can
still
use
it
in
standalone
mode
or
you
could
install
it
as
a
coupe,
CTL
plug-in
and
have
it
live
right
there
in
coupe,
CTL
other
commands
so
and
to
date.
As
far
as
we're
aware,
this
is
the
first
and
the
only
plug-in
that
anyone
in
the
kubernetes
community
has
written
to
actually
attempt
to
perform
useful
work.
First.
A
A
Our
hope
is
that,
after
after
today,
you
will
go
out,
you
will
write
your
own
plugin.
It
will
be
awesome
now.
This
is
good
for
a
couple
reasons:
one
we're
interested
in
there
just
being
more
plugins
in
existence,
so
people
can
use
them.
That's
benefit
the
kubernetes
developer
community.
It's
benefit
to
people
who
use
kubernetes
if
there's
just
more
plugins
that
do
more
interesting
things,
so
people
can
use
them
reason.
2
is
that
plugins
are
still
under
very
active
development
and
we
are
currently
sort
of
the
only
stakeholders.
A
So
if
we
had
more
users
or
more
developers,
rather,
if
plugins
out
there,
it
would
provide
more
feedback,
60
ly
on
what
plugins
should
be,
what
features
they
want
that
sort
of
thing,
so
that
would
be
super
helpful
yeah.
So
sorry,
ok,
so
what
is
a
plug-in
right
now?
A
coop
CTL
plugin
consists
of
two
pieces.
One
of
them
is
actually
entirely
optional,
so
we
have
some
sort
of
executable
and
a
plug-in
that
animal
file.
A
Really,
you
only
need
the
plug-in
the
animal
file,
but
we'll
cover
that
in
a
minute,
so
the
executable,
it
can
be
pretty
much
anything
that
runs.
It
could
be
a
bash
script.
It
could
be
going
executable,
it
could
be
a
ruby
script.
It
could
be
pretty
much
anything
written
any
way
you
want
could
do
anything
you
want
us
to
do.
A
The
one
we've
worked
with
mostly
I've
been
go
excuse
because
there
you
know
a
part
and
parcel.
They
use
client
go
that
kind
of
stuff
to
interact
kubernetes,
but
you
could
you
could
roll
your
own.
However,
you
want,
and
it
takes
in
a
whole
bunch
of
helpful
information
from
the
calling
coop
CTL
environment
by
these
environment
flags
to
let
you
know
about
what
context
coops
ETL
was
invoked
with
whether
people
you
know
we
were
invoked
it
with
a
specific
namespace
throne.
A
What
were
some
environment
variables
we'll
go
over
that
in
a
minute,
but
it
takes
and
how
much
information
why
these
invite
my
flags
and
it
lives
in
the
dot
coop
hidden
directed
at
the
rest
of
the
coop
CTL
stuff,
like
account
fake
and
all
that
it
just
sort
of
hangs
out
in
there
right
next
to
the
Yama
file,
so
the
mo
file
is
actually
the
only
required
part
of
the
plugin.
It's
a
description
of
the
various
commands
and
their
flags
and
how
to
invoke
them.
A
B
I
wrote
the
tiniest
absolute
plugin
possible
to
show
you
that
you
can
start
small,
do
something
fun.
This
is
it
literally.
Oh
man
I
actually
use
this,
so
it
doesn't
seem
like.
Why
would
this
be
interesting?
But
so
what
it
is
is
I
called
my
plugin
flags
I
have
a
little
short
description
and
what
it
does
is
it
basically
dumps
back
out
all
the
environment
variables
that
keep
CTL
feeds
into
your
plugin,
to
give
you
context
about
where
you're
running?
B
What's
the
cluster,
all
that
kind
of
fun
stuff
and
all
the
magic
is
on
that
command
line
right
there,
bash
Dash,
C,
E
and
V
and
I
just
dumping
out
all
the
environment
variables,
so
I
didn't
even
have
to
write
a
binary
or
anything
like
that
and
then
just
for
fun,
I
defined
a
flag.
So
we
could
see
what
that
looks
like
so,
let's
go
in
here
and
make
this
much
bigger.
B
B
B
B
So
I
have
a
couple
different
plugins
installed
and
cube.
I
have
a
Flags
plugin
that
has
absolutely
nothing
in
it,
but
that
one
yamo
file
I
have
a
kill
plug-in
which
we're
going
to
do
next
and
SV
cat,
which
has
as
we
can't
you
know,
compiled,
go
binary
and
it's
plug-in
demo
any
want
to
see
something
scary.
Let's,
let's
take
a
look
at
what
that
looks
like.
B
It's
just
yeah,
as
we
can't
is
actually
an
interesting
thing,
which
is
why
we
bothered
to
make
a
plugin
for
it.
It
also
means
that
our
plugin
demo,
which
specifies
every
single
command
and
flag
that
we
support,
is
so
hard
to
maintain
that
we
actually
generate
it
and
I'll
talk
about
that
later.
How
if
you're
writing
something
more
interesting
than
the
flag's
plugin,
how
to
kind
of
keep
up
to
date
with
something
like
that?
B
So
let's
look
at
a
real
plugin
that
maybe
demonstrates
why
you
would
want
to
try
to
make
a
plug-in
in
the
first
place.
So
I
wrote
a
little
plugin,
a
killer,
plugin
called
kill
and
it
doesn't
do
anything
terribly
exciting,
but
what
it
does
it
I,
don't
know
it
depends
if
you're
writing
stuff
with
finalized
errs.
It's
it's
very
useful.
So
the
deal
was
finalized
errs.
Is
that
if
I
hope
say
a
pod
and
I
put
a
finalizar
on
it
and
then
I
try
to
delete
it?
B
You
know
I
do
keep
CTL
delete
the
name
of
the
pod.
It
actually
won't
delete
until
that
finalizer
is
gone
and
that
can
kind
of
be
annoying.
We
find
keeps
ETL
edit
that
gets
old
really
fast,
and
I
think
this
is
kind
of
the
point
of
plugins.
Is
you
don't
have
to
be
a
cig?
You
don't
have
to
be
some
like
advanced
developer
or
be
doing
crazy
things.
It
could
just
be
here
common
things
that
I
do
and
normally
I
put
into
a
bash,
alias
or
helpful
scripts,
or
anything
like
that.
B
You
can
actually
put
directly
in
the
cube
CTL
and
the
reason
why
you
may
want
to
do
that
is
to
share
it
with
people,
because
this
is
probably
a
useful
thing
to
do
so.
I
wrote
a
plug-in
called
kill
that
takes
in
a
grace
period
and
rips
off
any
finalized.
Errs
and,
like
you
know,
don't
use
this
in
prod,
but
you
know
it's
about
dev,
it's
very
easy,
useful,
so
my
kill
function.
This
is
all
go.
B
I
load
up
a
client
and
I'll
show
that
in
just
a
second
and
what
I
do
is
I
just
use
the
regular
client
go
and
I
delete
all
the
finalized
errs
and
then
I
new
get
not
terribly
interesting
there,
and
so
this
is
what
it
would
look
like.
So,
let's
take
a
look
at
all
my
pods
at
the
moment
and
I'm
gonna
destroy
one
of
them,
so
I'm
gonna
do
keep
CTL
plugin
and
this
time
it'll
be
kill
and
I'll
just
put
in
the
name
of
this
pod
and,
let's
make
sure
that's
big
enough.
B
So
there's
a
couple
things
when
you're
writing
a
plug-in,
especially
if
you
go
through
the
go
way
that
you're
probably
going
to
end
up
wanting
to
do
pretty
quickly.
The
first
thing
I
ran
into
was
that
we
use
blog
in
the
client,
go
library
and,
if
you're
familiar
with
clock
at
all,
you
know
that
it
doesn't
handle
flags
as
gracefully
as
you
wanted
it
to.
So.
If
you're
curious,
what
is
the
special
to
art
King
commands
table?
B
Very
helpfully
gets
in
the
way
of
everything
else,
and
instead
of
having
a
flag
for
grace
period,
I
grabbed
it
off
of
environment
variable
here
and
then
I
go
to
kill
my
pod.
So
this
is
where
we're
trying
to
build
up
a
greater
library
of
things
to
help
you
make
plugins.
So
this
is
something
that
Jonathan
wrote.
It's
in
upstream
Kate's
cube
CTL,
it's
called
plug-in
utils
and
it
handles
grabbing
all
of
those
various
global
flags.
I
mean
you
saw
the
list.
B
It
was
quite
large,
it
goes
not
all
of
them,
but
all
the
really
important
ones.
It
goes
through.
Those
flags
parses
them
and
then
gives
you
a
cube
config
that
you
can
use
to
then
load
up
as
a
client
and
start
doing
what
you
cared
about
doing
so
for
my
little
kill
plugin,
this
is
all
I
had
to
do
was
say
in
it
client
and
config,
and
then
make
up
my
config
object
grab
off
the
current
namespace.
B
B
So,
let's
take
a
look
at
SVG
at
because
it
does
a
heck
of
a
lot
more
than
any
of
these
plugins.
You
can
run
it
in
plug-in
mode.
So
this
is
what
it
would
look
like
cube,
CTL
plugin
as
we
can't
get.
We
have
brokers,
it
doesn't
matter
and
it'll
print
out
nicely
formatted
information
for
you
at
that
point.
I
think
Jonathan
is
the
only
one
who
insists
on
running
it
as
a
plugin
at
the
moment
we're
actively
working
with
the
six
elie
to
improve
what
this
looks
like
and
in
the
future.
B
It
will
be
much
nicer.
It'll
pie
just
be
cube,
CTL
as
we
cats,
or
maybe
even
something
more
brief
than
that.
But
what
most
of
us
do
is
we
just
use
the
binary
directly
get
brokers?
So
a
couple
of
things
that
service
catalog
has
is
the
ability
to
have
a
connection
between
your
your
cluster
and
whatever
the
cloud
surfaces
are
of
the
platform
that
you're
running
on
today,
bi
manager,
I'm
on
Google
I'm
on
IBM's
thing
that
I
forgot
the
name
for
our
site.
B
You
can
list
out
all
the
different
capabilities
and
as
the
service
things
that
you
can
provision.
So
if
I
do
get
classes
on
this,
cluster
I
can
provision
the
best
databases
there
are.
This
is
actually
from
mini
broker,
which,
if
you
saw
Jeremy
talk,
is
the
best
broker
and
it
runs
inside
your
cluster
and
just
provisions,
things
as
containers
and
it's
very
useful
when
conference
networks
are.
B
So
this
isn't
terribly
interesting
like
yet
classes
like
well,
big
whoop
I
could
have
done
that
with
cube,
CTL
I
could
have
gone
cube,
CTL
get
cluster
service
classes.
We
have
a
very
verbose,
4
resource
names,
which
is
one
of
the
reasons
why
we
wanted
this.
It's
not
quite
as
helpful
but
you're
like.
Oh
that's,
not
so
bad.
Why
did
you
write
a
plugin?
So
let's
do
another
one.
Let's
do
SV
can't
get
bindings,
which
is
another
thing
and
I'm
showing
a
whole
bunch
of
information
and
like
that
ready,
you
won't
find.
B
So
bindings
are
associated
with
secrets,
and
so
in
this
case
we
have
a
secret
on
the
cluster
named
my
DB,
but
like
the
99%
case
of
what
I
want
to
do
when
I'm
looking
at
a
binding
is
actually
figure
out.
Well,
what
are
the
keys
within
the
secret
and
possibly
decode
it
and
see
what's
going
on
there?
So
this
is
another
example
of
where
keep
CTL
doesn't
quite
get
us
where
we
want
to
go.
B
We'd
have
to
execute
multiple
commands
and
it's
like
a
number
of
commands
and
then
base64
decoding
every
single
one
of
those
keys,
and
no
one
wants
to
do
that.
I
certainly
don't
want
to
do
that,
and
so
this
will
just
allow
you
to
do
a
bunch
of
commands
like
a
porcelain,
command
and
git
and
lets
you
bring
that
all
together,
so
we're
working
with
six
Eli
to
kind
of
figure
out
a
better
way
to
make
all
this
happen,
but
I.
Hopefully
you
see
like
the
value
in
why
they.
B
Why
we
did
this
one
more
ugly,
I
can
show
you
because
who
doesn't
want
to
show
all
the
ugly
is
keep
CTL
like
they
say
you
wanted
to
see
everything
about
it
like
this
describe
the
equivalent
if
I
do
describe
service
binding.
My
TB
I
get
some
of
this
back
but
like
going
through.
This
is
kana
awkward
and
not
terribly
helpful
and
eventually
we'll
get
more
control
over
the
formatting.
But
at
the
moment
the
usability
experience
for
this
was
really
hurting
us
onboarding
people
onto
our
project.
C
A
So
and
that
version
of
SP
cap
that
we
showed
is
actually
it's
still
in
active
development,
so
that
you
know
we
have
I,
don't
know,
I.
Think
it's
like
around
a
dozen
commands
at
this
point,
we're
still
adding
more
every
everyday,
because
not
only
are
we
adding
commence
to
interact
with
these
independent
resources
that
we
added
brokers
and
classes
and
all
that
we
also
want
to
add
sort
of
medic
commands
things
that
wouldn't
really
make
a
whole
lot
of
sense.
A
Ascore,
Cooper
Nate,
like
extensions
of
CI
DS,
so,
for
instance,
the
Service
Catalog
has
the
sort
of
notion
of
a
marketplace
which
isn't
directly
tied
to
a
single
resource
type.
It's
sort
of
a
notion
of
like
what
services
can
I
buy
on
this
thing
and
it's
sort
of
an
amalgamation
of
brokers,
classes
and
plans.
We
want
to
be
able
to
have
our
own
command
that
sort
of
provides
information
about
all
of
those
things
and
once
would
have
helpful
to
find
place.
Yeah.
B
B
Otherwise,
a
couple
suggestions,
I'm
sure
you
notice
that
we
use
verbs
like
get
and
describe
when
we
do
things
like
that.
It
was
on
purpose.
It
wasn't
to
confuse
people.
It
was
to
provide
a
pathway,
a
migration
path
to
an
eventual
esv
cat,
isn't
a
standalone
binary,
and
maybe
in
this
wonderful
future
you
could
type
cube,
CTL
get
classes
and
you,
the
output,
that's
coming
from
our
plugin
was
the
hope.
B
So
we
didn't
want
to
have
any
of
the
flags
or
the
syntax
or
the
output
vary
too
much
from
what
keeps
ETL
does
today,
and
then
you
notice,
a
lot
of
the
output
looks
very
similar.
One
of
the
things
we'd
like
to
work
with
six
CLI
is
to
bring
some
of
the
printers
and
export
a
little
bit
more
of
that
logic,
so
that
we
can
make
use
of
it
inside
of
our
plugin
at
the
moment,
we're
just
being
really
good
at
mimicking
what
it
looks
like
for
the
most
part
and
then
otherwise.
B
I
do
recommend
avoiding
replication
of
cube
CTLs
core
functionality
whenever
you
can
so
that
as
the
plug-in
model
evolves,
you
don't
end
up
having
written
some
sad
amount
of
code
that
is
going
to
be
deleted.
When,
eventually,
we
have
a
proper
plugin
experience
in
cubes,
ETL
I
want
to
go
over
a
couple
of
the
gotchas
and
tricks
that
you
need
to
know
when
you're
working
on
a
plugin
one,
as
I
mentioned
before
I'll
type
in
at
the
command
line.
B
All
of
these
different
flags
and
they're
coming
to
me
as
environment
variables,
which
is
fine
depending
on
what
you're
doing,
but
when
it
comes
to
doing
things
like
loading
in
all
my
configuration,
that
can
be
a
huge
pain
very
quickly,
so
I
definitely
recommend
use
Jonathan's,
plug-in
utils
for
a
consistent
way
to
load
up
your
client
have
a
handle
of
the
flags
and
figure
out
what
the
current
namespace
is.
So
that
you're
not
rewriting
a
lot
of
logic
out
there
and
then
otherwise.
B
If
you're
trying
to
write
a
plug-in
if
you're
anything
like
me,
you
immediately
want
to
use,
go
and
then,
if
you're,
anything
like
me,
you
immediately
go
like
Cobra
is
the
best
thing
ever
and
if
you're
not
like,
tell
me
what
you're
using
so
Cobra
is
one
of
the
libraries
and
NGO
that
handles
flight
parsing.
It's
a
it's
a
higher-level
one
built
on
Flag
and
it
allows
you
to
not
have
to
write
yourself.
How
do
I
purse
equals
or
space
whatever?
B
So
your
are
two
functions
that
we
use
to
allow
us
to
handle,
running
and
plug-in
mode
and
running
in
standalone,
binary
mode.
So
I
have
this
handy.
Little
function
called
is
plugin
and
it
just
checks
for
the
existence
of
an
environment,
variable
and
then
I
know.
No
sane
person
would
ever
have
this
they're
machines,
so
I'm,
probably
in
plug-in
mode,
hopefully
yeah
and
then
otherwise
bind
environment.
Variables
uses
another
library
that
was
also
written
by
SPF
13
that
handles
basically
all
the
configuration
you'd
ever
want
to
do.
B
It
knows
how
to
handle
configuration,
files,
environment
variables
and
flags,
and
this
is
the
magic
glue
that
smooshes
it
all
together
and
feeds
it
into
your
standard,
Cobra
stuff,
so
that
none
of
our
other
code
is
aware
that
it's
a
plug-in.
So
there
isn't
huge
overhead
I
wrote
these
two
functions
and
tada
I'm
a
plugin.
So
again,
Glock
is
silly.
You
need
to
do
a
little
bit
of
fiddling
to
buying
glogs
information
and
then
otherwise.
Vip
set
environment,
prefix
VIPs
for
Viper.
B
B
Ctl
plugins,
local,
flag,
foo,
which
is
a
mouthful
and
the
last
bit
essentially
rips
through
all
of
Vipers
configuration
and
applies
it
to
Cobra,
and
at
that
point
once
this
is
run
you're
free
and
you
don't
have
to
worry
about
whether
or
not
your
plugin
anymore,
otherwise,
the
biggest
kicker
that
I
ran
into
when
I
first
started.
Writing
plugins
is
that
there
are
reserved
flags
in
cube
CTL,
you
know
what
they
are
by.
Writing
keep
CTL
options
that
will
list
out
a
big
list
of
all
their
short
flags
and
long
flags
for
you.
B
If
you
happen
to
use
one
of
those
and
define
it
in
your
plugin
demo,
it
will
just
not
load
your
plugin
and
it
won't
tell
you
why
it
doesn't
matter
how
high
you
set
for
both.
You
will
not
know
why
it
didn't
load,
your
plugin,
so
just
avoid
them.
The
common
ones
that
you
may
have
had,
because
you
were
running
in
standalone
mode,
is
contacts
config,
v4,
verbose,
end
for
namespace
stuff,
like
that.
B
So
I
have
a
little
bit
of
extra
logic
that
strips
this
out
before
I
code,
John
that
a
plug-in
demo
and
then
the
last
little
like
gotcha,
but
don't
worry,
I
have
open
PR,
for
this
is
that
it
doesn't
handle
boolean
flags.
Yet
a
boolean
flag
is
where
you
can
just
go
name
of
the
flag,
and
you
don't
say
true
or
false.
Its
existence
means
that
that
flag
is
true.
B
A
A
However,
plugins,
as
a
concept
are
here
to
stay,
so
the
60
light,
generally
speaking,
they're
pretty
sure
they
want
plug-ins
to
be
a
thing.
What
that
means
may
change,
because
the
current
proposal
is
to
move
towards
the
get
plug-in
model
where,
if
you
call
coop
CTL
with
a
command-line,
but
it
doesn't
recognize,
it
looks
through
your
path
for
some
binary
named
coop,
CTL
command
name,
and
if
it
finds
it,
it
calls
it.
What
does
that
mean?
A
That
means
that
if
you
wrote
a
plug-in
today
under
the
current
model,
as
long
as
you
adhered
to,
keeping
it
a
binary
making
it
not
steal
one
of
the
names
of
a
core
command,
it
would
be
fairly
easy
to
transfer.
So
our
hope
is
that
that
doesn't
scare
you
away
from
writing
plugins
because,
like
I
said,
we
need
more
users,
we
need
more
developers.
We
need
more
people
participating
in
this
ecosystem.
A
B
I
have
some
control,
controversial
recommendations
that
no
one
may
agree
with
other
than
me,
but
since
I
wrote
us,
we
cat
and
it's
the
only
plugin
I,
get
to
make
the
recommendation.
I
really
strongly
suggest
that
you
I
know
that
they
give
you
all
that
nice
magic
with
the
environment
variables,
but
honestly,
as
students,
you
start
writing
anything
that
isn't
even
remotely
trivial,
you're,
probably
going
to
end
up
wanting
to
write
just
a
standard
binary
and
obviously
go
because
Gophers.
B
That's
already
a
cube,
CTL
verb,
because
eventually
right
now,
you
run
it.
You
say:
cube
CTL,
plug-in
SV
cat,
but
eventually
that
plummet
plug-in
sub
command,
that
we're
using
during
alpha
will
go
away,
and
if
you
collide
with
an
existing
verb,
guess
who's
gonna
win.
It
won't
be
you
so
don't
make
a
plug-in
called
logs
course.
A
Yeah,
so
there's
one
more
thing:
I
want
to
mention
that
this
page
feel
free
to
download
our
slides
the
link
there
and
get
plug-in
models,
a
link
to
the
current
plugin
proposal
and,
like
I,
said
we're
looking
for
more
people
who
have
comments.
So
please
down
the
slides,
read
the
proposal
say
you
like,
it
stinks,
I,
don't
know
whatever,
but
we
need
more
opinions
holy.
B
A
So
this
is
just
a
couple
links
to
resources
for
writing.
Plugins.
The
first
is
just
a
link
to
the
coop
CTL
documentation
about
what
a
plug-in
is.
The
second
is
a
link
to
my
library.
So
this
is
the
library
I've
written
just
kind
of
for
to
help
myself
when
in
the
process
of
writing
svk
it
whenever
I
need
to
parse.
A
You
know
the
new
some
new
flag
that
coop
CTL
passes
to
us,
rather
than
just
writing
it
and
sticking
in
our
code
base
I've
been
attempting
to
extract
it
into
a
go
Lang
library
that
is
can
can
be
used
for
any
plugin
for
anything.
So
currently
we
have
support
for
most
of
the
big
ones.
Namespace
context
config,
but
there's
like
a
hundred
and
some
flags
that
get
passed
in
so
I'm,
just
adding
them
as
I
go
along.
A
B
Yeah
I
do
so
I,
one
of
the
things
I
was
recommending
to
you
was
I.
You
know
I'm
a
shill
for
go.
You
know
you
write
your
plugin
and
go
use
Cobra.
If
you
go
down
that
path,
if
you
and
you
end
up
writing
something
complicated
enough
that
you
manually
generating
that
plug-in
that
you
know,
if
I
as
a
huge
pain
in
the
butt,
my
threshold
is
like
one
command
and
then
I'm
not
willing
to
do
it
anymore.
I
have
a
little
library,
that's
inside
of
SV
cat.
B
That's
exported
that
you
can
use
it's
just
two
lines
of
code
where
you
can
give
it
your
Cobra
command
the
root
command
for
your
entire
app
and
it'll
generate
the
plug-in
diamo
for
you,
and
then
you
can
just
write
it
to
the
file
system.
So
don't
don't
rewrite
that
it's
it's
already
out
there.
So
I
wanted
to
come
up
with
a
couple
ideas
for
what
you
could
do
to
write
a
plug-in,
because
you
know
this:
like
fell
in
our
laps.
We
were
six
CLI
and
our
six
service
catalog.
B
We
needed
a
CLI,
and
so
it
kind
of
like
forced
us
to
go
down
this
path.
If
you're
writing,
CR
DS
and
you
have
maybe
custom
verbs
or
porcelain
commands
that
combine
multiple
actions
into
one
or
you
want
to
just
totally
go
hog-wild
on
your
output
or
hit
external
services.
All
these
kind
of
things
that
just
tweaking
what
cube
CTL
is
showing
it
won't
be
enough.
B
A
plug-in
may
be
a
good
thing
for
you,
the
plugin
that
I
was
totally
gonna
write
on
the
plane,
but
then
I
like
slept,
who
know,
is
the
wait
plug-in,
and
this
is
example
in
my
mind,
of
like
something
that
is
incredibly
useful.
I
just
deployed
something
and
it's
a
deployment
and
I
used
keeps
yellow,
deploy
it
now.
I
just
need
to
wait
until
it's
ready
to
use
and
available
I.
Don't
know
if
you
have
the
magic
bash
for
that.
B
That
works
every
single
time
like
send
it
to
me,
but
otherwise,
like
goodness
I
just
want
wait.
So
the
plugin
is
going
to
be
cube.
Ctl
plugin
wait
and
then
the
name
my
deployment
and
whatever
magic
bash
scripts
I
use
to
set
up
clusters
and
install
my
software
I
will
use
that
immediately.
So
maybe
next
week
this
will
be
posted
and
you
can
use
that.
Otherwise,
any
time
you're
running
in
a
batch,
alias
or
crazy
functions,
you
can
turn
it
into
a
plug-in
and
you
don't
even
need
to
do
the
binary
part.
B
You
can
just
shove
that
into
the
plug-in
Gemmell
put
in
whatever
magic
commands
you
need
and
you
can
share
it
with
people.
Another
idea
is
a
troubleshooter
plugin.
So
let's
say
that
you're
writing
some
application
that
runs
on
top
of
kubernetes
and
it's
more
complicated
than
a
single
service
or
a
single
deployment
and
health
checks
are
individual
on
each
one
of
these
components,
but
I'd
like
to
see
for
an
entire
cluster
where
my
application
is
installed.
B
Why
is
it
not
working
having
something
that
can
run
through
a
series
of
health
checks
and
a
checks
and
identify
like
actually
I
scraped?
Your
log
for
your
API
server
and
I
found
this
message,
which
means
this:
you
need
to
fix
that
or
Oh
DNS
is
down
something
like
that.
These
are
useful
things
that
normally
people
would
either
just
like
write
in
a
wiki
somewhere
and
having
that
just
be
an
instant
I
found.
B
A
These
are
just
a
couple,
more
ideas,
recording
of
having
a
plugin
that
will
let
you
record
and
replay
macros
of
pre-existing
coups,
ETL
commands
so
I
know.
A
lot
of
us
probably
have
workflows
of
these
five
things.
We
always
do
in
a
row
all
right.
You
know
tarting
a
certain
context,
all
that
this
would
just
be
something
that
would
be
helpful
to
help
automate
that
in
a
way,
that's
more
reproducible
than
a
bash
script.
A
A
B
A
C
B
So
I
wrote
a
standalone,
go
binary
and
I
drop
it
inside
of
the
cube
CTL
plugins
directory
I
have
two
ways
of
executing
that
one
is
I
can
just
type
s.
We
can't
use
the
binary
directly.
Another
I
can
use
it
through
the
cube,
CTL
plug-in
architecture
at
the
moment,
because
the
architectures
is
in
flux
as
it
is
most
of
the
developers
choose
to
run
it
in
standalone
mode
but
long
term.
We
want
it
to
be
a
hundred
percent
plug-in
yeah.
C
So
the
reason
I
brought
this
up
was
from
a
developer's
perspective.
I
totally
get
that
I
totally
see
that
from
an
end
user
perspective-
and
we
saw
this
mistake
in
OpenStack,
where
each
main
component
had
its
own
different
command-line
client
tool.
Yes,
huge
disaster
from
impacting
usability,
people
could
not
learn
how
to
use
all
the
components
they
literally
had
to
build
a
new
OpenStack
client
that
unified
that
all
back
so
I
know
from
a
developer's
perspective.
C
It
feels
good
to
do
that,
but
somehow
that
has
to
kind
of
go
away
quickly,
because
what
that
does
to
your
end,
users
is
just
it's
just
brutal,
don't
know
if
there's
just
one
but
wait
is
let's
say
sherry
or
for
other
projects.
Do
that
and
you
will
have
the
biggest
usability
impediments
that
you've
ever
seen,
and
so
please
don't
reinvent
old
mistakes.
Sure.