►
From YouTube: Kubernetes SIG CLI 20220921
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
Foreign,
hello
today
is
September
21st,
and
this
is
the
six
CLI
bi-weekly
meeting
for
September
21st.
My
name
is
Sean
Sullivan
I'll
be
your
host.
Today,
I'll
start
immediately
with
the
announcements
we
don't
have
too
many
of
them.
Let's
remember
about
the
the
new
126
release.
We
have
an
enhancement
freeze
in
about
two
weeks
on
Friday
October
7th,
so
we
have
about
a
couple
weeks
in
order
to
get
the
enhancements
submitted
before
for
the
126
release.
B
Yeah,
the
seventh:
if
you
look
at
the
at
the
UTC
calendar,
the
seventh
is
1am
in
the
morning.
B
Seventh,
so
I
think
it's
better
to
say
everyone
that
it's
the
sixth,
when
the
the
code
that
the
enhancement
screen
starts
because
it's
6
pm
aesthetic
so
that
that
will
be
the
majority
of
things
like
late
in
the
evening.
B
Also
an
important
date
would
be
a
week
earlier,
I
linked
the
no
126
days
and
the
fact
an
important
date
is
week
before,
because
the
sick
architecture
does
the
prr
reviews
and
they
asked
or
there's
a
soft
treat
a
week
before
that
on
Thursday
29th.
B
So
if
you're
awaiting
production
readiness
review,
I
would
suggest
getting
them
sooner
than
the
United
States,
because
it
might
be
tight.
There's
like
I
said
there
are
only
two
to
people.
That's
really
looking
at
the
prr
reviews.
A
Okay,
yes,
both
of
those
are
very
helpful
thanks
for
that,
so
I've
managed
to
get
that.
A
On
our
notes,
so
that
the
production
Readiness
review
is
Frozen
as
much
I
said
the
the
week
before,
then,
the
enhancement
freeze,
I've,
updated
that
date
to
October
6th
and
then
our
code
freeze,
which
is
further
down
the
road,
but
not
too
far
on
Wednesday
November,
9th.
A
And
the
next
item
is
that
the
steering
committee
election
is
ongoing
and
you
are
able
to
vote
until
the
30th
of
September
that
has
opened
and
is
continuing.
So
if
you
are
eligible,
please
vote
for
the
steering
committee
there's
going
to
be
four
members
that
are
going
to
be
chosen
this
cycle
and
there
looks
like
there's
eight
candidates
for
those
four
openings.
A
Okay,
let's
move
on
to
introductions
where
we
get
to
meet
our
newer,
the
the
newer
60
Liars
for
those
who
are
new
or
who
haven't
been
here
for
a
while.
If
you
would
like
to
introduce
yourself
to
better
acquaint
yourself
with
your
colleagues
in
the
Sig,
now
is
the
time
to
do
it,
and
this
is
completely
optional.
Is
there
anybody
who'd
like
to
introduce
themselves.
D
Yeah
I'll
go
first
since
I
have
some
items
today:
I'm
Alex
I
work
with
Sean
at
Google,
mostly
with
on
Sig
API
Machinery
I,
haven't
been
around
in
a
long
time.
So
some
of
you
might
recognize
me,
but
otherwise,
nice
to
meet
all
of
you.
C
Yeah
hi,
my
name
is
Sheikh
I'm
working
with
mavnir
I,
have
ideas
of
experience,
I'm,
CK
and
security
certified
yeah
nice
to
meet
you
all.
A
Yeah
sorry
about
that
I've
got
there's
some
work
going
on
and
they
just
started
making
lots
of
noise
right
now.
So
I
apologize,
but
we'll
move
on
to
the
topics
and
Alex
thanks.
D
D
D
Can
you
scroll
down
to
summary
just
let's
just
we
can
just
look
at
that
while
I
introduce
the
topic
so
yeah
me
and
Antoine,
and
some
of
the
other
six
API
Machinery
members
are
here
today
to
try
to
solve
a
pretty
large
issue.
That's
been
affecting
people
and
from
blocking
them
from
migrating
from
using
client-side,
apply
to
server
side
apply
So.
Currently,
the
documentation
directing
users
who
are
using
client-side
apply
to
begin
to
use.
D
Server-Side
apply,
directs
them
to
simply
just
call
Coupe
cuddle
apply
with
their
object
and
the
server
side
flag.
Unfortunately,
it
doesn't
really
work
like
that.
So
simply
because
of
the
problem,
that's
Illustrated
in
these
commands.
So
can
you
can
you
scroll
a
little
bit
more
so
in
the
First
Command
we
are
using
client-side
apply
to
just
create
a
simple
config
map
with
two
keys
key
and
Legacy
gets
created
successfully,
and
then,
if
we
follow
the
instructions
from
the
documentation
to
start
using
server-side
apply,
it
says
it's
successfully.
D
Server
side
applied
and
everything's
good
scroll
down
again
a
little
bit
more.
If
we
choose
again,
if
you
choose
now
to
try
to
remove
the
Legacy
key
using
server
side
apply,
the
server
accepts
our
patch,
but
when
we
print
out
the
object
again,
the
Legacy
key
will
remain,
and
this
is
because,
when
you
initially
use
that
server-side
flag,
the
API
server
will
copy
all
the
managed
fields
that
are
owned
by
client-side,
applied
to
also
be
owned
by
server
side
apply.
D
D
So
the
goal
of
this
cap
is
to
provide
a
migration
path
for
people
who
are
being
blocked
from
adopting
service
I
apply
by
this
issue.
Currently,
that's
mostly,
you
know.
Large
cluster
operators
who
have
a
lot
of
objects
to
migrate
and
their
current
only
path
would
be
to
manually
patch
their
managed
Fields
themselves,
so
yeah.
Their
goal
is
to
provide
a
path
for
this
using
possibly
a
coupe
cuddle
migrate
command.
D
If
you
can
scroll
down
a
little
bit
more
Sean,
if
you're
not
really
married
to
this
idea,
but
generally
just
a
an
operation,
users
can
run
to
migrate.
Some
client-side
apply,
manage
fields
to
now
be
used
by
server-side,
apply
a
one-time,
irreversible
patch
to
their
managed
fields
that
prepares
them
for
the
future
of
only
using
server
side
apply,
especially
now
that
it's
ga
but
yeah
this.
We
basically
just
like
this
Sig's
blessing
of
this
kind
of
change,
or
maybe
there's
some
other
ideas
for
how
it
should
surface
to
the
user.
C
Is
this
just
just
changing
the
field
manager
or
you
are
going
to
remove
the
last
applied
annotation?
Why
I'm
asking
asking
this
because
I
wonder
this
enhancements
has
effect
on
the
imperative
commands
that
does
not
support
server
cited
by,
for
example,
I'm.
Seeing
now
an
issue
related
to
the
chip
control
edits,
which
apparently
does
not
support
server-side
apply,
is.
D
So
there's
currently
an
implementation
of
this
migration
and
client
go
that
does
this
like,
if
you
give
it
an
object,
it
will
perform
this
patch
on
it
and
it
does
remove
the
last
applied
configurations.
So
client-side
apply
would
no
longer
be
possible
on
these
objects.
We
can
certainly
discuss
that
and
make
sure
that
your
use
case
isn't
blocked,
especially
could
cuddle
edit.
E
B
B
C
B
B
That
would
be
a
simpler
plan
for
migration,
because,
with
my
grade
the
fact
that
you're
adding
a
new
command
you'll
have
to
go
through
an
experimental
flow,
so
that
means
you'll
add
a
new
command.
B
The
command
will
be
hidden
under
Alpha
sub
command
and
also
only
after
a
little
while
on
the
necklace,
we
would
be
able
to
get
it
up
to
the
main
top
level
demand.
So
why
not
being
explicit
about
the
server's
thought
immediately
when
a
user
tries
it
the
first
time,
assuming
that
previous
invocation
was,
clients
are
or
basically
it
wasn't?
The
previous
wasn't
the
server
side
of
a
lot.
D
Off
the
top
of
my
head,
I
like
that
approach,
but
proposed
the
migrate
command
just
to
I,
guess
get
the
idea
across.
E
Can
I
yeah,
so
I
think
I
I
agree
with
you
in
Manchester
if
we
do
apply
inside
of
like?
After
all,
we've
done
this
migration
step.
We
should
definitely
detect
that
and
complain.
This
design
doesn't
prevent
that
from
happening.
So
we
should
do
both,
but
the
thing
is
we
can't
detect
if
the
migration
has
happened.
We
solid
state
reply
because
we're
not
supposed
to
get
the
object.
First,.
E
B
C
B
B
If
we
inject
that
information
in
the
current
flow,
rather
than
adding
additional
command
and
like
I
said
for
my
own
personal
experience,
users
will
not
migrate
if
it
will
require
third
parties
third-party
command,
because
they
will
either
delay
it
as
long
as
possible
and
they
will
still
mix
both
so
that
that
warning
should
be
there,
no
matter
which
option
we
will
pick.
B
It
should
be
there
that
oh
I
I,
already
migrated
with
the
server-side
applied
and
I
will
not
allow
it
if
I
remember
correctly,
at
least
for
the
service
that
apply
for
some
bits.
You
were
doing
something
like
that
in
the
past,
for
the
server
side
of
things
where
you
had
a
table
or
would
happen
if
this
or
that
apply
was
picked,
I
would
probably
just
copy
the
same
method
that
do
not
allow
going
back
from
server
backup
line.
You
have
to
reply
through
the
resource
or
recreate.
F
I'm
concerned
I
have
about
this
is
the
fact
that,
coming
back
to
the
pruning
conversation,
we've
had
a
few
times
in
recent
meetings.
The
printing
functionality
relies
on
that
client
side
apply
annotation
being
present,
that's
what
it
uses
to
identify
its
scope.
So
I
think
that
would
be
an
unexpected
side
effect
from
an
end
user
point
of
view
that
when
they
migrate
to
server-side
apply
suddenly
their
their
pruning
doesn't
work
anymore.
It
does
something
unexpected
on
the
next
invocation.
A
So
we
we
should,
we
should
allow
pruning
for
whether
the
server-side
metadata
is
there
or
the
last
Supply
configuration.
Is
there.
So
the
the
reason
we're
checking
for
the
last
applied
configuration
is
is
because
we
don't
want
to
prune
objects
that
have
been
created
with
Coupe
cuddle,
create
or
cuddle
run.
A
F
That's
what
I
was
going
to
say
on
time
like
if
this
would
be
a
potentially
a
change
like
if
you
had
multiple
appliers,
that
could
be
sketchy,
but
you
could
have
multiple
players
that
created
that
last
Supply
configuration
and
before
they
would
all
have
the
same
identity,
because
it's
always
classified
configuration
annotation,
that's
used,
but
in
the
new
world
that
could
be
actually
several
different,
several
different
identities
and
you
would
still
end
up
with
a
different
result.
After
migration,
foreign.
F
Since
it's
a
a
batch
like
it,
it
has,
it
inherently
is
operating
over
a
whole
set
of
objects
in
different
groups.
I,
don't
know
if
that
could
be
moved
to
the
server
side.
That
would
be
pretty
fundamental
change,
because
the
server
doesn't
sets
right.
A
A
C
A
That
yeah,
that
doesn't
matter
at
all
those
are
so
so
there's
two
separate
Concepts
that
may
be
conflated
here,
which
is
pruning
fields,
which
is
what
the
last
applied
configuration.
Annotation
is
necessary
for
for
pruning
a
field,
but
for
pruning
an
entire
object.
When
we're
applying
sets
of
of
objects,
then
it
not.
Those
considerations
are
much
simpler.
It's
just
whether
or
not
it
has
been
created
by
apply
versus
a
different
creation
command.
F
A
So
so,
okay,
so
for
for
a
pruning
operation,
let's
say
we.
We
do
the
use
the
minus
prune
flag,
minus
mice
prune
flag,
and
then
we
also
use
a
a
label
to
describe
what
the
previously
applied
set
was.
A
F
A
C
A
F
My
understanding
is
that,
like
you,
could
have
a
controller
in
your
cluster
that
uses
server
side
apply
right
and
then
that
would
also
cause
there
to
be
managed
fields
that
are
owned
by
that
controller,
hopefully
with
a
distinct
identity,
field
manager,
identity
and
then,
but
that's
not
who
I
am
in
this
operation.
I'm
I'm,
like
the
deployed
the
CI
pipeline,
a
CD
pipeline
rather
and
I,
have
a
different
field
manager,
so
I
should
not
then
look
for
objects
that
were
server-side
applied
by
a
random
controller.
F
A
A
Okay,
let's
see
what
let's
see
where
you're
going
with
that:
okay,
let's
I
put
that
there's
some
pruning
considerations.
Let's
make
sure
that
we
address
those
in
the
cap.
D
All
right,
yeah
thanks
guys,
sounds
like
for
this.
This
one
there's,
you
know
generally
support
for
the
you
know,
idea
that
we
need
to
fix
this
problem
just
need
to
surface
in
a
different
way
and
figure
out
some
of
these
dependencies
on
the
last
applied
configuration
there's
also
Kube
cuddle
edit.
That
was
mentioned
yeah
thanks,
guys,
I'll
be
off
for
this
one.
D
So
this
is
a
little
bit
I
guess
less
grave,
but
still
very
important.
We'd
like
to
upgrade
Coupe
cuddle,
explains
data
source
from
using
open,
API
V2
to
using
open
API
V3.
D
If,
like,
can
you
scroll
down
a
little
bit
more?
So
you
can
see
the
motivation
yeah.
The
reasons
for
that
I
guess
are
twofold:
open
API
V3
has
way
more
useful
data.
I
only
listed
a
couple
of
them,
because
I
think
that
they're
motivating
enough
nullable
in
default.
Being
too
ones
I'd
like
to
highlight
that
users
have
been
requesting
to
see
inside
of
their
explain,
so
you
can
see
like
what
would
be
the
default
value
of
a
field
or
if
the
field
is
nullable.
Things
like
that.
D
So
what
how
that's
manifested
with
clients
using
Coupe
cuddle
explained
is
that
if
there's
a
nullable
field,
for
example,
it
would
just
have
no
no
data
and
explain
just
be
just
say
object,
but
you
actually
I
should
include
that
in
a
cup
here,
but
the
server
will
just
elide
any
information
that
uses
open,
API
V3
features,
rather
than
represent
them,
inaccurately.
D
D
My
primary
goal
with
this
cup
today
is
to
get
some
backing
from
the
Sig
for
doing
this
change
and
get
some
advice
for
how
we
should
gate
the
feature
and
you
know,
promote
it
through
different
stages:
open
API,
v3s
right
now,
in
beta,
as
of
124.
D
D
While
we
were
looking
into
how
we
would
implement
this,
we
noticed
that
a
lot
of
the
current
explain
implementation
is
not
very
maintainable,
pretty
much
like
compared
to
F
formatting,
and
you
know
loops
and
things
like
that.
So
it's
not
very
easy
for
people
to
maintainer.
You
know
add,
updates
that
we're
trying
to
do
so.
D
We
thought
this
would
be
a
good
opportunity
to
replace
it
with
a
text
template
implementation
and
since
they
would
be
using
text
template,
maybe
it'd
be
possible
for
users
to
specify
their
own
templates,
but
that's
definitely
not
a
primary
goal
of
this
cap,
but
something
to
discuss.
C
B
Yeah,
are
you
planning?
Are
you
planning
to
maintain
both
V3
and
V2
implementations
such
that?
If
a
cluster
serves,
we
will
go
with
that
by
default,
because
it
has
a
richer
information
about
the
fields
or
for
whatever
reason,
either.
If
it's
an
older
cluster
or
the
V3
is
not
enabled,
we
will
fall
back
into
the
V2
as
a
backup
and
I'm
perfectly
fine.
B
If
that
will
be
even
up
to
the
point
where
we
have
two
separate
files
under
the
explain:
command
wants
just
for
maintenance,
maintainability
or
one
would
be
handling
the
V3
Printing
and
the
other
one
rv2
printing,
because
I
would
assume
that
you
set
its
beta
in
125.
D
B
I
would
prefer
we
do
it
smoothly
for
users,
because
they
will
not
lose
information.
It
will
be
actually
providing
more
more
information
if
the
cluster
allows
that
so
the
best
option
will
be
transparent.
Please
do
it
for
the
users
not.
D
B
Additionally,
we
can
print
that
information
somewhere
for
now
until
we
we
would
GA
that
oh
you're
across
or
it
does
not
support
V3
so
we'll
we
are
falling
back
to
B2
to
just
let
people
know
why
they
are
seeing
different
output
if
they
invoke
the
same
command
on
two
different
clusters,
but
something
along
those
lines.
Yeah
I'm,
definitely
supporter.
C
D
If
there
are
no
more
comments,
I
think
I
guess
our
questions
were
answered
for
today.
For
you
know,
general,
you
know
Sig
backing
and
such.
If
do
you
have
any
more
ideas
or
comments?
Please
leave
them
on
the
cup
and
we
can
continue
our
discussion.
There.
D
Right
so
some
of
our
thinking
with
the
templating
and
possible
user
customization
would
have
been
to
so.
We
have
right
now.
Cube
cuddle
explain,
has
a
human,
readable
output,
so
we
would
provide
a
template
that
basically
maps
to
the
human
readable
output
that
you
see
today.
D
We
are
also
thinking
of
providing
internally,
maybe
a
markdown
template
that
can
be
rendered
using
a
markdown
generator
or
possibly
users
might
want
to
provide
their
own
template
using
a
you
know:
minus
minus
template
flag
curious
what
this
sig
thinks
about
custom
templates
versus
only
allowing
built-in
templates
that
we
support
like
there's
a
lot
of
implications
with
allowing
yeah
custom
templates.
As
far
as
you
know,
you
have
to
now
support
the
interface
to
the
template
and
make
sure
that
they
don't
break
across
kubernetes
and
open
API
versions,
and
things
like
that.
E
So
one
of
the
reason
we
are
doing
that
is
because
I
think
those
various
tools
in
the
community
function
item
documentation,
file
types
and
none
of
the
tools
seems
to
be
great.
E
This
is
pretty
convenient
if
you
have
like
you,
can
have
your
own
HTML
template
and
generate
the
whole
documentation
for
your
types
in
your
own
cluster,
directly
from
control
with
like
a
one
way
to
do
that,
it's
like
it
would
be
the
official
way
of
generating
documentation
for
types.
E
Even
though
people
could
have
their
custom
templates
and
we
could
come
up
with
like
even
internally,
how
could
it
could
curl
a
HTML
template
so
that
we
have
a
default
way
of
generating
documentation
for
types,
but
people
could
customize
them
for
their
own
cloud
provider
or
whatnot,
and
we
would
have
only
one
way
of
generating
these
from
the
good
thing
is,
since
it's
coming
from
the
open
API
from
the
cluster.
It's
it's
a
pretty
common
way
to
get
the
types.
B
I,
don't
have
any
strong
objections
or
support
for
the
template.
I
I'm,
I'm,
honestly
fine
with
the
default,
but
if
we
maintain
a
default
as
is
and
I
wonder
if
we
could
somehow
split
the
cap
into
two
I'm
sure,
if
two
caps
will
be
needed
actually
but
maybe
write
it
as
one
and
then
try
to
migrate,
both
the
flag
can
be,
it
will
be,
we
will
call
it
experimental
initially
and
then
we
can
play
with
it.
It
will
be
delivered
in
126
or
a
little
bit
later.
B
B
B
G
One
of
the
things
that
would
have
been
useful
for
kui
when
I
was
working
on
the
explain
style
from
a
while
back
was
a
dash
of
Jason
kind
of
variant
where
I
would
wouldn't
have
to
worry
about
any
of
the
details
of
how
to
to
talk
to
the
API.
I
could
just
use
cucaro
for
that,
but
I
would
still
be
able
to
extract
the
schematic
level
of
information
and
then
I
can
pass
it
to
whatever
formatter
I
want.
E
Yeah,
that's
also
an
option.
We
could
have
a
template
named
raw
that
just
gives
you
the
Json
technically
but
yeah
it's
equivalent
to
doing
a
good
girl
proxy
and
then
getting
the
open,
API
directory.
So
I
this
the
value
is
low,
but
yeah
I.
Guess
we
could
do
that
and
at
least
then
we
don't
have
to
think
too
much
about
providing
the
template
mechanism.
G
C
D
A
So
we
we
put
this
next
item
on
to
revisit
the
coupe
cuddle
internationalization
that
we
started
talking
about
on
the
last
meeting.
A
And
so
I'm
gonna
ask
is,
is
Brian's
here?
Is
there
anything
else
that
we've
learned
that
we'd
like
to
to
update
this?
This
item.
H
I
haven't
had
a
chance
to
really
spend
a
lot
of
time
looking
at
it.
What
I
wanted
to
do
was
kind
of
try
to
get
a
scope
of
what
the
problem
was,
and
maybe
do
some
analysis
to
see
like
how
prevalent
are
missing
translations
and
I
didn't
know
if
there
was
like
some
automated
way
that
we
could
just
like
query
all
the
the
i18
in
calls
in
the
code
and
then
and
then
try
to
see
how
many
of
them
don't
match
up
for
a
recap.
H
This
problem
is
basically
because
we
all
the
I-18n
keys,
are
essentially
the
English
descriptions
of
things
and
when
we
change
that,
then
all
the
translations
get
broken,
and
so
the
result
is
we
end
up
with
language
translations
that
are
like
90
English
and
ten
percent
Japanese,
or
something
and
it's
just
like
not
a
great
translation
experience
or
foreign
language
experience,
so
so
I
guess
is.
H
Is
there
you
know
my
my
plan
was
to
try
to
find
some
way
to
automatically
generate
some
sort
of
report
or
something
maybe
maybe
a
script
on
in
the
in
the
hack
directory
or
something
that
people
can
run.
That
will
just
kind
of
say:
you
know,
hey,
there's
something
you
did
just
caused
a
translation
to
not
exist
anymore
and
I.
H
I,
don't
know,
if
is
that
even
actionable
I
mean
I,
don't
really
I,
don't
think
a
lot
of
people
really
think
about
the
I-18n
ramifications
of
changing
help
text
or
something
like
that
for
a
command
and
I
guess.
There's
a
bigger
question
of
what
is
our
commitment
level
to
doing
that
or,
as
Sean
mentioned,
there's
some
cncf
resources
or
Sig
docs
resources,
Maybe,
and
maybe
we
have
some
way
that
we
can
drop
something
into
a
queue
for
them
and
say:
hey.
We
just
changed
this.
H
Can
you
please
translate
it
so
so
yeah,
no
real
update
but
I'm
curious
to
know
if
anybody
has
any
thoughts
on
on
this.
B
We
have
an
option
to
send
tweets.
Kubernetes
deaf
Twitter
accounts
to
contradict
at
that
option.
I,
don't
know
where,
where
that
lives
I
think
you
just
created
for
requests
and
after
as
large
as
we
can
tweet
whatever
the
message
would
be,
how
about
a
wee
or
in
a
parallel,
maybe
on
several
places.
How
about
we
create
a
poll?
B
Do
you
care
about
internationalization
in
Chicago
or
not,
and
that
seems
like
the
best
starting
option
for
us
to
at
least
know,
because
if,
if
the
general
answer
will
be
that
nobody
cares,
maybe
we
could
start
the
deprecation
entirely
is.
If
there
will
be
users,
then
we
can
start
thinking
about
what
can
be
done
about
it.
B
I
mean
from
my
personal
experience
being
non-native,
English
speaker,
none
of
it
that
I'm
using
are
in
my
native
language,
most
often
than
not.
They
aren't
the
the
translations
are
not
accurate
enough,
so
I
rarely
use
them
at
all
it,
and
it's
just
easier
for
me
to
to
work
with
with
the
English
translations
and
whatever.
Well.
B
The
latest
text,
rather
than
translation
I've,
approved
multiple
translation
PRS
over
the
past
years,
but
there
weren't
that
many
and
I've
always
relied
on
someone
from
Ledger
geographical
area
to
know
and
to
task
to
have
the
final
attack
of
the
pr.
B
The
only
ones
that
I
actually
reviewed
supposedly
were
the
Polish
one.
All
the
directions.
B
So
the
question
is
where
we
will
be
looking
for
owners
for
those
either
is
fine,
but
I
would
probably
start
with
yeah,
with
some
kind
of
a
poll
that
overthinking
what
to
do
with
the
with
that.
Are
you
interested
in
it
at
all.
B
We
could
probably
send
it
on
multiple
channels.
We
could
send
it
to
Kate
Dev
Kate
users
announced
it
on
on
cornetti's
death.
Official
Twitter
Channel,
maybe
reach
out
to
six
country,
backs,
maybe
put
together
some
kind
of
a
blog
post
that
that
would
lay
out
the
options
that
we
currently
have
that
we're
considering
and
Link
it
from
there.
B
And
then
we
can
also
mention
this
topic
during
the
the
60i
session
that
we'll
be
holding
in
in
Detroit
in
over
a
month
and
then
just
start
talking
about
it
outside
of
only
our
internal
circles
and
learn
what
people
are
actually
doing
or
whether
they
care
about
that
bit.
B
B
F
C
Interested
so
rifle
yeah
I
just
want
to
add.
If
you
decide
to
keep
the
internationalization
like,
we
have
the
scripts,
there
called
update
translations
and
we
are
using
gnu
get
text
like
commands,
so
maybe
we
could
actually
like
update
the
script,
so
it
gives
us
a
warning
and
the
translations
change
and
which
need
to
be
updated.
So
it
should.
If
we
decide
to
have
it,
it
should
not
be
that
hard
foreign.
G
I
was
curious.
What
what's
the
desire?
This
is
going
to
be
a
naive
question,
but
for
the
extent
of
the
translations,
are
we
thinking
about
translating
names
of
resources
like
pod,
namespace
or
think
about
translating
metadata
spec,
or
is
it
more
the
surrounding
help
framework
of
the
coming
CLI.
H
Well,
I
mean
this
is
really
only
addressing
the
things
that
are
already
that
already
have
i18n
support,
which
are
things
like
the
short
and
long
description
of
the
commands.
Some
of
the
flag,
some
of
the
flags
or
most
of
the
flags
I,
think,
are
wrapped
in
the
function
call
for
I-18n
but
you're
right.
There
are
things
like
the
resource
names
and
things
that
are
just
really
Dynamic,
there's
also
things
like
error
messages
and
other
things
that
we
don't
necessarily.
H
We
haven't
necessarily
wrapped
all
those
in
internationalization
calls,
so
it's
incomplete,
as
it
is
right
now
so
I
think.
That's
all
the
more
reason
to
to
follow.
Mache's
suggestion
of
polling
the
community
and
say:
okay,
if
we're
going
to
do
this,
we
should
do
it,
do
it
well,
but
first
before
we
we
spend
the
resources
and
time
to
do
it.
Let's
find
out
if
it
how
how
important
it
is.
G
Makes
sense
we
actually
got
a
feedback
with
a
red
hat
team
and
there
was
one
of
their
QA
folks
noticed
that
an
element
of
the
UI
said
mainspace
and
they
said
oh
well,
it
actually
needs
to
be
translated
and
they
open
up
a
defect
and
they
I
said
well,
that's
we're
just
that's
just
the
name
of
a
resource
kind,
it's
and
so
anyway,
just
there's
a
there's,
definitely
desire.
At
least
at
that
level
there
was
the
QA
people
see
strings
that
are
in
English
and
it
seems
strange.
G
A
So
we
could.
We
could
revisit
this
in
every
single
future
meeting
just
to
see
where
how
we're
doing
on
this,
but
that
would
probably
be
more
successful
if
we
had
specific
action
items
which
I
don't
know
that
there
are
specific
action
items.
H
What
would
the
action
items
be?
I
know
we
have
one
with
the
with
well.
So
let's
I
guess,
let's
identify
them.
The
poll
is
one
a
block,
maybe
do
if
we
decide
we
want
to
do
a
blog
post
in
conjunction
with
that,
the
the
I-18n
channel
was
mentioned
in
was
mentioned
again.
It
was
mentioned
last
week
as
well
thanks,
Katrina
and
then
I
guess
there
would
be
just
us
asking
the
question
getting
there
getting
their
feedback
on
whether.
H
I,
don't
know
what
what
would
we
ask
them?
What
whether
we
should
attempt
translations
and
if
so,
which
translations
Which
languages,
is
that
what
what
we
would
ask
them.
H
And
language
and
well
and
then
also
like
us
from
a
more
like,
like
Logistics
standpoint
like
how
do
we?
How
do
we
keep
the
all
the
translations
synchronized
and
that's
yeah
if
they
have
any
tips
on
how
to
do
that
because
they
just
get
out
of
date
so
easily.
A
A
Specific
things
that
we're
trying
to
fix
and
or
to
to
solve
the
the
problems
being
tried
to
solve
which
yeah
it
seemed
like
I
said,
like
you
said
this,
it
feels
a
little
mushy
and
that
there's
it's
not
exactly
clear
where
we're
going
and
what's
the.
B
Problem,
maybe
we
could
start
with
draft
of
the
blog
post,
describing
what
the
current
state
is.
What
the
problems
are,
what
the
challenges
are
and
outlining
the
option
that
we
have,
and
once
we
have
that
in
place,
we
can.
B
And
out
of
that,
because
creating
the
blog
post
is
literally
as
easy
as
adding
a
pull
request
in
our
website
and
then
just
sync,
the
docs
folks,
and
that
will
be
up
and
ready
whenever
we
set
those.
So
let's
start
the
simplest
possible
way
that
and
then
try
to
promote
it
across
as
many
channels
as
possible.
Ideally
we
would
have
it
ready
the
blog
post
before
kubecon.
We
would
also
announce
that
during
coupon
and
then
we
would
ensure
that
the
blog
post
has
the
link
to
the
poll
eventually.
B
F
H
C
G
One
thing
we
could
go:
let's
say
we
could
we
if
it's
Noble,
when
we
don't
have
a
translation,
for
example
in
Slovak
or
whatever
for
mache,
then
we
could
it
made
it
appear.
You
know
to
Senator.
You
know,
please
submit
your
translation
suggestions
here.
You
know,
give
them
a
PR
link
and
send
it,
but
then
the
security.
Well,
then,
people
could
submit
whatever
yeah
who's
going
to
vet
Slovak
translations.
F
Polish,
if
we
I
I,
think
we
don't,
we
don't
really
have
that
in
place
and
that
should
definitely
be
described
as
part
of
the
blog
post
overview.
F
My
experience
with
it
personally
is
like
I
I,
think
much
of
a
references
as
well
I've
been
tagged
on
PRS
for
languages
that
I
absolutely
can't,
read
and
understand,
and
it
at
this
point
the
process
is
I.
Don't
know
like
try
to
go.
Try
to
find
somebody
through
the
syntax
localization
channels
to
see
if
we
can,
if
we
can
get
a
Community
member
who's.
F
And
ideally
I
think
mucho
said
this
earlier,
like
we
would
have
ownership
by
people
who
actually
speak
the
language
instead
of
necessarily
us
for
these
translation
files.
A
So
if
I
understand
the
consensus,
we
we
think
we
should
start
with
the
blog
post
and
with
the
blog
post,
we
can
move
on
to
a
poll
to
get
feedback
from
the
community.
Does
that
sound
correct?
And
if
so,
is
there?
Somebody
who
would
like
to
raise
their
hand
for
the
blog
post.
H
I
can
do
the
blog
post,
I
I'm,
not
I'm,
not
really
familiar
with
the
mechanics
of
how
how
the
translations
actually
work
so
I
have
to
kind
of
learn
that
a
little
bit
if
anybody
is
familiar
with
it,
maybe
I
could
pick
your
brain
on
it.
Yeah.
B
A
Thanks
yeah
I
understand
my
understanding.
Is
it's
not
all
that
involved
it's
where
we
have
the
text
which
is
surrounded
by
the
I-18
I?
Guess
it's
a
function
or
macro
or
whatever
it
is,
and
then
there's
a
separate
script
in
a
separate
directory
that
takes
these
translations
for
each
particular
language,
That
We're,
translating,
and
if
there
is
a
match
for
that
particular
item,
then
it
will
switch
it
out.
It's
it's
not
that
involved,
but
it's
it's
in
a
different
area.
It's
not
under
a
coupe
control.
H
A
H
A
Okay,
so
looks
like
we
are
over
mache
Arda.
Is
it
okay?
If
we
move
this
to
the
next
one,
or
do
you
want
to
spend
two
quick
minutes
on
the
shadowing.
B
I'll
go
with
the
two
quick
minutes
because
that
that
actually
might
require
a
cap,
and
if,
if
I
need
to
go
with
one,
then
I
would
like
to
start
sooner
than
later.
So
when
we
did
the
two
kind
of
plugins,
we
purposely
said
that
we
will
not
allow
shadowing
those
into
that,
because
that
was
the
easiest
option
for
us
to
start
with,
but
we
knew
that
there
will
be
some
options.
Some
commands
where
people
would
want
to
have
the
ability
of
the
Shadows
to
build
the
internet.
B
One
such
example
is
specific,
with
create,
especially
that,
with
with
so
many
crds
being
created
on
a
daily
basis,
a
lot
of
people
are
creating
their
own
have
crds
and
they
would
like
to
have
an
option
to
overwrite
or
at
let's
say
two
color
create
my
fancy,
crd
or
if
you
are,
and
the
question
is
what
people
feel
about
that
option
of
adding
searches
for
that
I
would
be
very
selective
about
allowing
certain
commands,
for
example,
I
would
not
allow
for
starters,
nothing
more
than
just
creates,
given
that
for
create.
B
We
have
good
examples
where
this
would
be
useful,
but
still
disallow
overriding.
The
built-in,
except
for
the
for
Creator
now,
but
we
would
always-
and
there
will
be
the
need
in
the
long
run.
We
would
be
always
revisiting
that
that
decision
and
eventually
adding
additional
self-commands,
which
would
be
taken
off
the
of
that
forbidden
list.
B
Yeah,
especially
that
a
lot
of
people
is
acting
like,
are
they
just
right?
A
lot
of
people
is
asking
about
create
subcommands,
and
we
are
very
frequently
saying:
oh,
we
don't
want
to
allow
additional,
create
supplements
because
they're
very
simple,
and
we
don't
want
to
maintain
them
if
we
would
allow
that
people
would
be
able
to
create
their
own,
create
sub
Commandments,
taking
some
of
the
burden
off
of
us
to
maintain
that
in
the
cubicle.
B
So
if
you
have
some
options,
some,
like
the
objections,
I'll
post
the
cap
once
I,
have
it
up
in
the
60i.
10
probably
will
send
it
over
to
to
our
main
language.
B
B
A
Okay,
it
looks
like
we're
about
five
minutes
over
anybody
have
any
last
last
thoughts,
yeah.
F
I
have
a
quick
one
for
for
customers.
We
have
this
on
Long
running
docs
migration,
project,
docs,
consolidation,
project
really
and
I
think
it
would
be
awesome
if
we
could
sort
of
do
a
big
push
on
that
ahead
of
kubecon
and
and
launch
the
new
site
then,
but
I
would
need
a
bunch
of
volunteers.
You
could
to
take
the
granular
tasks
so
I
without
the
information
I'm,
not
sure
if
it's
doable.
F
So
if
that
sounds
fun
and
exciting
to
you
to
try
to
get
that
goal,
and
you
would
like
to
help
out,
please
ping
me
on
slack
and
we'll
figure
out
if
we
can
coordinate
it
in
time.
A
A
F
I
want
to
know
if
there's
interest
in
doing
a
big
push,
if
I
can,
if
there
would
be
bandwidth
among
the
volunteers
interested
in
the
project,
so
I
would
really
like
to
get
it
done
and
I
think
this
could
be
a
cool
way
to
have
a
have
a
Target
together
for
launch
but
yeah.
This
is
a
project
where
I'm,
relying
on
on
community
volunteers,
foreign.
A
Okay,
great
okay,
we're
quite
a
few
minutes
over
I
apologize
for
that.
Thanks
for
joining
us-
and
we
will
see
you
in
two
weeks.