►
From YouTube: Kubernetes SIG CLI 20220810
Description
Kubernetes SIG CLI bi-weekly meeting on August 10, 2022.
Agenda and Notes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit#bookmark=kix.4m835xlzc8sf
A
So,
let's
start
with
the
announcements,
let's
see
where
we
are
on
our
release
calendar,
so
we
just
had
code
freeze
last
tuesday
august
2nd,
so
the
code
freeze
is
now
in
effect
and
there
you,
the
date
that
we
are
shooting
for
for
the
release,
is
tuesday
august
23rd.
A
Previously
it
was
reported
that
we
should
use
the
119
rc2
and
now
there
is
the
119
ga
that's
available
and
absolutely
necessary
to
to
work
on
on
master,
and
our
next
item
is
so
kubernetes
has
not
allowed
golang
generics
which
have
been
recently
implemented
in
golang
until
recently,
and
now
we
have
a
policy
from
the
sig
architecture
committee,
which
describes
how
kubernetes
should
use
generics.
So
if
you're
interested
in
that,
please
click
through
I'm
sure
we're
all
going
to
to
need
to
to
know
this,
and
so
for
kubecon
north
america.
A
In
this
year,
what's
just
happening
in
detroit
october
24th
through
the
28th.
The
schedule
has
been
released,
so
we
can
tell
exactly
what's
going
to
be
presented
and
the
leadership
for
this
sig
will
be
presenting
a
we'll,
have
a
presentation
about
six
cli
on
wednesday
october
26th
at
5
25.
So
set
your
calendars.
A
A
This
is
a
good
way
to
to
raise
your
profile
in
the
sig
so
that
we,
the
sig,
can
can
have
a
little
bit
more
context
on
on
who
you
are.
On
the
other
hand,
if
you
don't
want
to
that's
fine
too,
so
if
anybody
would
like
to
introduce
themselves,
please
go
ahead.
A
B
C
Yeah,
I
think
a
little
bit
of
background
is
is
needed
when
we
initially
started
disassembling
factory.
C
If
you
touch
cube
color
code,
which
currently
exists
as
sub
components,
for
example
in
a
cli
runtime
or
in
in
a
couple
other
places,
we
started
working
on
disassembling
the
factory
back
then,
and
we
reached
a
certain
point
where
we
were
happy
with
the
goal.
But
the
end
result
that
we
would
like
to
achieve
eventually
is
so
that
every
single
command
relies
on
the
red
client
getter
rather
than
the
factory
factory.
C
The
problem
with
the
factory
is
most
visible
in
the
testing
of
the
initial
commands
in
cube
cuddle
such
that
you
will
notice
that
people
are
adding
a
ton
of
boilerplate
to
be
able
to
to
test
the
functionality
functionality,
sorry
of
any
particular
command,
rather
than
focusing
on
the
actual
core
of
a
command.
They
have
to
add.
C
Serializers,
dc,
realizers
or
manually
handcraft,
get
comments
or
http
requests
to
be
able
to
work
with
the
factory,
because
what
that
was
one
of
the
main
bits
when
we
instead
look
at
the
commands,
such
as
events,
which
are
the
two
newest
commands
that
we
have
you'll
notice
that
each
and
every
single
one
of
them
is
usually
a
passing
wrestling
getter
which,
as
you
saw,
has
a
very
limited
interface,
and
on
top
of
that,
the
only
thing
that
we
most
often
care
is
to
be
able
to
get
the
cube.
Config
or
client.
C
Config
specifically
says
that
such
that
we
can
create
a
decline
for
any
particular
api,
and
the
good
thing
from
that
is
that
actually
for
testing,
you
don't
even
have
to
mock
the
rest
time
better.
But
rather
you
are
able,
assuming
we're
already
past
the
point
where
you
have
a
proper
option
structure
and
the
proper
flow
of
complete,
validate
and
and
run.
C
We
are
able
to
inject
the
client
which
every
single
current
client
usually
has
a
fake
counterpart
which
allows
you
to
inject
a
cube,
color
resource
or
cube
cuddle
object,
rather
than
dealing
with
the
serializers
and
all
that
you
can
focus
on.
Oh,
I
want
to
get
this
object
into
the
client
and
the
fake
client
is
able
to
return
that
particular
resource
for
testing.
C
So
the
main
goal
is
the
readability
and
simplification
of
all
the
commands,
but,
of
course,
yeah
we're
not
there
yet
and
we're
slowly.
Building
the
path
towards
that,
like
I
said,
there's
a
handful
of
commands
which
also
for
the
cli
reviewer's
cohort,
I
pointed
specifically
at
the
event
and
the
weight
commands,
because
these
are
the
perfect
examples.
B
The
problematic
ones
are
already
highlighted
by
sean
actually
open
api
schema
and
open
api
getter.
I
wonder
how
we
can
overcome
these
commands
using
open
api
camera.
C
Both
of
these,
depending
on
where
you,
where
we
need
them-
and
maybe
there
will
be
commands
that
will
require
a
little
bit
more
work.
But
if
you
look
at
the
at
the
signature
of
the
return
for
both
of
the
methods,
the
latter
is
talking
about
discovery.
C
So
what
you
can
easily
do
is
having
a
a
a
config.
You
can
easily
create
a
discovery,
client
and
fetched
open
api
as
needed.
Similarly,
I'm
guessing
the
open
api
schema
is
capable.
I
don't
remember
how
we
have
open
api
schema
fire,
but
probably
something
somewhat
already
pre-exists
somewhere
else,
because
yeah,
that's
that's.
Basically
the
goal.
A
So
I
think
going
in
these
commands
one
by
one
might
be
like
a
lot
of
work,
but
it
also
might
be
the
the
easiest
to
understand
for
the
reviewers,
just
like
the
two
that
have
already
been
updated.
C
A
good
point
that
was
pointed
by
brian
is
because
I
initially
thought
that
we
could
change
both
the
commands
and
the
test
for
the
client,
but
brian
pointed
out
that
the
factory
can
the
testing
factory
can
easily
be
reused,
also,
as
is
without
slight
change
to
brian's
idea
of
letting
the
actual
code
change
from
the
test.
Change
would
be
probably
very
desirable,
because,
when
we're
changing
the
code,
I
wouldn't
expect
from
the
factory
to
the
time
getter.
I
wouldn't
expect
too
much
of
a
changes.
C
C
But
the
testing
will
most
likely
be
done
in
entirely
separate
cr
such
that
we
will
be
getting
rid
of
the
testing
factory
entirely
eventually
and
replacing
that
with
direct
invocation
into
the
baseline
as
needed.
C
Also,
it's
a
good.
This
is
a
good
chance
to
to
double
check
what
we
have
in
the
commands,
because
in
the
other
pr
can
you
open
that
the
other
one
shown?
What
I
did
notice
is
that
we
were
actually
using.
C
We
have
two
coast
paths,
not
the
cluster
info,
the
other
one,
the
certification,
yeah
and
the
certificates
when
I
was
going
through
it.
What
I
noticed
is
that
all
that
was
creating
two
clients
which
was
done.
There
were
backwards,
compatibility.
C
And-
and
I
started
looking
when
the
one
beta
one
was
actually
introduced,
and
it
turns
out
that
it
was
separated
already
in
119,
so
the
code,
which
is
there
for
the
chief
cuddle
to
be
able
to
work
with
either
newer
or
older
clusters,
is
not
for
given
our
current
school,
it
is
way
out
of
the
the
supported
path,
because
we're
at
125
translate
and
v1
beta
1
wasn't
looking
at
119.
C
that
should
have
been
properly
removed
away
around
that
time,
but
nobody
did
it
and
probably
when
the
api
itself
will
be
dropped
that
would
pop
up.
So
when
we're
going
for
them,
it's
also
possible
to
catch
those
things
and
and
address
them
either
as
a
separate
comments
just
for
readability
and
for
historical
historical
purposes,
but
also
for
the
maintenance
use.
You
just
don't
need
to
have
two
codes
passed
depending
on
which
api
is
available.
C
At
this
point,
we
will
try
with
arda
to
make
both
of
these
pr's
like
a
perfect
example,
so
that
people
can
have
a
look
at
what
these
should
look
like
and
it'll,
so
that
this
should
be
both
easy
for
reviewers
and
for
people
who
will
be
interested
in
working
on
on
these
topics.
B
In
addition
to
matcha
two
weeks
ago,
I
was
trying
to
implement
a
cattle
plugin
was
using
to
apply
and
give
commands,
and
I
really
had
some
problems
about
creating
the
cmd
youtube
factory,
and
I
think
these
changes
will
make
easier
for
the
plug-in
developers,
because
you
will
just
create
a
rest,
client
getter
and
pass
it
to
the
command
and
it
will
just
work.
C
Correct,
that's
that's
one
of
the
goals
we
would
like
to
be
able
to
everyone
to
consume
the
commands
easier
for
people
that
will
be
building
on
top
of
chip
cuddle,
so
they
can
each
and
every
single
command
could
actually
be
ideally
as
small
as
possible
and
as
contained
as
possible,
without
without
the
necessary
necessities
to
pull
in
some
weird
factories
or
anything
like
that,
but
rather
minimal
interfaces
with
minimal
methods
or
very
specific
interfaces,
which
are
oh
yeah.
I
care
about
the
conflict.
C
If
you,
if
you're
curious
about
direct,
find
getter
a
perfect
example
and
a
perfect
implement
implementator
of
direct
client
getter
is
actually
config
flag,
which
is
one
of
the
main
features
that
people
have
available
in
the
cli
runtime,
which
basically
reads
the
entire
conflict
from
all
the
contents
back
and
that
can
and
that
already
fulfills
the
rust
client
getter
interface.
C
Just
because
we
only
care
about
the
mapper
and
the
client
config.
There's
no
need
for
any
additional
thing.
So
as
soon
as
your
plugin
is
capable
of
reading
this
politic
fact,
which
is
very
simple
because
that
already
exists
as
a
separate
there's,
a
set
of
methods
that
you
can
easily
embed
in
your
own
commands.
And
if
I
remember
we
already
have
example
with
that
with
the
context,
you
can
easily
satisfy
that
interface
and
then
reuse
and
pass
that
to
other
methods.
To
other
commands
which
accept
the
right
client
together.
A
So
mache,
what
how
should
I
answer
this
question
about
the
consensus
on
what
to
do
with
the
test
factory
we're
going
to
continue
to
use
the
test
factory?
Is
that
what
you
said
it?
It
also
implements
full
risk,
client,
getter,
but
also
other
stuff.
C
So
for
now,
yes,
we
will
continue
using
that,
but
ideally
the
command
should
not
be
using.
The
new
ones
are
discarded
from
using
test
factory.
There
should
be
using
reclaim
getter
and
fake
clients
if
necessary.
The
factory
is
more
like
it's
there.
We
will
leave
it
for
now,
but
it's
not
meant
to
be
used
anywhere
else
from
the
pre-existing
command.
C
Eventually,
we
once
we
have
cleaned
up
all
the
all
the
commands.
The
goal
would
be
to
get
rid
of
the
factory
and
the
test
factory
as
well.
C
A
As
far
as
the
the
open
api
commands
that
are
kind
of
the
exceptions,
they're
only
used
in
a
couple
of
the
commands,
and
so
we
could
get,
we
could
at
least
make
progress
on
all
the
other
commands
is
that
correct.
C
Correct,
I
wouldn't
expect
that
if
you
look
at
gap
in
the
first
place,
if
I
remember
exactly
get,
is
still
way
behind,
it
does
not
even
use
any
of
the
yet
options.
It
still
has
the
old
structure
how
we
used
to
run
the
class.
Oh
actually
it
does
not.
It
has
a
complete
valley,
it's
halfway
through
it's
not
that
bad,
there's,
still
a
bunch
of
tools
pre-existing
out
there
from
old
times
that
we
will
have
to
eventually
clean
up.
It's
just
that
he
didn't
get
the
time
there.
B
A
Uses
the
open
api
correct,
it's
not
part
of
the
build,
it's
part
of
the
builder,
which
kind
of
reads
all
of
these
reads:
all
of
the
config
off
of
the
disk.
That's
used,
I
know
in
the
apply
command
and
the
validate
in
the
builder
is
I'm
pretty
sure
it
needs
the
open
api
in
order
to
be
able
to
to
do
the
validation.
C
A
B
D
Is
there
going
to
be
an
additional
refactoring
connected
to
this,
like
with
config
flags
or
the
builder?
Like
we
had
a
discussion
about
this,
I
have
a
pr
about
sharing
the
transport
http
transport
client
and
it's
blocked
on
like
there
is.
There
are
some
like
not
not
a
great
design
like
dependencies
between
the
builder
and
config
packs,
and
so
we
had
the
discussion
about
this
this
refactoring
and
since
we
are
going
all
over
the
commands
and
seeing
how
how
they
work,
if
it
makes
sense
to
proceed
in
this
direction
as
well.
D
C
C
I
already
have
both
the
arc
yours
and
one
from
joel
written
down
where
we
should
ensure
that
any
weird
cycles
are
not
introduced
or
any
unnecessary
dependencies
that
the
overall
defensive
tree
is
a
little
bit
more
loose
than
it
currently
is
so
yeah.
It's
it's
definitely
something
that
I
would
like
to
see,
and
your
sharing
transport
is
also
a
perfect
pr,
perfect
example
of
where
I
would
like
to
push
forward,
because
that
will
allow
us
to
limit
the
amount
of
connections
that
we
have
open
to
the
api
server.
C
Right
it
is,
it
is,
it
is
loosely
coupled,
but
yours
is
more
like
a
follow-up.
A
Okay,
thanks
for
bringing
that
up,
arda
and
thanks
for
all
the
the
wisdom
mache,
it
sounds
like
we
do
have
a
consensus
that
we
want
to
refactor.
All
of
the
pedal
commands
to
make
the
rest
client
getter
the
interface
we
use,
since
it's
so
much
smaller
and
less
sprawling,
and
it
sounds
like
we're
open
to
other
refactorings,
like
the
builder
that
philip
just
mentioned.
A
Yep,
okay,
great!
So
I'm
going
to
to
open
it
up
for
stand-ups
and
if
that's
okay,
if,
if
we're
done
with,
if
we're
complete
with
that
I'll
move
on
to
stand-ups.
A
Are
there
anybody
who
would
like
to
give
an
update
on
one
of
their
sub
projects.
E
I
can
give
a
brief
update.
Sorry,
I've
been
absent
about
past
few
meetings,
some
internal
deadlines
getting
in
the
way
so
for
kui,
hopefully
we'll
be
able
to
roll
out
a
release
in
the
next
few
weeks,
there's
been
a
few
user
reported
bugs
that
we
fixed
some
we
haven't
yet.
For
example,
there's
been
a
long-standing
bug
with
cluster
versus
names,
namespace
scoping
with
openshift
openshift
data
type,
so
we'll
get
all
those
fixed,
I'm
hoping
to
make
roller
release.
E
The
next
few
weeks
can't
get
a
hard
deadline,
but
hopefully,
in
the
next
few
weeks,.
F
On
the
customized
side,
we
did
a
release.
Recently,
we
were
trying
to
get
in
the
latest
version,
the
light
of
the
code
released
in
time
to
update
cape
cod
for
the
code
freeze,
and
we
ended
up
running
into
some
complications
to
do
with
our
conversion
to
go
workspaces
and
the
reliance
of
our
test
suite
on
docker,
specifically
as
opposed
to
other
container
run
times.
F
F
We
also
for
the
docs
project
got
the
netlify
integration
set
up
to
only
preview
on
pr's,
without
releasing
the
website
for
real,
yet
so
that
will
help
the
contributor
experience
for
that
project.
E
One
thing
I
forgot,
I
forgot
to
mention
one
thing:
that's
come
up
on
this
other
project.
I've
been
working
on,
which
is
using
some
of
kui
stuff.
You
guys
are
probably
all
familiar
with
the
ubiquitous
trey
menu
participants.
Docker
has
one
everyone
seems
to
have
one
these
days.
Would
it
make
sense
for
us
to
have
one
for
cooy?
E
I
sort
of
resisted
that,
because
I
didn't
want
to
be
part
of
the
problem,
but
there's
some
benefits
to
it
being
able
to
see
your
namespace
and
switching
just
at
the
click
of
a
button
and
not
even
have
to
use
the
cli.
E
So
we
can
get
an
entry
sort
of
an
entrance
into
our
users
sort
of
experience
without
them
having
to
adopt
any
other
change
in
tooling.
They
can
just,
for
example,
switch
namespaces
lists
their
namespaces,
even
like
whatever
we
want.
We
could
whatever
we
want
their
realistic,
pods
active.
You
know
active
jobs.
E
A
And
that's
in
the
tray
menu
yeah
with
the
easy
user
interface
for,
for
instance,
namespace,
listening
name
spaces.
That
type
of
thing.
E
Yeah
we
could
put
a
kubernetes
icon
on
the
upper
right,
our
mac
os,
I
think
in
windows,
it's
on
the
lower
right
and
you
know,
then
we
can
pop
at
the
menu
with
whatever
we
want.
We
could
put
shortcuts
to
any
kinds
of
commands.
You
know
either
sort
of
ui
list
commands
like
switching
namespaces,
but
also
if
we
want
to
have
shortcuts
to
documentation
or
to
certain
visualizations.
For
example,
kui
has
its
grid-based
pod
visualizer,
so
you
can
go
up
there,
click
and
launch
out
the
grid
visualizer
for
your
jobs
or
your
pods.
E
G
Unless
we,
I
had
an
update,
okay,
so.
B
G
From
the
group
mentoring
coordinator,
we
had
our
yeah.
We
had
our
first
kickoff
session
on
third
of
august.
We,
I
unfortunately
couldn't
record
that
session,
but
hopefully
we
will
be
able
to
record
from
the
next
zoom
meeting
just
a
heads
up
august
17th.
We
have
decided
to
we
all
have
decided
kind
of
decided
to
do
a
cube,
ctl
deep
dive
just
wanted
to
know
who
will
be
going
to
come
up
and
give
the
session
the
mentors.
G
The
cubesated
tip
type
would
basically
be
just
a
walkthrough
about
the
codes
like
what
commands
are
there?
Basically
a
short
overview
of
the
commands
and
an
example
review
of
one
good
pr
pull
request,
which
will
give
an
idea
an
ideal
idea
about
what
what
one
does
to
do
in
in
acting
as
a
reviewer.
G
Sorry
I
didn't
catch
you.
What
did
you
say.
G
Oh
okay,
yeah
so
much
and
we
can
always
work
with
two
or
more
mint
one
or
two
more
mentors.
If
anyone
else
says
yeah
yeah
sure
already,
that's
all
from
my
site,
yeah
I'd.
A
So
so
sorry
to
to
I,
I
didn't
catch
the
the
name.
It's
a
tharva.
G
A
G
A
G
A
Okay,
I'll
I'll
reach
out
to
you
to
make
sure
that
I
get
that
correct.
So
that's
I
apologize.
A
A
Okay,
great
good,
to
see
you
all
and
hope
to
see
you
again
in
two
weeks
and
maybe
even
sooner,
for
some
of
the
other
six
eli
meetings.