►
From YouTube: Kubernetes SIG CLI 20200715
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
july
15th-
and
this
is
another
of
our
bi-weekly
six
cli
meetings.
My
name
is
mate
and
I'll
be
your
host.
Today,
our
agenda
is
packed,
so
let's
get
right
into
it.
A
couple
announcements.
A
We
have
a
our
monthly
boxcrop
call
next
wednesday
july
22nd
at
the
exact
same
time,
so
if
you're
interested
in
it
or
if
you're,
looking
for
first
time
issues.
This
is
a
perfect
call
to
be
on.
We
will
be
going
through
the
box
through
pr's
and
helping
to
solve
some
issues.
A
Another
topic
that
I
wanted
quickly
to
bring
up
is
the
kubecon
eu
2020
is
happening
on
in
slightly
over
a
month.
It
is
entirely
virtual,
so
you
are
all
more
than
welcome
to
join
and
we
will
be.
A
I
link
the
the
full
schedule
and
we
will
be
having
a
session
there
that
I'll
be
recording
in
in
slightly
over
a
week
or
so
that's
the
requirements
from
the
organizers
and
my
question
to
y'all
is
what
are
people
interested
in
seeing
in
that
call-
and
I
was
thinking
that,
maybe
because
the
most
frequently
answered
questions
that
we
have
is
why
there
is
this.
A
What
is
the
move
to
staging,
because
this
is
our
biggest
effort
that
we
are
currently
undergoing,
why
we
are
using
old
customize,
a
quick
overview,
how
a
proper
cube
cuddle
command
looks
like,
which
is
both
helpful
for
reviewers
and
first-time
contributors,
and
probably
that's
about
it.
I
have
about
20-25
minutes.
I
think
that
should
be
enough
to
cover
the
three
main
topics.
A
A
Okay,
if
you
can
come
up
with
something
in
the
near
couple
of
days,
ping
me
on
and
slack
with
your
ideas,
I'll
be
more
than
happy
to
to
add
them.
A
B
Yeah
sure
this
is
something
that
I
wasn't
really
too
aware
of.
I
mean
I'm
sure
some
of
you
guys
are,
but
for
me
it
was
something
that
that
I
didn't
really
know
about
until
I
started
digging
into
it.
So
I
was
looking
at
e
to
e
test
flakes
and
really
looking
at
the
triage
dashboard
and
noticing
some
tests
that
were
failing
all
the
time
and
kind
of
raised
some
questions,
so
I'm
really
kind
of
looking
at
it
from
two
ways
like
how
do
we?
How
do
we
fix
the
test?
B
B
The
jobs
typically
take
like
an
hour
to
run
so
if
running
it
every
hour
and
when
it
takes
an
hour
is
like
is
constantly
running.
So
I
don't
know
if
these
these
are
jobs
that
are
not
part
of
the.
So
there's.
Let
me
back
up
there's
some
of
you
know
this,
so
my
apologies,
but
there's
pre-submit,
post
submit
and
periodic
jobs
that
run.
B
So
these
are
the
jobs
that
are
not
part
of
the
pull
request,
but
they
just
run
on
a
scheduled
basis,
and
the
idea
is
that
they're
testing
things
like
do
older
versions
of
of
cube
cuddle
work
with
newer
versions
of
the
cluster.
So
it's
testing
sku
and
some
other
things,
and
the
idea
is
that
it
would
alert
us
if
there's
a
problem
and
then
we
can
go
go
fix
the
issue,
but
it's
not
part
of
the
every
pull
request.
B
So
a
couple
questions
and
I've
kind
of
put
them
in
the
notes
here.
But
how
frequently
should
these
run?
I
feel
like
one
hour
or
two
hour
might
be
too
frequently
given
the
load
on
the
test
servers
right
now
and
then
who
should
be
notified
so
like
right
now,
only
some
of
the
jobs
have
an
alert
email
set
up.
B
A
So,
honestly,
that
I
have
no
idea
what
that
email
is,
and
I'm
I'm
I'm
quite
sure
that
this
is
probably
some
kind
of
a
death
note
currently,
because
nobody
is
monitoring
that
one
I
I
did
take
a
peek
before
the
call
I
ran
out
of
time
looking
too
deeply,
but
to
answer
your
first
question,
probably
something
around
12
or
24
hours,
so
basically
running
this
once
at
most
twice
a
days
with
the
velocity
that
we
have
is
a
sufficient
delay
between
being
notified
when
something
breaks
and
and
when
it
gets
into
the
lens
in
the
cube,
because
we
can
in
the
worst
case
we
all
we
have
is
to
to
look
through
pr's
that
merge
in
the
past
12
or
24
hours.
A
C
So
my
guess,
my
guess
on
why
some
of
those
intervals
may
have
been
set
is,
I
think
there
years
ago
there
were
some
pretty
flaky
ede
jobs,
and
what
would
happen
at
release
time
is
to
get
a
good
signal.
You
couldn't
say,
oh,
like
I
expect
every
one
of
the
past
20
tests
to
have
passed
or
something
like
that
right,
and
so
what
you
need
to
do
is
just
like
you'd
run
it
10
times
and
then
say:
did
it
flake
once
and
then
you
can
get
within
a
couple
days?
C
You
can
get
a
good
signal,
whereas
if
you
ran
it
once
a
day,
then
you'd
have
to
look
at
like
the
last.
You
know
month
to
see
like
of
passes,
which
doesn't
tell
you
the
right
information,
so
yeah.
If
these
are
consistently
passing
once
a
day,
seems
good.
B
Right,
I
don't
know
I
mean
I
think,
there's
still
quite
a
bit
of
flakiness
in
in
ede
tests
in
general.
So
I
think
that's
a
valid
point.
I
don't
know
how
flaky
these
particular
tests
are,
but
I
know
some
are
really
freaky,
so
maybe
with.
C
B
A
Around
six
or
twelve,
in
that
case
yeah,
this
will
give
us
more
frequency,
but
not
too
frequently,
probably
so,
six
or
twelve.
That
will
give
you
about
two
or
four
hours
per
hour,
two
or
four
times
per
day.
That's
sufficient
signal
and
but
definitely
not
more
frequently.
If
we
get
to
the
point
where
we
are
certain,
this
is
green.
D
Have
we
set
up
recent
sku
tests,
like
which
version
against
which
version
I
I
don't
think
we've
done
that
for
a
long
time.
A
Yeah
the
tests,
those
tests
were
we're
not
looked
at
as
as
good
as
as
we
should
so
so.
B
B
Oh
sorry,
I
I
I've
been
looking
at
those
skew
tests
recently
and
I
have
a
separate
pr
out
to
handle
that.
But
I
the
way
the
way
the
skew
tests
are
set
up.
It
looks
like
it's
an
automatic
thing.
When
the
versions
get
get
it,
doesn't
it's
not
it.
Doesn't
it's
not
something
that
I
don't
think
that
we
have
to
update
every
version.
B
I
might
be
wrong
there,
but
I
think
it
looks
like
it
when
I
don't
know
if
it's
the
release,
team
or
whatever
else,
but
it
just
it
just
takes
a
generically
named
it
names
things
like
stable
one,
stable,
two
and
then
and
beta
and
current.
I
guess
so.
It's
like
current
is
the
current
and
then
beta
is
it's
kind
of
weirdly
named.
But
beta
is
the
last
version
stable.
One
is
two
versions
ago
and
stable
so
like
they
just
re,
rebuild
those
images
and
tag
them
that
way,
and
then
our
tests
will.
B
A
Definitely
that
on
call
that
I've
seen
oh
yeah,
that's
the
one!
That's
that's
not
good,
because
I
have
no
idea
where
that's
going.
I've
noticed
that
we
are
being
notified
and
the
release
team
in
one
of
them,
at
least
so
I
would
probably
go
with
the
with
our
mailing
list.
For
starters,
if
we
see
that
there's
too
much
of
the
notification,
we
can
either
create
a
separate
mailing
list.
A
Just
for
that
or
what
I
would
hope
for
in
the
in
the
long
run,
we
will
be
able
to
limit
the
amount
of
the
failures
such
that
those
notifications
will
be
rare
enough,
that
they
are
perfectly
fine
being
targeted
at
the
at
our
main
mainline
list.
B
Starters
all
right
cool
and
then
I
guess-
and
those
are
the
main
two
things,
but
the
last
thing
is,
I
don't
know
how
many
people
here
use
test
grid
to
look
at
things,
but
it
seems
like
I
I
guess,
that's
a
general
question.
Do
people
use
test
grid,
it
seems
like
we
could
unify
or
improve
some
of
the
the
way
that
things
are
displayed
in
test
grid.
E
C
I
was
just
going
to
say:
like
are
you
proposing
like
do?
Do
you
have
like
specific
things,
ideas
around
improving
this
or
is
it
just
a
general
comment.
B
I
guess
it's
just
a
general
comment.
I
think
I
was
looking
at
the
test
grid
and
it
seemed
like
some
things
were.
Not
I
don't
know
I.
Actually.
I
don't
remember
what
what
I
was
thinking
there.
I
think
I
think
I
was
looking
at
it
and
thought
that
it
didn't
look
like
things
were
in
the
right
place
and
I
was
curious
if
people
use
test
grid
or
or
if
that
was,
if
I
guess
any
thoughts
on
that,
I
guess
maybe
there's
nothing
that
needs
to
be
done.
There.
C
I
think
like,
if
you
can
think
of
a
way
if,
if
there's
some
way,
you
think
that
we
could,
you
know,
arrange
the
test
results
like
having
other
aggregate
views
or
something
sure
I'd
be
very
open
to
that.
C
B
But
no,
I
was
thinking
more
like
just
the
the
naming
of
the
tabs
that
we
the
things
in
the
yaml
file.
So
I
I
I'll
I'll,
probably
do
a
pr
with
these
changes
and
I'll
look
at
them
just
see
if
they
make
sense,
but
I
probably
won't
change
them
unless
they
don't
make
sense.
But
I
I
think
I
was
I
don't
know
what
I
was
thinking
that
last
point
there,
but
I
think
the
first
two
clarifications
give
me
some
direction
on
that.
A
I'm
pretty
sure
that
there's
some
well
thought
out,
meaning
behind
the
the
naming
honestly
with
with
my
tenure
with
the
project.
The
majority
of
them
are
somewhat
readable
for
me
because
they
usually
are
about
the
type
of
a
cluster,
the
version
in
what
they
are
doing.
A
So
it's
either
skew
cluster
latest
keep
cuddle
table,
one
gce
or
eventually
they're,
just
gc
serial,
which
means
all
of
the
the
serial
tests
so
definitely
mixing
the
the
cereal
and
the
rest
should
be,
as
is
for
those
that
are
unfamiliar
with
the
what's.
The
difference
is
the
majority
of
the
e2e
in
kubernetes
are
run
in
parallel,
which
means
when
we
set
up
a
cluster
for
every
pr
we
are
running
in
parallel.
A
I
don't
know
20
or
30
tests
at
the
same
time,
but
there
are
some
tests
that
are
required
to
be
run
in
serial
and
they
are
usually
tacked
similarly
to
what
we
have
those
tags
in
in
the
square
brackets.
There's
a
square
brackets
serial
in
the
test,
name,
they're,
very
rare
and
there's
not
that
many
of
them,
because
obviously
it
requires
a
lot
more
time
to
run
them.
A
But
so
I'm
not
sure
if
we
have
that
many
of
them
two
and
they're
related
to
teens,
which
obviously
modify
how
the
cluster
behaves.
So
it's
perfectly
fine
that
they
are
part
of
the
serial
test.
A
A
In
cleaning,
but
as
long
as
we
will
fit
in
with
the
the
the
naming
schemes
that
were
that
were
already
in
a
project
and
set
up
by
someone
else,
because
with
something
if
something
something
that
might
make
sense
for
us
right
now,
not
necessarily
will
be
readable
by
others
in
in
a
couple
of
days
in
a
couple
of
weeks.
A
So,
but
I
don't
see
any
objections,
if,
if
you
notice
that
there
are
some
pointless
or
maybe
there
are
groups
where
the
well
there's
nothing
going
on
at
all,
I
wonder
if
there's
anything
happening
in
the
aws
and
from
what
I
see
there's
nothing,
not
sure
if
we
even
run
aws
tests.
So
so,
probably
if,
if
there
are
some
duplicates
or
something
like
that,
I
I
don't
see
any
objections
in
cleaning
them.
A
Okay,
that's
great
as
long
as
it
makes
makes
make
sense,
yeah,
I'm
I'm
all
for
it
all
right,
cool
thanks.
A
Okay,
does
anyone
have
any
top
questions
about
this
one
before
we
move
on
to
the
next
topic,.
A
Sean
this
is
topic
from
last
time,
yeah
here,
so
we
bumped
it
over
to
basically
this
this
week
keep
controller.
Should
we
have
an
option
not
to
know
you
want
to
talk
about
it.
D
Sure
I'll
and
hopefully
the
dog
will
stop
barking.
Sorry
about
that
yeah.
So
actually
I
I
I'm
pretty
sure
this
came
up
just
in
the
bug
scrub
and
I
think
I
I
might
have
volunteered
to
bring
this
to
the
to
the
entire
community
to
see
if
this
was
something
that
actually
sounded
reasonable.
I
I
don't
have
as
much
experience
with
drain
and
and
and
generally
my
understanding
is
that
you
know
cordon
is
gonna.
D
It's
gonna.
Keep
things
from
going
onto
a
node
and
drain
is
one
step
further.
It's
not
only
keeping
things
from
going
on
to
a
node,
but
it's
going
to
kill
every
kick
everything
off,
and
so
does
this
even
make
any
sense?
Would
we
want
to
drain
without
coordinating?
D
We
want
to
kick
everything
off
and
not
say
you
can't
schedule
anything
on
it
again.
Does
anybody
have
any
experience
with
this?
Does
this
make
sense.
A
Honestly
thinking
about
it,
I've
been
playing
with
cor
with
drain
several
times.
I
I
don't
recall
using
cordon,
but
just
thinking
about
it
from
a
user
point
of
view,
it's
hard
for
me
to
figure
out
a
use
case
where
I'm
draining
a
node,
and
I
don't
want
to
coordinate
because
basically
the
goal
of
draining
a
node
is
you
want
to
take
it
down
for
maintenance
upgrade
whatever
and
without
coordinating
that
node.
First,
the
drain
will
be
racing
with
the
scheduler
which
will
be
trying
to
schedule
parts.
A
Maybe
even
the
exact
same
that
you
just
drained
back
to
the
node
because
of
let's
say,
for
example,
there
is
a
daemon
set
which
is
running
on
all
the
nodes
and
you're
draining
your
your
node,
including
those
daemon
sets
you're.
Removing
the
the
pod
and
the
scheduler
then
looks
at
the
pod.
Oh
there
I
mean
the
the
daemon
sets
controller
will
figure
out.
Oh
there's
a
there's,
a
node
that
sounds
healthy
and
I
should
probably
create
a
pod
back
on
it,
which
means.
D
Yeah
I
was
worried
about
yeah
that
that
what
sounds
like
dysfunctional
dynamic
of
you
know
kicking
everything
off
and
still
allowing
it
open
so
that
the
scheduler
starts
throwing
stuff
on,
as
things
are
being
kicked
off.
D
So
if
we
click
on
the
there's
a
pr
that's
talked
about,
if
we
look
further
down
that
is
actually
implementing
this,
I'm
consider
it's.
It's
still
open,
I'm
considering
putting
a
hold
on
it,
so
maybe
this
isn't
a
something
that
the
entire
sig
needs
to
be
in
on.
I
just
wanted
to
get
anybody
else's
expertise.
D
If
anybody
else
wanted
to
comment
on
this
as
it
stands
now
from
what
I
understand,
I'm
gonna
put
a
hold
on
this
and-
and
you
know
describe
this-
is
probably
not
a
very
healthy
situation.
If
anybody
wants
to
chime
in
with
some
other
points,
then
please
do
my
guess
from.
C
Reading
the
issue
original
issue
description
is
that
they
want
to
remove
like
some.
They
want
to
like
remove
some
set
of
pods
from
the
node
and
then
paint
it
and
then
like
allow
it
only
to
be
scheduled
for
some
other
set
of
pods
or
something
of
that
nature,
and
so
so,
maybe
like,
instead
of
a
general
drain
command.
C
What
they're
really
looking
for
is
like,
I
remove
pods
from
like
paint
and
remove,
or
something
like
that,
so
it
might
be
worth
like
just
thinking
about
this
as
a
separate
command,
which
would
you
know,
apply
it
apply
the
taint
and
then
remove
nodes
that
don't
or
remove
pods.
That,
like
aren't
then
scheduled
to
it
or
something,
and
then
you
wouldn't
be
in
the
problem.
You
just
described.
F
A
Yeah,
that
is
correct,
because
currently,
the
way
we
have
the
scheduler
written
is
that,
after
the
note
is
scheduled,
something
has
to
remove
the
pod
and
that
something
could
be
a
descheduler
there
is,
there
is
a
descheduler,
it's
part
of
the
it's
one
of
the
sub
projects
from
six
scheduling
that
can
be
run
periodically
and
it
will
go
through
your
through
your
cluster
and
to
be
able
to
either
balance
at
it,
balance
it
or
remove
pods
that
do
not
match
the
current
things.
For
whatever
reason.
C
A
I
mean
I'm
perfectly
fine
with
doing
what
shawn
said
hold
the
pr
and,
in
the
original
issue,
ask
the
author
for
the
particular
use
case
that
they
that
they
are
targeting,
because
they,
the
author,
did
not
stated
that
the
actual
use
case
that
they
are
having
that
they
want
to
address
without
knowing
that
it's
just
a
wishful
thinking
and
we
we
could
come
up
with
like
at
least.
A
X
million
possible
options
why
he
he
wants
to
do
it
this
way
or
the
other
way.
I
would
just
ask
what
is
the
use
case,
and
then
we
can
reconsider
whether
it
makes
sense
to
to
do
it
the
way
he
wants
it
to
be
done,
or
maybe
we
just
need
to
direct
him
that
there
is
something
else
that
he
should
be
doing.
A
Does
anyone
else
have
any
other
suggestions
about
that?
One.
A
Okay,
hearing
none,
let's
move
on
to
the
next
one
eddie.
We
started
the
discussion
last
time
about
the
patterns
discussion.
You
want
to
continue
the
topic.
I
need
to
recall
what
we
talked
about
last
time:
oh
yeah,
historical
reason
for
complete
violation:
yeah,
okay,.
F
F
A
A
Whether
the
the
cube
cutoff
against
rga,
I
think
when
we
originally
created
that
with
with
who
on
over
a
year
ago-
or
so,
we
started
that
as
an
alpha
or
oh,
the
initial
was
alpha
and
the
current
design
was
beta.
That's
how
we
did
it,
but
we
never
promoted
it
as
a
ga,
not
sure
if
there's
something
more
than
just
updating
dogs.
A
A
A
A
So
some
time
ago
I
wanted
to
get
rid
of
another
deprecated
functionality
in
not
sure
if
that's
cube,
cuddle
or
that's
client
go.
Oh
that's
client
go
which
basically
does
defaulting
of
the
kubernetes
master.
A
And
currently
it
is
always
defaulting
to
localhost.
Unfortunately,
this
broke
a
lot
of
stuff.
Mainly
it
is
impossible
to
do
any
of
the
local
commands
with
cube
cuddle.
A
I
went
through
the
code
and
the
pieces
where
it
is
breaking
is
where
we
are
creating
the
client,
because
the
if
you
go
through
the
several
hoops
how
we
are
creating
clients
whenever
we're
creating
clients
incline
in
complete,
we
need
to
have
about
keep
config.
If
there
is
no
cube,
config
or
there's
no
kubernetes
master
cube.
Cuddle
will
complain
that
it
doesn't
have
a
cube
config
and
for
local.
It
should
not
require
one.
A
A
A
A
So
if
you
chase
down
the
rabbit
hole
through
dynamic,
client
and,
however
building
client
at
some
point
in
time,
you
will
get
to
the
to
this
piece
of
code,
which
is
getting
the
default
server
and
with
the
default
server
in
it,
will
magically
just
works,
and
it
will
think
that
it
has
a
valid
conf
config
pointing
to
localhost.
A
To
the
server
when
the
server
is
not
defaulted,
meaning
that
I
remove
the
deprecated
functionality
from
here,
the
clan
cannot
be
created
and
you
are
basically
getting
an
error
that
you
are
missing
or
there
is
an
incomplete
cube
config.
Even
when
you
specify
the
local
flag,
so
we
would
have
to
either.
A
A
A
It
will
not
invoke
the
it
will
not
invoke
anything
onto
the
server
local
does
not
even
connect
to
the
server,
except
for
the
place
when
it
tries
to
create
the
connection
which
basically
means
vocal,
is
broken.
Currently.
C
A
C
And
the
reason
this
is
going
to
be
like
the
fix
is
relatively
simple,
like
if
there's
just
one
command,
which
is
only
create
the
client
if
it's
used.
But
the
problem
is
that
we
have
like
this
code
to
create
a
client
and
then
like
pass
it
around,
replicate
it
across
two
dozen
commands
or
something
like
that.
Right.
B
C
And
so
like
the
quote-unquote
right
way
to
fix
this,
I
would
naively
think
is
that
sounds
like
code
smell
anyway.
If
we
have
like
a
bit
of
logic,
that's
duplicated
over
two
dozen
places
that
all
need
to
be
changed
together
and
so
like
it
might
be
worth
before,
like,
instead
of
just
trying
to
solve
like
doing
a
code
cleanup
ahead
of
time
to
say:
okay,
like
how
are
we
initializing
dependencies
and
maybe
look
a
little
more
holistically
at
that,
because
today
it's
this
client
and
tomorrow
it's
some
other
dependency
right.
C
A
C
C
There
we
go
all
right
yeah,
why
don't
you
get
hooked
up
mache
afterwards,
and
maybe
you
could
try
taking
this
one
on.
A
A
I
think
it's
yao
with
yao
and
aurelian
on
removing
the
generators
from
the
create
commands,
they're
doing
the
heavy
lifting
I'm
just
reviewing
their
vrs
and
yao
created
a
uber
issue
for
tractors,
work
I'll,
try
to
get
all
of
those
issues
listed
out
and
I'll.
A
Add
that
one
as
well
that
email,
so
that,
first
of
all,
we
we
can
point
people
to
where
they
could
start
and
eventually,
sync
with
whom,
with
whom
to
sync
with
that,
is
currently
working
on
it
or
who
is
the
approver
I'll,
try
to
create
such
a
list
and
create
the
necessary
issues?
A
A
I
started
wondering
whether
local
at
all
makes
sense
for
people
to
use,
and
maybe
it's
a
artifact
of
the
past-
that
as
part
of
the
overall
cleaning
of
the
commands,
we
should
maybe
rethink
and
and
remove
those
as
well,
because
local
is
nothing
more
than
oh.
I
have
this
deployment
file
locally
and
I
want
to
in
that
particular
particular
example.
Add
some
labels
onto
it
or
annotations,
or
probably
the
the
commands
that
we
are
trying
not
to
encourage
people
to
use.
A
A
A
The
final
topic
that
that
we
got-
and
I
had
a
discussion
with
with
jordan
brian-
and
I
can't
remember
who
is
there-
was
pr
about
a
week
or
two
weeks
ago
where
people
want
to
have
support
for
global
facts
and
keep
cattle
options.
A
Currently.
The
way
we
have
plugins
is
that
when
we,
when
we
are
processing
parameters,
when
we
notice
a
flag,
we
stop
processing
the
commands,
which
means
all
the
arguments
for
a
plug-in,
needs
to
be
passed
after
the
after
the
command.
A
So
you
need
to
do
cube
cattle,
foo,
dash
and
namespace
dash,
whatever
whatever,
but
with
with
create,
for
example,
or
whichever
built-in
cube
commands,
you
can
do
cube,
cuddle
dash
and
namespace,
create
something
which
means
you
can
you
can
make
the
the
commands
with
the
arguments
and
keep
cuddle.
The
building
commands
will
work
just
fine.
A
There
was
a
pr
and
after
the
discussion
that
I
had
with
jordan
last
week
shortly
before
the
code
freeze,
we
put
a
hold
on
that
one
because
it
was
changing
the
default
behavior
and
one
of
the
reasons
was
that
it
is
hard
to
justify
whether
you're,
whether
the
the
value
that
you're
working
on
is
an
argument
to
a
flag
or
it's
a
flag.
That
does
not
accept
arguments
or
it's
a
command
name.
A
A
Us
supporting
only
the
current
approach
is
it
problematic
for
the
plugins,
because
if
you
read
through
all
the
links
that
I
pointed
there
along
the
the
the
issue
in
the
agenda,
it
is
pretty
reasonable
to
not
to
extend
to
global
flags
being
supported
in
the
plug-ins.
C
I
think
there's
like
two
sorry:
do
you
want
to
interrupt
you?
That's
it!
No!
No
go
ahead.
Go
ahead.
I
think
there's
like
two
folks.
Two
parties
here,
like
one
is
as
a
control
user
who
may
be
running
a
plugin.
C
If
it's
like
a
apply-ish
sort
of
plug-in
or
something
like
that
right,
then
you
got
like
the
plug-in
authors
right
in
kind
of
the
technical
limitations
of
making
such
a
thing
possible
right,
which
is
the
the
command,
may
not
support
that
flag
right
and
may
do
strict
flag
validation.
I
think
ahmet
left
a
comment
about
this
right,
in
which
case
passing
in
would
cause
the
command
to
fail,
or
it
may
not
take
that
flag
and
it
may
not
do
strict
argument,
validation,
in
which
case
it
may
not
work.
C
It
may
just
silently
ignore
that
or
these
sorts
of
things
right,
and
so
the
like
reconciling
those
two
differences
is
like.
What
do
we
want
like?
We
want
the
person
passing
the
global
flag
to
effectively
know
that
it's
not
being
passed
to
the
the
plug-in,
and
I
think
what
they're
asking
for
is
that
it
just
gets
past
the
plug
in
and
just
magically
works,
but
the
you
know
with
the
cons
constraints.
That's
that's
not
possible.
So
one
thing
I
suggested
somewhere
and
this
one
of
these
issues
is
just
for
plugins
like
fail.
A
I
mean
to
answer
your
first
question
or
statement
that,
if
you
specify
a
global
flat,
for
example,
context
or
namespace,
and
it
does
not
get
applied
properly
within
a
command
the
way
we
currently
invoke,
the
commands
from
within
cube
cuddle
the
plugins
from
within
keep
cuddle.
We
do
not
enforce
anything
at
a
global
element.
A
We
leave
all
of
the
client
creation
context,
picking
the
right
config
file,
picking
the
right
context,
picking
the
name
space.
Everything
is
up
to
the
plugin
author.
B
B
So
there
I
think
there
is
one
nuance
to
this-
that
if
you
look
at
the
original
issue,
884
the
the
problem
that
this
original
issue
reporter
said
was
they
had
an
alias
defined
for
for
coop
cuddle
that
had
the
name
space
in
the
alias
and
then
they
tried
to
call
plug
in,
and
so
they
had
like
dash
in
names
dash
in
with
no
need
with
with
a
space
and
then
the
name
space
name
and
then
their
plug-in,
and
it
failed
because
it
can't
it
can't
interpret
any
flags
that
come
before
the
plug-in.
C
Right
so
like
the
answer,
right
is:
okay,
put
it
after
the
plug-in
right
and
that's
just
the
way
you
specify
these
things
right.
Is
there
like
a
compelling
need
to
support
this
particular
ux.
B
C
C
G
G
A
A
G
So
we
could
probably
like
rearrange
the
global
options
that
were
passed
before
the
plug-in
name
to
the
end,
but
then
the
problem
becomes
what,
if
the
plug-in
is
parsing
the
flags
themselves.
Like
the
plug-in,
imagine
expects
one
argument,
but
you
just
gave
it
that
one
argument,
plus
some
more
command
line
options
like
so
some
plugins,
might
fork
out
that
way.
A
A
It
not
necessarily
can
be
true
for
the
majority
of
the
flags.
You
can
have
flags
which
are
bulls
and
it's
still
valid
local.
If
you
use
dash
dash
local,
for
example,
it's
a
boolean
flag,
there's
no
value
and
then
can
be
flag,
no
value
again
flag
and
the
parsing
needs
to
be
aware
whether
there
is
a
value
or
if
there
is
no
value,
and
that
becomes
super
tricky
and
you
might
actually
end
up
in
a
completely
messed
up
world
where
you
will
be
passing
wrong
arguments,
wrong,
commands
or
looking
for
wrong.
C
F
C
G
C
Maybe
what
it
comes
down
to
is
for
the
built-in
commands.
With
this
global
flag.
We
can
say
that
if
the
command
targets
a
name
space
that
that
we
can
guarantee
that
that
namespace
will
be
or
the
flag
value
will
be
respected
right,
but
for
plugins
the
command
may
target
a
main
space
and
there
is
no
way
for
us
to
enforce
that.
It
respects
the
flag
and
therefore
this
gives
a
false
sense
of
security.
G
What
if
we
arrange
the
to
the
end
and
assume
plugins,
have
good
enough
plug-in
command
line
argument
parsing,
so
they
can
say
hey.
I
don't
support
dash
dash
namespace,
but
you
know
the
user
can
tell
they
use
the
dash
dash
namespace
because
they
were
using
the
alias.
B
Yeah,
that's
a
great
option.
We
I
came
here
on
the
pr
or
the
issue
we
talked
about
doing
that
and
that
works
well,
except
for
I
think
the
only
exception
is
that
on
like
the
name
space
flag,
you
have
to
use
equal
sign.
You
can't
you
can't
say
like
or
well
I
don't
even
have
to,
but
it's
it's
hard
to
parse
out
flags
if
they
don't
have
an
equals.
So
you
don't
know
whether
that's
whether
what
comes
after
the
space
is
a
plug-in
name
or
the
argument,
but
I
think
that's
that's
probably
a
viable
option.
B
G
Some
a
lot
of
the
plugins,
don't
even
talk
to
the
api.
They
just
do
like
some
options,
some
things
on
the
local
context
or
they
parse
yaml
files,
or
they
rearrange
fields
or
something
like
that.
So
they
that's
why
it
doesn't
solve
that
problem.
C
G
A
It's
only
a
matter
of
time
when
we
would
get
an
an
issue
back
with
why
there
is
this
restriction.
I
want
to
remove
that
restriction
and
we
will
be
back
at
the
same
point
where
we
are
today
and
I
think
what
we
need
to
do
is
to
properly
document
their
the
limitation
of
the
design
that
we
that
we
picked
some
time
ago
and
and
make
it
obviously.
A
Documented
properly,
both
for
plug
and
others
and
the
in
the
users,
especially
okay,
I
don't
wanna,
keep
you
too
long,
we're
already
one
hour
after
that.
One.
F
Real
quick
there
was,
there
was
action
items
for
the
recording
issue.
Did
someone
take
that
on
to
do
that
or.
A
The
drain
and
coordinate
issue
sean
will
be
handling
that
one.
D
So
I
I
assigned
it
to
myself,
I
put
a
hold
on
it
and
asked
for
for
a
better
description
of
the
use
case.
Does
that
sound
real?
What
do
you
think?
What
do
you
think.
A
Yeah
with
that,
okay
I'll
update
I'll
update
the
the
agenda
with
the
with
the
action
attempts.
Thank
you
very
much.
Sorry
for
the
two
minutes.
Extra
see
you
in
a
week
on
our
bug,
scrap
have
a
good
one.