►
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).
SIG CLI Deep Dive - Phil Wittrock, Google (Intermediate Skill Level)
Technical deep dive into the techniques and best practices used in developing kubectl as well as many of the challenges faced. Will cover using the Discovery Service, OpenAPI and subresources to support client/server version skew and API extensions. Will also cover kubectl plugins.
"About Phil
Phillip Wittrock is Senior Software Engineer at Google, Kubernetes SIG CLI Lead, and a member of the Kubernetes Steering Committee. Phillip’s hobbies include debating how kubectl is pronounced, talking about Kubernetes at social events, and appreciating code as art.
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.
A
A
All
right,
so
here's
some
of
the
possible
topics-
I'm,
not
I,
don't
have
slides
on
all
these,
but
I'd
be
happy
to
talk
about
any
of
them.
So
if
anything
up
here,
piques
your
interest,
there's
a
Q&A
session
at
the
end
that
we
can
dive
into
the
first
is
about
yeah
Mel
composition
like
ryomo
composition,
and
how
to
manipulate
it.
A
Coo
control
has
some
commands
for
authoring.
Yeah
Mel,
the
crate
commands
sub
commands
are
actually
so.
If
you
do,
coop
control
create
deployment,
but
that
actually
does
under
the
covers
is
create
like
a
JSON
or
a
Gamal
and
then
send
it
to
the
API
server.
But
if
you
do
create
deployment,
OH
Gamal
dry
run,
it
actually
just
prints
out
the
yeah
Mel
that
would
have
sent
to
the
server.
A
Okay,
I'll
talk
about
that
for
a
sec,
so
there's
two
ways
of
creating
objects
with
cou
control,
typically
or
two
tracks.
The
first
is
I
want
to
use.
Kubernetes
like
I
use
a
UNIX
command
line
right,
which
is
I
type
in
a
command,
and
then
it
goes
and
does
something
so
kou
control
run
will
go,
create
a
deployment
for
me
to
control.
Expose
will
go,
create
the
service
for
me.
A
Could
control,
create
secret
or
create
config
map
will
go,
read
in
a
file
and
then
create
that
in
the
cluster,
and
it
works
a
lot
like
you're
used
to
with
grepping
or
other
commands
right.
There's
no
declarative,
persistent
file
that
you're
working
with
there's
another
set
of
commands,
which
is
really
how
everything
works
under
the
covers,
which
are
the
cou
control,
create
F,
you
give
it
a
file
to
control,
apply
app,
you
give
it
a
file.
A
And
then
you
can
answer
some
questions
with
me.
Thanks
man,
I
was
a
little
bit
joking,
but
a
little
bit
serious.
Just
everyone
saw
me
remove
that
okay,
so
the
canonical
way
we
encourage
people
to
use
the
system.
If
you
want
to
have
like
a
nice
production.
Workflow
is
to
use
this
declarative
approach,
the
code
style
approach.
We
call
it
config.
What
this
allows
you
to
do.
Is
you
have
a
nice
checked
in
record
into
your
version
control
of
what
you
actually
want
running
in
your
cluster?
That
has
nice
a
few
nice
properties?
A
A
A
So
the
first
line
here
is
about
if
you'd
use
that
declarative
approach,
which
is
what
we
recommend
people
do
to
do.
Is
you
start
to
want
some
of
the
same
things
you
have
available
in
programming
languages
like
reuse?
This
reuse
is
really
great
and
when
you're
defining
configuration
you
may
want
to
have
some
base
or
you
have
multiple
environments.
You
have
your
test
environment,
your
staging
environment,
the
production
environment.
A
Maybe
you
have
different
regions
or
different
clusters,
each
with
slight
variations
for
one
reason
or
another,
on
some
base,
a
set
of
config,
and
so
instead
of
if
this
was
the
code
analogy
instead
of
having
one
program,
that's
a
thousand
lines,
and
then
you
want
slight
variations
on
that
program.
So
you
just
copy
and
paste
that
thousand
line
program
and
then
change
a
couple
of
constants
here
and
there
you
really
want
something
where
you
can
come.
A
We're
using
code
and
templating
is
an
example
of
this.
Another
example
is
inheritance
and
using
like
the
same
programming
models
that
you
may
be
used
to,
and
one
thing
we're
trying
to
figure
out
is:
is
it
possible
to
do
it
just
by
declaring
the
config
itself
and
not
introducing
new
concepts
or
this
sort
of
thing?
A
And
you
don't
need
to
be
pairing?
The
exact
version
of
your
client
with
the
exact
version
of
the
cluster
and
those
kind
of
fall
into
the
second
candidate.
So
the
second
bullet
point
there
is
about
how
do
we
take
existing
commands,
like
cout
control
scale
to
control,
create
foo,
make
it
so
that
when
you
create
a
CRD
API
that
those
are
you
have
support
for
those
and
you're
represented
in
those
commands?
The
second
one
is
when
you
create
a
CRT
and
you're
like
look
I
have
the
CID
as
this
very
specific
set
of
business
logic.
A
A
Okay,
so
this
is
just
real,
quick.
Our
goals,
support
client
version,
SKU
support,
API
extensions.
Also.
How
do
we
get
faster
releases,
faster
development,
all
this
stuff
by
having
the
code
not
not
as
much
bespoke
coding,
cout
control
but
making
it
more
generic,
so
more
people
can
extend
it,
and
then
we
can
iterate
faster,
okay,
so
real
quickly.
Here,
who
knows
what
happens,
win
and
the
answers
on
the
slide?
So
you
can
just
read
it
right
off.
A
A
The
second
way
is
there
something
called
an
unstructured
object
which
just
reads
it
into
effectively
a
map
of
string
to
interface,
and
so
then
this
never
actually
goes
through
it.
You
go
struct,
so
it
doesn't
drop
anything
and
the
third
is,
you
can
just
manipulate
raw
amyl.
So
these
are
some
of
the
approaches
that
you'll
see
used,
and
this
is
why
they're
used
instead
of
just
doing
the
simple,
hey,
update
the
go:
struct
ID
history,
okay,
so
a
little
bit
about
generic
commands.
A
That
means
that
the
command
can
look
at
effectively
the
metadata
published
by
the
API
server
that
it
reads,
and
then
it
has
all
the
information
it
needs
so,
as
you
add,
or
remove
api's
from
the
api
server,
either
through
extensions
or
through
upgrading
or
downgrading
versions
of
your
cluster,
that
the
qu
control
just
magically
continues
to
function.
And
so
how
do
we
do
this?
A
The
first
approach
is
to
use
metadata
about
the
schema
and
the
structure
of
the
api's
themselves.
The
second
approach
is
to
actually
expose
endpoints
that
do
the
business
logic,
so
the
business
logic
is
implemented
in
the
server.
So
you
either
write
generic
logic
that
works
on
a
schema
but
still
done
in
the
client,
or
you
can
just
expose
an
endpoint
that
offers
a
different
abstraction
layer
that
you
can
send
a
request
to.
A
I'll
just
skip
this
okay.
This
is
an
open,
API
schema.
So
what
is
open?
Api,
open
API
is
a
format
that
gives
the
endpoints
and
the
schema
for
the
api's
that
the
cluster
knows
about
and
I
just
took
out
a
snippet
of
deployment,
open,
API
and
folded.
A
couple
pieces
mm-hmm,
but
the
noticeable
thing
you
can
see
here
is
it
has
the
fields
it
has
their
type.
So
if
it's
a
if
the
type
is
like
a
structure
or
a
complex
type,
it's
a
reference
and
you
can
go
look
that
up.
A
It
has
the
description,
so
you
can
even
print
data
about
it
and
we
have
this
cool
thing
down
at
the
bottom,
which
is
you
can
have
extensions
to
the
open,
API
metadata.
So
that
means,
if
you're,
like
gosh
I,
really
wish.
I
could
annotate
this
field
on
this,
for
this
particular
API
with
something
like
this
is
the
scale
field
and
when
you
scale
me
you're
updating
this
number
here
right,
that's
actually
possible
through
this
sort
of
thing.
A
The
other
piece
of
API
metadata
is
something
called
the
discovery
service.
The
discovery
service
has
just
the
endpoints
now
this
has
some
overlap
with
open
API,
but
it's
not
complete
and
so
open
API
doesn't
actually
have
all
the
information
present
in
the
discovery
service
and
the
format
of
the
discovery
service
is
a
little
bit
different
where
it
starts
out
with
an
object
and
then
has
the
endpoints
for
that
object,
where
the
open
API
just
has
the
endpoints
as
a
flat.
A
So
they're
not
they're,
not
logically
hanging
off
specific
resources.
So
you
can
see
here
you
can
ask
the
API
server
about
all
its
API
is
and
it'll
say:
hey
I
know
this
thing
called
deployments.
It
has
a
kind
deployment
which
you
can
go
and
look
up.
The
schema
for
from
the
open
API
here
are
the
verbs
that
I
support.
Here's
this
short
name
thing,
so
you
can
do
cout
control,
deploy
instead
up
to
control
or
to
control,
get
deploy
instead
of
to
control,
get
deployments.
A
Okay,
so
those
are
the
two
kind
of
tools
you
have
for
implementing
generic
client-side
logic,
where
you
don't
hard-code
against
an
API,
and
you
just
ask
okay:
what
I
pays?
Do
you
have
that
have
a
scale
field
sub-resources?
Are
you
can
think
of
them
kind
of
like
functions
that
you
can
attach
to
resources?
So
if
a
resource
has
a
schema,
it's
a
declarative
piece.
A
You
can
have
a
scale
sub
resource
that
will
go
and
take
some
scale
scale
field
and
update
the
number
of
replicas
for
a
particular
object,
and
that
means
that
not
every
resource
needs
to
have
the
same
replicas
field.
Look
exactly
the
same
or
even
be
updated
exactly
the
same
way,
and
you
can
just
implement
actual
business
logic
and
wrap
it
in
this
nice
interface
and
then
everyone
can.
Your
commands
can
just
work
against
this
interface
instead
of
instead
of
the
schema.
A
A
A
And
that
seems
to
be
the
common
approach,
but
I
think
there's
some
other
reasons
for
people
wanting
plugins
plugins
could
exist
as
callbacks
from
actual
commands
right.
So
do
you
want
to
swap
out
this
component
of
how
to
control?
Does
something
like
one
aspect
of
the
diff
command
or
something
like
that,
and
so,
instead
of
being
exposed
directly,
those
would
actually
be
invoked
to
override
start
parts
of
to
control.
That
is
not
something
that
we
are
actively
looking
at,
but
it
is
something
people
like
plug-ins
for
so
I
thought.
A
One
piece
that
we
want
to
develop
is
CLIA
library.
So
if
you're
writing
a
plugin,
you
don't
have
to
write
200
lines
to
read
in
the
coop
config.
That's
an
exaggeration!
You
don't
have
to
do
that,
but
there
are
a
lot
of
simple
things
that
are
not
trivial
to
do
and
you
have
to
copy
this
boilerplate
code
around
it
really
great.
If
you
didn't
have
to
do
that
so
we're
looking
at.
A
This
is
something
that
my
channe
have
been
talking
about,
particularly
recently,
as
recently
as
last
night,
at
Tivoli
and
and
I.
Think
it's
a
really
interesting
example
of
some
of
the
work
we're
trying
to
do
right,
because
there's
a
lot
of
ways
that
we
can
approach
these
problems
and-
and
they
all
have
trade-offs
here.
A
How
would
you
support
a
ku
control,
create
sub
command
for
your
own
bespoke
foo
resource
right?
So,
if
I
have
create
food
CRD,
how
do
I
create
a
crate,
foo
sub
command,
so
the
first
is
would
be
with
a
RPC
resource
sort
of
driven.
So
today,
if
you
do
create
deployment,
there
is
a
function
that
knows
how
to
create
a
deployment.
The
registers
flags
with
the
CLI
and
then
reads
those
into
a
ghost
rock
pills
and
the
rest
of
the
go
struct
with
some
other
random
stuff,
and
then
that's
where
you
get
your
deployment.
A
But
not
have
it
compiled
into
the
client,
so
you
could
do
that
on
the
server
side
and
then
publish
it
right,
so
a
sub
resource,
as
you
we
saw
earlier,
you
can
have
the
API
server,
publish
these
sub
resources
and
you
can
register
sub
resource.
That's
like
the
create
sub
resource
and
that
could
have
specific
fields
and
then
now
the
code
just
runs
on
the
server
side
instead
of
locally
right
and
you
could
either
have
it
so
that
that
then
sends
back
the
ml.
So
it
doesn't
have
any
permissions
to
write
to
the
cluster.
A
And
then
your
client
takes
the
amyl
and
then
takes
the
raw
ml,
which
the
first
slide
I
talked
about
as
an
option
right
step
back
to
the
server
or
potentially
you
could
send.
The
server
could
impersonate
the
client
and
then
create
it
directly
on
the
server
sup
resource
is
one
way
of
doing
that.
That
requires
having
a
mechanism
for
registering
sub
resources
for
your
CR
DS,
which
doesn't
exist.
Yet
it's
being
discussed.
If
you
just
want
to
do
it
on
your
own,
you
could
probably
publish
ERP,
Cu
or
some
rest
in
point
and
then
annotate.
A
The
sir
like
create
that
as
a
service
annotate
the
service.
Now
you
can
write
a
program
that
goes
and
or
label
it
program
that
goes
in
uses
the
label
selector
to
go,
find
all
the
services
that
are
great
services,
reads
their
metadata
and
then
sends
them.
One
thing,
I
think
that's
important
here
to
consider
is
this
should
be
possible
to
map
flags
into
a
request.
Object.
So,
like
flags
have
there's
only
a
couple
types:
they
can
happen
they're
relatively
flat
right.
A
Who
knows
what
label
selectors
are
by
the
way?
Ok,
so
label
selectors
are
essentially
a
way
of
applying
indexed
metadata
to
resources.
So
there's
a
map
in
an
object
metadata
that
takes
a
string,
key
string
value
and
then
you
can.
That
will
be
indexed.
So
you
can
then
query
it
and
say:
hey
give
me
all
of
the
services
that
have
the
key
I'm
a
coup,
Control
Service
and
the
value
whatever
right,
true
or
something
like
that.
A
The
second
approach
that
we've
kind
of
kicked
around
there's
a
little
less
overhead,
so
that
first
one
is
requires
a
little
bit
of
thought
about
how
to
implement
it
right
and
we
can
prototype
it,
but
it
there's
more
work
there.
What
can
we
do?
That's
a
little
lighter
weight
right.
Well,
one
thing
we
could
do
is
instead
of
trying
to
support
this
bespoke
arbitrary
business
logic.
We
could
just
say:
look
what
if
we
just
attach
a
JSON
structure
to
the
CRD
as
an
annotation.
A
So
what
we
could
do
right
is
for
a
deployment.
For
instance,
we
could
come
up
with
what
a
JSON
struck
looks
like
for
a
deployment
you
could
just
run.
We
could
attach
it
to
if
deployment
was
a
CR,
D
and
annotation
on
the
C
or
D,
and
then
when
the
cou
control
starts
up,
I
could
say:
okay,
give
me
all
the
C
IDs
I'm
gonna
read
off
their
annotations.
Okay,
this
is
how
here's
the
JSON
for
creating
a
deployment.
So
now,
if
you
say,
Q
control
create
deployment,
I'm
gonna
start
with
this
JSON.
A
If
you
don't
give
me
anything
else,
I'm
just
gonna
create
this
deployment
here
that
you
totally
showed
me
how
to
create,
and
then
I
can
register
some
additional
flag
that
map
to
like
fields
using
JQ
or
something
right,
and
so,
if
you
specify
image,
I
can
use
a
JSON
path,
so
know
where
the
image
is
and
then
rewrite
that
field.
So
this
is
somewhat
limited
in
what
it
can
do,
but
it
can.
Actually,
you
can
actually
get
you
a
create
command
that
works.
It
has
some
basic
features,
and
this
might
actually
be
really
good.
A
Having
this
limitation,
because
back
to
my
first
slide,
we
really
want
people
to
use
the
declarative
way.
This
is
really
a
bootstrap
mechanism
to
say:
okay,
you
want
to
do
something
really
simple
and
easy.
You
want
to
do
it
fast
and
you
want
to
make
sure
that,
like
you,
don't
have
a
typo
in
your
config
when
you're
writing
it
or
have
to
copy
and
paste
it
from
a
page.
A
This
will
work
for
that
when
you
want
to
start
editing,
adding
arbitrary
ports
and
this
sort
of
stuff
and
modifying
the
CPU
and
this
sort
of
stuff,
this
doesn't
work
so
well.
Well,
we'd
argue
that
at
that
point
you
should
probably,
if
you're,
if
you
care
about
the
CPU,
that
you're
running
your
service
with
you,
should
probably
use
any
declarative,
config.
A
And
right,
the
disadvantage
with
this
approach
is
a
number
of
things.
If
you
have
multiple
clusters,
some
of
which
have
the
API
and
some
of
which
don't
because
either
the
clusters
are
at
different
versions
or
because
the
clusters
have
different
series
installed,
you
got
one
to
control
binary,
you
have
installed
it's,
it's
not
gonna
work.
Well,
it's
either
gonna,
it's
gonna
be
present
for
clusters
that
don't
have
the
thing
or
it
won't
be.
Some
things
won't
have
plugins
for
clusters
that
do
have
the
thing
you
have
version
skew
problems
where
now
you
have
a
version.
A
Skewing
control
is
already
one
of
our
biggest
pain
points,
and
now
we
have
version
skew
for
every
other,
different
binary
that
you've
installed
and
we're
not
managing
that
and
it
took
us
years
to
figure.
It
really
grabbed.
Our
heads
around,
like
the
implications
of
version,
skew
and
kind
of
the
mitigating
factors,
so
asking
plugin
developers
to
try
and
like
make
sure
they
get
version.
Skew
correct
is
not
not
a
nice
thing
to
do,
but
nonetheless,
it's
good
to
know
what
our
options
are
and
and
sometimes
a
bad
option
is
better
than
no
option
at
all.
A
C
It
sounds
like
a
lot
of
the
problems
you
are
describing
are
the
sorts
of
problems
that
anybody
who
wants
to
write
some
binary
that
interacts
with
the
kubernetes
cluster
and
deals
with
version
skew
and
deals
with
different
features
and
different,
different
CRTs
and
stuff
is
going
to
have
to
deal
with.
So
the
the
question
in
my
head
is
like
this:
a
lot
of
this
functionality
seems
like
it
belongs
in
client,
go
and
then
I
view.
Cuddle
is
just
the
like.
C
Nice
UI
wrapper
over
top
of
that,
and
this
kind
of
lines
up
with
discussion,
I
keep
seeing
from
some
individuals
that
client
go
is
too
hard
to
use
and
we
need
an
easier
client.
Then
I
hear
you
talking
about
different
strategies
of
like
what,
if
we
just
use
raw
gamma
land
and
patch
it
and
stuff
so
I'm
trying
to
grok.
C
Just
from
your
perspective
like
how
much
of
the
work
you're
describing
is
inside
of
client
go,
how
much
of
it
is
you
re
implementing
stuff
and,
and
where
do
you
think
it
can
be
done
in
a
way?
That's
reusable
for
everybody
to
benefit
from
these
these
hard
decisions,
because
I
think
your
dogfooding
a
lot
of
the
problems
that
any
tool
developer
for
kubernetes
would
have
to
deal
with.
A
A
Actually,
not
that
important
to
me,
I
think
the
thing
to
consider
is:
are
you
trying
to
write
a
generic
tool
such
as
apply
that
just
operates
on
kubernetes
api
is
in
general
for
other
people
to
use
so
we're
like
a
diff
right
and
then
the
answer
is
yes,
that's
what
I
want
to
do.
I
want
something
to
operates
on
generic
crease,
on
resources,
generically
and
qi.
A
A
If
that's
what
you
want
to
do.
Yes,
these
libraries
would
be
helpful
for
you.
There
were
three
options
up
there
right.
There
is
patch
they're,
unstructured
object
and
there's
the
raw
ml
and
we
are
still
trying
towards
something.
That's
really
polished
and
there's
actually
new
work
being
done
on
the
server
side
to
apply
it
to
support
other
options
that
weren't
listed
there,
notably
server
side,
apply,
allows
you
to
not
have
to
do
the
patch
piece
or
would
replace
the
patch
operation.
A
A
Addresses
some
piece
of
functionality
for
specific
api's,
maybe
an
api
that
you
wrote.
You
don't
want
that
stuff
right.
If
you
don't
care
about
version
skew,
for
instance,
so
if
you're
a
controller
right
and
you're
running
in
the
cluster
and
your
controller
is
packaged
with
your
CR
d,
so
the
two
are
always
shipped
together
right.
In
that
case,
you
probably
don't
want
to
be
working
with
raw
ml,
because
it's
harder
to
work
with
and
more
error-prone
and
you're,
not
gonna
have
Version
skew
and
you're
not
going
to
need
to
work
with
extensions.
A
So
that's
kind
of
where
I'd
fall
on
that
I
guess,
maybe
there's
you
can
think
of
it
as
two
pieces
naively,
which
is
the
controller
I
just
went
over
since
q1,
API
and
totally
generic
like
it
might
not
even
be
kubernetes.
It
might
be
just
something
running
raw
API
machinery
code
that
doesn't
know
about
pods
and
has
totally
different.
Api
is
installed
right
and
there
is
kind
of
some
stuff
in
the
center
where
it's
like.
A
Well,
it's
for
my
API,
but
I
do
want
to
support
version,
skew
right
and
that's
where
stuff
and
that's
where
you
need
to
think
about
like
well.
What
happens
if
we
drop
fields
right
and
is
that
bad
and
that's
or
so
or
can?
Is
it
okay
to
tell
folks
to
always
run
the
latest
version
of
the
client
potentially
right
and
as
long
as
the
client
is
newer,
then
what's
up
what's
being
served
by
the
server,
then
it
won't
drop
fields
in
this
sort
of
stuff.
So
yeah,
it's
complicated
all
right.
D
A
A
A
A
Going
to
the
next
step,
for
it
is
going
to
be
to
work
with
server-side
apply,
so
the
history
behind
the
diff
command
when
the
the
original
motivation
was
that
when
you
Dooku
control,
apply
it'd,
be
really
nice
to
know
what
that
thinks
is
gonna
do
before
it
does
it,
and
we
wrote
the
diff
command
in
the
apply
logic,
we
changed
somewhat
how
it
was
merged
for
the
diff
command,
so
the
diff
command
simulates.
What
it
thinks
is
going
to
happen,
but
it's
not
perfectly
aligned
with
necessarily
what
the
what's
gonna
happen.
A
So
apply
used
to
use,
go
struck,
tags
to
figure
out
how
stuff
was
gonna
be
merged
on
the
server-side,
assuming
it
had
the
same
go
struck
tags
that
the
server
had
right,
but
when,
in
reality
it
might
be
a
version
behind
and
so
missing
a
field
and
then
make
something
up
right
so
apply
more
recently
now
uses
that
open,
API
metadata
and
the
extensions
that
were
listed
there
to
be
able
to
know
exactly
what
the
server
thinks
it's
good
or
what
the
server
intends
to
do,
not
what
it
thinks
it
is.
But.
A
The
the
I
think
the
broader
point
is
right
now
on
the
client.
We
don't
have
a
hundred
percent
certainty.
Yes,
I
know
exactly.
This
is
what's
gonna
happen.
We
just
have
a
like.
This
is
pretty
much
what
we
think
is
going
to
happen
when
apply
moves,
server-side
fully,
which
is
in
their
active
development.
A
Now
it's
like
a
multi
quarter
effort
and
it's
gonna
take
some
time,
but
when
it's
there
and
when
the
client
is
then
invoking
the
server
side
apply
piece
that
is
gonna,
expose
a
dry
run
piece
and
then
the
server
can
tell
us
yes,
this
is
definitely
how
I'm
gonna
do
it
at
that
point
in
time,
we'll
update
the
diff
command
to
to
have
that,
and
it
will
be
more
mature.
The
diff
command
can
also
be
used
for
other
interesting,
some
things.
That
was
the
main
use
case.
B
A
B
A
A
Maybe
we
need
to
improve
the
built-in
documentation
for
that,
so
I
guess
a
general
tip
is
if,
if
you
want
your
feature
or
your
request
or
your
issue
to
get
attention,
github
has
a
lot
of
noise
and
it
is
really
hard.
Actually
it's
just
impossible
to
really
stay
on
top
of
github
issues
in
in
a
definitive
way.
That's
not
to
say
we
don't
try,
but
it's
like
UDP,
not
TCP.
A
If
you
want
a
TCP
sort
of
experience,
come
to
the
sig
CLI
meeting
or
send
to
the
sake
CLI
mailing
list
and
and
that's
a
better
way
to
get
engagement,
so
you
can
throw
an
item
on
the
agenda
for
the
sake
CLI
meeting
and
we
usually
go
through
those
and
we
can
discuss
it
and
after
that,
we'll
probably
communicate
on
the
issue.
But
now
it's
been
brought
into
the
cache.