►
From YouTube: Kubernetes SIG CLI 20210602
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are
today
is
june,
the
second-
and
this
is
another
of
our
bi-weekly
six
year-
life
halls.
My
name
is
manche
and
I'll,
be
your
host
today,
and
I
should
probably
switch
to
6li
agenda
instead
of
the
presentation.
That
will
be
the
first
one
announcements.
A
I
think
the
only
announcement
I
have
is
with
regards
to
the
code
freeze
code
freeze
for
122
is
on
july,
8th,
if
I
remember
correctly
I'll,
post
the
link
to
the
sick
release,
122
page
just
so
that
anyone
everyone
can
have
a
look
at
it
and
prove
me
that
I
was
wrong.
I
hope
I
did
not
sean
eddie
any
added
announcements.
A
B
Yeah,
I'm
I'm
new
to
this
call
chris
negus.
I
work
with
the
documentation,
sig
doc,
and
I
was
talking
yesterday
with
eddie
about
your
guys
proposal
to
move
some
of
your
cube
cuddle
docks
into
the
regular
kubernetes
docks
and
I
was
going
to
help
volunteer
and
see
if
I
could
help
out.
C
So
I
was
working
before
for
sig
docs
as
a
contributor
and
now
kubernetes
member.
I
was
a
study
or
last
week
as
part
of
the
discussion
for
the
interactive,
related
delete
for
the
clusters
and
the
namespace
related
discussions.
I
was
being
part
of
it,
so
I
would
like
to
be
part
of
this
meeting
and
want
to
deal
with
you
guys.
E
F
Welcome,
hey
I'll,
introduce
myself,
I
don't
think
I
did
last
time
my
name
is
jeremy.
You
might
know
me
from
sig
release.
I
was
the
120
release
lead.
I
work
with
katrina
and
we're
I'm
doing
stuff
with
customize.
So
I
thought
I
would
join
these
meetings
and
see
where
I
can
help
out
upstream.
F
A
Hearing
none,
I'm
gonna
move
over
to
the
main
topic,
so
katrina
jeff,
here's
your
presentation,
take.
D
It
away
great,
thank
you,
I'm
jeff
and
katrina
is
here
as
well.
We're
gonna
talk
about
our
proposed
customized
roadmap
for
the
rest
of
the
year.
It's
pretty
ambitious.
We
hope
to
get
as
far
along
as
we
can
and
it's
informed
by
all
of
the
issues
that
have
been
filed
over
the
past
year
or
so,
and
let's
go
to
it
next
slide.
Please
thank
you
so
to
help
us
think
about
this.
D
This
is
all
about
configuration
as
data
right
yaml
in
yaml
out.
That's
what
customize
does
and
then
customizes
integration
into
coupe
cuddle
is
all
about
just
taking
in
yaml
and
spending
it
out
without
having
a
programming,
language
involved
or
templates
or
whatever,
to
help
us
think
about
the
issues
and
projects
involved.
We've
broken
into
three
categories.
D
The
first
is
contributor
community.
How
we
can
get
everyone
more
people
involved
in
it.
The
second
category
is
the
end
user
experience.
What
is
a
final
user
going
to
what
features
are
they
interested
in?
How
do
they
want
things
to
work?
How
can
we
provide
those
things
and
the
third
thing
is
sort
of
in
the
middle?
D
It's.
The
extension
experience
is
for
folks
that
aren't
necessarily
contributing
to
the
main
code
but
base
end
users
and
particular
things
that
they
want
to
implement
and
how
we
can
provide
a
platform
for
that
all
right.
Next
slide:
please:
okay,
first
contributor,
community,
there's
only
three
slides
in
this
talk
by
the
way,
so
it'll
it'll
go
fast
and
I
got
a
timer
on
myself
now.
D
First
thing
is
publisher
roadmap,
so
talk
about
the
whole
direction
that
we
want
to
work
on
and
provide
a
high
level
description
of
that
we
want
to
lower
the
contributor
barrier
in
general,
so
we're
creating
projects
we're
going
to
try
out
github
projects
as
a
way
to
organize
issues
and
have
a
sense
of
completion
as
to
when
a
project
can
get
done.
D
There's
a
new
architecture
document
that
talks
about
how
the
code
is
laid
out
where
the
the
bodies
are
buried,
how
the
whole
thing
works,
we're
trying
to.
We
are
going
to
make
the
api
smaller,
stable
and
then
issue
version
1.0
over
the
api
version,
1.0
in
a
semantic
versioning,
go
module
very
pure
sense
right
and
that's
the
kind
of
thing
that
couple's
going
to
depend
on
and
and
other
projects
you
use.
The
customized
approach
are
going
to
depend
on
and
document
the
test
harness,
so
people
can
write.
D
So
there
were
really
good
regression
coverage
so
that
things
minimize
breakage
we
want
to
vendor
our
depths,
cube
cuddle
vendors,
all
of
its
steps.
We
want
to
have
the
reason
you
do
that
is
to
understand
your
transitive
dependencies.
You
don't
want
to
depend
on
the
world
and
have
your
your
build
broken
by
some
remote
thing
that
that
stops
working
or
whatever
doesn't
doesn't
follow,
sunbury
very
well.
D
The
other
thing
we're
doing
is
we're.
Some
of
these
things
fall
into
also
the
end
user
experience
as
well.
So
it's
it's
it's
a
difficult
taxonomy,
but
in
in
the
spirit
of
the
version
one
of
the
api.
We
also
want
to
go
to
version
one
in
the
customization
object,
which
is
a
kubernetes
object.
So
it's
at
beta
v1
right
now.
We
want
to
just
go
to
v1
and
commit
to
that
for
a
while,
and
as
part
of
that
we'll
be
deprecating
some
old
fields
and
replacing
them
with
new
functionality.
D
We
want
to
improve
the
release
process,
so
it's
not
just
like
some
magic
thing.
We
want
to
build
it
more
make
it
more
case,
like
more
doable
by
other
folks
in
the
community,
just
we're
just
going
to
model
cuddle
on
this
and
administration.
So
we
want
to
have
oh
same
thing.
What
I
just
mentioned
same
infrastructures
kubernetes
and
get
more
people
involved
in
doing
the
releases
and
make
it
really
easy
to
integrate
with
coop
cuddle.
D
It's
already
kind
of
easy,
but
it's
it
requires
some
knowledge
next
slide,
please
so
the
end
user
experience
also
things
that
we
want
to
focus
on
for
the
remainder
of
the
year
documentation's
at
the
top
of
the
list.
D
We
have
a
lot
of
lots
and
lots
of
examples,
but
they're
hard
to
discover
and
they
aren't
organized
in
any
kind
of
progression,
so
it'd
be
great
to
have
like
hello
worlds
and
then
expand
on
that
with
you
know
how
you
do
more
complicated
things,
how
you
do
overlays,
how
you
combine
things,
how
you
might
leverage
diamond
patterns
and
so
on,
and
that
would
be
that's
one
of
the
big
things
is
lower
the
barrier
to
end
users,
understanding
how
to
use
customize
telemetry
is
a
project
that
has
no
code
for,
or
has
it
doesn't
exist
yet,
but
it's
it
would
be
the
idea
of
learning
how
people
are
using
customized
so
that
we
can
inform
where
to
invest.
D
Customize
cli
version
five
right
now
we're
at
version
four
one:
three.
We
don't
want
to
do
major
versions
unless
we
absolutely
have
to,
but
there's
things
that
are
sort
of
deprecations
forces
to
do
a
major
version
in
increment.
D
D
Open
api
integration
in
kubernetes
started
about
the
same
time
that
custom
resources
came
into
being
and
those
things
are
coupled
you,
you
express
type
definitions
using
open
api.
That's
what
exists
to
help
you
understand
apis
and
types
and
how
the
fields
and
those
types
relate
to
each
other,
and
we
need
to
have
more
open
api,
invest
more
in
that
standard
and
start
deprecating.
How
we
did
it
in
the
past
with
weird
fields
that
describe
how
types
are
related
to
each
other
performance
is
another
thing
we
want
to
work
on.
D
Caching
remotes
is
something
that
people
really
want
to
have
happen
when
you
download
git
repositories
as
part
of
your
base,
keeping
those
things
around,
especially
if
they're
using
a
diamond
pattern.
You
just
don't
want
to
download
it
over
and
over
again
in
a
build
benchmarks.
People
complain
about
performance,
but
they
I
really
encourage
people.
If
you
have
a
way
to
measure
importance
performance,
please
check
it
into
the
repo
and
give
us
that
kind
of
regression
coverage
and
then
just
more
features.
D
There's
lots
of
feature
requests
out
there
and
there's
just
a
smattering
of
them
sampled.
Here
the
replacement
transformer
is
our
approach
to
replacing
vars.
We
want
to
ship
a
binary
for
the
new
cpus
that
apple's
shipping
etc
and
katrina
take
it
away
with
the
extension
stuff.
G
All
right
so
for
those
who
may
not
be
familiar
the
right
now,
customize
has
a
few
different
ways
that
you
can
extend
it
and
they're
all
in
alpha.
They
have
varying
levels
of
documentation
and
different
trade-offs
for
for
how
well
they
work.
So
perhaps
the
biggest
point
here
is
that
we
want
to
take
a
hard
look
at
these.
Various
mechanisms,
see
what's
holding
them
back
from
graduating
to
a
more
stable
form
and
make
a
plan
for
making
that
happen,
so
we're
actually
gonna
have
a
kept
for
that.
G
G
So
as
part
of
this
extension
story,
there's
also
a
cap
that
already
is
open
called
the
composition
kept,
which
I
presented
at
a
previous
sig
meeting.
So
that
is
sort
of
a
way
to
take
these
extensions
and
build
abstractions
with
them
and
sort
of
build
a
tree
of
abstraction
based
extensions.
In
a
way
that
is,
is
going
to
be
composable,
so
actually
implementing
that
cap
is
is
part
of
the
plan
for
the
extension
experience
here.
G
The
last
bullet
on
the
slide
here,
the
oci
artifact
based
plug-in
catalog,
is
also
a
component
of
just
making
this
experience
better.
One
of
the
issues
that
we
have
with
the
extensions
today
is
that
they
aren't
easy
to
discover
or
distribute.
So
this
is
an
idea
for
how
to
solve
those
issues
with
plugins
and
then.
Finally,
as
I
mentioned
at
the
beginning,
these
extension
mechanisms
are
in
more
or
less
documented.
The
document
stocks
might
be
on
the
website
they
might
be
in
the
repo.
G
They
might
not
exist
very
much
so
as
part
of
graduation.
We
need
to
really
make
that
a
lot
better
make
lots
of
stories
about
how
to
write
plugins.
We
want
to
document
when
you
want
to
use
them
and
how
they
work
and
have
not
only
a
third-party
extension
story
where
you
can
build
these
for
your
yourself
and
your
own
company,
but
also
a
mechanism
for
writing.
G
Go-Based
plugins
that
you
can
compile
in
as
built-in,
which
is
something
that
that
you
can
do,
but
we
want
to
make
that
easier
and
we
want
to
document
it
with
everything
else,
so
that
that's
that's
about
it
for
extensions.
There's
gonna
be
a
lot
more
detail
on
this
on
this
part,
once
the
cap
comes
out
for
the
alpha
to
beta
graduation,
oh
one
more
thing
to
mention
about
that.
G
Actually
is
that
another
issue
with
the
way
plugins
are
today
is
security,
and
for
that
reason
they
are
not
enabled
in
the
cue
cuddle
customize.
So
that's
an
inconsistency
that
we
have.
So
we
need
to
explore
whether
the
barriers
to
inclusion,
whether
we
could
make
a
plug-in
mechanism
that
would
be
acceptable
for
inclusion,
for
greater
consistency
between
the
two
ways
that
we
publish,
customize
and
and
and
how
that
would
be
part
of
the
plan
as
well
next
slide.
G
So
there's
a
lot
in
this
roadmap.
We're
really
excited
about
it.
We
think
there's
a
lot
of
high-value
stuff
here
and
and
for
that
first
chunk
in
particular,
we're
excited
to
get
more
people
involved
and
we're
doing
a
lot
of
work
right
now,
like
in
the
past
weeks
and
in
the
coming
weeks,
to
try
to
make
these
issues
more
accessible
to
newcomers.
So
we
can
get
more
people
involved
in
the
project.
This
link
here
we'll
share
the
slides.
G
A
Hearing
none,
I
think
the
next
topic
is
sort
of
connected
with
customized
roadmap.
I'm
not
sure
if
yani
is
around,
but
he
basically
is
asking
about
customized
plugins
graduation
from
alpha.
D
So
I'll,
so
that's
what
katrina
was
talking
about.
We
we
need
to
so
we've
learned
a
lot
about
what
it
means
to
be
secure
with
plugins
and
we
want
to
make
customize
and
coop
cuddle
the
same.
So
we
are
going
to
put
together
the
doc
that
lays
that
out.
It's
it's
somewhat
complicated
because
of
the
security
implications
and
so
on.
D
So
yeah
that's
in
progress
and
there
should
be
a
link
to
there
will
be
a
link
in
the
roadmap
to
that
doc
to
the
to
the
cap
that
describes
the
the
graduation
criteria,
so
the
alpha
flag's
going
to
stay
in
there,
the
the
flag
to
enable
plug-ins
is
going
to
stay
in
there,
but
some
flavor
of
plug-ins
are
going
to
go
away,
particularly
the
the
go
shared
object,
library
plugins
they
just
caught.
They
they
just
don't
work
very
well.
The
way
go
currently
works.
There's
proposals
to
fix
that
on
the
go
side.
G
If
I
had
to
summarize
what
is
going
to
be
involved
in
the
assessment
of
what
we
need
to
change
for
or
evaluate
for
plug
and
graduation
it'd,
be
security,
distribution,
discoverability
and
consistency
with
the
way
that
customize
treats
its
own
built-in
plugins.
A
G
That
item
was
on
the
agenda
for
a
long
time,
so
they
may
not
have
even
realized
that
it
was
going
to
be
discussed
today.
Unfortunately,
it.
A
H
Eddie
well
so
this
was
actually
started
by
irvy.
I
I'm
sorry.
I
really
hope
that's
how
you
pronounce
your
name
a
while
back,
and
it's
been
on
my
backlog
to
follow
up
on,
I
managed
to
get
to
a
sig
docs
meeting
recently
where
we
talked
about
it.
The
tldr
is
we
had
siam
over
the
gsod
google
season
of
docs
build
us,
a
cube,
cuddle,
sig,
cli,
customize
docs
website,
and
the
sig
docs
folks
wanted
to
find
a
way
to
upstream
that
with
the
regular
kubernetes
stocks.
H
So
I
met
with
them
yesterday
and
most
folks
seem
to
be
on
board
with
making
it
happen.
Chris
generously
volunteered
to
help
drive
that
from
the
sig
dock
side,
the
ask
was
that
we
put
forward
someone
from
our
side
as
a
point
of
contact
who
would
want
to
help
with
that
work
to
work
together
in
tandem
and
figure
out
what
we're
going
to
do
there
so
any
thoughts
that
I
summarize
that
correctly.
E
H
That's
okay.
It
took
me
a
few
weeks
to
get
there
so
the
okay,
so
cool,
so
the
the
ask
there
is:
do
we
have
anyone
from
our
side
interested
in
helping
drive
this
forward?
H
My
first
thought
was
siam
who
originally
built
the
website,
but
I
don't
think
that
they've
been
very
active
recently
since
gsad
has
ended.
A
Right,
but
I
remember
that
he
was
helping
to
push
some
stuff
with
our
dogs,
even
after
the
google
summer
of
code
ended
summer
of
dock
sorry,
so
I
would
I'll
probably
start
of
with
pinging
him
and
then,
if,
if
you
don't
hear
back
from
him
sync
with
phil
once
again,
I
remember
that
phil
was
the
original
person
that
brought
siam
on
board,
not
sure,
if
he's
in
a
close
contact
with
him,
or
maybe
he
has
someone
who
will
be
picking
it
up
from
siam.
A
H
It
looks
like
april
29th
was
his
last
commit
there.
So,
yes,
he
is
still
relatively
active,
okay
cool.
I
will
sync
up
with
him
and
we'll
get
all
those
docs
folks
connected
and
we
will
see
where
that
goes.
Any
someone.
H
B
Yeah
real
quick,
I
I
don't
necessarily
have
to
run
it
from
the
sig
dock
side
if
one
of
the
other
people
want
to
do
that,
I'd
rather
really
just
write.
You
know,
help
contribute
with
the
reworking
and
the
reorganization,
so
it's
kind
of
for
grabs
on
on
our
side
as
well,
but
I'll
do
it.
If
nobody
else
does.
G
A
quick
question
about
what
the
project
involves.
Currently,
that
site
has
both
cube,
cuddle
and
customized
documentation.
Are
we
trying
to
completely
get
rid
of
that
site
in
favor
of
moving
all
of
the
content
over
or
would
it
are
we
taking
just
a
piece
of
the.
E
H
G
And
does
that
currently
require
using
or
often
involve
using
customize,
or
is
it
more
for
the
cuddle
side.
D
E
D
G
I
guess
it
would
just
be
really
interesting
to
see
the
information
architecture
plan
once
this
gets
going,
because
this
is
like
a
ton
of
content,
especially
like
on
the
customized
side.
There's
this
whole
series
of
content
that
we
haven't
written
yet
that
we
want
we
want
to
make
better
and
we
want
to
add
more
examples
and
more
content,
not
less.
So
if
it's
just
a
part
of
a
subpart
of
a
sub
part
of
the
website,
making
that
continue
to
be
discoverable
and
navigable
is
going
to
be
a
challenge.
I
think.
A
Okay,
I'm
hearing
no
further
questions,
so
we
can
move
on
to
the
next
topic.
Eddie
want
to
talk
about.
H
It
more
sure
so
something
that
we've
been
struggling
and
wanting
to
change
is
users
accidentally
deleting
all
of
their
stuff
in
their
clusters.
H
Numerous
cases
of
this
happening,
where
they
accidentally
delete
a
namespace
or
pass
a
dash
all
to
the
namespace
on
delete
and
deleting
all
the
namespaces
deletes
all
the
resources
in
your
cluster
extremely
destructive
action.
That
does
not
have
any
confirmation
date,
so
it
is
indeed
user
error,
but
we
basically
allow
for
it
to
happen.
H
So
if
you
haven't
seen
that
yet
give
it
a
read,
but
the
conversation
that
was
had
throughout
the
thread
was
very
good.
Some
great
suggestions,
a
lot
of
them-
can
stand
alone
as
individual
kept
some
things
like,
adding
locking
to
resources
through
like
annotations,
where
we
can
like
lock
a
resource,
so
it
can't
be
deleted
if
the
deletion
is
refused
on
the
server
side.
H
A
lot
of
that
stuff,
I
feel,
is
orthogonal
to
the
problem
we're
trying
to
solve
at
the
moment,
which
is
we
we
still
no
matter.
You
know
how
many
mistakes
need
to
happen,
no
matter
what
privileges
are
locked
down
or
changed.
As
long
as
someone
has
the
ability
to
delete
all
the
resources
they
can
with
a
you
know,
single
keystroke
right
now
with
enter
key
after
mistyping
a
command
and
we
don't
give
them
a
chance
to
stop
or
cancel
or
warn
them
about.
H
What's
going
to
happen
so
I'll
pause
there,
I
know
there's
a
lot
of
folks
on
the
call.
Does
anyone
want
to
give
thoughts,
comments.
G
I
agree
100
with
what
you're
saying
lots
of
great
ideas,
but
I
think
what
one
of
the
things
that
we
should
definitely
do
is
something
to
help
users
of
cube
cuddles,
specifically
not
shoot
themselves
in
the
foot
like,
I
think,
you've
identified
a
really
serious
usability
problem
that
is
in
cubital,
specifically.
H
H
H
Well
sure
I
mean
the
the
things
being
proposed
in
the
thread
were
explicitly
breaking
changes.
We
could
make
explicitly
breaking
changes,
server,
side
and
I
think
the
the
considerations
like
from
a
user
perspective.
H
If
a
thing
they
used
to
do
that
used
to
work,
stops
working
they're
not
really
going
to
care
whether
the
braking
change
was
client,
side
or
server
side
like
their
perspective,
is
my
script
broke
or
my
workflow
broke,
and
so
the
same
considerations
or
sort
of
resistance
to
making
breaking
changes.
I
think
applies
client
side
as
well.
H
H
I
accidentally
passed
in
the
wrong
flag
and
I
deleted
all
my
namespace
and
it's
it's
getting
hard
to
like
keep
closing
them
and
saying
hey,
like
historically,
we've
said
that
we
can't
make
a
conference
they're
like.
Why
isn't
this
a
confirmation
right?
That's
the
number
one
thing
that
people
are
asking
and
we've
you
know
they
go
to
answers
just
been
like
hey.
H
Historically,
we
said
this
is
a
breaking
change,
so
we
we've
decided
that
we're
not
able
to
implement
this
at
the
moment
and
it's
just
more
people
keep
falling
and
falling
to
this,
and
I
put
in
in
the
bottom
of
that
thing,
a
bunch
of
stack
overflow
threads.
I
found
a
bunch
of
github
issues
that
came
up
and-
and
I
only
spent
like
five
minutes
pulling
up
these-
you
know
this
evidence
so
to
speak,
and
so
that's
where
that's
where
I'm
at
right.
H
Now
it's
like
it's
getting
really
hard
to
see
people
making
these
mistakes
and
and
being
able
to
make
a
change
that
can
prevent
them
from
doing
so
and
not
being
not
doing
it
because
we're
afraid
of
breaking
existing
scripts
in
some
way.
H
So
a
couple
a
couple
things
there,
one
suggestion
tim
made
was
like,
rather
than
it
being
a
hard
fail
like
doing
some
sort
of
in
interactive
mode
print,
a
warning
and
delay
for
10
seconds
or
something
like,
so
that
it's
not
it's
not
a
question
of
like
working
or
broken,
but
it's
a
surfacing
cases
that
a
user
might
not
have
intended
and
say
like
this
is
going
to
delete
everything
across
all
namespaces
control
c,
to
cancel
like
finding
ways
that
we
don't
break
scripts
while
improving
life.
H
For
someone
who's,
like
you
know,
typing
on
the
command
line
and
hitting
enter.
That
to
me
seems
like
a
reasonable
place
to
go
the
the
fact
that
some
people,
through
user
error,
are
causing
themselves
pain.
It's
hard
to
weigh
that
against,
like
the
silent
masses
that
have
working
scripts
like
no
one
opens
issues
saying
like
my
script
that
I
implemented
this
delete
on
is
working
as
I
intended
and
so
like.
You
can't
just
take
like
issue
reports
and
then
weigh
that
against
breakage
of
existing
users
who
are
currently
working
the
way
they
expect
yeah.
G
I
was
going
to
say
one
one
thing
that
comes
to
mind
for
me
on
that
specific
point
is
what
this
command
in
particular,
is
doing
right,
we're
talking
about
a
command,
that's
to
wipe
out
a
cluster,
essentially
to
remove
everything
when
that's
done
by
accident,
it's
completely
devastating
and
if
you
think
about
the
context
in
which
the
scripts
would
be
doing
it
on
purpose,
you're,
probably
not
wiping
out
your
entire
cluster
on
purpose
in
production
all
the
time
right.
J
Just
just
to
clarify
for
myself,
maybe
for
others,
so
the
two
things
we're
weighing
are
number
one:
the
users
who
accidentally
destroyed
their
entire
cluster
and
then
the
existing
scripts,
which
assume
which
are
using
this
particular
language,
and
that
would
break
those
scripts
correct.
So
this
it's
it's
weighing.
Those
two
particular
issues
specifically
is:
does
that
sound,
correct
heading.
H
So,
yes,
I
should
clarify.
I
I
posted
a
a
reply
to
that
thread
later
in
the
day
yesterday.
H
I
think
that
the
takeaway
for
me
was
that
we
should
scope
the
first
change
smaller,
and
so
my
recommendation
was
that
we
start
at
the
place
of
confirmation
and
we
can
the
flag
changes
and
erroring
and
renaming
flags.
We
can
completely
separate
that
so
I
think
for
now.
H
We
should
just
focus
in
on
the
confirmation
aspect
of
things,
because
I
think
that
that
gets
us,
probably
like
80
90
of
the
way
of
like
putting
some
good
protective
measures
in
place,
because
once
we're
saying
hey
you're
about
to
do
this-
and
you
know
basically
pipe
the
output
of
a
dry
run
on
a
hey
like
this
is
what
will
happen
all
this
stuff
will
be
deleted.
H
A
So
I'll
continue
supporting
jordan
on
this
one
since
eddie
knows
because
we
had
conversation
last
week
before
he
posted
the
threat
that
I
was
playing
also.
The
devil
advocate,
because
my
past
experience
with
this
and
actually
the
the
idea
of
having
the
the
sleep.
I
don't
know
for
five
ten
seconds
whatever
that
will
allow
you
to
quickly
break.
A
This
seems
the
most
simple,
the
least,
problematic
approach
that
I
would
be
interested
in
seeing
implemented
even
in
122,
because
I'm
not
100
sure
about
the
the
figuring
out
how
interactive
we
are
or
not,
and
I
think
someone
actually
posted
that
in
the
thread
as
well.
A
But
that's
that's
something
even
in
the
worst
case,
it
will
just
cause
some
of
the
scripts
to
be
delayed
for
whatever
we
pick.
As
that
delay,
which
I
guess
is
acceptable
in
some
cases.
In
other
cases,
we
will
be
just
probably
patching
that
approach.
A
What
what
I
really
like
from
the
entire
thread,
though,
is
there
was,
I
think
that
was
from
josh,
where
josh
was
suggesting
that
picking
an
extended
time
doesn't
actually
help
to
solve
the
problem,
but
having
the
ability
to
overwrite
your
preferences.
In
a
file
would
be
the
preferred
way
and
which,
which
basically
folds
nicely
with
the
topic
that
we've
been
within
also
putting
for
a
while
is
user
preferences
for
cube
cuddle.
A
So
I'll
probably
just
implement
the
delay
right
away
because
that's
pretty
straightforward.
That's
like
literally
one
line
change
with
for
this,
and
that
could
probably
fix
the
immediate
issue
and
then
focus
on
having
the
preferences
and
then
only
after
we
have
the
preferences.
A
G
Is
there
any
objection
to
implementing
the
interactive
mode
as
like
off
by
default
and
letting
so
the
users
can
opt
in
with
delete
dash?
I,
and
then,
like
the
initial
email
proposed
flipping
that
default
effectively
eventually,
but
we
could
also
just
never
do
that
and
use
that
config
file
like
you're,
saying
much
a
to
allow
people
to
to
opt
in
to
that.
A
H
There
were
a
few
suggestions
made
in
that
thread
like
one
was
detecting
interactivity
and
when
we
think
we're
interactive
like
putting
a
delay
but
not
actually
like
blocking
another,
is
sort
of
the
you
know
yes
to
confirm
every
individual
delete
so
without
knowing
sort
of
the
specifics
it's
hard
to
figure
out
like
what
would
be
what
what
the
user
experience
would.
H
Look
like
another
thing
to
keep
in
mind
is
that
people
write
scripts
against
like
their
local
version
of
cube
control
and
they
sort
of
expect
those
scripts
to
work
pretty
much
identically
everywhere,
and
so,
as
we
consider
adding
new
capabilities,
either
opt-in
or
opt-out
or
like
config
file,
driven
like
preference,
driven
capabilities.
H
It's
useful
to
keep
in
mind
like
someone
who
writes
a
script
against
their
local
version
of
like
122,
cube
controller
123,
cube
control
will
not
realize
that
they're
like
getting
new
behavior
and
that
their
script,
if
they
say
like
oh
here's,
how
you
do
this
and
then
they
like
put
it
into
their
ci
environment
like
it
it's
going
to
work
differently
in
that
environment,
that's
that
doesn't
mean
we
can't
do
that.
H
It
just
there's
a
cost
to
adding
new
features,
especially
to
these,
like
really
core
commands
like
create
and
delete
and
basic
crunch
commands,
as
soon
as
we
add
a
new
thing
and
then
expect
people
to
write
to
that
new
thing.
We're
basically
putting
a
mark
at
that
point
in
time
and
saying
these
scripts
will
not
work
on
the
previous
versions
of
cube
control.
The
way
you
expect
so
that
it's
worth
calling
out
and
just
thinking
through
like
what
will
happen
when
someone
does
this.
H
Yeah,
no,
I
I
really
appreciate
your
it's.
We
all
have
different
passions
for
different
things
right,
so
your
your
passion
lies
in
like
breaking
existing
users.
My
passion
right
now
lies
in
stopping
users
from
accidentally
deleting
their
stuff
and
there's
definitely
an
intersection
between
the
two,
where
we
can
make
everything
work.
I
just
I
don't
want
us
to
be
afraid
of
making
changes
with
plenty
of
warnings
and
communication
through
change,
logs
and
blogs,
and
everything
we
do.
H
I
desperately
want
us
to
be
afraid
of
that.
I
I
again
my
experience
over
the
past
six
years
on
this
project.
Is
that
no
matter
how
much
advanced
nervousness
we
give
people
are
incredibly
busy
and
distracted,
and
when
we
make
breaking
changes,
they
actually
break
people
and
they
break
people
in
sometimes
really
bad
ways,
and
so
for,
like
beta,
like
pre-ga
things.
H
The
default
of
the
project
should
be:
we
don't
break
this.
We
find
ways
to
accomplish
our
goals
without
breaking
this,
so
I
like
the
interactive
delay
I
like
sort
of
giving
users
a
chance
to
opt
in
to
confirmation
via
config
file.
I
think
that's
a
good
idea,
but
like
removing
flags
that
have
been
considered
stable,
ga
flags,
I
am
not
on
board
with
renaming
them,
not
on
board
with.
H
So
I
I
appreciate
the
desire
to
protect
users,
and
so
I
would
like
to
find
ways
to
do
that
without
breaking
users
who
are
currently
working
yeah.
No,
I
get
that
and
I
think
that's
why
I
think
we
should
completely.
I
I'd
like
to
push
that
off
the
table
for
now.
So
I'd
just
like
to
focus
on
the
deletion.
Confirmation
delay
that
type
of
stuff.
For
now
the
interactivity
I
do,
you
do
bring
up
a
ton
of
good
points
there.
H
So
the
thing
that
does
come
to
mind
is
we
are
slowly
trying
to
move
cube
coddle
out
to
its
own
repo,
so
it
can
be
released
and
versioned
independently
right,
like
at
what
point:
where
do
we
bump
a
cube,
cuddle
2.0
and
we
can
make
breaking
changes?
People's
package
managers
are
still
going
to
auto
update
that
right,
so
we're
still
going
to
have
the
same
issue
there.
So
I
just
don't
want
us
to
fall
into
this
place
where
we
have
a
decision
that
was
made.
H
I
think
the
I
think
the
debt
we
owe
users
is
significant
and
we
should
not
break
them
if
we
can
avoid
it
and,
like
I
being
in
a
position
where
I
support
a
lot
of
users
on
a
lot
of
versions
like
the
idea
that
a
few
releases
or
a
year
is
sufficient
time
to
communicate
out
of
change
like
people
write
scripts
and
they
expect
them
to
work
against.
H
That's
debatable,
but
that
is
the
expectation
and
they
have
been
successful
doing
that,
and
so
it's
not
the
kind
of
thing
we
should
do
lightly
to
say:
oh,
like
oh,
it's
2.0,
so
we're
going
to
break
stuff
now,
like,
I
think,
a
lot
of
the
success
that
cube
control
has
gotten
has
been
because
it
has
been
reasonable
to
consume
and
wrap
this
way
and
use
as
a
building
block
in
solutions.
H
That's
been
largely
invisible
because,
like
it's,
just
the
core
commands
have
sort
of
continued
on
and
remained
stable
and
solid
generally
and
so
again,
it's
hard
to
weigh
like
specific
pain
points
against,
like
invisible,
successful
users.
I
Like
that's,
that's
really
hard
to
weigh
against
each
other.
Are
you
open
to
the
idea
of
adding
an
actual,
adding
a
concept
built
server
side
to
protect
certain
resources
to
say
no,
you
can't
delete
this
namespace
right
now.
I
mean
I'm
open
to
that,
because
I
see
it
as
an
additive
step
that
someone
would
create
a
new
resource
and
say
protect
this
thing
for
me
and
would
also
be
able
to
benefit
every
client
and
not
just
cube
control.
H
Yeah,
I
I
think
that's
a
great
idea,
I
think
was
that
brian
is
the
one
who
posted
how
azure
does
the
locking
with
the
annotation.
The
problem
is
the
the
solution.
We're
trying
to
solve
are
the
mistakes
right
where
people
didn't
add
that
in
right?
So
I
think
it's
a
great
thing
to
add
for
sure
I
just
I
think
it's
orthogonal
to
the
issue
I'm
trying
to
actually
solve
right.
H
I
I
suppose
I
can.
I
can
see
that
to
some
degree,
I
guess
there's
also
the
we
provided
a
mechanism
for
you
to
not
have
permission
to
do
this.
We
provided
you
mechanism
to
protect
yourself,
even
if
you
did
have
the
permission
to
do
this,
we
made
it
not
the
default
and
you
explicitly
typed
it
and
you
did
it,
and
I
mean
that
that's
a
lot
of
that's
a
lot
of
ands.
I
I
don't
know
that
I
would
even
allow
on
the
same
resource
just
because
that
provides
some
some
editing
power
problems,
but
you
know
you
can
build
a
system
of
protect
this
that
is
external
and
would
provide
protection
from
all
sorts
of
agents.
I
It
is
possible,
yes,
I
guess
it
again
falls
into
the
like.
You
know
how
many
safeties
do
you
put
on
the
thing
by
the
time
you
get
to
the
third
safety
and
you
went
past
it
without
using
it,
and
you
had
an
accident,
I
mean
I,
I
feel
you
for
some
degree,
but.
H
But
that's
that's.
The
thing
is,
you
have
to
add
the
safety
right.
Trina
is
the
one
who
I've
been
quoting
on
this.
Now
she
originally
said
users
don't
intend
to
delete
the
resources
they
are
accidentally
deleting
not
that
there
are
things
that
should
never
be
deleted
and
that
that's
really
what
I
think
the
heart
of
this
is.
G
Yeah
it
if
you
were
to
completely
use
a
server-side
opt-in
mechanism
to
prevent
this
mistake,
which
is
fundamentally
coming
from
the
fact
that
people,
the
expression
of
how
to
delete
everything,
the
flags
that
you
use.
I
agree
we
can't
change
them.
I
think
those
arguments
it's
extremely
compelling.
We
can't
change
them,
but
they
they
are
confusing.
Users
do
not
understand
them
properly,
so
they
type
something
that
they
think
is
going
to
do
one
thing,
and
it
actually
does
another:
it's
not
that
they're
trying
to
do
that
and
and
they're
making
a
typo.
G
They
look
at
it
and
they
think
that
means
x
and
it
actually
means
y.
So
in
order
to
protect
users
using
a
server-side
mechanism
for
making
that
mistake,
you
would
have
to
you're
basically
saying
that
every
single
cluster
resource
in
the
cluster
has
to
be
annotated,
with
the
special
don't
delete
anything
at
which
point.
That's
extra
complexity
and
the
result
isn't
actually
all
that
different.
I
G
If
you
look
on
the
issues
they're,
the
the
confusion
is
about,
they
put
a
dash,
dash,
namespace
argument
that
is
ignored
and
they
think
that
that
namespace
argument
is
going
to
take
effect,
which
is
kind
of
a
reasonable
thing
to
think.
And
they
think
you
know
if
I
have
passed
a
namespace
flag,
I'm
restricting
the
impact
of
what
I'm
doing
to
that
namespace.
And
it's
just
not
true,
because
they
targeted
by
accident
a
clusters
scoped
resource
when
they
thought
they
were.
They
were
not.
G
I
don't
know
if
that's
a
if
you
can
help
clarify
eddie
you're,
the
one
who
did
the
most
research
on
this.
But
that's
that's
what
I
saw.
H
Yeah
I
dropped
the
most
recent
one.
Actually,
that's
not
even
the
most
recent
one
now
I
dropped
an
example
of
this
in
the
chat.
This
is
the
most
recent.
H
H
I
don't
know,
I
don't
know
why
people
are
throwing
dash
dash
all
at
things,
but
they
are
and
we
have.
We
have
the
examples
that
they
are
doing
it.
So
it's
again
it
is
completely
user
error.
I'm
just
trying
to
find
what
we
can
do
to
help
them
from
making
the
error.
A
So
I
mean
I,
I
think,
we're
going
in
circles.
Basically,
the
the
majority
of
the
discussion
we're
having
is
around
the
countdown
to
put
it
nicely.
So
this
kind
of
countdown
is
the
simplest,
most
effective
and
pretty
straightforward,
even
if
we
would
consider
cherry
picking
now
all
the
way
back
to
whatever
is
supported
today,
because
that's
like
one
line
change
and
the
problem,
because
I
I
looked
at
it
from
a
customer
point
of
view
a
couple
years
back,
but
then
again
with
this
many
customers
that
I
spoke
over
the
years.
A
It
was
only
one
customers
over
three
years
and
I'm
inclined
to
judge
this
in
a
similar
fashion.
As
with
the
majority
of
the
requests
we
are
dealing
with,
as
in
I
haven't
seen
this
being
upvoted
for
sufficient
number
of
times,
which
basically
is
what
jordan
was
saying
that
we
will
only
hear
from
those
that
did
delete.
A
I'm
not
saying
that
I
I
wasn't
in
the
shoes
of
a
person
that
deleted
accidentally
a
production
because
I
did,
but
maybe
not
necessarily
for
cube,
but
I
did
a
delete
all
from
whatever
table,
which
was
on
production
and
sql.
Doesn't
stop
you
from
from
doing
this
in
any
way,
it's
still
possible.
You
can
easily
drop
the
entire
table,
the
entire
database,
if
you're
in
production
with
the
sufficient
access
rights
it
eventually
at
some
point
in
time.
A
It
boils
down
to
being
a
responsible
administrator
and
enforcing
sufficient
procedures
that
this
kind
of
accident
doesn't
happen
if
they
do
and
if
they
do
or
when
they
do.
You
got
a
chance
to
practice
your
restore
story.
If
you
have
one,
maybe
that's
a
good
story
to
to
figure
out
that
you
should
have
one.
H
Yeah,
I
I
I
I
don't
want
us
to
like
set
up
artificial
opposition
here
like
I,
I
want
all
of
our
users
to
be
successful,
and
so
I
want
users
who
are
currently
successful
to
continue
being
successful,
and
I
want
users
who
are
getting
bitten
by
typos
on
a
command
line
to
stop
getting
bitten
by
titles
on
your
command
line.
So
I
am
on
board
with
approaches
that
improve
life
for
the
people
who
are
currently
getting
bitten
without
breaking
current
users.
So
I
I
don't.
I
don't
want
us
yeah.
H
I
don't
want
there
to
be
this
artificial,
like
two
sides
fighting
against
each
other.
I
don't
think
I
think
we're
all.
On
the
same
side.
We
just
need
to
keep
our
current
successful
users
in
mind.
A
So
yeah,
I
would
go
with
the
internet
with
the
with
the
countdown
right
away.
There
was
one
as
one
question
from
jordan
from
two
questions
of
his
before
where
he
was
asking
about
the
interactive
flag.
The
idea
of
the
interactive
web
flag
would
be
something
similar
to
what
rm
on
linux
does
as
in
it
will
ask
you:
are
you
sure
you
want
to
remove
this,
and
then
you
would
have
to
type?
Basically,
yes,
which
is
kind
of
similar
to
what
the
majority
of
the
web
uis
are
doing?
A
I
don't
know
if
you
pick
docker
if
you
pick
quay,
if
you
pick
github
and
if
you
try
to
delete
a
regis
repository
registry
from
any
of
these
as
a
confirmation,
you
need
to
type
in
the
name
of
the
repo
you're
trying
to
remove
so
having
something
like
that
as
an
opt-in
for
cube,
cuddle,
delete,
would
be
fair
and
with
the
in
the
combination
with
the
preferences
where
you
could
always
set
that
on
by
default,
would
give
you
sufficient.
A
A
So
that's
that's
also
possible
because
you
would
have
to
explicitly
type
type
dash
dash,
all
all
which
is
like
five
characters.
If
you
type
five
additional
characters,
that's
pretty
sufficient
sign
that
you
know
what
you're
doing
if
you're,
if
you
type
a
and
then
just
tap
tap-
and
it
just
so
happens
that
all
will
be
the
first
one
and
you
hit
enter
without
thinking
too
much.
H
Then
maybe,
but
you
meant
shell
autocomplete.
I
thought
you
meant
like
the
alias
expansion
of
all
yeah.
H
If
we
can
isolate
the
cases
that
people
are
confused
by
like
deleting
namespaces
and
passing
namespace
or
deleting
namespaces
and
passing
all
if
we
can
detect
those
and
at
the
very
least,
print
warnings.
Printing
warnings
is
like
free,
basically,
warnings.
H
Is
free
when
run
interactively
delay
and
give
a
chance
like?
Are
you
sure
this
is
pretty
destructive
that,
to
me
that's
a
great
starting
point
and
could
be
done
without
like
a
ton
of
angst
or
due
diligence
about
breaking
people,
because
we
wouldn't
be
actually
breaking
people
so
to
to
we're
running
out
of
time,
so
just
to
summarize
and
wrap
up
so
we're
all
okay
in
down
with
the
idea
of
delays
and
warnings.
For
now,
where
do
we
land
on
confirmation
requiring
confirmation
for
ttys?
A
H
Opt-In
still
doesn't
solve
the.
I
can't
think
of
another
cli
that
I
use
every
single
day.
That
lets
me
delete
everything
without
asking
me.
Are
you
sure
you
want
to
do
this
right?
Your
sql
example
is
a
good
case
where
yeah
raw
sql
won't
stop
you,
but
any
sql
command
line
tool
will
be
like.
Are
you
sure
you
want
to
do
this?
No.
A
I'm
I'm
I'm
positive
that
pause,
ps,
qrs.
H
Rf,
won't
let
you
do
that
unless
you
type
no
preserve
root
to
delete
your
root
file
system.
So,
yes,
it'll
delete
everything,
but
your
root
file
system,
but
you're
also
passing
dash
f
there
right.
You
are
explicitly
adding
the
force,
so
I
don't.
I
don't
feel
bad
that
you're
forcing
it
yeah.
I
mean
you
aren't
you're
exactly
adding
all
like.
I.
I
agree
that
it's
destructive
also
dash
dash
all
won't
actually
remove
cube
system
and
it
won't
remove
like
the
what
are
considered
the
core
namespaces.
H
No,
no
question
that
it's
destructive,
I,
I
think
giving
people
away
in
their
config
file
to
say
I
would
like
confirmation
mode
on
when
I
run
interactively.
H
That
seems
like
a
good
direction
to
move
and
and
then
that,
like
the
things
that
generate
cube,
configs,
it's
up
to
them
to
say
like
this
is
a
safer
way
to
operate.
It
scopes
it
to
interactive
modes
so
that
scripts
aren't
affected
and
like.
I
would
start
there
and
and
see
what
the
adoption
is
and
what
the
feedback
is
not
start.
H
There
start
with,
like
the
delay
when
running
interactive
long
term,
give
the
opt-in
and
the
config
to
say
like
when
I'm
interactive,
and
I
try
to
delete
stuff
like
prompt
for
interactivity
or
prompt
for
confirmation.
We
actually
want
to
break
that
out
to
like
a
cube
rc
to
separate
user
configs
from
server
config.
So
whatever
the
mechanism
is,
I
think
it's
a
good
starting
point.
I
think
that
we
still
should
work
towards
confirmation
by
default
at
some
point,
but
I
will
I
will
be
okay
for
now
getting
something
in
place.
G
Yeah,
if,
if
you,
if
we
were
to
do
exactly
what
jordan's
suggesting
here,
which
which
I
I
agree,
I
think
that
sounds
like
a
good
plan.
Actually,
you
know
if
we,
if
we
do
implement
the
the
interactive
opt-in
and
then
we
give
you
the
ability
in
your
preferences
which
can
be
generated
to
make
opt-in
by
default,
for
you
that's
already
a
great
start,
and
that
will
also
get
users
an
awareness
of
this
mechanism
right.
G
So
maybe
at
that
point,
if
we
start
seeing
tons
of
users
clamoring
for
this
to
be
on
by
default,
then
then
maybe
we
can
have
this
conversation
again,
but
I
think
that
already
this
is
like
such
a
great
plan
for
for
making
this
better
for
the
people
who
are
shooting
themselves
in
the
foot
and
it
doesn't
break
anything.
I
think
it's
really
worth
doing.
J
J
I
was
just
hoping
to
to
bring
that
to
your
attention,
we're
going
to
be
sending
extra
headers
to
the
api
server,
so
we
could
gather
telemetry
on
coupe
cuddle
usage,
and
so
so,
jordan
and
david
david's
already
seen
the
cap
I'll
I'll
contact
you
personally,
jordan,
if
you
don't
mind
just
to
get
your
take
on
it.
Okay,.