►
From YouTube: Kubernetes SIG CLI 20201202
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
A
If
I'm
counting
correctly-
and
I
was
looking
at
the
right
calendar-
we
have
a
box
crop
next
week.
Is
that
correct,
eddie
yeah
that
sounds
right
yep.
So,
if
you're
interested
in
working
on
particular
cube,
cuddle
box
feel
free
to
show
up
and
you
will
be
giving
a
chance
to
assign
some
of
the
interesting
work,
120
ga
is
still
planned
for
december
december,
8th,
which
is
next
tuesday.
A
I
haven't
seen
any
announcements
about
delaying,
but
obviously
that
might
change
over
the
next
couple
of
days,
so
that
pretty
much
was
all
unless
shawn,
eddie
or
phil
wants
to
add.
Oh,
yes,
there
is
one
important
announcement
since
we
spoke
last
time.
A
Almost
a
month
ago
we
got
our
new
chair
joining
us,
so
the
three
of
us
sean
phil
and
myself.
We
decided
that
eddie
with
his
amazing
work
with
the
bugs
crops
and
the
entire
project
management
from
for
our
six
eli,
was
so
helpful
that
we
decided
to
promote
him
to
chair
so
congrats
eddie.
A
He's
he's
an
amazing
addition
to
to
our
team,
so
thanks
a
lot
and
welcome
eddie.
A
Okay,
I
think
that's,
that's
all
with
regards
to
announcements
and
we
can
jump
over
to
the
main
topics,
and
I
know
that
antoine
and
julian
have
a
pretty
big
topic,
so
take
it
away
from
here.
Let's
start
with
intros
mochi,
oh
true,
especially
that
I
I've
noticed
that
we
have
couple
new
faces.
A
If
you're
new
don't
be
shy,
introduce
yourself
tell
us
who
you
are
say
hi
to
everyone,
and
what
are
you
trying
to
work
on
if
you
need
any
help
or
something
like
that?
That
would
be
very
helpful
for
us
to
get
to
know
you
as
well.
C
D
F
I'm
al
I
did
an
internship
with
6cli
in
2017.
I
think
with
anton
shan
phillip
that
gang
I'm
here
just
to
see
what's
going
on
see
if
I
can
help,
don't
have
much
time
to
dedicate
to
doing
extra
work.
But
if
I
can
do
a
couple
bug
fixes
here
and
there
that
would
be
a
lot
of
fun.
E
G
H
A
A
Yeah
welcome
we're
we're
super
excited
to
have
you
uncle
and,
like
I
said
at
the
beginning,
we
will
be
having
a
box
crop
called
next
week.
That's
a
perfect
place
to
volunteer
for
any
particular
issues
that
are
open
against
cube
cattle
or
any
other
areas
as
well.
I
Yeah,
hey
there,
so
I'm
julian,
I'm
here
with
antoine
from
working
group,
api
expression.
I
So
it's
we
have
120
coming
up
and
we're
planning
on
taking
server
side
apply
to
ga
in
1.21,
so
we'd
like
to
start
triaging
any
server-side
apply
ga
blocking
or
post
ga
blocking
issues
for
a
cube
cuddle,
so
we're
looking
for
feedback
here.
I
Examples
are
like
if
we're
happy
with
the
experience
using
server
side
apply,
particularly
with
flags
there's,
an
umbrella
issue
linked
and
one
example
of
an
issue
that
we
know
that
we
wanted
that
we'll
triage
is.
We
know
that
the
managed
fields
output
is
verbose.
That's
an
issue
with
like
quite
a
few
votes
and
antoine
brought
up
that
there.
People
are
complaining
about
it
on
like
twitter,
so
we'll
definitely
get
to
that
one.
I
But
if
there
are
other
issues
actually,
if
anyone
has
feedback
now
that
would
be
great
or
feel
free
to
comment
on
the
umbrella
issue
or
contact
us
directly,
yeah
and
antoine.
I
don't
know
if
you
had,
you
wanted
to
add
any
anything
else.
J
We
should
probably
do
both
because
so
changing
the
server
is
gonna
take
some
time
we
can
have
the
option,
do
it
on
the
client
until
it's
available
on
the
server
we
need
to.
We
need
to
decide
what
is
the
the
flag
that
we're
gonna
use.
A
Yeah
I'll
probably,
I
think
I
was
proposing
some
some
some
suggestions
in
the
in
the
issue.
If
you
have
your
own
suggestions
or
issues
with
the
manage
fields,
itself
feel
free
to
comment
in
the
9066
issue.
It's
it's
pretty
big
by
now,
but
there
are
some
valuable
information
you
might
find.
A
Oem,
because
we,
the
discussions,
are
so
far
we're
leading
towards
opt-in,
because
we
would
be
breaking
the
compatibility.
The
idea
is
that
dash
o
yum
or
dash
o
json
are
giving
you
the
the
object,
as
it's
seen
on
the
server
without
any
modification
and
hiding
the
managed
fields,
is
some
sort
of
modification.
J
Yes,
okay,
yeah.
The
idea
is
that
we
need
to
keep
the
object
as
it
is
by
default.
I
think,
in
my
personal
opinion,
we
should
change
the
bash
or
yaml
to
something
else.
J
I
know
field
proposed
something
like
sy
for
camel
something
very
heated
type,
and
this
would
just
drop
either
on
the
server
available
on
the
on
the
client.
K
I
think
that's
pretty
easy
to
do.
I'd
say
like
I
use
dasho
yaml
a
lot
because
I
want
to
get
like.
I
want
to
see
the
spec
in
the
status
of
some
of
the
metadata,
but
there's
others.
It's
not
like
the
managed
fields
are
by
far
the
worst
offender,
but
there's
also
other
fields
that
are
probably
verbose
and
you
don't
want
like
self-like
like
it's,
it's
pretty
rare
that
I
want
self-linked
or
just
like
some
of
the
other
random
stuff
in
metadata
and
then
like
and
oftentimes
like.
K
I
might
want
events
or
certain
things.
So
maybe
thinking
about
like
having
a
output
format,
that's
like
shows
you
all
the
stuff.
That's
in
the
object
that,
like
you,
want
99
of
the
time
getting
like
hiding
the
man's
fields
and
other
stuff
might
be
a
good
option.
M
J
M
K
J
Yeah
yeah
we
could,
we
could
probably
do
both
keep
the
keep
the
chest
on
for
the
dash
or
yaml
and
still
have
a
specific,
clean
output
but
yeah.
I
agree
that
it's
it's
too
it's
too
big.
Even
on
dash
or
yaml,
we
could
keep
the
same
meaning
and
the
same
content
but
format.
It
format
it
in
a
way
that
is
less
intrusive.
D
So
this,
I
think
this
comes
back
to
a
couple.
Other
discussions
we
had.
The
thing
I
want
to
bring
up
is
phil.
If
you
were
doing
dash,
oh
something,
and
it
gave
you
only
the
writable
fields
in
that
yaml
output.
Would
that
be
more
beneficial
in
terms
of
like
deciding
what
to
send
back
that
users
can
actually
work
with?
What's
right.
J
D
What's
that,
what's
writable,
you
said
right,
you're,
muted,
writeable,
so
not
read
only
fields
like
the
self-link,
the
uuid
managed
fields
like
all
of
that
stuff.
I'd
consider
like
not
user
writable.
K
A
Yeah,
but
you
would
want
to
get
them
when
you're
getting
the
object,
if
I
wanna,
if
I'm
explicitly
asking
for
a
young
or
json
representation
of
the
object,
is
because
I
want
to
have
full
description
of
the
object.
If
I
don't
care
about
the
full
I'll,
just
go
with
describe
or
get
which
gives
me.
The
80
of
cases
that
I
needed
and
the
20
cases
is
what
I'll
be
reaching
for
for
full
yum,
because
I'm
looking
for
something
specific.
K
I
know
I'd
say
like
I,
we
almost
never
use,
or
I
tell
people
not
to
use,
describe
and
just
use
get
yaml
because
describe
oftentimes
is
missing
some
crucial
piece
of
information,
especially
when
it
comes
to
like
status
conditions
and
summarizing
those
things
like
so
so
I
it
would
be
nice
to
like
having
something
that
has
everything
instead
of
like
describe
has
like
it.
K
Ops
like
it
has
a
filtered
view
where
it
chooses
what
to
show
you
and
that
works
well,
except
when
someone
forgets
to
update
describe
with
some
piece
of
data,
or
something
like
that.
K
N
What's
the
behavior
of
the
managed
fields
versus
coop
cuddle
diff,
do
I?
If
I
do
if
I
have
a
change
locally,
like
I
changed
whatever
the
name,
if
I
do
a
quick
little
diff,
am
I
going
to
see
the
diff
on
the
managed
fields
too?
You
should
yes,
okay,
that's
what
we
were
seeing.
It
seems
a
bit
like
a
false
positive.
Just
from
a
ux
standpoint.
N
J
I
I
don't
know
if
I
agree
with
that,
if
you're
trying
to
see
what
you
changed
locally
use
get
div,
because
I
mean
it's
local.
If
you
want
to
see
how
your
change
is
going
to
impact
the
server,
then
you
use
google
div
and
in
this
case
it's
also
going
to
show
you
how
the
ownership
of
the
field
transfers
from
one
actor
to
another,
and
I
think
that's
actually
valuable.
N
J
N
J
Resource
version
shouldn't
change,
but
that
sounds
like
a
bug.
You'll
see
definitely
some
things
change
because
of
your
change
directly,
and
so
we
are
actually
printing.
These
yeah,
like
the
defaults,
for
example,
if
you
remove
a
field
and
it
gets
defaulted,
you'll
see
the
default
and
I
think
that's
actually
valuable.
O
A
Antoine,
maybe
you
know
also
that
one
off
the
hat,
if
I
remember
correctly,
div,
has
two
modes
of
running
the
default.
Is
the
client
side
diff,
but
there's
also
the
server
side
div,
which
uses
the
server
side
apply.
Logic.
A
J
Yeah,
so
let
me
clarify:
there
are
both
several
site
operations.
They
both
send
a
request
to
the
server
the
server
side.
Div
uses
server
side
apply
to
make
the
change
the
non-server
side
reply.
Flag,
uses
the
client
side
apply,
but
still
makes
the
request
to
the
server
not
apply
the
diff.
That
they've
also
done.
A
J
A
I
remember
looking
at
the
at
the
div
some
time
ago
and
it
was
calculating
the
div
using
the
local
code
without
reaching
the
server.
I
might
be
wrong.
I
would
have
to
check
the
code
this.
J
M
Okay,
if
you
you
would
see
in
addition,
changes
like
mutating
web
hooks.
In
addition,
but
they're
they're
both
going
to
the
server.
J
Yeah
you're
going
to
see
the
mutating
web
hook,
changes
in
both
versions,
both
in
the
south
side
and
the
non-server
side,
because
they
all
go
to
the
server
they
all
get.
The
mutating
web
hooks
are
played
and
yeah.
It's
just
that
one
uses
the
merge
on
the
on
the
client
and
one
uses
the
merge
on
the
server,
but
they
both
pretend
to
make
a
change.
They
both
use
a
a
dryron
patch.
D
G
A
Which
is
sort
of
related
to
managed
fields?
Actually,
so
I
can't
remember
whom
I
own
the
credit
for
the
for
the
idea,
but
I
was
talking
with
someone
from
my
team.
I
think,
and
the
suggestion
was
that
we
could
probably
use
the
managed
fields
to
provide
something
like
get
like
blame
for
cube,
cuddle
and
1942,
and
I
yeah
john
zeng.
A
He
was
fast
enough
to
provide
us
with
a
working
implementation
of
such
a
of
such
a
feature.
It
will.
It
looks
pretty
cool
which
basically
means
you're
getting
the
resource.
If
you
invoke
keep
cuddle,
blame
you'll
get
the
output
of
the
resource
and
it
will
nicely
annotate
each
line
with
information
who
perform
a
particular
change,
or
rather,
what's
the
manager
behind
a
particular
change
which
basically
maps
to
either
particular
commands,
not
sure
if
users
or
particular
components
in
the
system.
A
It
will
be
very
useful
and
from
the
comments
that
are
in
the
issue
pretty
much
each
and
every
single
person
is
singing
praises
basically
for
that
kind
of
functionality.
So
I'm
curious
what
others
think
I
remember
there
was
a
demo
also.
Let
me
try
to
find
it
and
his
repo
can
definitely
play
it
out
it.
Basically,
it
looks
pretty
cool,
so
any
questions.
P
P
I
just
I'm
worried
about
pulling
in
functionality
like
this
when
the
plug-in
system
exists
and
what
that
means
for
maintainability-
and
I
mean
I
was
talking
to
eddie
about
like
customize-
is-
is
an
old
version
in
cube
control,
because
it's
hard
to
cut
those
releases
and
being
able
to
have
plug-ins
independently,
update
and
upgrade
outside
of
cube
control
releases
seems
really
good,
and
so
I
wasn't
sure
where
the
line
is
of.
What's
core
cube
code,
you
know
commands
versus
plug-ins.
A
So
I'll
I'll
try
to
cut
the
cord
for
customize
because
with
customize
it's
it's
a
little
bit
different.
The
reason
that
we're
behind
with
customize
is
because
of
the
dependencies
that
the
customized
have
on
the
cube
internals
and
the
version
that
we
vendored
back
in
the
days
did
not
have
the
problems
and
eventually
we
we
got
into
cycles
and
we
can't
bump
customize.
A
But
I
know
that
jeff
is
working
tirelessly
with
a
couple
of
folks
to
clean
this
thing
and
be
able
to
update
customize
within
cube
cuddle
and
I'm,
if
I
remember
correctly,
121
is
when,
when
we
will
be
able
to
actually
bump
the
customize.
D
Yeah,
well
not
not
to
discredit
any
of
that
matcha
and
jeff
and
everyone's
doing
great
work,
but
I
think
that
it's
a
bigger
point
than
if
customize
is
tied
to
a
cube,
cuddle
release
right
and
I
think
that's
the
issue
that
justin
and
I
were
talking
about-
was
any
anything
we
stick
into
cube.
Control
itself
is
then
tied
to
a
you
know
three
to
four
month
release
period
before
it
gets
in
people's
hands
for
upgrades,
and
you
know
what
I
mean.
K
That's
true
revisit
this
conversation
like
cube
control
is
almost
its
own
repo,
and
you
know
it's
possible
that
once
it's
in
its
own
repo
and
can
be
built
independently
of
the
who,
like
can
be
released
independently
of
kubernetes
and
then
then
we
can
like
set
up
like
a
bi-weekly
release
cycle
or
whatever
it
is
we
can.
We
can.
We
have
more
flexibility
there
at
that
point
in
time
like
that
that
would
probably
change
what
it
looks
like
to.
K
You
know
integrate
this
sort
of
stuff.
What
do
you
think
eddie.
D
Well,
I
I,
I
think,
that's
a
great
idea,
but
I
actually
I
put
on
the
agenda
too.
I
think
I
don't
know
if
we've
ever
talked
about
graduation
criteria
for
plug-ins,
because
I
think
we
you
know,
we've
we've
been
telling
people
that
the
path
to
getting
a
certain
command
in
the
cube
control
is
to
start
the
plug-in
and
then
prove
you
know.
Adoption
and
people
want
it.
D
I
don't
know
if
we've
ever
discussed
like
if
there's
graduation
criteria
for
something
to
be
upstream,
like
the
bug
we
just
kind
of
was
like
the
bugs
awesome.
Let's
make
it
into
an
alpha
command,
now
we're
making
into
a
beta
command.
I
don't
know
if
we've
ever
like
defined
what
that
you
know
that
journey
looks
like.
K
Maybe
one
point
is
right:
like
you
could
I
think
some
of
our
conversations
look
like
wow.
This
seems
like
a
useful
piece
of
functionality
that
someone
wants
to
contribute,
and
then
but
then
we
say,
but
there's
like
that
means
we
have
to
maintain
this
or
it
becomes
packaged
with.
K
You
know
other
pieces
of
code
control,
and
so
there
seems
to
be
like
a
a
like
a
tension
there
between
do.
We
want
to
build
out
a
do.
Do
we
want
to
allow
folks
to
contribute
and
build
out
a
suite
of
tools
that
is,
you
know,
polished
in
in
not
just
like
low-level
functionality,
but
includes
maybe
like
richer,
debugging
and
richer
display
and
in
richer
functionality,
which
has
a
cost
associated
with
doing
so
or
is
coo
control
a
are
we
trying
to
keep
control?
K
K
D
You
just
made
me
think
about
how
much
I
like
the
g
cloud
cli
in
the
sense
that
it
has
all
the
functionality
there
for
me
and
when
I
need
it,
it
goes
out
and
downloads
the
right
plugin.
So
that's
always
something
that
we
could
consider
where
crew
is
deeply
integrated.
So
when
I
run
cube
control
blame,
if
I
don't
have
the
plugin,
it
will
go,
grab
it
or
something.
K
Yeah,
that
might
be
may
be
the
right
path
forward
to
have
that
mean,
like
we'd,
have
a
the
formal
way
we'd
support
this
right
is
we'd,
have
a
our
own
60
li
plug-ins
and
cube
control
itself
would
have
some
notion
of
what
those
plug-ins
are
and
be
able
to
install
them.
When
they're
asked
for
if
cubecontrol
becomes.
P
A
package
manager
I'm
just
going
to
kind
of
laugh
at
that
teddy's
point,
though
I
do
agree
like
g-cloud,
is
great
at
keeping
things
minimal
when
needed,
and
so
like
tab
completion
isn't
completely
insane.
If
I
only
have
you
know,
if
I
use
three
projects,
I
don't
need
to
tap
complete
everything.
I
look
at
the
aws
cli,
which
is
absolutely.
P
I
think
that
is
a
really
good
path
to
say
we
can
have
something
that
is
third-party
added.
If
you
need
it,
but
then
also
we
have
a
some
extensions
that
maybe
not
everyone
needs
them
right,
like
I
mean
app
developer,
well,
app
developers
hopefully
aren't
using
cube
control
every
day,
but
the
reality
is
they
probably
are,
and
so
if
we
can
keep
some
of
their
interface
smaller,
I
think
that's
a
good
idea.
P
Which
is
another
point
to
keeping
cube
control
small
right?
If
something
else
is
taking
a
cube
control,
they
don't
necessarily
want
you,
know,
blame
or
or
debug
or
whatever.
These
commands
are
inside
of
their
tools,
so
keeping
cube
control
as
like
the
the
smaller
interface
with
core
functionality
for
authentication
and
port
forwarding
that
sort
of
stuff
that
more
people
want
and
then
keeping
the
extra
extra
plug-ins
whatever
it
is.
The
case
may
be,
you
know,
outside
of
that
core.
K
K
Probably
not
gonna
like
come
to
a
conclusion
here,
but
maybe
the
metapoint
is
like
that
we
need
to
decide
like
does.
Coop
is
coop
control
the
home
for
all
the
you
know,
rich
functionality
that
you
know
folks
would
like
to
have
and
contribute,
or
is
coup
control,
not
the
home
for
it
and
if
so,
where's.
What's
the
home.
K
P
Yeah
I
mean
looking
at
like
oc,
and
you
know
you
can
do
so
many
kubernetes
like
things
with
other.
You
know
whatever
the
platform
is
they're
targeting,
so
I
think
it's
fine
to
have
whatever
that
abstraction
is
that
they're
building
in
because
again
it's
like.
Are
people
using
kubernetes
directly?
Are
they
using
platforms?
On
top
of
it?
I
think
a
majority
of
people
are
just
using
straight
kubernetes.
Some
people
have
wrappers,
but
in
a
lot
of
cases
it's
still
cube
control
under
the
covers.
A
If
you
only
care
about
three
four
core
commands
from
cube
cuddle
that
you
want
to
embed
in
your
own
wrapper,
you
can
easily
do
that
already,
because
you
will
only
pick
the
three
four
or
whatever
will
be
the
core
that
you
care
about
from
cube
cuddle,
especially
after
we
manage
to
move
it
out.
You
don't
have
to
embed
the
entire
cube
cut
out.
A
A
So
yeah
it's
it's
definitely
an
important
discussion
that
we
should
probably
have
both
with
regards
to
promoting
plugins.
A
P
Right
and
there's
no
agree,
there's
no.
Like
final
thing
right
now,
it
was
just
something
to
consider
as
I
don't.
I
haven't
written
any
cube
control
code,
so
I'm
not
a
maintainer
of
the
project.
I
think
it's
just
something
to
be
aware
of,
and
for
me
looking
at
blame,
I'm
like
this
is
an
amazing
plug-in,
I'm
totally
fine
with
that
staying
a
plug-in
forever,
and
I
maintain
it
there.
If
it
is,
you
know
a
desire
to
have
it
inside
of
core
that
that's
fine
too.
P
I
mean
I
think
you
could
look
at
some
metrics,
but
to
me
I
like
to
keep
things
as
pluggable
as
possible,
just
to
keep
the
centralized
code
small
and
say:
okay,
this
can
move
faster
or
the
plugins
can
move
faster
than
the
core
piece,
because
you
know
compatibility
with
what
kubernetes
version
I'm
using
matters
a
lot
with
how
fast
my
command
line
interface
to
it
also
varies.
I
mean.
K
I
think
there
is
a
real
cost
to
plug-ins
right
like,
for
instance,
you
know
your
organization
may
say
like
white
list,
what
binaries
you
can
run
right
and
so
effectively
you
can't
use
plug-ins
or
you
have
to
go
through
red
tape
to
get
for
each
single
plug-in
right.
So
as
a
practical
purpose,
they
may
not
be
available
to
you,
the
cost
of
downloading
and
installing
those
things
right
like
in
your
ci
cd
system
having
to
you,
know,
make
sure
the
right
plugins
are
installed.
In
addition
to
coop
control.
K
It's
not
there
is,
they
do
create
friction
and
the
I
think
the
release
process
is
solvable
right
like
if
you
look
at
customized,
customize
itself
releases
relatively
frequently
right.
Coupe
control
does
not,
because
of
it's
not
inherent
to
coupe
control.
I
don't
think
I
think
it's
incidental
and
something
we
can
fix
so
for
that
particular
issue.
If
we
were
to
fix
the
control
release
schedule,
I
think
it's
reasonable
to
say
you
know
a
two-week
cycle
or
something
like
that
for
releasing.
A
Well,
there
are,
there
are
other
things
that
we
should
look
at,
because.
A
Will
affect
how
you're,
looking
at
the
plugins
versus
the
built-in
commands,
the
building
commands
have
a
completion
working
out
of
the
box,
whereas
the
the
plugins
do
not,
and
I'm
not
sure,
if
we'll
be
able
to
to
address
that
issue
or
how
far
we'll
be
able
to
address
that.
I'm
looking
out
of
curiosity
at
two
plugins
that
I
have
one
is
cubecara
which
is
44
max
and
then
there's
the
the
example
plugin,
which
changes
namespace.
A
The
plugin
itself
is
almost
as
big
as
cubecarl
itself.
If
there
will
be
one
additional
command
with
living
without
within
cubecuddle,
you
will
not
notice
the
difference
and
the
benefit
of
what
phil
just
said.
Where
you're
running
in
a
restricted
environment
and
adding
additional
plugins
is
a
problem.
Well,
you
can
obviously
solve
that
by
having
cui
with
a
allowed
set
of
plugins,
because
we
currently
allow
crew
to
to
change
the
default
index
to
something
predefined.
A
So
it's
solvable,
but
instead
of
having
one
thing
one
audited
binary,
you
end
up
auditing
a
couple
of
more
so
it's
always
a
a
balance
between
so
many
factors.
I
guess.
D
I'm
not
opposed
to
upstreaming
it,
and
I
want
to
make
sure
that's
understood,
like
I'm,
not
opposed
to
upstreaming
diff
at
all,
I
mean
blame
it
all.
I
just.
I
want
us
to
think
about
the
the
broader
picture
of
like
what
that
looks
like
right,
because,
like
we
did
it
for
the
bug
we
you
know,
if
we
do
it
for
this
one,
that's
two,
then
that
we
really
didn't
think
about
a
process
there,
and
I
just
want
to
make
sure
we
have
something
in
place
going
forward.
K
I
was
just
saying
I
totally
agree
with
what
eddie
said.
We
should
think
about
what
what
we,
what
we
have
stream,
what
we
don't
upstream
and
what
the
process
is
and
especially
make
sure
that
if
someone
thinks
something's
going
to
be
upstreamed-
and
we
don't
think
it
is,
we
communicate
that
early
instead
of,
like
after
they've
been
working
out
for
six
months.
A
True,
I'm
definitely
in
favor
of
having
the
discussion
and
trying
to
write
down
some
ground
rules
so
that
people
can
at
least
have
some
expectation
of
what
to
do
or
how
to
proceed
if
they
want
to
do
one
way
or
if
they
want
to
go
one
way
or
the
other
so
yeah.
That's
that's.
Definitely.
A
We
can
probably
move
on
to
the
next
topic.
Harsh
I've
noticed
you've
been
adding
that
one,
but
eddie
eddie
topic
was
first
I'll.
Oh.
D
A
H
Yeah,
so
I
was
thinking
so
basically,
this
is
about
the
future
weight
command,
and
I
was
thinking
that
we
have
a
flag
which
would
be
named
for
hyphen
condition
and
there
we
would
give
just
a
single
string
instead
of
having
even
what
the
user
suggested.
So
we
would
just
have
one
single
string
where
we
would
just
keep.
H
The
key
is
equals
to
value
like
whatever
the
condition
is
inside
the
string
itself,
and
then
we
have
our
conditional
operator,
and
there
was
some
discussion
around
we
just
support
or
and
users
could
you
know,
use
d,
morgan's
law
and
pipe
it
or
something
type
or
use
linux
to
aggregate
them
together.
H
A
A
B
A
Not
sure
how
others
are
seeing
look
at
it.
H
Yeah,
so
just
supporting
or
should
basically
do
it
right,
like
support
or
into
the
string
and
people
can
use
the
linux
and
operator
for
the
rest.
H
B
H
A
A
Okay,
if
there
will
be
questions,
suggestions
for
something
else,
there's
nothing
stopping
us
from
well,
I'm
worried
that
if
we
start
mixing
and
matching
ends
and
ores,
you'll
basically
end
up
in
a
situation
where
you,
where
you
end
up
in
a
situation
where
you
want
to
express.
A
B
H
D
Yeah,
that's
what
I
was
going
to
share
as
well.
It's
like
I
am
this.
This
one's
gonna
have
to
go
through
some
iterations,
probably
because
we
don't
know
what
we
want
until
it's
in
our
hands
and
someone's
playing
with
it
and
testing
it.
So
as
long
as
you're
aware
of
that,
like
it's
gonna
go
through
a
couple
iterations,
I
just
want
you
to
jump
into
this
work,
and
you
know
it
this
one
might
take
a
bit
for
us
to
get
right.
D
A
Wait
is
around,
for
I
don't
know
like
three,
maybe
four
releases,
if
I
remember
correctly,
that
was
somewhere
at
the
beginning
of
our
journey
when
we
were
slicing
and
dicing
all
of
the
commands,
probably
at
the
time
when
we
were
extracting
cli
runtime.
A
B
H
Okay,
so
just
to
be
sure
again
if
I
would
just
be
processing
a
string
which
would
have
the
all-conditional
statement
right.
A
Yeah
yeah,
we'll
probably
iterate
on
your
pr,
so
I
wouldn't
yeah.
Okay,
cool
eddie,
cube
cuddle
as
an
implementation
tool.
D
So
this
might
lead
to
a
longer
discussion,
but
this
historically
we
have
said
that
the
output
of
cube
control
is
not
versioned
and
if
you
parse
it
you're
totally
on
your
own,
and
we
may
break
things
without
telling
you
this
issue
that
came
up
during
our
bug.
Scrub
makes
it
sound,
like
the
person,
is
actually
parsing
the
structured
output
and
wants
a
more
structured
output
that
they
can
work
with.
I
think
this
is
what's
used
in
cap
street.
Let
me
refresh
myself
no
scaffold.
D
This
is
scaffold,
so
scaffold
they're,
actually
using
cube
control
and
parsing
the
output
to
do
different
things.
So
I
just
I
wanted
to
bring
up.
We
need
to
revisit
this
if
this
is
something
we
want
to
still
stand
by,
if
we
want
to
start
considering
having
a
structured,
our
power,
how
do
we
want
people
to
consume
the
output
of
cube
control?
D
M
We
we
have
some
long-standing
convention
that
we
don't.
We
won't
honor
we're
not
going
to
treat
the
kukul
output
as
an
api
and
that
anybody
who's,
relying
on
particular
output
in
a
particular
format
will
is,
is
risking
that
it
could
change
underneath
them.
We
we
can't
tie
our
hands
and
then
they
could
ask
for
a
particular
output
with
you
know.
The
minus
o
yeah.
D
D
A
A
Q
A
Yeah,
it's
easy
to
to
dissect
output,
standard
output
from
standard
error.
If
we're
not
putting
something
on
standard
error,
that's
a
bug,
so
you
should
be
checking
the
exit
code.
If
it's
non-zero
the
command
failed
and
you
can
just
print
the
the
the
output
in
the
standard
error
and
we
are.
We
are
not
planning
on
structuring
the
output
on
the
standard
error.
A
Most
at
most,
I'm
inclined
to
say
that
we
can
probably
add
quiet
or
something
like
that,
where
we
only
fail
with
a
non-zero
exit
code,
which
is
which
doesn't
give
any
information
currently
and
that's
an
another
long-standing
issue
where
it
would
be
nice
to
have
a
set
of
standard
error
codes.
We
don't
we
currently
exit
non-zero,
that's
it
and
they
don't
have
any
particular
meaning.
D
Print
the
error,
so
this
is
this
also
goes
beyond
just
errors.
So
if
you
scroll
up
and
click
the
example
link,
he
has
there
something
like
a
rollout,
for
example
right.
So
when
a
rollout
is
successful,
it
prints
out
successfully
rolled
out
right.
That's
not
an
actual
error
message,
but
this
user
right
now
for
scaffold
is
consuming
that
as
a
string.
D
A
A
The
current
move
to
staging
he
can
literally
embed
the
command
itself.
Instead
of
invoking
cube
cuddle
under
the.
A
A
But
to
cut
it
short,
no
we're
we're,
not
gonna
change
this
functionality.
That's
that's
off
the
table.
A
It
will
be
too
much
of
a
burden
for
us,
especially
that
the
errors,
the
errors,
are
sometimes
something
that
we
don't
control
because
oftentimes
we
are
just
presenting
whatever
we
got
from
the
server
or
whatever
we
got
from
the
library
that
we're
invoking.
Sometimes
we
wrap
them
with
additional
information,
but
most
often,
if
client
go
fails,
we
will
just
print
the
client
go
error
and
if
I'm
correct
in
that
particular
case
when
he
was
showing
the
tls
handshake
timeout,
that's
a
go
internal
error.
A
A
Okay,
we
have
five
minutes
left,
I'm
not
sure
if
you
want
to
talk
about
the.
M
I
don't
normally
bring
twitter
discussions
into
the
six
cli,
but
this
is
tim
hawkin,
and
so
he
was
asking
about
ways
to
discourage
people
from
running
containers
as
root.
One
of
the
ideas
was
a
pedal
output
that
had
different
colors
for
containers
that
were
being
run
as
root
or,
and
you
know,
maybe
different
output
yeah.
M
If
you,
if
we've
only
got
five
minutes,
I'm
not
sure
if
anybody
wants
to
to
discuss
this
or
even
deal
with
this,
but
I
think
that
you
know
for
someone
like
tim
hawkin,
maybe
we
kind
of
deserve,
or
at
least
I'll
take
take
it
on
to
to
get
back
to
him.
If
we
have
any
anything
to
to
tell
him
and
the
community
about
what
we
can
do
in
coop
cuddle
about
containers
being
run
as
root.
K
I
think
we're
already
looking
at
colorizing
the
output
for
tube
control
right,
so
this
kind
of
does
align
with
that
effort.
If
you
were
to
it
seems
like
a
natural
extension
to
say,
instead
of
just
highlighting
this
field
in
this
color
to
go
one
step
further
and
say
if
we
can
identify,
you
know
bad
things
or
good
things,
or
do
some
actual
syntax
highlighting
highlight
stuff
in
red
that
we've
identified
as
bad,
which
could
be
containers
as
root
and
could
be
other
stuff.
It
seems
like
an
interesting
idea
to
explore.
P
I
could
use
the
extra
help
yeah.
I
love
the
idea
that
colorization,
I
didn't
know
that
was
planned
to
be
rolled
into
default.
That
would
be
great.
The
cube,
color
plug
and
I
or
commit
wrapper
I
linked
there.
I'd
been
using
for
a
little
while
I'd
be
wary
about
making
it
red,
though,
because
red
to
me
in
any
shell
is
an
error,
and
it's
not
really
an
error.
It's
more
of
a
warning
so
like
yellow
or
something
else
that
is
less
of
a
this
is
broken
sort
of
flag.
D
A
Yeah
and
and
we're
again
touching
the
territory
of
people,
people
different
people
having
different
opinions
of
what
has
to
have
what
kind
of
colors.
How
many
which
and
which
not.
P
A
Yeah,
so
I
was
actually
thinking
at
the
back
of
my
head
that
for
the
ones
for
the
terminals
where
the
colors
are
not
supported,
for
whatever
reason,
we
could
probably
put
some
kind
of
a
exclamation
mark
next
to
them.
Whatever
there
are
options
yeah,
it's
definitely
something
that
worth
talking
about,
so
I'll
definitely
make
sure
to
bring
it
up
during
the
next
call.
We
have
two
minutes
left
I'll
leave
the
topic
for
the
next
time.
A
Do
we
have
anyone
that
want
to
share
any
stand
up?
I'm
not
sure
if
any
of
the
projects
want
to
say
something.
H
Oh,
I
I
had
a
question.
Yeah
go.
A
H
Yeah,
so
I'm
a
bit
confused
about
why,
like
so
there's
a
cube
kettle
repo
which
I'm
assuming
is
enough
for
me
to
build
the
weight
command
upon,
but
there's
also
staging
folder
inside
the
kubernetes
repo,
where
cube
cuddle
exists.
So
I'm
I'm
not
sure
like
what's
the
difference
and
how
what's
going
on
around
that.
A
Yeah,
that's
that's
probably
still
a
that
causes
a
lot
of
confusion
to
a
lot
of
folks.
I'm
very
glad
that
you
asked
so
all
of
the
development
still
happens
within
the
main
kubernetes
repo,
so
you're
modifying
the
files
within
the
staging
directory
and
there's
a
process
that
is
responsible
for
synchronizing
the
staging
directory
contents
into
the
kuvkado
repo.
A
So
it's
only
for
consumption,
the
actual
development
happens
within
the
main
kubernetes
repo
for
now,
okay,
okay,
this
applies
to
kate's
io
api
client
go
cli,
runtime
and
everything
that
lives
within
the
staging
repo.
A
A
Yeah
there
is
a
long
history.
Basically,
a
lot
of
initial
code
of
cube
cuddle
was
tied
to
kubernetes
internals,
mostly
the
internal
apis,
and
over
the
past
couple
of
years
we
were
cleaning
the
cupcake
code
so
that
it
doesn't
rely
on
the
internals
and
staging
was
is
a
is.
It
is
one
step
where
it
allowed
us
to
ensure
that
everything
in
staging
does
not
rely
on
the
main
kubernetes
repo,
and
so
whenever
we
have
a
command
that
was
not
relying.
We,
we
moved
those
one
by
one
to
the
staging
repo.
A
Currently,
all
the
commands
are
in
the
staging
repo,
the
only
one
that
that
was
left
in
the
main
repo
is
convert,
and
the
reason
for
that
is
convert
relies
on
the
grenades
internal
apis,
so
we
decided
that
that
one
command
will
be
built
from
within
the
main
grannies
repo.
A
And
yes,
there
is
a
plan
to
fully
move
cube
cuddle
to
a
separate
repo,
but
it
requires
discussion
mostly
around
how
the
release
machinery
will
work
and
how
the
testing
will
be
working,
because
we
need
to
ensure
that
every
single
pr
within
kubernetes
repo
is
still
tested
against.
A
The
current
cube,
cuddle
version
or
whatever
is
in
the
repo
and
then
the
other
and
the
same
applies
in
the
other
direction.
And
then
there's
the
the
question
of
figuring
out
how
the
release
is
and
the.
A
Backwards
compatibility
works
currently
there's
a
hard
rule
written
down
that
we
support
minus
one
version.
If
the
plan
would
be
to
move
to
a
bi-weekly
releases
of
cube
cuddle,
we
would
have
to
ensure
wider
support
range
because
within
a
single
cube
releases,
we
would
have
about
six
releases
of
cube
cuddle.
So
we
would
need
to
ensure
that
there
is
a
longer
window
of
support.
R
I
have
a
quick
question:
please
sorry!
Yes,
okay,
hello,
everyone!
I'm
working
on
the
issue,
I'm
trying
to
fix
the
linting
errors
in
create
command
and
the
lender
is
complaining
about,
like
these
structures
have
names
like
create
cron
job
options,
so
the
linter
is
complaining
about
like
it
will
be
used
for
outside
the
library
is,
create
dot,
create
cron
job
options,
so
I
have
to
fix
it.
So
shall
I
just
remove
the
create
portion
from
name
no.
A
These
are
perfect,
not
everything.
There
were
several
instances
in
the
past
where
we
just
closed
or
reverted
prs,
such
as
that
the
names
were
mostly
for
readability
rather
than
for
following
what
linters
said.
We
don't
want
to
blindly
follow
what
lenders
do.
A
I
had
people
changing
the
file
names
because
linter
was
complaining
and
suddenly
I
was
not
able
to
distinguish
between
controllers,
because
all
the
controllers
have
had
a
controller.google
name
and
with
the
current
k
lock,
it
was
impossible
to
to
know
which
one
is
which
so
don't
blindly
follow
what
the
linter
says,
but
rather
try
to
to
look
at
it
with
a
little
bit
of
grain
of
salt
and
look
at
the
other
commands
and
follow
the
patterns
in
the
other
commands,
rather
than
following
letters
blindly.
R
Okay,
so
I
won't
change
so
there
was
an
issue
which
which
has
a
long
list
of
files
which
had
problem
in
linters,
and
this
one
was
mentioned
in
the
in
one
of
the
files,
not
the
files
in
one
of
the
files
which
contain
the
lint
that
crashes
with
linters.
So
this
was
mentioned
in
one
of
the
files.
So
what
should
I
do
about
it
like?
Should
I
just
leave
my
messages
as
they
are
or
because
I
commented
on
several
portions
of
it.
R
I've
commented
like
made
comments
of
some
several
questions,
but
the
name
just
sucks,
because
there
are
a
lot
of
maintenance
which
we
have
to
do
to
change
the
name.
So
should
I
just
leave
the
name
as
it
is.
A
Okay,
we're
six
minutes
out
of
time,
so
thanks
very
much
all
it
was
nice
talking
with
you
and
see
you
next
week
for
for
the
blocker
bug
call.
Thank
you
all.