►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes SIG CLI: Intro and Updates - Eddie Zaneski, Chainguard; Katrina Verey, Shopify; Maciej Szulik, Red Hat
SIG CLI is the special interest group for the command line tooling of the Kubernetes project. The SIG maintains kubectl, kustomize, and related libraries. In this session the SIG CLI leads will provide an introduction to the SIG and an overview of how to contribute. They will share the work that's been done the past year, an introduction to the KRM Functions subproject, and thoughts on declarative vs. imperative workflows. The session will conclude with open discussion and Q&A.
A
Okay
folks,
good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are
welcome,
everyone
on
site
welcome
everyone
on
virtual.
My
name
is
mate,
and
I'm
joined
today
here
with
katrina
and
eddie,
who
are
the
coaches
of
six
cli,
we're
missing
one
person
more
who's,
our
dear
friend
and
coacher,
for
six
eli,
which
is
sean
hi
sean
if
you're
watching
this
today,
although
it
might
be
a
little
bit
late
for
you,
it's
like
middle
of
the
night
in
in
california
anyhow,
what
do
we
do?
So?
A
There
are
two
primary
things
that
we
are
trying
to
to
work
on,
which
is
adding
additional
tools
and
libraries
to
discuss
with
to
talk
with
your
kubernetes
clusters
and
we're
basically
trying
to
make
them
awesome
both
for
users
and
for
the
developers
that
are
building
on
top
of
it.
If
that's
too
vague,
that
means
we
are
building
cube,
cuddle
customize.
I
don't
think
I
didn't.
I
need
to
introduce
these
two.
A
A
bunch
of
libraries
that
you
can
all
use
and
build
your
awesome
tools,
even
better
than
cube
cuddle
is
and
a
recent
addition
which,
which
is
a
krm
functions,
which
is
basically
a
customized
plug-in
mechanism
that
katrina
will
be
talking
about
in
a
bit.
You
can
find
us
all
in
60,
like
kubernetes
slack
channel,
as
well
as
in
a
mailing
list,
and
we
also
meet
every
week
on
wednesdays.
There
are
times
depending
on
where
which
time
zone
you're
in
for
all
europeans.
A
Since
we're
in
europe,
it's
6
pm
every
wednesday
and
depending
on
the
week,
it
will
be
either
6
eli,
meeting
or
customized
or
cube
cuddle
box
crop.
So
you
can
volunteer
or
work
on
specific
bugs.
What
are
the
main
things
kubernetes
enhancements
proposal
that
we
worked
on
in
the
past
couple
releases
that
will
be
cube,
cuddle
debug,
which
is
still
in
beta,
that
helps
you
work
with
or
debug
the
problems
that
you
might
have
with
your
applications
or
containers.
A
It
heavily
relies
on
ephemeral
containers,
there's
another
proposal
that
we
put
together
just
recently
about
exit
code
normalization
where
help
we're
hoping
to
slowly
start
implementing
the
features.
If
you
have
some
ideas
about
the
exit
code,
normalization
for
ci
usage
and
so
forth,
we're
more
than
happy
to
hear
from
you
nikita
and
and
her
group
helped
with
adding
the
sub
resources
support
to
cube
cuddle.
A
So
she
worked
both
on
the
server
side,
changes
and
the
cube
cuddle,
and,
like
I
mentioned
a
minute
ago,
katrina
will
be
talking
a
little
bit
more
about
the
the
new
customized
plug-in
mechanism.
We
are.
We
also
want
to
use
this
this
meeting
today
to
call
out
several
people
who
helped
us
push
certain
major
changes
to
cube
cuddle.
A
Firstly,
katrina
who
exposed
customize
directly
and
the
cube
cuddle
version,
that's
very
useful,
because
a
lot
of
people
were
asking
frequently,
which
version
of
customize
is
embedded,
whether
you
are
directly
using
cube
cuddle
or
you
were
building
on
top
of
cube,
cuddle
and
vendoring
that
into
your
own
tools.
So
thank
you
very
much
for
exposing
that
information.
A
A
Another
amazing
shout
out
goes
to
mark
who
appeared
out
of
nowhere
and
improved
or
revamped
almost
all
of
our
completions,
and
not
only
that.
He
also
improved
the
cupcato
completions
and
he
devoted
a
lot
of
his
own
time
and
energy
into
pushing
the
changes
also
into
cobra.
So
if
your
tool
is
using
cobra
directly,
you
can
also
benefit
and
feel
free
to
shout
out
to
mark
for
his
awesome
work.
A
Manish
kumar,
who
had
a
numerous
conversation
with
me
about
the
discovery
cache
that
we
have
in
cube
cattle,
which
previously
was
being
populated
every
10
minutes.
We
bumped
that
limit
over
to
six
hours,
so
that
should
limit
a
little
bit
the
amount
of
data
that
we're
pulling
from
the
clusters.
The
additional
two
is
jordan,
along
with
the
sigoth
are
revamping
how
we're
using
secret
secrets
and
tokens.
A
They
are
trying
to
limit
the
amount
of
secret
tokens
that
we're
using,
and
so
they
introduced
a
new
api
for
requesting
tokens
and
expose
that,
under
the
cue
color
create
command
and
gently
added
a
defaulting
to
the
first
container
and
the
cube
cutter
logs
and
any
other
commands
which
are
picking
the
container
if
a
default
annotation
isn't
set.
So
if
you
don't
know
about
the
default
annotation,
if
your
pod
has
several
containers
in
it,
you
can
annotate.
If
I
remember
correctly,
that's
cube
cuddle
quantities
that
I
o
slash
default,
annotate
default
container.
A
B
Thanks
manche
so
another
thing:
that's
new
in
the
sig,
since
our
last
update
is
that
we
have
a
new
sub
project.
It's
called
carem
functions,
so
we
thought
we'd,
give
you
a
bit
of
an
intro
to
this
sub
project
and
what
it's
all
about
the
karem
functions.
Sub
project
is
based
on
a
specification
called
the
krm
function
specification.
B
It's
actually
a
very
long
document
that
you
can
go
and
read
up
on
at
the
link
below
it's
inside
the
customized
repository,
but
the
most
important
part
of
that
is
the
sentence
here.
It's
a
standard
for
client-side
functions
that
operate
on
kubernetes,
declarative
configurations,
that's
pretty
dense,
so
let's
dig
into
what
that
means
a
little
bit.
B
B
All
of
that,
the
the
and
these
functions
specifically
they're
they're
there
to
operate
on
these
kubernetes
resource
model
objects
that
might
sound
a
little
bit
like
a
controller.
But
the
third
part
is
is
a
key
distinction
here.
These
are
built
for
use
on
the
client
side,
not
on
the
server
side.
Specifically
they're
meant
to
be
chained
together
as
part
of
a
configuration
management
pipeline.
So
in
tools
like
customize
and
in
fact
this
is
actually
a
way
to
build
customized
extensions
and
also
extensions
for
another
tool
called
kept
in
the
configuration
management
space.
B
So
let's
take
a
look
at
what
this
actually
might
look
like
in
practice.
As
I
mentioned,
the
heart
of
the
specification
is
around
using
km
style
objects
on
the
client
side,
so
we're
using
them
not
just
because
that's
what
we're
manipulating,
because
what
we're
goal
here
in
configuration
management
is
to
produce
a
set
of
configuration
that
we're
going
to
deploy,
not
only
that
we're
actually
using
these
declarative
specifications
to
describe
the
operation
that
we're
going
to
do
with
our
function.
B
So
in
this
case
we're
going
to
do
something
super
simple:
we
have
our
value
annotator
kind,
and
it's
just
going
to
inject
this
very
important
data
as
an
annotation
on
all
of
our
resources.
So
this
is
our
specification
here
telling
us
what
our
function
needs
to
do,
but
on
its
own,
this
wouldn't
be
enough
for
our
function
to
do
its
work,
because
what
is
it
going
to
operate
on
right?
We
need
the
list
of
resources
we're
on
the
client
side,
so
that
actually
needs
to
be
given
to
us.
B
B
So
our
function
is
going
to
take
this
resource
list
as
its
input
it's
going
to
do
whatever
the
function
config
tells
it
to
do,
and
then
it's
actually
going
to
use
the
resourceless
kind
as
its
output
as
well,
and
that
comes
back
to
the
core
principle
of
making
these
things
chainable.
So
you
have
your
output
items
and
you
also
have
a
field
where
you
can
put
structured
results
is
one
of
the
use.
B
Cases
for
km
functions
is
validation,
so
you
might
need
a
structured
way
to
describe
the
results
of
a
validation
operation
and
that's
what
that
field
is
there
for
so
in
practice,
not
only
do
you
have
the
function
config
as
your
input,
you
have
this
entire
resource
list.
So
in
our
example,
here
we're
going
to
operate
on
just
a
very
simple
list
of
one
item.
It's
one
config
map
and
we
have
our
same
function,
config
that
we
saw
before
telling
us
to
add
that
important
data
as
an
annotation.
B
What
this
looks
like
in
practice,
it's
customized
and
kept
are
the
two
tools
that
are
driving
the
function
specification,
so
we're
going
to
take
a
quick
look
at
them
in
customized.
Specifically,
we
have,
on
the
right
hand,
side
there,
a
customization.yemel
that
is
referencing
annotator.yaml,
which
we
have
on
the
left.
It's
that
same
specification
of
what
the
function
is
supposed
to
do.
You
can
here
we
have
it
referenced
in
the
transformers
field.
B
As
I
alluded
to
a
moment
ago,
you
can
also
build
validators
this
way,
so
it
works
in
the
validators
field
and
it
also
works
in
the
generators
field.
If
you
were
creating
resources
so
customization,
if
in
your
customization.yaml,
there's
three
places
where
you
can
use
it
for
customize.
However,
you
might
notice
there's
an
additional
stanza
here
in
the
annotations
of
your
configuration
object.
B
You
have
this
config.kubernetes.ioslash
function,
annotation
that
refers
to
container,
that's
because
in
customize
we
don't
know
where
the
code
you
wrote
is
you
have
to
tell
us.
So
this
is
the
function
annotation
that
we're
using
to
do
that,
and
here
we're
pointing
to
a
docker
image.
This
is
not
super
elegant,
especially
because
the
folks
writing
the
functions
probably
aren't
the
same
ones
that
are
consuming
it.
So
we
want
to
make
this
a
lot
nicer
and
we
have
some
big
plans
around
that
area.
B
I
don't
have
time
to
get
into
all
the
details
here,
but
there
are
three
separate
caps
around
this
around
this
plan
for
making
customized
extensions
great
using
the
karam
function
specification
the
top
level
one.
Is
this
plug-in
graduation,
that's
sort
of
the
umbrella
kept
that
describes
the
overall
arching
plan
and
the
other
two
go
into
details
about
specifics
that
have
to
do
with
making
that
plan
successful.
B
So
if
you're
interested
in
customized
extensions
and
cam
functions
as
they
relate
to
that
check
out
these
caps
and
then
since
kept
is
the
other
tool
that
supports
the
specification
right
now.
I
thought
it
would
also
just
show
off
what
it
looks
here
very
similar
again,
you
have
your
configuration
object
and
you
reference
it
in,
in
this
case
a
kep
file
and
you're
also
pointing
to
the
image
that
does
the
implementation
very
similar
in
the
great
thing
about
having
an
interoperable
focused
standard.
B
Is
that
not
just
these
two
tools
but
any
other
tool
that
is
operating
on
the
client
side
and
is
in
charge
of
manipulating
some
kubernetes
configuration
very
common
task?
We
all
need
to
do
can
adhere
to
the
specification,
and
then
we
can
write
tools
that
we
can
then
share
a
km
function,
specifically
that
these
tools
can
share
to
implement
common
needed
logic.
B
So
the
subproject
of
sig
cli,
the
km
function
sub
project,
was
actually
created
to
host
the
code
for
the
new
karem
functions
registry.
This
was
also
proposed
in
a
cap.
The
idea
here
is
that
we're
going
to
have
a
6cli
sponsored
registry
of
carry-on
functions
that
are
useful
to
everybody
that
can
be
shared
amongst
the
the
tool,
two
tools
for
starters,
customize
and
kept,
but
also
any
other
tools
that
adopt
the
standard.
B
So
this
is
a
very
new
initiative,
we're
still
getting
this
spun
up,
so
that
also
means
that
it's
a
great
avenue
for
getting
involved
in
the
sig
if
you're
interested
in
the
standard,
if
you're
interested
in
the
functions,
if
you
have
a
configuration
management
tool
that
you
think
could
benefit
from
operating
this
way
come
talk
to
us.
We
would
love
to
hear
from
you
and
on
that
note
we
have
a
bi-weekly
meeting.
C
So
I
have
a
couple
more
slides
now
we
have
plenty
of
time
for
some
discussion
and
questions.
I
gotta
stand
on
the
soapbox
for
a
minute,
though,
we
have
to
talk
about
declarative
versus
imperative
workloads.
This
is
something
that
comes
up
quite
often,
and
we
just
wanted
to
give
the
community
a
reminder
about
it.
C
So
I'm
going
to
talk
about
three
different
management
techniques.
There's
a
note
that
these
management
techniques
should
not
be
mixed.
You
should
only
work
with
resources
that
were
created
and
operated
on
by
one
technique.
So
just
keep
that
in
mind.
If
you
do
mix
them,
the
result
is
undefined
behavior,
so
you
will
probably
break
things.
C
So
the
first
technique
here
is
is
when
you're
operating
with
just
imperative
command.
So
this
is
your
create,
replace,
and
so
this
is
where
you
are
manually
on
the
command
line,
interface,
doing
a
create
deployment,
dash
dash
image
and
given
in
an
image
you
are
operating
here
on
live
objects,
and
this
is
great
to
use
when
you
are
developing.
C
We
do
not
recommend
that
you
use
these
commands
at
all
when
you
are
working
with
production
resources,
so
great
for
developing.
Don't
use
in
production,
this
obviously
has
the
lowest
learning
curve,
which
is
why
most
people
jump
to
this,
but
it's
really
important
to
learn
some
of
these
other
techniques.
The
second
one
is
imperative,
object
configuration.
So
this
is
where
you
are:
writing
your
kubernetes
resource
yaml
out
to
a
file,
and
then
you
are
doing
create
dash,
f
and
replace
dash
f.
C
This
is
great
to
use
because
you
are
replacing
your
resource
in
the
cluster
completely
right,
so
it
blows
it
over.
It
paves
over
it,
but
this
is
still
actually
an
imperative
operation
and
it
will
potentially
leave
you
in
a
a
mixed
state
depending
on
what
the
resource
was
before
it
doesn't
take
into
account
anything
that
was
there
before.
If
you
had
gone
in
and
you
had
done
a
set
image,
this
will
replace
it.
If
you
had
set
an
auto
scale
manually,
if
you've
done
cube
control
scale,
this
will
overwrite
it
right.
C
C
Great,
that's
awesome,
keep
using
apply.
So
this
is
where
you
have
your
file
written
to
disk.
You
are
using
cube,
control
apply
and
it
does
a
three-way
merge
with
an
annotation
that
gets
written
to
your
object
state
in
the
cluster,
and
so
this
is
the
last
known,
applied
configuration
and
I'll
talk
about
that
in
a
second,
so
declarative
commands,
there's
only
one,
it
is
cube.
Control
apply,
please
use
cube
control
apply.
It
is
not
good
to
mix
these
commands.
Obviously,
but
this
is
what
we
want.
People
using.
C
This
is
the
best
way
to
manage
your
kubernetes
resources.
You
would
run
this
inside
of
your
git
ops
pipeline
right.
Your
state
lives
in
your
file
on
disk.
There
is
never
a
question
on
where
the
source
of
truth
is.
It
will
always
match
the
file
on
the
disk
and
the
file
in
your
cluster
and
again,
if
you
make
imperative
operations
on
that
resource,
it
will
blow
away
that
annotation.
So
your
three-way
merge
will
fail.
C
These
are
imperative
commands
who
here
uses
these
in
production
couple
folks
yeah.
So
these
are
not
ones
that
you
want
to
use
in.
Production
did
folks
know
that
cube
control.
Rollout
undo
is
a
imperative
command
yeah.
So
this
is
a
command
where,
if
you
made
a
mistake,
you
realize
during
a
roll
out
that
maybe
you
had
the
wrong
image
configured
or
production
is
coming
down.
You
would
use
rollout
undo.
This
definitely
breaks
things
because
this
will
blow
away
that
last
known,
applied
configuration.
C
We've
actually
had
an
issue
that
had
a
ton
of
community
back
and
forth
because
it
is
a
very
convenient
command,
but
is
not
one
you
should
be
using.
You
should
be
redoing
your
apply,
your
your
your
undo
should
be
a
git
revert
and
then
reapply
in
your
pipeline
right.
So
again,
these
are
the
imperative
commands
great
for
development.
Please
don't
use
them
in
production
again,
so
this
is
the
annotation
I
was
talking
about.
So
mixing
cube
control
apply
with
the
imperative
object,
configuration
commands,
create
and
replace
is
not
supported.
C
C
We
have
been
in
the
progress
of
refactoring
our
cube
control
commands.
Does
anyone
right
now
depend
on
cube
control
code
in
their
applications,
any
folks
yeah,
so
there's
currently
not
a
guarantee
that
we
won't
break
things
with
cube
control
commands.
We
provide
no
sla,
we
want
people
to
use
them
and
give
us
feedback,
but
again
we
may
need
to
refactor
a
command
and
it
might
break.
We
want
to
get
to
the
point
where
we
consider
the
cubecontrol
library
code
stable,
that
other
people
can
consume.
C
The
next
thing
we're
thinking
about
is
a
better
way
to
handle
flags,
so
structured
data,
like
kubernetes
resources,
is
not
made
to
be
represented
on
terminal
flags,
if
you
think
about
a
full
deployment
resource,
and
you
think
about
all
the
flags
that
you
would
need
to
specify
to
do
a
create
with
that.
It
is
awful.
It
is
terrible
for
maintainer
overhead
and
it's
just
not
repres.
It's
not
meant
to
be
represented
that
day,
so
we
are
trying
to
think
through
a
way
to
make
this
better.
C
For
folks,
this
really
comes
from
a
place
of
where
we
have
some
flags
for
some
create
commands,
but
not
all
the
full
fields
in
it
and
people
always
open
an
issue.
The
community
opens
a
pr
to
add
a
new
flag
and
we've
opted
to
not
merge
these
right
now,
just
because
we
really
don't
want
to
bloat
the
name,
the
flag
space
of
the
commands.
So
please
don't
take
that
personally,
don't
take
offense
to
it.
We
really
just
need
a
better
way
to
do
this
overall.
So
if
you
have
ideas,
please
let
us
know.
C
C
This
is
what
they
recommend
you
doing
if
you're
studying
for
the
cka,
whatever
it's
called,
we
want
to
find
a
way
to
take
open
api
example
data
and
help
use
that
to
create
templates
and
scaffold
it
out
files
on
the
disk,
and
so
this
is
great
for
crds,
because
crd
authors
can
specify
exactly
what
they
want
via
the
open
api
spec.
So,
if
anyone's
interested
in
working
on
that,
please
let
us
know
we
are
as
a
project
focusing
on
project
reliability.
C
We
will
not
be
accepting
prs
that
don't
have
tests
and
in
fact,
if,
if
you
are
making
a
pr
to
a
command
that
doesn't
have
tests,
we
will
push
back
and
ask
you
to
add
tests
for
the
command.
This
is
kind
of
just
a
stance.
We've
taken
as
a
project
to
you
know
not
think
in
the
future.
These
tests
will
get
added,
but
we
will
need
them
added
at
time
of
pr.
So
there's
a
reliability
bar
kept
that's
open
and
then
an
open
letter
from
a
bunch
of
us
maintainers.
C
So
again,
this
is
not
personal
to
you.
It's
not
offensive.
We
just
need
to
stabilize
the
core
as
a
product
and
make
it
more
sustainable
for
everyone
in
the
long
run.
So
if
you
get
pushback,
please
don't
take
offense.
Lastly,
we
have
a
customized
documentation,
revamp
so
shout
out
to
the
replicated
folks
go
check
out
their
booth.
They
donated
customize
that
io
and
cubecontrol.io
to
us
as
a
project.
So
we
plan
to
redo
all
the
sig
cli
documentation.
Customize
is
definitely
in
in
need
of
the
biggest
revamp.
C
C
Thank
you
so
as
a
project
we
are
in
dire
need
for
new
contributors,
folks
want
to
step
down
for
maintainer
and
lead
positions,
but
don't
actually
have
people
to
hand
off
to
so.
If
you
are
interested
in
contributing,
please
join
us
at
any
of
our
sig
meetings,
any
of
the
other
sig
meetings
you
can
find
them
all
in
the
kubernetes
community.
Repo
talk
to
your
managers.
Talk
to
your
vps,
see
if
they'll
support
you
20
times,
50
time
whatever
you
can
ask
for.
C
Please
let
us
know,
especially
if
your
company
sells
products
or
services
in
the
kubernetes
space.
So
we
really
need
some
new
contributors.
We
are
absolutely
open
to
mentor
and
bring
folks
on
as
maintainers.
We
have
mentoring,
cohorts
that
are
starting.
The
only
thing
is
we
need
a
commitment
that
folks
aren't
going
to
disappear
after
one
or
two
pr's.
That's
the
quickest
way
to
lead
to
maintainer
burnout
is
where
we're
constantly
training
new
people
and
then
they
disappear.
So
please
join
us
and
please
make
a
firm
commitment
to
help
us
out.
C
B
A
C
D
A
The
problem
that
we
currently
have
is
that
each
and
every
single
controller
was
written
by
a
different
person
at
a
different
point
in
time
and
that
led
to
the
problem
that
every
control,
every
author
just
figure
out.
Oh,
I
want
to
know
about
this
state
and
that
state,
but
there's
no
continuity
and
it's
hard
to
follow.
What's
going
on
with
everything,
every
separate
controller
we're
trying
to
somehow
unify
this.
A
This
is
both
for,
if
you're,
trying
to
build
tools
on
top
of
it,
but
also
for
new
people
debugging
if
you're,
for
example,
if
a
newcomer
and
you
start
working
with
deployments,
you'll
learn
how
to
work
with
deployments.
But
then,
if
you
switch
over
to
daemon
sets
or
stateful
sets
it's
hard,
because
the
statuses
and
the
information
provided
by
those
controllers
are
completely
different.
A
That's
what
we're
trying
to
fix-
and
this
will
help
both
users,
because,
oh
I
work
with
deployments
and
it
should
be
natural
that
I
more
or
less
know
at
least
the
general
idea
where
the
the
controller
is
at
or
what
it
is
struggling
with,
rather
than
learning
a
new
entirely,
what
the
controller
works.
Of
course,
it
won't
solve
all
the
problems.
There
will
be
always
some
intricacies
of
every
single
controller.
We
can't
share
everything
but
we're
trying
to
improve
that
situation.
A
On
the
cli
front,
we
are
pushing
towards
the
cube
cuddle
events
command,
which
exposes
that
information
and
on
the
controller
side,
we're
hoping,
through
those
events
and
statuses,
in
the
in
the
controllers,
to
somehow
improve
the
situation.
Also,
there's
a
cube,
cuddle,
debug
command
that
lee
and
a
couple
of
folks
is
helping
him.
I
was
just
recently
reviewing
pr
and
we're
hoping
to
push
this
forward
as
soon
as
femoral
containers
were
ga
we're
hoping
to
ga
debug.
So
I'm
I'm
pretty
happy
and
looking
forward
to
it.
D
C
That's
probably
going
to
be
the
best
on-ramp
is
once
we
stabilize
and
agree
on
an
interface.
We
have
a
ton
of
cube
control,
commands
that
are
going
to
need
to
be
rewritten
to
match
the
specification.
So
we
will
have
a
big
issue
tracking.
All
of
that
really
the
best
place
to
join
us
is
in
slack
or
at
our
meetings
introduce
yourself.
C
B
B
Yes,
this
actually
is
still
an
issue
in
the
latest
version.
We
don't
have
nearly
as
many
people
on
the
projects,
as
as
we
would
like
to
have
so
we're
very
open
to
various
kinds
of
contributions
and,
like
eddie
said
pointing
out
to
us
that
you
are
committed
to
learning
like
if
you
are
going
to
be
around
for
a
while,
then
we
can
mentor
you,
we
can
help.
You
learn
these
areas.
We
just
need
to
know
that
that's
the
case.
A
My
slack
is
probably
the
easiest,
but
even
then
please
do
not
be
offended
if
I
disappear
for
a
week
or
two
or
a
little
bit
longer
just
keep
on
pinging
me
I'll
get
back
to
it.
Sometimes
it
takes
me
days
weeks.
I
it
there's
nothing
personal,
I'm
jumping
between
my
professional
duties
at
red
hat
and
my
community
community
duty
duties,
like
I
mentioned
earlier
before,
I'm
responsible
for
2
6,
4,
6,
cli
and
cig
apps.
So
I'm
jumping
between
the
topics.
B
C
C
So,
yes,
pms
technical
writers
for
documentation,
you
don't
have
to
be
a
developer.
If
you
are
a
developer
and
you
don't
know
where
to
start,
you
can
just
review
prs
on
the
kubernetes
project
itself
right,
you
don't
have
to
be
a
project
maintainer
to
review
a
pr.
We
welcome
and
encourage
anyone
who
gets
the
code
to
a
higher
bar
for
us.
F
I
have
another
question:
we
have
an
arrow
which
we
occurred,
multiple
times,
which
is
related
to
sealed
secrets.
So
when
we
do
the
cubes
cubesat
apply
and
the
secret
creation
failed
through
the
controller,
the
port
cannot
be
started,
and
this
is
a
thing
we
cannot
see
when
we
apply
this,
even
if
we
have
it
in
the
in
the
ci
pipeline.
Are
there
any
plans
to
to
integrate
such
as
external
controllers,
which
are,
depending
on
the
deployment.
B
B
A
A
We
currently
pass
the
threshold
where
a
lot
of
people
is
on
on
cube
is
on
is
using
certain
tools
and
we
are
overwhelmed
by
oh.
How
do
I
debug
those?
How
do
I
learn
more
about?
What's
going
on
a
lot
of
that?
Information
unfortunately,
is
hidden
way
deep
in
the
controller
locks,
so
in
in
your
case,
that
will
be
in
the
deployment
controller
locks
and
the
only
way
for
you
to
debug
is
is
to
be
cluster
admin
or
have
access
to
the
controller
logs.
A
A
So
there
is
a
lot
of
work
around
the
structured
logging
on
the
server
side
to
simplify
and
help
with
debugging
those,
and
then
on
top
of
that
we
will
be
slowly
exposing
as
much
of
the
information
as
we
can
over
to
to
the
users
who
don't
have
that
much
of
access
to
the
cluster.
That's
the
problem
and
I'm
fully
aware
of
it.
I
see
how
my
customers
are
struggling
with
this
from
pretty
much
cli.