►
From YouTube: Kubernetes SIG CLI 20220223
Description
Kubernetes SIG CLI bi-weekly meeting on February 23, 2022.
Agenda and Notes:
https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=id.jodjnabod8f1
A
According
to
the
cloud
welcome
to
another
edition
of
these
bi-weekly
cli
meeting,
I'm
your
host
sean
sullivan,
we're
going
to
start
with
some
announcements
and
then
we're
going
to
progress
to
a
couple
introductions.
I
see
there's
a
couple
of
people
who
don't
normally
attend
our
meetings
and
then
we're
going
to
get
into
our
topics.
A
A
B
You
did
yes
thank
you.
This
is
a
bit
of
a
tongue
twister,
so
thank
you
for
getting
it
right.
My
name
is
tom.
I'm
the
director
of
developer
relations
at
a
startup
called
lightrun,
and
I
would
present
when
my
time
comes.
No
personal
project
would
like
to
contribute
back
to
the
sig.
So
we'll
talk
about
that,
then
thank
you
for
having
me.
A
C
My
name's
holden
o'neill,
I'm
a
software
developer
at
sas
institute.
You
may
be
familiar
with
one
of
my
previous
co-workers
bailey
hayes,
who
I've
seen
her
name
in
here
and
talked
her
a
bunch
she's
at
single
store
now,
but
I'm
picking
up
a
bunch
of
the
work
around
our
internal
usage
of
customize
and
creating
customized
manifests
and
doing
all
that
jazz.
F
Yeah,
so
this
is
just
an
issue
on
the
customized
repo.
We
are
really
excited
to
have
a
volunteer
to
tackle
this,
which
we're
hoping
to
find
someone
who's
interested
in
taking
on
the
issue
in
a
holistic
way
and
seeing
it
through,
and
we
a
volunteer
so
we're
looking
to
make
a
plan
as
to
what
we
want
to
do
with
this.
More
specifically
to
outline
the
problem.
Customized
documentation
is
split
across
four
different
places.
F
There
is
a
legacy
version
of
the
site,
that's
still
being
published
off,
of
the
repo
itself,
like
with
github
pages,
and
that
is
mostly
redirects,
but
it
hasn't
been
entirely
cleaned
up,
there's
the
main
documentation
so
most
of
it,
which
is
being
published
off
the
sig
cli
experimental
repo,
which
is
a
hugo
site.
It
has
the
most
information
by
far
and
is
otherwise
definitely
the
best
source,
but
it
has
severe
seo
problems.
If
you,
google,
customized
docs,
it
doesn't
come
up.
F
We
run
tests
against
like
run
them
as
tests,
which
is
which
is
really
nice,
but
they
are
completely
separate
from
the
main
documentation
because
they're
over
on
our
repo,
so
they're
not
integrated
and
then
the
fourth
place
is
some
spar
stocks
in
the
main
kubernetes
docks
themselves,
which
that
one,
I
think,
that's
okay,
that
we
have
a
little
bit
of
documentation
there
and
it's
not
an
appropriate
place
to
go
into
extreme
levels
of
detail
about
advanced
customized
features.
But
the
other
three
are
what
we
want
to
consolidate.
Oh
wait.
F
Did
I
even
mention
the
customized
io,
that's
the
the
front
page
that
replica
replicated
donated
to
us
so
that
one
links
back
to,
I
think
the
github
pages
site.
That's
mostly
redirects.
It
is
a
single
page
thing
that
is
prettier
than
the
rest
of
our
docs
and
actually
has
good
seo.
So
there
you
go
tons
of
different
spots
that
we
have
the
docks
and
the
goal
is
to
sort
of
yeah,
consolidate
them
and
make
it
easier
on
our
users
and
on
us
to
maintain
this
stuff
going
forward.
F
The
two
main
options
that
I
see
are
sticking
with
the
sig
cli
site,
which
is
it's
basically
for
cube,
control
and
customize,
and
every
single
page
that
you
go
to
there's
like
a
bifurcation
like
you
know,
guides
customize,
cue,
control,
api
documentation,
customize,
cube
control
like
it's
got
two
sections
in
pretty
much
every
section
to
split
apart
the
docs
for
those
two
tools.
They
are
connected,
of
course,
but
it's
a
little
disjoint
that
is
certainly
is
certainly
possible
for
support
all
the
the
content
over
there.
F
The
disadvantage
is
that
we
continue
to
have
the
examples
on
our
own
repo
in
order
to
test
it
with
our
regular
suite
so
that
that
won't
be
integrated,
and
it
is
the
information
architecture
is
a
little
challenging
like
we
couldn't,
for
example,
like
just
bring
in
the
customizatio
homepage
from
replicated,
because
it's
not
a
dedicated
site.
So
we
can't
just
say:
okay,
we're
gonna
use
that
as
an
entry
point
and
we're
going
to
merge
everything
else
in
like
that.
Would
that
wouldn't
really
work
if
the
site
is
still
60
line?
F
I
think
it's
clearly
inappropriate
to
move
the
customized
specific,
deep
docks
there,
but
cute
pedal,
maybe
someday
they'll
they'll
come
back,
and
actually
you
know
work
on
that.
So,
if
that
were
to
happen,
then
we
would
be
asking
ourselves
this
question
about
the
customized
docs
again.
So
with
that's
another
thing
to
keep
in
mind
with
these
options.
F
So
I
guess
that's,
that's
that's
the
situation.
Does
anyone
have
any
thoughts
on
which
of
these
two
options
seems
more
desirable?
Does
the
stake
feel
strongly
about
like
historically
what
why
did
did
cute
covalent
customize
end
up
merging
the
docs
in
the
first
place
to
six
eli
any
any
feedback
or
historical
context
or
opinions
on
this.
F
A
D
So
yeah
I
I
have
been
talking
to
sig
docs.
It
definitely
fell
through
the
gaps
there
and
they
definitely
had
a
period
of
turnover
with
leadership,
and
so
we
can
bring
it
back
up
to
them.
The
idea
I
have
I've
been
our
original
doc
site
was
from
a
google
season
of
docs
mentee.
I
believe,
I
think,
they're
the
ones
who
worked
on
the
cli
experimental
one
if
we
so
the
lfx,
the
linux
foundation's
mentorship
program,
which
is
also
project
driven
application
deadline,
closes
for
the
25th.
D
So
we
still
have
two
days
if
we
want
to
submit
a
project
for
mentees
to
work
on.
So
if
we
we
would
have
to
provide
guidance,
though
right
it's
like
hey,
we
have
to
scope
it
out.
We
have
to
help
them.
So
if
we're
looking
for
like
someone
to
you,
know
a
mentee
to
put
time
into
and
help
them
get
through,
it
like
that
might
be
a
good
option.
F
F
I
guess
that's
the
question:
do
we
want
it
all
in
one
place,
because
I
I
don't
know,
I
guess
my
personal
opinion
is
that
I
I
would
think
it
kind
of
makes
more
sense
for
customers
to
be
separate
because
of
that
bifurcation
like
every
single
time.
You
try
to
lift
something
up
on
our
existing
dock
site.
You
have
to
there's
extra
clicks
to
go
through
to
the
actual
tool
that
you're
looking
for,
and
I'm
not
sure
that
for
an
end
user,
the
six
seal
I
mean
branding
is
meaningful
like.
F
Why
do
they
care
which
sig
maintains
it?
Do
they
even
know
that,
like
they
probably
are
looking
for
the
tool,
not
not
for
the
sig,
so
like
I
actually
leaned
towards
having
customized,
I
o
and
cube
control,
dot,
io
separated,
even
if
q
control
stays
independent
but
yeah,
I
think
before
we
bring
it
to
take
dogs.
We
should
probably
like.
If,
if
we
have
an
opinion,
we
should
settle
on
it.
A
F
What
it's
not
actually
keep
control
customize,
isn't
like
an
embedded
customized
inside
cube
control.
It's
like
an
embedded
customized
build.
So
there's
a
lot
of
stuff
that
that,
if
you
think
it's
the
latter
or
sorry,
the
former
you're
going
to
be
confused-
and
we
don't
do
a
good
job
of
explaining
that,
because
they're
like.
E
F
F
Yes,
it
is,
and
we
have
we've
been
getting
reports
about
that
since
before
we
had
access
to
the
code,
we
should
probably
just
remove
the
link.
We
don't
have
access
to
the
api
that
backs
that
and
we
don't
have
the
bandwidth
to
maintain
it
either,
even
if
we
did
so,
I
think
we
should
just
go
ahead
and
remove
that.
G
G
F
E
A
D
Yeah,
this
is
quick.
I
just
had
a
I
had
a
new
contributor
reach
out
that
is
interested
in
working
on
this
cap.
I
think
they're
on
the
call
today,
I'm
going
to
butcher
your
name,
I'm
so
sorry,
sahu,
I'm
awful
with
names,
but
you
do
you
want
to.
You,
have
any
insight
you
want
to
share
or
what
you're
looking
to
work
on,
or
I
suggested
they
come
here,
and
we
also
can
look
into
the
the
status
of
this
cap.
I
think
I
think
ross
was
taking
it
over
for
ricardo.
E
E
E
A
E
E
It's
especially
useful
in
scripting
activities
where
you
know
something
might
fail,
but
you're
in
the
position
to
handle
it.
If
you
are
given
the
right
code-
and
you
know
you
know
how
you
know
how
to
work
around
with
that
code,
you
can
potentially
continue
the
the
scripting
operation
until
it's
successful.
So
really
the
exit
codes
are
about
making
it
easier
to
to
automate
scripts
and
to
give
those
scripts
a
little
bit
more
insight
into
what's
happening.
D
A
E
D
B
B
Well,
I
assume
I
usually
start
off
by
mentioning
what
it
is
that
this
whole
project
is
about
which
is
coop
city
ld
bug.
I
feel
as
if
the
room
is
quite
aware
of
the
picture
that
was
released
to
beta
a
while.
Back
specifically,
we
noticed
when
the
feature
we've
been
following
it
for
a
while
now
and
we
waited
it
for
go
to
go
into
beta,
and
we
had.
B
We
noticed
one
aspect
about
the
api
that
that
felt
as
if
it
could
use
a
bit
of
love,
which
is
this
part
here
so
as
far
as
we
know,
and
that
that
might
be
incorrect.
So
please
feel
free
to
correct
me
if
I'm
mistaken
here,
but
there's
no
default
set
of
images
intended
for
use
with
groups.
Tl
debug
you're,
basically
saying
that
through
a
busy
box
or
anything
else
on
that
image,
so
that
would
spin
up
when
the
when
koopa
city,
when
they
female
container
spins
up.
B
Basically
now
we
thought
about
it
and
we
I
work
for
an
observability
company.
We
build
developer
native
debugging
tools
for
like
the
cloud
native
world,
and
one
of
the
things
that
kept
on
coming
up
is
when
you're
shipping
a
real
production
application
over
kubernetes.
The
images
are
built
digitalis
or
just
like
very
tiny
images
that
don't
contain
all
the
tools
that
you
need.
B
So
we
collected
a
bunch
of
tools
that
relate
to
networking
troubleshooting
and
a
lot
of
runtime
work
and
I'll
explain
what
that
means
in
a
moment,
bake
them
into
images
that
you
can
use
with
group
cdl
debug
create
a
short
script,
that
kind
of
wraps
them
around
in
a
nice
api
way
in
a
nice
api,
sorry
and
publish
the
repo,
and
I
want
to
show
just
the
repo
itself.
It's
called
cool
kids,
so
kubernetes
toolkits,
which
we
thought
was
cute
and
basically
at
the
end
of
the
of
the
of
the
line.
B
I
have
a
bunch
of
pods
running
on
minikube
locally
and
the
way
I
usually
demo
it
is,
if
I
would
do
groups
that
exact
one
of
those
parts
using
a
normal
bash
terminal.
This
is
running
a
simple
java
application.
It
doesn't
do
much
except
for
counting
prime
numbers.
My
cto
has
a
fascination
with
them,
so
all
of
our
demos
are
on
prime
numbers.
B
So,
instead
what
we
could
do
is
we
could
use
cool
kits.
So
this
kk
command
is
a
wrapper
around
the
coupe
security
bug
with
a
bunch
of
kind
of
pre-populated
parameters.
Let
me
actually
see
if
I
can
pull
up.
I
have
it
in
the
repo
I'll
show
in
a
moment,
but
anyways
the
api
feels
as
so,
you
give
it
the
command
line,
kk
the
name
of
the
pod,
the
name
of
the
cool
kit.
B
You
would
like
to
enter
in
this
case
the
jvm
cool
kit
and
the
name
of
the
deployment,
and
I
have
everything
I
need
on
path.
Sorry,
I
have
everything
I
need
on
path
so
jmx
term,
you
have
it
on
path.
You
have
sdk
to
get
all
the
nice
java
stuff.
You
like
you,
have
h
top
for
nice,
shenanigans
with
processes
and
so
forth,
and
so
forth.
There's
a
bunch
of
tools
we
baked
in
and
kind
of
pre-configured,
so
they'll
be
available
on
path
for
for
easy
debugging.
B
And
if
I
go
back
to
the
repo,
you
can
see
that
the
actual
thing
that
we
add
to
the
bachelor
c
of
the
user
is
just
kubectiol
debug
it
with
the
name
of
the
pod,
the
deployment
and
the
relevant
runtime
you'd.
Like
the
sorry,
the
runtime
cool
kit
you'd
like
to
spin
up
with
the
colon
process
and
we've
pushed
under
our
own
docker
hub,
docker
hub
organization,
a
bunch
of
different
cool
kits
for
different
runtimes.
We
started
out
with
java
python
and
ogs
it's
what
we
support
back
home.
B
So
it
kind
of
made
sense
for
us
and
we
have
a
bunch
of
things
on
the
roadmap
too.
So
we'd
like
to
create
one
specifically
for
go
we'd
like
to
add
a
bunch
of
tools
that
are
more
requires
some
finer
configuration
other
than
just
kind
of
getting
the
binary
and
doing
a
d
package
or
kind
of
installing
them
using
npm,
install
or
whatever.
So
we've
got
a
bunch
of
stuff
coming
up
and
there's
there's
basically
two
items
I
wanted
to
to
get
kind
of
to
show
with
the
community
today.
B
He
mentioned
that
this
would
be
a
really
kind
of
a
good
thing
to
kind
of
give
back
to
the
community,
and
he
said
I
should
pop
on
the
meeting
come
to
6cli
and
suggest
that,
and
then
I
talked
to
deems-
and
he
mentioned
that
I
should
present
it
and
then
perhaps
have
one
of
the
channels
of
the
6cli
group
open.
A
repository
on
github
see
how
we
can
get
everything
all
the
images
pushed
onto
gcl,
given
that
you
know
you
folks,
like
it
and
kind
of
it,
makes,
makes
sense
and
take
it
from
there.
B
So
basically
I'm
an
open
book
like
I
love
this.
It
was
a
so
such
a
fun
thing
to
build,
and
I
want
to
see
how
we
can
kind
of
spread
the
word
and
and
get
it
for
people
to
people
to
to
use
it.
One
extra
comment
that
that
was
often
asked
if
you
kind
of
followed.
My
demonstration
here
is,
if
I
have
my
own
scripts
and
my
own
programs,
that
I
want
to
add
to
cool
kids,
how
do
you
do
that?
B
A
B
G
B
And
like
wild
in
a
real
life
setting,
which
will
starting
to
get
a
sense
that
it
that
it
that
it
is
but
specifically
before
I
would
kind
of
suggest
this
to
any.
You
know
real-time
production
usage.
I'd
get
some,
I'm
not
a
security
person,
but
I'd
get
some
security
people
to
kind
of
take
a
look
and
tell
me
where
the
cell
facilia
is
most
vulnerable
and
kind
of
proceed
from
there.
Hopefully
get
people
from
the
kubernetes
sigs
itself
to
get
their
eyes
on
that.
G
B
We
don't
we
don't
mind,
especially
we
can
push
them
to
the
gcl
repositories
for
quantities
itself
and
then
have
it
under
kubernetes
repository.
We
can
host
them
ourselves,
we
we're
open,
whatever
is
most
more
comfortable.
I
was
just
one
of
the
things
that
dims
didn't
mention.
I
didn't
get
quite
a
good
answer
on
and
the
debate
about
the
customer
is
to
my
domain
here
kind
of
brought
that
up.
B
Is
it
easier
if
we
kind
of
own
the
resources
as
a
vendor
or
like
a
like
a
commercial
entity,
and
then
once
everything
is
kind
of
baked
and
settled,
we
pass
it
over
or
if
we
pass
over
the
resources
or
every
kind
of
the
stuff
first,
and
that
starts
from
the
beginning
of
the
process.
Is
that
easier
for
the
community
and
I'm?
I
was
a
bit
iffy
on
the
process
inside
the
six.
D
G
You
know,
I
think
the
I
think
I
think
is.
I
think
the
main
concerns
I
would
have
here
are
just
the
continued
maintenance
of
the
base
images.
I
think
it's
a
great
idea,
but
you
know
I
think
the
security
they're
gonna
skew
versus
you
know
security,
vulnerabilities,
they're,
going
to
go
out
of
date,
base
images
you
know,
depending
on
the
repo
there's
going
to
be
pull
pull
rate
limiting
and
if
we're
publicizing
these
on
the
main,
kubernetes
repo.
G
B
B
You
know,
originators
of
this
project
and
we're
willing
to
accept
and
do
that,
but
I
would
hate
for
this
to
kind
of
go
under
the
radar,
because
it
is
remaining
under
the
maintenance
of
a
separate
commercial
entity,
I'd
like
to
kind
of
see
how
we
can
at
least
get
some
on,
whether
we're
doing
the
right
things
from
the
community
itself
or
the
guiding
forces.
So
once
we're
ready
once
it's
fully
baked
once
it's
ready
to
kind
of
it
has
the
community
engagement,
it
has
the
proper
maintenance
structures
applied
it
on
a
constant
basis.
B
Has
the
pop-up
automations
in
place
perhaps
has
some
sort
of?
I
don't
know
again.
I
can
think
about
a
bunch
of
different
things
that
might
need
help
before
we
do
that.
But
what
you're,
basically
suggesting
so
I
understand
is
that
we
continue
maintenance
and
work
on
this
separately
kind
of
outside
of
the
sig
and
outside
of
the
main
project
roadmap
and
then
come
back
once
everything's
baked
just
just
kind
of
show
it
to
you.
Or
would
you
like
some
input
on
where
we're
going
with
this?
B
G
Because
on
our
side
we
need
to
do
code,
cleanup
yeah,
there
was
just
some
dirty
laundry.
We
needed
to
clean
up
to
be
honest
on
our
side,
but
in
the
in
the
process
of
that
we
we
got
a
lot
more.
You
know
we
got
a
lot
more
adoption,
so
we
got
more
confidence.
You
know
that
this
was
something
worth
pursuing.
G
G
It
was
probably
took
longer
than
that,
because
it's
a
larger
project
I
imagine
than
this-
so
I
imagine
in
your
case
your
turnaround
time
would
be
quicker
in
terms
of
the
what's
the
user
experience
proposal
here.
Is
it
just
to
have
advertising
for
the
base
images,
or
are
you
proposing?
There
would
be
a
sort
of
built-in
options
to
to
the
kukudo
debug
command
set
or
there
be
a
separate
sub-command?
What's
the
proposal
there.
B
That's
a
good
question:
we
thought
about
it
a
lot
and
we
wanted
to
be
as
less
intrusive
as
possible
to
begin
with,
because
those
two
those
two
possible
avenues
that
this
might
take.
In
my
opinion,
the
first
one
is
people
use
the
base
cookies
that
we
suggest
the
very
highly
opinionated
version
of
tools
that
we
choose
and
would
like
to
use
that
as
the
base
images,
as
so
as
to
not
consider
themselves
with
which
type
of
packages
I
want
to
install
and
so
forth.
That's
option
a.
B
If
we
go
with
that
direction,
then
to
me
it
makes
more
sense
to
find
a
way
to
bake
it
into
the
integrated
itself
as
a
kind
of
a
flag
with,
like
you
know,
instead
of
dash
dash
image,
dash
dash
jvm
image
or
dash
dash
networking
image
or
whatever
that's
optionally,
we
felt
that
this
might
be
too
intrusive.
So
and
also
it
removes
this
level
of
customization
that
I
feel
some
people
might
want
in
this
case,
because
we
might
have
version,
you
know
x,
point
one
of
jmx
term
and
somebody
needs.
B
You
know
x,
point
two
for
some
other
type
of
project
that
they
have
and
is
not
the
specific
version
with
a
feature
that
we
need,
so
we
thought
about
creating
an
outside
command
line
tool,
or
maybe
even
a
group
cdl
plugin
itself.
Again,
I
don't
know
yet
which
early
days
and
have
the
capability
to
customize
the
actual
image
that
is
being
pulled.
We
will,
of
course,
do
the
all
of
the
enumeration
and
create
the
relevant
images,
but
allow
the
user
to
customize
the
exact
things
they
want.
B
Added
to
that
image,
using
this
external
cli,
slash,
coop,
style,
plugin
and
have
it
live
outside
of
tree
outside
of
trunk.
Sorry,
basically
live
it
in
a
different
in
a
different
world.
I
have
a
sense-
and
this
is
just
my
personal
opinion-
that
we
will
get
an
endless
amount
of.
Please
add
this
requests
to
the
image.
Should
this
cache
traction
that's
going
to
happen,
and
I
think
the
best
api
is
to
allow
the
users
to
customize
it
themselves.
B
Maybe
not
all
the
packages
like
get
the
jvm
package
and
I
don't
know
svd
support
or
something
and
then
having
that
leave
outside
of
kind
of
the
main
coop
ctl
repository,
but
that's
kind
of
an
asterisk
have
what
could
scale
plugins
have
with
crew,
so
the
best
practice
or
like
the
the
good
way
to
get
good
debug
images
is
to
use
cool
kits,
but
it
doesn't
actually
live
in.
I
think
co
is
now
an
actual
kubernetes
project.
B
A
G
B
D
Yeah,
sorry,
I
I
should
have
started
with
thanking
you
for
wanting
to
donate
this
cool
thing
you've
built.
So
thank
you
for
for
coming
and
demoing
and
sharing
it's
always
awesome.
When
people
want
to
give
back
to
the
community
for
sure
we
can.
I
I
think
we
should
send
an
email
to
the
kdev
mailing
list,
and
we
should
you
know,
especially
once
you,
if
you
decide
to
do
a
plug-in
or
even
now,
just
be
like
hey
like
we're,
starting
on
this
toolkit
type
thing
for
debug
images.
D
You
know
I
I
could
absolutely
either
see
this
landing
as
a
plug-in
or
you
know,
even
if
it
lands
in
the
debug
plug-in
where
we
can
list.
You
know
if
there's
like
cubecontrol
debug
list
images,
and
we
provide
like
a
list
of
images
with
different
tags
and
names
and
so
there's
a
lot.
We
can
do
there
for
sure.
D
I
do
have
the
same
concerns
about
maintaining
and
customizability
and
we
get
a
lot
of
rock
when
it
comes
to
images
and
people
don't
upgrade
their
binaries
either
we
sell
people
that
are
using
cube
control
from
like
three
years
ago
and
plus
but
yeah.
I
I
think
it's
great,
and
we
should
definitely
we.
We
can
craft
an
email
together
if
you'd
like
to
send
to
the
cadet
mailing
list
and
yeah.
D
B
So,
but
by
all
means
I'd
appreciate
you
know,
jumping
on,
I
don't
know,
maybe
a
separate
caller
or
email
for
that
with
you
to
kind
of
draft
up
that
email.
I
want
to
mention
one
thing
that
that
bugged
me,
I
wrote
a
significant
portion
of
this.
The
docker
files
come
to
research
and
one
thing
that
kind
of
kind
of
immediately
came
to
me
was
coop
city,
l,
debug,
and
I'm
not
sure
if
this
is
the
correct
platform
to
raise
it.
But
it
is
kind
of
I
thought.
B
Groups
of
the
bug,
generally
speaking,
is
very
infrastructure,
oriented
in
the
sense
that
the
type
of
issues
you
might
be
able
to
debug
with
it
are
less
application
level
problems
and
more
infrastructure
level
problems,
and
that
is
true
for
most
debugging
utilities,
in
a
kind
of
in
a
very
highly
network
distributed
environment.
Now
the
problems
are
problems
with
networking,
with
things
not
being
whether
it's
supposed
to
be
and
so
forth,
and
this
is
a
question
not
not
a
not
a
comment,
but
generally
speaking
in
the
kubernetes
ecosystem
as
a
whole.
B
D
D
This
is
where
we
get
tricky
as
like
maintainers
of
the
project
and
and
I
for
some
reason,
I
keep
thinking
back
to
package
managers
right,
so
the
kubernetes
project
provides
binaries
and
a
single
ubuntu
debian
repository
and
we
get
requests
from
everyone
in
the
community.
Oh,
I
want
to
be
able
to
install
cube
control
with
this
package
manager
with
this
package
manager,
and
our
philosophy
has
been
to
kind
of
let
the
community
handle
distribution
for
that,
as
opposed
to
us.
D
Maintaining
you
know
a
repo
in
every
single
package
manager
out
there,
because
there's
new
one
every
day
it
seems-
and
I
don't
know
why
I
keep
coming
back
to
that
with
this.
But
that's
where
the
that's,
where
the
that
user
customization
comes
with
is
like
what
are
you?
Users
are
going
to
want
every
bit
and
tool
in
here,
and
you
know
we'll
have
to
figure
out
how
to
support
and
handle
that
if
this
is
something
we
decide
to
bake
in
and
that's
getting
way
ahead
of
myself
but
yeah.
D
B
If
I
can
get
the
same
experience,
I
have
with
debugging
with
intellij
locally
on
my
id
with
a
running
container
in
production.
That
would
be
awesome
now.
This
is
just,
and
the
cool
kids
is
just
like
one
tiny
step
in
that
direction
right.
But
I
felt
as
if
this
was
what
was
missing
from
those
people
who
got
kubernetes
sprinkled
on
them.
They
needed
this
type
of
familiarity
with
all
the
tools
they
know
within
diamonds.
B
B
Plugin
I've
written
one
before
I
think
you
can
write
one
again,
and
I
think
that
once
we
have
a
bit
more,
I
guess
traction
and
after
the
cate
of
email,
we'll
come
back
with
some
good
news,
hopefully
and
get
this
moving
all
right.
I
super
appreciate
the
opportunity
to
come.
Talk
to
you
all
today.
It's
awesome
awesome,
so
yeah,
I'm
here
for
the
end
meeting,
but.
A
G
B
A
F
I
did
that,
actually,
I
forgot
to
put
my
name
yeah,
so
a
quick
question
relating
to
docs.
Again,
we
have
a
contributing
md
on
on
the
sigs,
like
what
repo
is
that
org
or
community,
and
it's
definitely
out
of
date,
and
it's
also
specifically
about
cube
cattle.
So
one
of
the
action
items
that
we
have
to
do
for
the
annual
report
is
certifying
that
it
is
not
out
of
date.
So
I
wanted
to
bring
up
that.
We
need
to
do
that
work
and
also
point
out,
like
that.
F
It's
it's
very
specific
to
control
and
there's
already
docs
on
that
six
cli
experimental
site
that
are
extremely
brief,
but
also
about
how
to
get
started,
contributing
so
sean
in
particular.
You
and
somebody
else,
I
think
maybe
munchie
are
mentioned
in
this
stock
as
being
like
pinged
directly
for
support
on
issues
and
stuff
like
that,
which
I
don't
think
is
the
the
process
that
we
had
had
wanted.
So
perhaps
please.
F
So
I
I
think,
there's
we
have
some
work
to
do
there
in
any
case,
and
the
other
thing
for
the
annual
report
more
relevant
to
the
whole
entire
group
is
that
we
also
have
to
certify
that
the
maintainers
lists
are
up
to
date
on
all
the
sub
projects.
So
that's
something
that
we
need
all
the
sub
project
owners
to
well
own
and
and
make
sure
that
that's
done
before
the
report
gets
merged
cube.
I
can
save
for
both
karen
functions
and
customize.
That
is
already
done.
D
Awesome,
thank
you.
I
will
we
can
talk
about
this.
On
slack
too,
I
gotta
I
got,
I
gotta
do
feedback.
I
don't
give
me
a
bullet
point.
I
got
to
add
to
there
it's
funny.
I
did
sig
testings
yesterday
and
they
might
be
in
a
little
worse
shape
than
we
are
when
it
comes
to
owner's
files,
so
yeah
any
action,
any
other
specific
action
you
want
to
take
from
that.
We
just
need
everyone
to
confirm
their
owners.
F
D
Yeah,
sick
testing
doesn't
even
have
a
contributing
md,
so
we
can,
I
think,
most
people
honestly
just
have
the
the
boilerplate
one.
I'm
looking
through
some
sig
release
doesn't
have
one
sig
docs
has
one
there's
very
short,
so
yeah
we
can.
We
can
talk
through
cleaning
that
up.
We
can
send
a
draft
to
the
mailing
list
too.
If
you
want.
D
A
G
G
We
submitted
some
publication
and
cora
we'll
hear
next
month
about
whether
it's
accepted
rejected
cora
would
like
to
not
publicize
it
too
much
just
you
know
to
make
sure,
because
it's
anonymous
review,
but
the
paragraph
I
have
there
is
what
she's
happy
to
share
for
now,
but
things
could
change
in
a
few
weeks.
So
mostly
I
wanted
to.
I
can
summarize
the
findings
in
a
second,
but
are
you?
Are
you
all
interested
in
hearing
from
her
sort
of
a
deeper
dive
on
what
she
found?
G
G
G
So
the
main
thing
we
found,
I
think,
is
unsurprising
to
us
on
the
cli
side.
Is
that,
but
I
think
surprising
to
the
people
with
the
designers
we
talked
to
that
clies
were
the
vast
preference
for
most
tasks
and
across
the
board
of
expertise,
beginners
across
the
board.
In
fact,
beginners
prefer
the
cli
more
than
than
some
of
the
other
expertise
levels.
G
G
Whenever
I
talk
to
designers,
I'm
not
sure
if
you
spend
much
time
talking
to
designers,
but
their
their
real
mindset
is
really
centered
around
developing
their
web
consoles
around
a
beginner
experience,
and
I
think
our
data-
I
don't
know
my
experience,
russ
countered
that
and
the
day
that
we've
collected
friends
counter
to
what
their
assumptions
are
so
I'll.
Let
y'all
go
with
the
submission,
but
anyway
she's
happy
to
talk
anytime
in
more
depth.
I've
just
summarized
her
work.
Hopefully
I've
done
it
justice
that
would.