►
From YouTube: Everything You Always Wanted to Know About SIG-CL... Phillip Wittrock, Maciej Szulik & Sean Sullivan
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
Everything You Always Wanted to Know About SIG-CLI but Were Afraid to Ask - Phillip Wittrock, Google; Maciej Szulik, Red Hat; & Sean Sullivan, Google
This session is intended for all interested in what SIG-CLI is and what it does. Whether you're fresh to Kubernetes or an old-timer you are more than welcome. This session will be fully interactive, and its contents will entirely rely on the expectations of the attendees. Depending on audience interest, Phil, Maciej, and Sean will address several topics, including: - Kubectl code tour which will provide basic knowledge for working on kubectl itself, as well as how to write kubectl plugins. - The main initiatives SIG-CLI is undertaking, including but not limited to: splitting kubectl out of main Kubernetes repository, plugins - its development and management, resource configuration with kustomize, dynamic commands, etc. - Gathering feedback and discussing problems people struggle the most with kubectl.
https://sched.co/Uakq
A
Okay,
good
morning,
good
evening,
good
afternoon,
depending
on
the
way
you
are,
if
you've
ever
heard,
yeah
it's
225
yeah.
If
you
ever
heard
that
greeting
that
means
you
either
attended
one
of
our
meetings
or
you've
watched
our
recordings,
which
is
a
pleasure
to
welcome
you
in
person.
If
you
have
not
that's
basically
how
we
greet
everyone
on
our
bi-weekly
meetings,
my
name
is
ma
che
I'm
one
of
the
sig
leads
tech
leads
whatever
this
is
Sean.
The
other
person
trouble
troublemaker
for
60
Li
and
the
third
one
is
Phil.
A
A
This
is
when
we
meet
and
where
we
meet.
If
you
have
any
questions,
this
is
where
you'll
find
us
that's.
Basically,
all
we
had
the
session
idea
was
that
we
will
be
live.
Answering
any
kind
of
questions
that
you
might
have
with
regards
to
what
six
Eli
is
apt
to
about
our
sub
projects,
about
how
to
become
involved
in
a
six
CLI,
how
to
get
a
reviews
on
PRS?
How
to
write
plug-ins
anything,
any
kind
of
questions
that
you
have.
A
A
No,
we
have
an
official
pronunciation
since
we
have
with
the
logo
and
if
you
haven't
seen
and
have
a
look
at
myself'
fill
or
Sean.
That's
the
official
logo,
thanks
for
amazing
Ashlee
McNamara
from
Microsoft.
She
created
the
logo
at
the
beginning
of
this
year.
So
since
then,
it
is
pronounced
cubic
ATO
because
of
the
cuttlefish
that
we
have
on
on
our
t-shirts.
But
then
again,
I
I'm,
not
consistent,
I'm
gonna
be
saying
everything
interchangeably
most
frequently
I'll
be
using
cube
control.
Cube
CTL
could
be
cubic
on
oh
yeah.
A
E
A
Very
good
question
so
currently,
and
that
will
probably
be
for
at
least
another
six
months
to
a
year.
The
entire
code
of
Cuba
coddled
is
within
the
main
kubernetes
repo.
So
if
you
want
to
fix
issues,
you're
going
to
look
in
kubernetes,
slash,
kubernetes
and
then-
and
this
is
the
tricky
part
we
are
in
the
process
of
splitting
the
Cooper
cube
CTL
out
of
the
main
repo,
which
means
95%
of
the
commands-
are
already
split
out
and
they
are
living
inside
of
what
is
called
a
staging
repository.
A
So
staging
is
a
is,
is
a
way
for
us
to
say
this
is
kind
of
external
repository,
but
for
the
purpose
of
ease
of
development,
we
are
keeping
them
together
in
a
single
repo.
We
have
a
mechanism
that
is
then
responsible
for
taking
the
the
contents
of
the
staging
directories
and
publishing
them
to
a
separate
repositories.
That's
why
you
will
find
a
kubernetes,
slash,
cube,
CDL
repository
that
represent
area
is
being
synced
on
a
hourly
or
so
basis
from
the
main
kubernetes
repo.
A
So
all
the
changes
still
will
land
in
the
main
kubernetes
repo,
so
staging
source,
kate's
IO
cube
CTL,
and
this
is
all
the
commands
that
are
living
there's.
Another
repository
that
we
own
within
staging,
which
is
the
CLI
runtime
CLI
runtime,
is
a
set
of
helpers
that
we
exposed.
We
extracted
to
a
library
so
that
people
who
are
writing
plug-ins
can
reuse
for
their
own
good
so
that
it
don't
they
don't
have
to
fight
with
primitives
such
as
printing
resources
or
reading
the
resources
from
from
the
server
or
from
the
local
file.
A
So
this
is
where
you're
gonna
look.
Unfortunately,
the
case
for
issues
is
not
that
simple,
because
we
happen
to
have
issues
in
both
of
the
repos,
so
in
the
main
repo
there
is
this
thing
to
find
six
CLI
issues
is
to
use
the
sick,
CLI
label
and
I'll
be
honest,
brutally
honest.
We
do
not
have
anything
as
good
first
time
issues
and
that's
probably
our
big
problem,
if
you,
if
you
want
to
go
through
the
issues
and
mark
them
as
good
for
a
first
time,
that
would
be
super
super
awesome,
but
we
haven't
done
it.
A
There's
only
a
couple
of
us
working
actively
on
a
daily
basis
on
on
the
sick
CLI.
So
issues
from
both
repos
are
perfectly
fine
to
be
addressed
within
the
main
communities.
If
it's
a
smaller
issue
such
as
a
single
command
I,
don't
know
mistreating
or
not
having
some
kind
of
functionality.
There's
no
no
problem
just
leave
a
comment
that
you
are
working
on.
This
issue
open
a
PR
ping,
one
of
us
or
the
maintain.
Well,
that's
that's
mostly
us,
but
not
github.
A
A
You
need
to
be
persistent
and
I.
There
has
been
several
people
apologizing
us
that
they
there
are
pinging
me
consistently
and
I,
always
say
yes,
keep
pinging
me
so
I
don't
forget
and
your
PR
will
get
reviewed
the
more
pings
the
sooner
I'll
get
to
it.
It's
not
a
problem.
I'm
not
totally
treating
this
as
a
noise
I'm
more
than
happy,
because
I
only
have
this
amount
of
time
within
a
single
day
and
there's
like
this
amount
of
work
that
I
need
to
do
so.
A
B
B
F
B
That's
okay!
For
those
who
want
to
contribute
to
kubernetes,
do
you
who
wants
to
contribute
something
specific
versus
once
you
just
get
involved
with
the
community
and
start
understanding
like
how
to
contribute
so
first,
like
wants
to
contribute
specific
all
right.
A
couple
of
you.
A
second
wants
to
contribute
like
just
something
anything:
okay,
a
few
more
so
one
thing
is:
we
have
COO
control.
It's
in
the
main.
Repo
COO
control
has
a
lot
of
baggage
in
a
lot
of
dimensions,
so
one
is
the
libraries
it
uses.
B
A
A
Wasn't
tested,
but
once
we
get
it
to
a
separate
repo
and
the
goal
for
thou,
one
of
the
goals
is
to
have
a
faster
releases
more
frequently
than
the
main
communities
you
bro.
We
will
have
to
raise
the
bar
to
at
least
two
or
three
plus
minus
releases,
because
if
kubernetes
is
released
once
per
quarter,
and
we,
for
example,
will
be
releasing
every
every
month,
we
need
to
ensure
that
every
past
release
of
kubernetes
and
the
next
release
communities
is
always
working,
which
basically
means
plus
minus
three
is
to
the
goal.
G
A
G
B
Api
is
ever
right,
so,
okay,
for
example,
that
means,
if
you
so
apply,
is
actually
pretty
stable
at
this
point.
But
there
is
a
point
in
time
when
we
apply
identified
how
to
merge
objects
together.
So
for
those
of
you
don't
know
what
apply
does.
Is
it
merges
local
configuration
into
what's
remote?
The
reasons
that's
necessary
is
stuff.
Like
services
insert
the
cluster
IP
after
the
objects
has
created,
and
you
can't
just
replace
that
or
you
blow
away
the
cluster
IP.
So
it
does
a
merging
of
objects.
The
way
it
merges.
Those
objects
was
embedded.
B
Instructs
and
those
trucks
were
compiled
into
the
command,
and
so
what
that
meant
is,
if
you
were
running
a
version
of
qu
control
apply.
Maybe
an
older
version
of
coop
control
apply
against
a
new
our
server
that
you
wouldn't
have
the
data
of
how
to
properly
merge
things
together.
So
that's
an
example
of
that's
you
and.
A
G
A
H
So
I'm
curious
about
the
decision
to
split
it
out
into
its
own
repo.
It
seems
like
now
we're
gonna
have
cube.
Cuddle
has
a
drifting
version.
Is
it
going
to
be
version
DeLong
the
same
scheme
as
kubernetes
and
is
there
going
to
be
a
way
to
easily
tell
the
cube
cuddle
I'm
running
is
actually
gonna
work
with
a
given
particular
with
a
given
cluster
except
a
lot
of
problems.
H
Now
people
are
gonna,
install
it
from
somewhere
and
now,
there's
suddenly
gonna
have
to
worry
about
which
version
they're
running
and
how
to
run
multiple
versions
or
is
there
gonna
be
like
a
cube,
cuddle
switch
to
say
what
API
you're
targeting
like
there's
there's
a
lot
of
issues
in
there
as
curious.
What
your
thoughts
are.
That's.
D
So
I
mean
so
one
of
the
schemes-
oh
oh
yeah,
trial
at
least
give
my
take
on
that.
So
one
of
the
schemes
that
we're
imagining
is
that
we
would
keep
the
same
major
and
minor
versions
in
coop
cuddle
as
in
the
API
server,
and
that
our
patch
would
be
what
we
increment
significantly
since,
as
our
cadence
gets
much
much
faster,
our
patches
could
diverge
significantly,
but
it
should
be.
D
You
should
be
able
to
say
you
know:
1.15
coop
cuddle
works
with
there
were
one
point
and
or
whatever
that
n
is
works
with
an
API
server,
plus
or
minus
one
of
of
what's
in
coop
control,
that's
one
way
so
so
so
that
actually
hasn't
been.
We
haven't
determined
exactly
how
that's
gonna
gonna
work.
Just
to
give
you
a
little
background
on
why
we're
doing
that,
we
we
hope
to
have
a
significantly
faster
cadence.
D
In
addition,
once
we
pull
the
code
out,
we
can
it's
easier
for
other
projects
to
reuse
or
vendor
that
code,
for
instance
the
drain
code,
which
drains
a
node.
You
don't
want
that
logic.
You
know
in
five
or
six
different
places,
you'd
like
just
one
version
of
that,
and
then
everybody
kind
of
pulled
that
one
in,
and
it's
just
recently
that
now
that
we've
gotten
the
drain
code
into
staging
that
there's
actually
quite
a
bit
of
activity
on
that
in
that
code
base
in
order
to
refactor
it
it
make
it
significantly
more
useable
elsewhere.
D
B
Think
it's
worth
noting
that
as
we
move
stuff
into
staging,
it's
intended
to
be
safe
to
use
to
vendor
into
CL
is
that
code
was
written
with
the
assumption
that
it
was
running
in
the
CLI
that
will
exit.
So
that
means
that
there's
parts
of
the
code
we've
seen
that
leak
go
routines.
For
instance,
there's
just
a
PR
defiled
to
fix
some
of
those.
A
With
regards,
there
are
two
things
that
I
wanted
to
clear
up,
also
with
regards
to
versioning.
If
you
look,
for
example,
about
the
client,
go
that
it's
also
part
of
the
staging
repos
and
is
being
published
as
part
of
the
sig
API
machinery,
they
took
a
completely
different
approach.
They
are,
they
have
their
own,
completely
distinct
versioning
scheme
from
the
main
repo,
the
only
and
even
though
that
they're
their
release
cadence
is
strictly
tied
to
kubernetes
releases.
We
haven't
settled
on
a
particular
path.
Like
Sean
said,
there
are
multiple
variants.
A
We
haven't
figure
out
which
one
we
will
follow.
It's
definitely
think
that
we
will
have
to
tackle
eventually,
maybe
having
some
kind
of
a
helper
command
that
will
tell
you
or
a
matrix
is,
is
at
least
a
starting
point
for
us
to
have
and
to
answer.
Additionally,
the
the
split
the
reason
initially
Cuba
Caudill
ended
up
in
the
main
canal.
His
repo
was
that
everything
historically
was
dealing
with
internal
versions
and
whatnot,
and
the
way
it
was
written
it
had
to
live
next
to
the
api's.
A
Now
that
we
spent
good
couple
of
months,
we
factoring
significant
amount
of
code.
We
made
it
so
that
it
actually
works
with
the
API
without
the
need
to
to
get
all
those
of
those
internals.
Unfortunately,
due
to
the
fact
that
it
was
living
in
the
main
repo,
a
lot
of
code
was
interdependent
on
each
other.
A
B
B
We'd,
probably
do
things
like
check
to
see
if
the
necessary
end
points
exist
and
if
they
don't
just
fail,
the
command
right
and
so
as
we
develop,
each
command
say
assume
that
you
can
run
arbitrary,
cou
control
force,
arbitrary
kubernetes
server,
and
so
the
way
one
of
the
proposals
for
moving
forward
in
that
direction
is
to
create
a
new
set
of
commands
like
reimplemented
a
ground
up.
That
would
adhere
to
this
and
pick
out
ones
that
this
is
particularly
important.
For
so
say,
apply
say
if
just
apply
has
that
semantics.
B
That
adds
a
lot
of
value,
put
that
in
a
different
command
group
and
rewrite
it
rewrite
it
outside
of
the
main
kubernetes
repo,
so
that
it
doesn't
have
dependency
issues
with
being
moved
out
and
all
that
sort
of
stuff,
and
so,
if
you're
interested
in
that
it
might
be
easier.
As
a
new
time
contributor
to
actually
contribute
to
the
commands
that
maybe
we're
going
to
start
building
outside
of
the
grants,
repo
like.
A
Ideally,
it
should
not
matter
which
version
of
compute
QB
kind
of
your
Roenick.
It
should
always
work
whether
it's
an
older
one.
You
won't
want
it
has
to
work
with
your
ear
kubernetes.
Obviously
we
will
encourage
you
to
use
the
newer
one
because
it'll
be
more
future
fold.
It
will
be
cool
stars
and
tacos
and
whatnot,
but
it
should
always
work
with
any
kind
of
community's
concert.
That's
the
goal.
H
A
I
How
does
a
how
does
like
cross
sig
and
working
group
work
for
you
also
for,
like
server
side,
apply,
for
example,
the
you
know,
cute
control
has
to
change
how
it's
doing
application.
There
is
that's
something
that,
like
your
cig,
takes
on,
or
just
a
working
group
take
that
on.
How
does
that
look
for
projects
like
that.
B
They're,
like
the
way
we
do,
it
is
actually
like
individuals
aren't
siloed
into
specific
sakes,
and
so,
in
the
case
of
server-side,
apply
was
actually
Antoine
policie,
who
implemented
that
he
was
formerly
focused
on
six
CLI
and
doing
areas.
I
think
he
did
actually
work
with
apply
and
open,
API
and
different
things,
and
so,
when
it
came
to
server-side
apply,
he
just
started
working
on
that
area.
The
code
base
start
attending
API
machinery
meetings,
so
I'd
say
cross
sig
I
mean
we
do
cross
sake.
Joint
planning
is
important,
I.
B
Think
working
groups
are
the
formal
body
that
these
things
are
supposed
to
be
developed
through
and
practice.
Working
groups
I
think
introduced
a
lot
of
overhead
with
them,
because
it's
like
I
knew
meetings
everyone's
going
their
own
meetings
and
now
there's
this
new
meeting,
how
our
decisions
made,
and
so
it's
the
best
way
to
do.
It
is
actually
just
have
individuals,
develop
expertise
around
the
codebase
and
share
that
expertise
and
work
together
on
kind
of
a
individual
basis.
I
mean.
A
A
There
will
be
a
separate
there
will
be
separate
tasks.
We
have
something
planned,
something
that
called
dynamic
command,
that
that
Phil
wrote
a
cap
or
there's
something
that
we
want
to
track
the
commands
being
sent
over
to
the
cluster.
It
will
require
from
us
to
synchronize
with
the
sig
API
machinery
trying
to
figure
out
the
part
of
the
work
who
will
be
doing
the
work.
Most
probably
it'll,
be
us,
because
we
have
the
knowledge
I'm
personally
attending
more
than
just
one
Sigma
dings
I'm
active
in
at
least
four.
A
At
this
point
in
time,
which
is
like
CLI
apps
scheduling
a
API
machinery,
so
we
have
the
knowledge
to
work
with,
with
other
six
and
and
even
if
you're,
not
part
of
any
of,
if
any
of
the
six
but
you're
a
feature
that
you
wanted
to
add
to
kubernetes
is
cross-cutting.
Several
six
is
not
a
problem
to
show
up.
Yes,
it
will
require
some
additional
time
from
you
as
the
contributor
to
attend
and
synchronize
with
all
the
SIG's,
so
that
they
are
aware
that,
yes,
there
is
a
cap
that
I'm
planning
to
work
on.
A
This
is
the
feature
that
I
want
to
see:
sync
with
them
to
ensure
that
does
not
conflict
with
their
plans
or
maybe
they
already
are
working
on
something
similar.
So
you
can
just
pick
up
whatever
they
are
working
on
or
combine
the
work
together.
So
it's
more
about
ad
hoc
decision
rather
than
strict
plan.
Yes,
this
has
to
be
done
this
way
or
the
other
way
around
we're
very
flexible.
There's
no
strict
rules
about
yes,
sig!
A
No,
because
that's
a
different
stick
or
whatever,
like
signal
working,
came
to
us,
showed
up
to
one
of
our
meetings
and
was
discussing
us
with
us.
The
dual
IP
v4
v6
stack
and
how
that
will
be
presented
and
cube.
Ctl
get
commands,
for
example,
it's
a
minor
thing,
yet
they
showed
up
told
us.
We
didn't
have
any
issues
with
that.
That
was
rather
a
minor
change
from
our
point
of
view,
oh,
but
they
just
told
us
that,
yes,
this
is
something
to
be
expected.
We're.
G
A
H
B
They're,
like
going
kind
of
the
first
principles
like
how
might
we
design
this
right
in
one
way
that
was
offered
and
I
even
like
suggested
in
wasn't,
a
good
idea
was
like
everything's,
a
plug-in
everything's,
a
separate
binary.
You
just
download
them
all
right
and
it
was
actually
Clayton
Coleman
who
I
sat
down
with
us.
I
said
about
this
idea
and
he's
like
okay,
so
each
binary
is
about
like
40
megabytes
like
yeah
and
he's
like
okay,
and
you
got
a
hundred.
B
Into
a
4
gigabyte
download
like,
and
so
you
can
develop
things
modular,
Lee,
independently,
right
and
I
think
we
want
to
do
that.
That's
definitely
the
way
we
want
to
go
and
go
modules
actually
really
help
with
this
right.
The
set
of
commands
that
we
develop
as
part
of
the
sig
that
we
would
kind
of
like
to
publish
to
everyone
I
think
we
see
as
ideally
being
vendored
in
using
go
modules
right
and
then
so
now
it's
still
40
megabyte
download,
but
you
can
actually
do
stuff
and
customize
has
actually
started.
B
This
approach,
like
you,
can
use,
go
modules
to
version
each
soft
command
independently.
So
you
can
change
the
code
for
an
individual
sub
command,
but
when
you
build
the
main
one
depend
on
a
specific
go
module,
lattice,
fake
semantics
version
in
these
sorts
of
things
right,
and
so
you
get
a
lot
of
the
benefits
of
a
sort
of
plug-in
development
style
where
folks
can
even
download
those
individual
commands,
maybe
ahead
or
experimental,
or
anything
like
that.
B
So
for
the
commands,
we
support
that's
kind
of
the
direction
we're
heading
instead
of
developing
them
as
plugins
with
the
actual
COO
control
version
sort
of
notion
of
different
API
semantics.
One
way
when
I
that
I
explored
with
that
is
just
make
that,
for
instance,
a
plug-in
and
develop
it
out
externally
entirely.
B
H
B
Okay,
so
yes,
that
is
a
painful
problem
for
us.
That
problem
is
actually
has
to
do
with
some
technical
details
about
go
modules
and
go
pen
during
and
when
we
ship
to
customize
with
part
of
coop
control
who's
using
a
go
been
during
module,
my
method
and
it
worked,
and
then
we
changed
to
go
modules,
the
updates
break-
and
it's
been
actually
spending
a
lot
of
time,
trying
to
fix
that,
and
so
I
think
these
solution.
There
is
actually
that
Jeff,
who
is
the
primary
maintainer
of
customize.
B
We
are
moving
off
of
all
dependencies
on
any
staging
stuff.
The
reason
we
can't
update
customized
in
control
is
because
it
depends
on
stuff
that
comes
out
of
staging,
which
creates
a
circular
dependency,
even
though,
logically,
it
shouldn't
be
a
circular
dependency
in
practice.
It
is
a
circular
dependency.
B
Go
can
compile
it,
but
but
our
tools
don't
work
well
with
it.
So
by
rewriting
customized
to
not
depend
on
that
stuff,
it
will
be
able
to
be
updated.
Now,
we're
not
rewriting
it
just
to
fix
that
problem.
Actually
we're
writing
it,
because
those
libraries
don't
do
what
we
want,
and
one
thing
they
don't
do
is
like
preserve
comments.
Preserve
yam
will
structure
these
sorts
of
things
right.
B
It
would
be
really
nice
when
I
customize
a
file
and
there's
a
bunch
of
comments
in
there
and
some
structure
and
format
that
you
keep
that
and
there's
a
go
library
called
the
go.
Yama
library
released
the
version
3
of
go
yeah
--ml.
This
offers
really
fine
gain.
Control
for
display
include
stuff
like
comments
and
include
stuff
like
structure.
It
also
includes
stuff.
Like
do
you
want
that
string
quoted.
D
A
A
vendors
there's,
there's
other
plot
plan
because
we
would
like
to
have
currently
customize
is
being
vendor
in
its
entirety
into
the
CLI
runtime.
So
if
you,
if
you
reuse,
Eli
runtime,
writing
your
own
commands
you're
getting
basically
customized,
at
least
the
current
version.
That's
in
keep
could
be
cut
off
for
free.
F
I
F
Have
another
question
around
customizing
to
kick
the
hornet's
nest
a
little
more
here
organizationally.
So
where
do
you
see
six
CLI
in
the
application
definition
and
deployment
space,
because
customize
starts
to
encroach
into
an
area
which
maybe
some
would
consider
not
to
be
really
CLI
related
per
se,
but
more
in
that
area?
Is
that
something.
F
F
G
F
B
It
actually
came
directly
out
of
kou
control
commands
that
pre-existed
customized
now
I'd
be
happy
to.
You
know
talk
about
whether
those
are
in
scope
or
that
sort
of
thing.
But
if
you
look
specifically
at
customized
like
setting
the
namespace
came,
there
is
a
control
apply
in
flag
right.
If
you
look
at
setting
labels
and
annotations,
there
is
kou
control
set
labels
as
kou
control
set
annotations
image.
There's
cou
control
set
image
right.
It
kind
of
goes
on
patch.
There's
a
good
control
patch
command
right,
where
it
gets
a
little
bit
less
obvious.
B
D
B
Maps
and
generating
secrets
also
commands
for
both
of
those
things
that
work
pretty
much
exactly
the
same
way.
So
the
original
vision
for
customized
you
can
think
of
kind
of
two
ways
like
one
is:
there's
this
whole
declarative
application
management,
space
right
and
so
like
is
customized
like
the
one
true
tool
for
solving
that
entire
right.
The
answer
is
no,
the
other
thing
is
hey.
There's
this
credit
application
manage
space.
You
gave
me
a
bunch
of
commands
that
don't
work
declaratively,
but
they're,
useful
and
people
are
using
them
right
and
like
this
in
flag.
B
Like,
obviously,
I
wanted
to
apply
for
everything
that
I'm
applying,
because
I
don't
apply
to
namespace,
but
I
can't
review
ahead
of
time
that
I
everything's
going
in
that
namespace
right
these
sorts
of
things,
so
that
was
the
scope
of
customized.
Specifically,
what
is
the
scope
of
the
sake?
What
is
the
scope
of
the
project?
I'd
say
that
Brian
grant
has
from
seek.
Architecture
has
drawn
the
line
in
the
sand
at
packaging.
Right
and
packaging
is
a
bit
weird
right,
because
is
any
directory
of
configuration,
a
package
and
if
I
can
apply
a
URL.
B
Is
that
a
package
right
and
so
I
think
these
are
kind
of
the
wrong
questions
to
ask
because
I'm
not
sure
what
we're
trying
to
solve
necessarily
with
asking
them
right
but
kind
of
saying
at
a
painting,
broad
strokes,
the
tools
we
build
should
be
able
to
work
with
Dallaire
ative
configuration
that
exists
in
a
file
system,
or
maybe
some
end
point
that
we
can
fetch
that
uses
something
like
HTTP.
You
write
that
and
get
is
kind
of
borderline,
I
guess
I'd
say
where
it's
like
a
well-known
protocol,
but
maybe
less
customized
does
it.
B
Thing
versus
recommending
you
just
pull
it
locally,
so
I'd
say:
package
management,
I,
see
more
as
stuff
as
like
indexing
groups
of
packages
in
curation
and
creating
universes
and
creating
update
channels.
For
these
sets
of
packages
like
that
sort
of
stuff,
I
would
say
we're
going
to
be
careful
about
what
we
do
again,
there's
actually
a
project,
that's
a
crawler
that
helps
you
find
yomel
config
on
the
Internet
right
in
so
you
can
search
for
yam
Wilkin
fake.
B
B
B
What
about
say,
QX
that
just
got
found
it
there's
this
I
know
if
you're
familiar
there's
a
project
called
Kui,
which
has
been
collaborating
very
closely
with
us
in
six
CLI
in
kind
of
I'd,
say
incubating
as
a
sub
project,
which
would
then
take
declared
a
configuration
approaches
and
visualize
it.
So
in
nan.
B
I
think
the
principles
principles
behind
that
are
that
we
want
configuration
to
be
stored
in,
like
a
data
state
like
the
configuration
for
either
the
actual
kubernetes
api
or
an
abstraction
like
a
CRD,
or
something
like
this,
which
isn't
the
kubernetes
api.
But
it's
something
a
meta
api
that
configures
the
communis
api's
and
there's
a
lot
of
ways
of
doing
that.
Like
templating,
is
one
approach.
A
lot
of
people
use
template,
II
am
NOT,
saying
templating
is
a
bad
approach.
I,
don't
think
we
have
a
strict
opinion
on
it.
B
What
I'm
interested
in
is,
if
you
want
to
use
templating,
how
do
we
facilitate
using
templating
with
other
tools
right?
Because,
if
one
problem
with
the
template
is
you
can't
analyze
it
right?
If
you
want
to
like
lint
a
template
and
say
like
does,
did
this
specify
the
CPU
right?
You
can't
do
that
stuff
right.
That
means
it
doesn't
interoperate
with
the
person
over
there,
whose
cell
project
is
to
create
a
linter
right
so
figuring
out.
So
the
first
step
in
this
was
the
vision
behind
customized.
B
You
use
your
helmet
arts
right
you
get
to
use
helm.
Then
you
use
customize
to
customize
them.
Now
you
don't
need
to
go
in
there
and
fork
the
helm.
Charts.
We've
learned
a
lot
since
developing
customized.
In
that
time,
we've
come
up
with
a
lot
of
new
innovative
approaches
that
work
with
customize
that
may
be
built
into
customize
in
some
way
and
might
be
exposed
independently.
But
again
the
focus
there
is
to
figure
out.
J
D
A
A
We
set
up
a
patterns,
not
every
single
command
follows
the
patterns,
but
we
will
try
to
show,
and
it's
fine,
if
you
open,
if
you
are
redoing
the
old
commands
to
follow
the
new
patterns
that
Sean
will
be
showing
in
a
bit
definitely
worth
pyaare.
So
don't
be
scared
if
you
see
some
of
the
commands
not
following
the
same
patterns
so.
D
So
this
is
a
slide
from
we
had
a
workshop
on
Monday
on
coop
control,
development
and
I
brought
up
this
slide
because
it
actually
has
the
code
locations
the
three
that
we
really
care
about,
and
we've
been
talking
about,
staging
and-
and
maybe
that's
not
as
clear
to
some
people
kind
of
a
new
concept,
but
the
code
lives
under
and
when
I
say
Kate's
root.
That's
just
like
the
top
of
the
kubernetes
development
tree
staging
source
case
out
of
coop
cuddle
and
then
we've
we're
moving.
There's
a
couple
of
a
little
bit
of
the
code.
D
D
D
Just
did
an
LS
on
this
staging
and
you
could
see
there's
a
couple
levels
down
as
packaged
CMD.
This
is
where
all
of
the
coop
cuddles
sub-command
Slough,
almost
all
of
them.
So
you
could
see
you
know
from
exec
there's
actually
some
above
that
all
the
way
down
to
wait.
So
you
mentioned
annotate.
Let's
have
a
quick
look
in
there.
A
D
D
Go
so
you
could
see
here's
where
we
create
the
Cobra
command
for
annotate
and
it
connects
all
the
all
the
usage
like
the
long
usage
short
usage
examples
and
then
what
another
common
pattern
that
you're
going
to
see
is
that
almost
all
of
the
the
run
that
happens
when
this
finally
gets
executed?
There's
always
three
sub
or
there's
three
functions
that
get
called
there's
a
complete,
validate
and
then
run
the
command
run.
Annotate
the
complete
will
fill
in
the
options,
and
you
know
basically
complete
that
option.
D
Struct
the
validate
will
validate
those
options
and
then
the
run.
Actually,
that's
where
you
know
the
rubber
hits
the
road
you
actually
run
the
command,
and
so
underneath
it
you're
gonna,
see
all
of
the
connection.
Connection
of
the
flags
and
Cobra
knows
how
to
basically
parse
those
flags,
and
you
will
fill
the
data
from
the
flags
into
your
Shen's
variables
like
over
right.
You
see
the
address
of
ODOT
override
so
you're
filling
in
the
option
struct
with
the
value
from
from
a
flag.
D
If
there's
an
overwrite
flag,
so
am
I
getting
like
too
deep
into
the
is
this
so
so
actually
a
lot
of
this
was
covered
in
this,
the
workshop
that
happened
on
Monday.
So
if
you
guys
want
to
see
that
video,
actually
there
were
some
technical
hiccups,
but
I
think
that
at
least
the
presentation
of
it,
a
lot
of
the
content
would
be
really
if
this
is
what
you're
you're
interested
in
is
finding
out
the
you
know
the
the
deep
dive
into
how
coop,
cuddle
or
coop
control
actually
works,
and
what
the
code
looks
like.
B
A
This
do
we
want
to
do
with
the
code.
It's
pretty
simple.
If
you
look
at
one
command,
you'll,
pretty
much
get
any
command,
because
90%
of
the
code,
at
least
in
annotate,
is
a
boilerplate
that
is
copied
over
and
over
from
command
to
command.
There's.
Oh,
there
will
be
always
entity
of
options.
It
has
all
the
options
that
command
has
plus
the
extra
that
are
needed
for
execution.
A
Complete
is
setting
up
clients
and
stuff
like
that,
you'll
most
probably
copied
them
them
over
from.
We
have
something
that
is
called
it's
one
of
the
staging
repos.
It's
called
sample,
CLI
plugin.
It
literally
is
the
simplest
possible
command
that
could
possibly
live.
So
complete
will
be
just
that
validate
well.
That
will
depend
on
the
logic
of
your
command.
It
can
be
it
can
it
cannot.
A
It
is
possible
for
it
not
to
exist
if
there's
no
validation
for
your
command,
but
the
actual
meat
of
the
command
and
something
that
you
might
be
interested
in
lives
inside
of
the
run
command.
Maybe
let's
show
the
run
annotate
sure
I
guess
that's
like
literally
all
the
thing,
because
the
rest
is
I,
do
hope
pretty
self-explanatory.
It's
like
wiring
flag,
too
Cobra
complex,
complete.
It's
pretty
reasonable
because
we're
just
getting
dry
around
flack
setting
stuff,
but.
A
On
a
tape
is
like
literally
where
the
actual
functionality
of
the
command
is
here,
for
example,
we
are
using
something
called
a
resource.
Builder
resource
builder
is
a
is
a
structure
a
and
and
with
the
entire
built-in
functionality
that
is
Liz
living
inside
of
the
CLI
runtime.
So
if
you're
thinking
about
writing
a
seal
like
plugin
for
keep,
CTL
or
or
or
or
basically
your
own
command
for
interacting
with
kubernetes
api
resource
builder
from
the
CLI
runtime
will
be
very
useful.
Why
would
you
ask
first
of
all
it?
A
It
has
all
the
API
knowledge
and
it
can
either
connect
a
remote
cluster.
Read
the
resources
you're
interested
in
or
it
can
read
the
same
resources
from
a
file
all
that
is
being
currently
passed
through
here.
Unfortunately,
for
historical
reasons,
if
you
have
a
look
at
this
command,
it's
like
one,
two,
three,
four,
five,
six,
seven,
eight
additional
steps
that
we
do,
you
might
wonder:
what's
unstructured
local
param,
continuing
their
a
namespace,
param
and
whatnot,
if
someone's
interested
in
in
squashing
this
thing
into
one
two
calls
I
would
like
to
see
that
happen.
A
90%
of
the
commands
is
copying
pasting.
This
thing,
actually,
this
one
is
slightly
different
because
that's
one
is
using
unstructured
I,
don't
want
to
go
deep
into
detail.
What
unstructured
and
what's
typed,
but
basically
the
idea
is
I
would
like
to
minimize
that
invocation
to
I
one
builder.
That's
it
and
then
not
to
mention
that,
after
whether
it's
local
or
non-local,
it's
adding
additional
bunch
of
stuff,
it's
nice,
but
we
are
pretty
certain
that
90%
of
cases
90%
of
the
commands
that
we
have
within
cube
CDL
could
be
could
be.
A
So
if
I
want
to
put
annotation
on
a
pod,
it
will
read,
the
pod,
add
annotation
on
to
it
and
then
either
write
it
or
push
it
to
the
server.
Eventually
we're
doing
some
check
and
then
there's
iteration
over
resources
at
the
bottom.
We
are
reusing,
visitor
pattern.
The
resource
builder
returns
a
result
and
you
can
iterate
over
the
results,
and
we
are
using
visitor
pattern
inside
of
this
the
resource
builder
again,
and
we
are
basically
calling
update
annotation
function,
which
is
as
simple
as
oh
yeah.
A
Add
those
annotation
that
the
user
specified
and
the
and
basically
most
of
the
command
will
be
reusing,
the
same
pattern:
what
label
will
be
identical?
The
only
difference
will
be
instead
of
setting
annotations.
We
are
selling
labels
set
resource
or
set
limits
that
image.
They
are
pretty
much
the
same.
The
only
difference
between
set
image-
and
this
one
is
that
set
image
is
using
something
called
polymorphic
helpers.
A
A
A
So
these
days,
the
problem,
one
of
the
problems
why
we
did
it
was
that
if
people
had
CR,
these
cubes
ETL
did
not
know
how
to
print
their
CR
days,
but
the
CRT
out
CR,
the
others,
knew
exactly
that
they
care
about
field
ABC
and
D
keeps
ETL
only
printed
name
and
and
the
creation
date.
That's
why
we
exposed
we
extended
the
see
Rd
definition
for
the
orders
to
be
able
to
specify.
A
Oh
I
want
to
have
this
this
and
that
and
the
other
field
printed,
but
that's
the
knowledge
that
is
that
exists
on
the
server.
That's.
Why
currently
server
sends
to
the
cube
CTL,
something
that
is
called
a
table,
which
is
a
header
and
just
the
data
that
we
need
to
print
and
I.
Think
118
will
be
the
time
where
we
will
remove
the
code
responsible
for
printing
the
resources
from
cubes
ETL
entirely,
if
not
1819
I
do
hope
is
when
this
should
happen.
A
You
can
freely
use
the
client
and
that's
not
a
problem.
The
resource
builder,
the
only
difference,
will
be
that
client
will
get
to
a
particular
resource
right
away.
So
if
you
ask
for
pods
you're
gonna
get
pods
resource
builder
gives
you
the
flexibility
of
working
with
multiple
with
multiple
types
of
resources
which
you
don't
have.
There
is
something
called
dynamic
client,
but
that,
unfortunately,
is
similar
to
the
unstructured,
which
means
you're,
not
gonna,
get
a
specific
type
of
resource.
A
You're
gonna
get
a
map
of
strength
to
emptying
for
interface,
representation
of
the
resource
from
the
server.
So
that's
one
thing
and
client
will
always
reach
the
server
resource
builder
can
either
get
data
from
the
local
disk,
local
file,
local
input
stream
or
from
the
server
depending
on
how
the
flags
the
user
specified.
So
it's
more
like
it's
a
wrapper
around
around
client.
A
D
And
there's
for
the
client
there's
one
other
abstraction,
which
is
this
helper,
that
that
is
actually
very
common
in
coop
control,
but
there's
there's
actually
many.
As
you
mentioned,
there's
many
different
types
of
clients,
including
like
a
discovery,
client,
dynamic,
client
client
set
from
client
go.
The
commonality
amongst
all
of
them
are
usually
that
they
wrap
the
rest,
client
and
the
rest
client
understands
that
rest
protocol.
You
know
the
HTTP
method
as
well
as
the
URL,
the
URL.
D
You
know,
if,
like
you,
were
getting
a
pilot
in
a
particular
namespace,
it's
gonna,
you
know,
there's
a
particular
URL
to
hit
that
end
point
on
the
API
server
for
it,
but
but
it
turns
out
it
you're
right.
It
is
a
little
bit
I
think
a
little
bit
awkward
that
you
have
this
builder.
That
is
an
abstraction
for
it's.
It's
basically
just
retrieving
resources,
but
the
what
what
it
gives
you
is
that
as
much
you
said
it
abstracts
away
where
you
get
it
from
either
the
API
server
or
the
file
system.
D
It's
going
to
get
this
ya
mole
or
this
object,
and
it's
going
to
decode
it
usually
into
or
not
usually,
but
sometimes
into
a
strongly
typed
golang
struct
like
a
pod.
If
it's
a
pod
it'll
be
decoded
into
this
struct
and
then
there's
this
this
other
abstraction,
which
actually
is
kind
of
more
here's.
The
crud
operations
against
the
API
server
that
you
could
do
that.
Yeah.
A
A
A
similar
pattern
that
we
also
use
in
the
other
direction,
I,
don't
know
like
about
two
years
ago:
every
single
command,
almost
reimplemented,
the
idea
of
printing
resources,
and
if
you
look
at
cube,
I,
don't
know
14:12.
For
short,
there
was
no
consistency.
Currently,
if
you
specify
Oh
young
Jason,
name
every
command
across
the
board.
It's
consistent
with
that
beforehand.
Well,
some
had
Young's
some
had
Jason
some
had
both
some
had
short
names.
Some
had
wide
output.
It
wasn't
consistent.
A
D
F
Yeah,
probably
a
design
question:
there
are
several
references
mentioned
to
server
versus
client
functionality
so
get
and
then
the
apply
command.
So
we
also
have
a
situation
where
we're
running
coop
cuttle
in
a
pod
as
part
of
an
operator
that
we've
created
and
particularly
customized
functionality
that
we've
been
talking
about.
F
Sometimes
you
know
we
wonder
about
whether
you
know
so
what
is
the
determination,
I
guess
that
you
make
with
respect
to
functionality
being
part
of
the
client
versus
the
server,
because
I
could
imagine
a
scenario,
especially
if
we're
creating
operators,
for
example,
I
need
to
customize
like
functionality
that
it
may
be
the
case
that
that
type
of
functionally
may
be
more
convenient
to
be
in
the
server
rather
than
the
client.
So
what
kind
of
what
is
the
decision?
How
do
you
make
the
decision
so.
D
So
it
it's
basically
his
it's
basically
been
historical
up
till
now.
It's
just
been,
you
know
what
somebody
has
implemented
and
then,
after
the
fact
we
said,
oh,
it
makes
a
lot
more
sense
that
apply
beyond
the
server.
So
multiple
clients
can
actually
hit
the
endpoint
do
this.
Instead
of
having
this
massive
amount
of
applied
code
and
complexity
that
it's
gonna
be
really
hard
for
other
clients
and
controllers
to
re-implement
its.
B
A
B
Not
a
go
moving.
Something
to
the
server
is
an
on
goal
right,
because
delivering
value
is
our
goal.
Types
of
things
that
don't
make
sense,
necessarily
moving
to
the
server
quote.
Unquote,
are
things
that
work
on
a
collection
of
resources
right,
so
the
server
and
when
we
say
server
we
mean
API
server
in
this
context,
operates
on
the
single
resource
right.
So
something
like
the
namespace
portion
of
customized
moving
that
into
the
API
server
is
not
something
we
have
any
plans
of
doing
I.
B
B
Another
consideration
is
how
soon
do
you
want
this
in
folks
hands
right
because
folks
are
running
like
old
versions
of
kubernetes
right
and
so
say
we
introduce
a
new
feature
like
deletion?
Is
something
they've
been
talking
about
and
declared
a
deletion,
and
maybe
you
can
just
annotate
a
resource
to
delete
it
through
apply,
which
could
be
implemented
in
server
side
apply
pretty
trivially.
For
that,
so
we
decided
write
in
so
there's
two
considerations
there.
The
first
is:
how
mature
is
that?
How
do
we
want
to
roll
it
out?
B
How
do
we
want
to
enable
it
for
folks
right
and
when
we
put
stuff
in
the
API
server
like
that
deletion
command
or
that
deletion
piece?
It's
really
hard
to
change
afterwards
right
if
we
put
it
in
the
CLI
and
make
it
a
flag,
and
we
change
our
decide
our
decision
on
how
to
implement
it,
not
so
hard
right,
keep
the
flag
around.
We
put
it
in
the
API,
really
really
hard
to
change.
How
do
we
implement
that?
So
that's
one
consideration
of
introducing
the
client
first,
let
it
mature
move
it
to
the
server.
D
B
A
There's
the
other
important
factor
is
whether
the
command
is
meant
to
work
with
extensions
or
not.
Dad
was
a
very
good
example
of
that
one.
How
can
I
suppose
how
we
within
the
gap
or
coops
ETL,
are
supposed
to
know?
What's
your
extension?
What's
your
CRD,
the
same
problem
applies
to
describe,
and
we
are
currently
discussing
that
with
the
cig
API
machinery
how
to
move
describe
to
the
server
same
way
we
moved
the
same
way.
A
We've
moved
get
server
knows
the
CRT
outdoors
knows
what
are
the
main
fields
that
they
want
to
see
printed
as
part
of
it.
They
can
embed
that
information
inside
of
the
CR
definition.
The
cube
CTL
get,
will
only
then
read
that
a
done.
That
was
one
of
the
reason
why
we
did
get
and
we
moved
it
like
it
is
called
server-side
printing.
Officially,
it's
not
the
service.
I
get
it's
the
surface,
I
printing.
If
you
find
a
flag
in
the
get
there's
a
server-side
print
which
is
false,
what
would.
E
A
I
mean
the
explain
command
by
default,
is
reading
the
open,
API
information
that
we
are
keeping
on
the
server,
and
this
is
again
an
effort.
Like
you
see,
we
interact
with
other
six
Allah.
This
is
an
effort
that
we
in
cooperation
with
the
API
machinery,
because
we're
not
doing
any
magic.
If
you
look
under
explain
what
we
actually
do
is
we
read
the
open,
API
information
that
the
server
publish
and
we
just
display
it
nicely
in
a
tabular
form?
That's
basically
it
so
for
any
C
Rd
to
have
a
proper
cube,
CTL
explain
data.
A
It
has
to
have
a
proper
metadata
embedded
in
the
CR
D
definition.
If
you
have
that
and
recently
with
with
the
work
towards
the
structured
schema
on
the
server
side,
it
does
require
some
additional
extra
work
from
the
CRT
authors
to
comply
with
this.
But
here
the
queue
builder,
which
is
I,
wouldn't
call
it
our
project.
A
But
it's
a
project
that
we
partially
take
part
in
cube
was
fill,
was
one
of
the
co-authors
initially
to
builder,
has
a
controller
gen
and
as
part
of
the
controller
gen,
you
can
generate
that
schema
for
your
CR
DS
and
we,
for
example,
in
open
super
heavily
reusing
that
mechanism
to
ensure
that,
let's
see
are
these
are
explainable
to
users.
Yes,
but
that's
a
server-side
thing
that
just
CRD
authors
need
to
put,
and
then
we
just
explain
I
ask.
B
E
B
B
Spent
questions
you
said
you
learned
about
the
API
through
explain
and
I've
asked
this
question
before,
but
I'm
curious
to
see.
If
the
answers
are
the
same,
who
here
learns
about
who
control
through
the
command
help
as
the
primary
way
way?
Jóvenes?
Okay?
Who
here
learns
about
coop
control
through
the
documentation,
either
on
Cates
that
IO
or
the
COO
builder
book
or
other
sources
like
that?.
G
E
A
A
B
A
B
B
That's
why
I
came
working
in
CRTs
if
CR
DS
published
the
metadata
as
part
of
their
definition.
So
yes,
these,
specifically
the
help
commands,
will
pull
down
that
information.
Now,
that's,
like
you
know,
90%
true,
like
I,
think
there's
certain
things
like
you
can
run
help
on
a
command
and
then
it
will
show
you.
This
is
how
you
use
the
command,
but
maybe
it
didn't
talk
to
the
server
and
the
server
doesn't
support
that
API
and
when
you're
on
the
command
there'll
be
an
error
or
something
like
that.
B
C
A
I
A
Not
gonna
remove
it
entirely.
We
are
the
plan.
Is
we
move
all
the
burden
from
the
cubicle
run
and
leave
it
like
dumb,
simple,
similar
to
docker,
run
pod
magma
and
whatever
run
run,
thus
the
most
basic
unit,
which
is
a
pod
in
communities
world
in
a
cluster
which
is
I,
think
a
fur
starting
usage,
I've.
B
Heard
that
a
lot
actually
the
teaching
case
and
what
I'd
rather
do
is
actually
develop
a
command
to
help
users
learn
how
to
use
this
system
right,
like
coop
control
run,
may
be
the
best
tool.
You
have
right
now
to
teach
people,
but
there's
also
a
lot
of
flags
in
there
and
I
bet.
Not
all
of
those
flags
are
really
the
things
you
want
to
use
to
teach
people
right,
for
instance,
and
so
if
we
were
to
take
that
and
say
actually,
let's
just
make
it
clean
and
focused
on
teaching
people
to
use
the
system.
B
A
Would
even
I
would
even
welcome
that
kind
of
a
command
that
will
help
me
start.
It
help
me
start
the
workshop
or
anything
like
that
as
that
built-in
command,
because,
yes,
we
are
more
than
100%
a
word
that
this
is
a
problem
and
how,
from
Ron
that
will
be
creating
just
a
pod
direct
people
towards
create
deployment,
create
job,
a
cron
job,
great
service
expose,
expose
deployment,
expose
service
and
all
those
bits
that
are
already
there.
We
we
do
miss
this
kind
of
run.
A
Oh
I
need
to
this.
Have
the
problem
currently
that
exist
is
after
I'm
done
with
Ron
I
need
to
know
the
perimeter
that
I
want
to
create
to
be
able
to
match.
Oh
I
actually
want
to
keep
cube,
Caudill
create
deployment,
but
the
user
that
is
just
starting
that
just
run
his
image
in
a
cluster
doesn't
know
that
he
needs
a
replica
set
or
deployment.
So.
B
A
B
B
A
A
B
Actually
be
yes,
it's
basically
templating,
but
that's
what
the
crate
commands
are
and
we
actually
are
directing
people
towards
great
commands.
I'd
say
my
preference
would
be
to
if
we
had
it.
If
we
had
a
clean
slate
I
take
the
crate
commands
we
have
today
have
an
output,
Y
mo
tell
people
to
pipe
them
to
apply,
and
then
we're
teaching
people
the
more
patterns,
some
interesting
things
about
cook
control
run.
Actually,
our
t
I.
Those
are
actually
super
useful,
like
being
able
to
connect.
I
can
imagine
those
being
super
useful
for
ya.
A
Maybe
maybe
I'll
tell
a
little
bit
about
how
you
wanna,
if
you
want
to
create,
because
there
you've
mentioned
that
at
the
beginning
so
fixes
are
you
know
you
just
submit
a
patch
open,
open,
app,
ER
and
ping
us
for
reviews.
It
also
helps
if
you
show
up
on
the
sick,
CLI
meetings
and
bring
to
all
the
people
attention
that
yes,
I
created
this.
This
is
the
type
of
effects.
A
B
Once
we
add
that
right,
and
so
we
want
to
be
really
careful
before
we
add
these
sorts
of
things
and
there's
probably
like
three
different
ways:
the
UX
can
work,
and
maybe
it's
consistent
with
this
other
command.
But
it's
actually
not
the
way.
We
want
to
write
it
and
so
there's
a
lot
of
debate
that
goes
and
each
one
of
these
things
and
so
having
those
sorts
of
relationships.
One
kind
of
removes
the
like
reading
the
comments
and
being
like
what
was
behind
this
comment
and
I
thought
they
told
me
to
do
this.
B
A
A
Want
like
we
don't
buy,
we
try
to
have
fun
meetings
every
other
week
on
Wednesdays,
so
definitely
show
up
and
talk
to
us
and
then
again,
if
you
have
a
major
feature
that
you're
considering
working
on,
then
definitely
you
want
to
show
up
talk
throughout
the
idea.
You
have
into
the
agenda,
discuss
it
through
with
the
group
and
only
after
you
have
a
more
or
less
consensus.
A
The
next
step
will
be
write,
a
cap
because
that's
what
we
usually
end
up
asking
people
to
do
and
whether
that
will
be
to
you
will
be
directed
towards
Oh,
give
it
a
try,
write
a
plug-in
or
write
a
cap
and
we'll
see
where
it
goes.
That
will
depend
on
the
discussion.
So
definitely
the
meetings
is
is
worthy
attending
there
are
I
do
hope
at
some
reasonable
times.
I
know
we're
kind
of
not
your.
B
D
D
D
B
B
I
Okay,
I
just
had
a
so
back
to
we
were
talking
on,
keeps
detail,
explain.
I
saw
a
nice
trick
from
Joe,
where
you
can
like
toss
on
the
recursive
flag
and
like
pipe
that
out
to
a
file
and
like
that,
gives
you
almost
like
a
template
to
start
working
with.
That
has
like
all
the
options
on
there
has
like
a
full-fledged
like
generate
me,
a
you
know,
a
new
deployment
file.
Yes,.
B
You're
trying
to
solve
is
how
do
I
get
started
with
the
configuration
right
and
there's
number
of
techniques
we've
described,
we've
been
exploring,
specifically
ones
that
are
going
to
work
with
CRTs
and
work
with
extension
mechanisms,
so
doing
it
from
the
open,
API
I
think
is
effectively
what
you're
describing
is
a
way
that
we've
prototyped
and
experimented
with,
and
it's
better,
but
it
still
has
a
number
of
issues,
I
think
and
so
I
actually
have
a
couple
prototypes
of
ways
of
doing
this.
If
it's
something
you're
interested
in,
let's
follow
up.
E
When
we
started,
we
started
with
no
approach
for
CLI
structure
like
having
a
CMD
directory
and
with
all
commands.
Then
we
looked
at
CL
Aaron
time,
and
then
we
had
this
complete,
validate,
run
pattern.
So
I
have
this
question
like
how
you
got
inspiration
of
moving
to
this
pattern
or
what
all
things
you
faced
that
so
that
you
move
this
pattern.
I
mean
I
really
like
this
pattern.
The
dynamic
crave.
C
A
From
oh
we're,
getting
more
CRD
is
how
we
can
bake
in
the
knowledge,
because,
currently,
if
you
look
at
the
create
commands,
there
are
very
simple,
but
unfortunately
they
rely
on
the
go
types
being
present
within
the
cube
CTL
during
compilation,
and
we
can't
go
this
path
towards
with
a
CRT.
Obviously,
so
we
need
to
have
a
dynamic
way
for
a
cube.
Gotto
create
to
know
what
are
the
actual
required
fields.