►
From YouTube: Kubernetes SIG Usability 20220607
Description
Brian Grant reviews kpt https://kpt.dev/
Cora Coleman shares her data from her research last summer, and next steps in her research project this year
A
A
That
he'll
do
a
deeper
dive
into
in
our
next
meeting
and
we
have
cora
coleman,
who
has
been
working
on
a
kubernetes
study
for
some
time
that
we've
sort
of
helped
her
with
in
the
past,
just
to
get
more
folks
participating
and
she's
going
to
give
us
a
little
update
and
tell
us
what
the
next
phase
of
that
is
so
to
kind
of
get
started.
Brian
was
wondering
what
the
sig
is
kind
of
interested
in
right
now,
so
I'm
going
to
briefly
share
our
jobs
to
be
done
project
plan
now.
A
This
is
something
that
we've
been
working
on
for
about
a
year
and
a
half
at
this
point,
and
so
jobs
to
be
done.
Studies
are
where
we
do
really
in-depth
interviews
of
users
of
kubernetes
to
understand
what
they're
trying
to
accomplish
what
jobs
they're
trying
to
accomplish
when
they're,
using
kubernetes
and
then
from
doing
a
synthesized,
basically
going
in
and
tagging
the
individual
jobs
that
they
mentioned
during
their
user
interview.
A
So
we
had
yeah,
they
are
somewhat
segmented
by
like
who
we
were
talking
to.
But
when
we
were
interviewing
people,
we
were
very
specific
that
we
wanted
to
talk
to
people
who
were
users
of
kubernetes,
not
builders
of
kubernetes,
because
we
were
kind
of
targeting
that
user
base
versus
the
builder
base.
A
No,
no,
these
are
people
using
kubernetes
itself,
so
not
as
high
as
the
application
layer,
but
in
the
middle
like
I
am
the
person
who's
deploying
kubernetes,
but
I
don't
actually
build.
Does
that
make
sense,
like
so
kind
of
separating
like
folks
in
upstream
from
consumers
of
upstream
I'm
building
a
platform
with
kubernetes,
but
I'm
not
like
actively
building.
A
Yeah
exactly
yeah,
so
people
who
are
in
the
guts
of
the
kubernetes
right
like
so
not
like
just
I
deploy
an
application
and
try
not
to
think
about
it,
but
not
like,
as
far
upstream
as
the
rest
of
us
yeah.
Okay,
so
we
have
so
we
have
a
couple
milestones
that
we
have
hit
and
then
I
need
to
reengage
the
folks
who
are
finishing
up
the
the
synthesis.
So
I
think
everyone
has
actually
finished
their
synthesis
and
now
we
just
need
to
pull
it
all
together.
A
So
that
is
where
we
are
right
now,
and
so
I
think
kind
of
to
answer
your
meta
point,
brian,
the
folks
who
have
been
actively
contributing
to
sig.
U's
ability
so
far
are
really
user.
Researchers
and
user
designers
and
they've
been
contributing
their
research
capabilities,
as
we've
been
doing
the
jobs
to
be
done
study
we
have
had
other
folks
come
in,
who
wanted
to
spearhead
different
efforts
that
are
more
broadly
under
the
usability
umbrella,
but
they
haven't
really
gotten
anything
going.
B
C
A
It
was
really
just
trying
to
understand
you
know,
and
this
is
sort
of
a
user
research
capability
that
we
thought
was
really
cool
because
it's
never
been
done
in
upstream
before
it's
it's
used
internally
at
a
lot
of
organizations,
but
jobs
to
be
done.
Study
done
in
upstream
had
never
been
done
before,
and
so
it
was
really
just
trying
to
understand.
As
you
use
these
tools,
what
job
are
you
trying
to
get
done?
A
Because
then
that
way
you
can
kind
of
try
and
tease
out
if
the
original
job
they
were
trying
to
get
done
is
actually
getting
done
or
not
by
the
tools
that
they
have,
and
so
that
was
really
the
focus.
I
can
dig
up
all
of
the
raw
data,
but
I
I
don't
have
it
open
on
my
laptop
right
now:
okay,
sure,
yeah,
cool
yeah.
C
A
C
Yeah
super
interesting.
I
was
wondering
about
like
what
the
jobs
to
be
done.
Do
any
of
them
also
kind
of
cover
like
because
I
know.
Sometimes
you
need
to
get
familiar
with
the
tool
that
you're
using
or
to
accomplish
a
job.
You
need
to
kind
of
like
familiarize
yourself
with
kubernetes
a
bit
or
the
tool
you're
using
so
did
that
at
all
come
up
in,
like
I
guess,
like
onboarding
or
training
at
all,
like
for
these,
for
these
users
and
the
resources
they
use
to
do
that.
A
Yeah
yeah,
so
here
I
think
this
is
I
don't
I
actually
not
totally
sure
which
are
public
and
which
or
not.
But
let
me
share
this
link
with
you
so
just
to
be
transparent.
My
co-chair
was
driving
this
and
she
recently
stepped
down
for
maternity
leave.
So
that's
why
I'm
a
little
like
that.
But
here
is
the
project
plan
that
we
worked
on
together
and
you
can
kind
of
see
here.
The
questions
are:
who
are
the
main
users?
A
A
So
this
is
like
your
ideal
process
flow
and
then
looking
at
how
I
define
locate,
prepare,
confirm,
execute,
monitor,
modify
and
conclude,
and
then
we
want
to
find
out
like
kind
of
what
you're
trying
to
dig
to
is
like
what
was
their
desire
like
when
they
started
on
this
journey.
What
is
actually
the
desired
outcome
of
all
of
this
and
then
kind
of
then
phase
two
is
what
we're
trying
to
kind
of
dive
into
now.
A
So,
like
phase
one
is
functionally
complete
and
now
what
we're
really
trying
to
do
is
get
into
the
phase
where
we
can
quantify
opportunities
using
user
data.
So,
for
example,
back
up
with
like
using
the
desired
outcome,
statements
and
typing
questions,
we
can
create
this
survey
that
you
know
right
now.
We've
just
done
12,
deep
dives.
This
would
be
something
you
can
send
out
to
like
100
plus
people
and
get
to
like
how
important
it
is
that
the
desired
outcomes
we
uncovered
from
the
more
in-depth
study
are
achieved
to
a
wider
group
of
people.
A
A
And
we've
done
a
couple
sort
of
deep
dives
at
our
kubecon
sessions
over
the
past
couple
years,
where
there's
one
where
carl,
who
was
a
user
researcher,
I
think
initially
at
red
hat
and
then
he
was
at
apple
and
now
he's
moved
on
to
a
new
role.
I
think
at
facebook-
or
maybe
it
was
the
other
around,
but
this
is
kind
of
what
he
does
all
day,
and
so
he
really
helped
us
define
it
from
the
quantification
perspective
and
the
data
driven
analysis.
A
And
then
we
had
a
bunch
of
user
designers
who
had
never
done
a
jobs
to
be
done.
Study
who
are
sort
of
so
carl
put
together
an
entire
presentation
on
how
to
do
the
nuts
and
bolts
of
the
actual
jobs
to
be
done,
job
analysis,
and
so
that's
what
folks
have
been
following
as
they
get
onboarded.
That
being
said,
we
have
wanted
to
sort
of
verify
people
before
we
give
them
access
to
the
data
just
because
it
does
have
personal
stuff
in
there.
A
B
B
All
right,
so
I
think
I
shared
a
window
be
wrong,
but
yeah,
and
what
we're
building
is.
This
is
the
prototype.
Configuration
is
data
which
allows
us
to
programmatically
manipulate
configuration
and
it's
kind
of
native
kubernetes
yaml
form
more
or
less
and
the
interesting
thing
about
it
is
it's
not
manipulating
the
data
in
the
kubernetes
api
server.
The
way
you
know
most
wire
tools
do
like
cube
control,
the
kubernetes
dashboard
and
so
on,
but
actually
manipulating
the
data
in
storage.
B
So
our
this
is
about
a
version
that's
about
a
month
old,
but
you
know
what
I
have
here
is.
It
shows
git
repositories
that
are
registered.
We
have
a
blueprint
repository
in
what
we
call
a
deployment
repository
and
just
like
you
could
create
kubernetes
resources
through
the
kubernetes
dashboard
or
some
other
dashboard
or
ui
for
kubernetes.
B
We
can
actually
create
blueprints
and
deployments
from
those
blueprints,
so
you
can
actually
create
repeatable
deployments.
Multiple
variants
of
a
deployment,
much
like
you
could
with
configuration
tools,
so
the
alternative
is
to
use.
You
know
one
of
the
hundred
or
more
configuration
tools
that
exist
for
kubernetes
like
helm
or
customize,
or
cdk
desk
or
starlard
doll,
queuing,
etc.
B
And
you
know
what
people
do
is
they
write
those
files
by
hand
because
they're
in
code-
or
you
know
some
kind
of
templates
code
like
format
you
know,
so
what
those
end
up
looking
like.
Hopefully,
you
can
see.
This
is
something
like
this,
so
this
is
a
helm
template
for
a
roll
binding
or
actually
for
an
arbitrary
number
of
role
bindings
that
can
be
specified
in
the
values.yaml
file.
B
B
You
know
so
even
the
the
simplest
object
in
kubernetes
is
the
name
space
and
even
that
can
look
pretty
complicated
to
be
able
to
specify
you
know.
Here's
an
example
of
a
conditional
for
you
know.
If
there
are
labels
specified,
then
insert
all
the
labels
here.
You
know
you
can
also
get
into
examples
that
do
yaml,
formatting
and
quoting-
and
things
like
that,
so
it
can
get
even
more
complex
than
this.
I
will
note
that
you
know
this
doesn't
have
annotations
in
it.
B
So
if
you
wanted
to
add
annotations
to
your
namespace,
you
would
have
to
go
edit.
This
template
before
you
could
add
the
values
to
your
values.yaml
file,
and
that's
pretty
common.
I
find
is
that
users
often
can't
just
be
consumers
of
configuration
templates.
They
end
up
having
to
be
authors
of
the
configuration
templates
because
there's
something
that
they
need
from
the
template.
So
here's
an
example
of
defaulting
and
quoting,
for
instance,
you
know,
there's
something
they
need
that
wasn't
actually
specified
in
the
templates
itself,
so
they
need
to
go
edit.
B
The
templates
and
add
you
know
the
new
attribute
they
need
or
the
new
field
they
need
before.
They
can
add
it
to
their
values.yaml.
Now
values.yaml
is
in
a
format
that
could
be
machine
edited.
Potentially
it's
a
nested
map,
which
is
a
pretty
simple
format.
It's
convenient
for
merging
different,
multiple
values.yaml
files.
B
B
B
B
Ux
kind
of
techniques
you
can
imagine
in
a
traditional
ui,
you
could
do
in
these
ui,
it's
built
in
a
pretty
straightforward
way,
happens
to
use
backstage
because
we
thought
that
would
be
interesting
to
the
platform
building
audience,
and
this
is
a
using
useful
platform
kind
of
mechanism.
Service
catalogs
backstage
has
service
catalogs.
This
is
kind
of
a
special
purpose.
B
B
And
say
that,
and
you
know
pretty
much:
every
namespace
also
needs
a
role
binding.
So
we
can
add
that,
and
we'll
say
this
will
be
a
namespace
for
an
app
team,
so
it
will
be
owned
by
the
app
admin
and
we'll
refer
to
a
cluster
role
of
type
admin
or
name
app,
admin
and
we'll.
But
we'll
bind
that
to
a
group
that
has
a
name
of
a
form
that
is
a
convention
decided
by
the
platform
team.
So
we'll
just
call
this.
B
For
for
the
group
now
we
could
look
at
the
yaml
and
people
who
are
familiar
with
kubernetes
might
want
to
do
that,
but
we
never
actually
have
to
look
at
the
ammo
and
again
this
is
kind
of
a
rudimentary
ui
that
you
can
imagine.
You
know
providing
a
little
bit
more
step-by-step
guidance
here.
So
we'll
just
say
that's
and
we
can
save
that
to
the
blueprints.
B
B
B
B
B
B
B
The
packages
the
blue
print
I
created
was
written
to
get
so
our
we
have
a
backend
that
we
call
the
package
orchestrator
that
interacts
with
git
and
can
create
packages,
update
packages,
delete
packages,
create
derived
packages,
update
those
packages
from
drive
from
the
original
upstream
package
and
so
on,
and
you
know,
because
we
have
a
service
doing
this-
you
can
do
it
through
ui
or
through
other
automation
tools,
and
we
had
we
actually
built
a
prototype
before
we
started
building
this.
It
also
supported
bulk
upgrades,
for
example.
B
So
if
I
created
50
name
spaces
from
the
one
blueprints,
we
could
update
them
all
automatically
if
we
change
the
base
blueprint
so
yeah.
The
idea
here
is
again
just
kind
of
getting
away
from
manual
editing
of
these
text
files
and
going
through
the
the
git
process
you
know
is
basically
you
need
to
fork
the
original
git
repo
or
create
a
branch
make
your
edits,
commit
them
tag
them
push
them,
get
that
pull
requests
reviewed
and
merged.
A
I
know
and
then
sometimes
it's
right,
where
it
always
was
and
you're
like
how'd
you
get
over
there.
I
have
that
happen
too
cool.
Thank
you
so
much
for
going
over
that.
It
reminds
me
a
lot
of
some
designs
we
did
when
we
were
working
on
vsphere
with
tanzu
a
couple
years
ago,
so
I
think
it
definitely
resonates
with
the
with
the
personas
that
you're
looking
at
there.
B
B
The
workflow
yeah
we
just
assumed
people
would
want
to
do
review
and
approval.
So
we
added
a
rudimentary
review
and
approval
workflow,
but
it
can
really
be
whatever
people
want.
You
could
have
more
automated
checks
and
and
bypass
approvals
if
it
passes
the
automated
checks,
for
example,
you
can
do
pre-deployment.
Validations
of
various
kinds
you
can
do.
Versioning
gonna
do
is
something
we
should
be
able
to
show
next
month.
B
A
B
B
B
Instead
of
so
one
nice
thing
about
this
approach,
I
think,
is
the
work
can
be
amortized
over
a
lot
more
packages
because
it's
really
specific
to
the
resource
type
more
than
specific
to
the
package,
so
here
we're
making
it
really
easy
to
create
new
blueprints
for
ins,
for
instance
at
least
that's
the
goal.
So
if
you
wanted
to
create
a
blueprint
for
something
else,
you
just
need
to
create
new
editors
in
the
ui
for
the
resource
types
and
new
transformation
functions
to
perform
the
kind
of
customizations
that
you
need
for
those
types.
B
B
A
Yeah,
but
I
think
it's
super
interesting
approach.
It
reminds
me
a
lot
of
the
design
work
that
we
did
when
we
were
designing
for
vi
admins
versus
kubernetes
platform
teams,
because
the
the
vsphere
admins
really
want
a
ui,
and
then
you
also
want
to
have
the
ability
to
edit
the
yaml
for
the
super
user.
So
I
think
your
approach
makes
a
ton
of
sense
and
having
it
all
backed
up
by
version.
Control
is
like
clutch,
so
yeah.
B
B
You
know,
for
example,
I
talk
to
a
customized
user
who
is
automatically
generating
all
their
customization.yaml
files,
so
they
already
built
additional
automation
to
do
some
similar
kinds
of
things
or
you
know
like
if
I
want
to
just
install
a
home
chart
that
I
didn't
even
write,
it's
a
process
where
you
know
I
may
need
to
fork
it
and
maintain
that
fork.
So
then,
I
need
to
create
another
branch
with
patches
over
over
the
original
version,
and
then
I
need
to
create
my
own
values.yaml
file
and
so
on.
B
A
Yeah
yeah,
the
folks
that
we
interviewed
were
very
aware
of
it
and
frustrated,
so
it
was
definitely
like
they.
They
felt
pretty
comfortable
just
sharing
with
us,
like
you
know,
just
kind
of
learning
the
ecosystem
and
getting
everything
running
and
then
keeping
up
with
the
tooling
and
the
changes
and
the
upgrades
like
they
were
struggling.
So
I
I
definitely
think
yeah
you
see
a
lot
of
that.
A
A
C
C
C
Okay,
so
last,
this
is
a
research
project.
I
started
last
summer
as
part
of
an
internship
with
the
ibrahim
hybrid
cloud
research
group,
and
so
we
looked
at
different
preferences
that
cloud
developers
had
and
we
tried
seeing
if
these
preferences
aligned
with
different
tasks
that
they
did
like
if
they'd
prefer
to
use
different
tools.
C
They
were
working
on
different
type
of
tasks.
So
we
looked
at
three
different
types
of
tests.
We
looked
at
crud,
debugging
and
monitoring,
and
we
asked
our
participants
what
kind
of
tool
modality.
So
if
it
was
a
cli,
something
purely
textual
or
something
with
a
bit
of
graphics
like
like
an
ide
or
a
web
console,
and
we
asked
them
if
they
prefer
to
use
that
according
to
a
different
task,
and
so
there's
a
lot
of
yellow
here.
C
So
a
lot
of
people
did
say
that
they
preferred
to
use
the
cli
for
crud
and
debugging
and
less
so
for
monitoring.
But
a
lot
of
people
then
said
web
console
for
monitoring,
but
this
was
surprising
to
us
because
graphics
are
super,
useful
and
but
and
clies
don't
really
incorporate
that
a
lot,
and
so
it's
kind
of
like
where,
where
does
this
fit
into,
how
it's
helping
people
accomplish
their
tasks
like?
Where
did
those
features,
because
they
clearly
are
important
when
it
comes
to
something
like
monitoring?
C
So
where
did
these
features
fit
in
so
in
prior
work?
We
haven't
found
a
lot
of
this
was
a
survey
so
in
prior
surveys
that
we
were
looking
into.
None
of
them
really
asked
about
developer
preferences
as
they
vary
by
the
type
of
tasks
that
they're
working
on.
So
we
looked
at
kind
of
the
cncf
surveys,
this
red
hat
openshift.
C
You
working
on
different
programming
tasks,
but
not
necessarily
different
types
of
programming
tests,
just
kind
of
like
easier
programming
tests
and
then
more
challenging
ones.
I
think
they
were
working
on
different
algorithms,
maybe
and
then
so.
We
wanted
to
help
address
scap
with
a
two-part
study
where
he
did
like
the
survey
where
we
looked
at.
You
know:
developer
preferences
across
different
tasks
and
then
deep,
diving
a
bit
more
into
a
comparative
user
study
where
we
had
people
working
on
these
tasks
and
different
tools.
C
C
How
does
the
programming
task
impact
developer
tool
preferences
and
how
does
the
modality
impact
tool
preferences
and
we
did
a
developer
survey
where
we
recruited
60
participants
through
the
ibm
research
groups
through
sig
groups
like
this,
like
usability
and
also
cli
tasha's
help
on
linkedin,
we
recruited
people
and
we
asked
them
questions
about
their
level
of
kubernetes
experience.
How
frequently
they
worked
on
these
types
of
tasks
and
their
preferred
modality,
and
we
found
that
they
frequently
work
on
multiple
types
of
tasks
a
day.
C
There
wasn't
a
clear
majority,
but,
as
you
can
see,
a
lot
of
a
lot
of
intermediate
experts
work
on
crud
tests,
many
types
of
many
many
times
a
day,
but
also
monitoring
tasks
many
times
a
day,
and
so
that
was
also
interesting
just
to
try
and
understand
you
know
what
are
the
most
relevant
tasks.
So
I
think
that's
why.
The
job
study
is
really
interesting
too,
because
you
guys
are
all
kind
of
discovering
like
what
are
what
are
the
real,
their
everyday
tasks.
C
People
are
working
on,
and
that
was
something
that
we
really
wanted
to
to
better
understand.
We
didn't
find
a
lot
of
examples
out
there
when
we
were
constructing
when
we
were
developing
our
deeper
dive
study.
We
were
thinking
of
a
task
to
have
people
to
do.
We
wanted
to
know
what
what
they
were
most
frequently
doing,
and
you
know
that
does
impact
the
the
from
I
guess
more
of
a
designer's
perspective.
I
worked
with
nick
mitchell,
who
is
who's
a
reason,
shirt
ibm,
I'm
not
sure.
C
And
so
then
we
moved
on
and
did
a
bit
of
a
like
a
deeper
dive
with
a
comparative
user
study,
and
it
was
very
small
and
in
our
survey
results
we
only
had
60.
we
would
have.
We
would
have
liked
to
have
more
and
part
of
what
we're
doing
this
summer
is
we've
rewritten
the
survey,
and
we
would
like
to
get
more
responses
and
we've
added
a
few
more
questions
in
it
too,
just
to
get
some
more
data
just
to
iterate
on
it
a
bit
and
improve
it.
C
So
we
recruited
participants
through
the
ibm
research
groups
and
also
through
the
sig
usability
groups
and
cli
and
or
no
sorry.
This
is
for
the
for
the
comparative
study,
my
bad
too
fast,
so
for
a
comparative
study.
It
was
just
these
four
participants
from
the
ibm
research
groups
and
we
had
them
complete
a
kubernetes
task
where
they
created
a
list
of
pods.
C
They
found
a
keyword
in
the
logs
and
then
they
deleted
the
deployment,
and
they
did
this
task
using
the
cli
and
using
the
openshift
console,
and
we
we've
recorded
their
kind
of
their
thoughts.
We
had
them,
do
you
think
aloud,
as
they
were
completing
the
task.
A
lot
of
people
said.
Oh,
I
know
there's
a
faster
way
to
do
this
with
the
cli.
C
They
couldn't
quite
remember
the
command
that
they
needed
to
quickly
accomplish
the
task,
so
they
had
to
do
it
if
they
had
to
expend
a
bit
more
effort
in
repeating
some
commands
instead
of
having
a
more
succinct
command.
Also
had
some
post
study
survey
questions
so
what
tool
did
you
prefer
to
use
all
of
them
all?
C
C
You
know
it's
not
a
lot
of
conclusions
to
be
drawn
just
more
of
a
kind
of
a
proof,
a
proofing
for
us
to
like
go
through
this
and
see
if
these
metrics
make
sense
for
a
see
if
the
task
makes
sense
for
to
to
repeat
later
on
more
broadly
so
and
then
in
future
work
we're
finding
our
survey
to
be
because
our
survey
initially
wasn't
vendor
neutral
either.
We
had
suggestions
for
like,
for
example,
this
is
what
a
cli
is
but
to
be
published
on
the
kubernetes
website.
C
It
needs
to
be
vendor
neutral,
so
making
it
that
and
then
publishing
our
original
survey
data
and
then
including
the
the
refined
survey
and
then
in
future
work.
This
is
going
to
be
part
of
my
part
of
my
dissertation
at
ucsd,
where
I'm
a
phd
student
right
now,
so
we're
going
to
be
working
also
with
the
anonymous
project
at
ucsd.
They
they're
like
a
super
computer
center.
That
is
big
on
kubernetes,
which
is
great
for
me,
because
I
can
go
and
do
some
interviews
with
them.
C
I
would
really
like
to
do
more
like
deep,
dives
and
interviews
with
kubernetes
developers
and
understanding
their
everyday
work,
and
also
continuing
with
the
hybrid
cloud
group
at
ibm,
and
then
kui
is
the
project
that
nick
is
working
on
too.
So
curry
is
kind
of
like
a
graphical
cli,
so
it
has
some
some
aspects
of
the
ui
and
some
aspects
of
the
terminal
whereby
you
know
if
you
list
something.
If
you
have
a
command
to
list
your
files,
you
can
then,
like
click
on
the
the
list
of
files
that
it
outputs.
C
C
And
so
maybe
using
these
findings
to
inform
that
that
redesign,
if
possible,
yeah
but
I'd
I'd,
be
really
welcome
any
like
feedback
or
if
anybody
has
input
on
like
similar
studies
that
have
been
done.
I'd
be
really
interested,
and
I
just
like
appreciate
your
time
and
the
space
for
this,
and
I
appreciate
tasha's
help,
of
course,
and
helping
us
get
the
word
out
on
this
study.
Yeah.
A
C
B
C
No,
I
mean
I
it's
interesting,
because
you
would
have
thought
that,
like
a
lot
of
the
beginners
would
have
not
preferred
the
cli,
so
we
only
had
like
five
beginners
give
us
responses
and,
like
all
of
them
didn't
say
they
preferred
this
year.
All
of
them
said
they
preferred
the
cli,
which
is
kind
of
strange.
It's
it's
like.
What
do
you
mean
that
has
the
steeper
learning
curve
than
a
more
graphical
tool?
You
would
have
thought
that,
like
that
I
mean
it
just
like
yeah,
so
that
was
a
surprising
finding.
C
B
A
C
Yeah,
I
think
that's
really
interesting,
because
yeah
definitely
a
lot
of
like
different
companies.
They
they
have
different
tool
sets
and
they
they
they
onboard
people
with
different
things
and
something
that
we
also
want
to
look
into
is
like
how
like
how
do
people
learn
to
use
these
tools
like
what
kind
of
resources
are
you
are
you?
A
C
C
B
C
C
B
You
know,
sort
of
as
part
of
the
platform,
so
it'd
be
helpful
to
clarify
some
of
those
kinds
of
things
and
they're
a
bunch
of
new
tools
since
2018,
like
all
the
get
ops
tools
were
very
nascent
in
2018,
so
they
weren't
widely
used
and
now
they're
a
lot
more
widely
used.
So
I
think
it
could
be
interesting
to
redo
this
survey
just
see
what
you
know,
how
much
has
changed.
C
Totally
one
of
the
questions
we
added
was
about
automation
like
for
credit,
debugging
monitoring
in,
in
addition
to
which
modality
we
added
an
option
just
to
just
use
automation
at
the
end,
we
asked
them
what
technologies
they
use
for
automation,
because
that
might
be
your
element
but
yeah.
Thank
you
so
much
for
this
feedback
and
you
had
some
good
feedback
on
the
like
clarifying
like
the
like,
segregating
the
tasks
more,
could
you
like
explain
that
a
little
bit
more,
please.
B
Yeah
and
segregating
by
role
so,
for
example,
a
platform
builder,
may
you
know,
write
operators
or
find
cube
control
plugins
to
install
or
you
know,
assemble
a
set
of
tools
from
the
ecosystem
or
write
their
own
to
fill
the
gaps
and
kind
of
glue.
All
that
together,
you
know
they
use,
like,
I
said,
terraform
to
stamp
out
clusters
and
components
in
those
clusters.
B
You
know
so
that
they
have
a
set
of
tasks
that
they're
trying
to
do
to
create
a
reproducible
platform
for
all
the
different
environments
they
have
to
manage
for
their
application
teams.
You
know
so
they
may
worry
about
multi-tenancy
in
kubernetes,
or
you
know,
backup
and
restore
and
those
kinds
of
things,
whereas
app
teams.
B
They
also
are
the
you
know
own
their
own
clusters
entirely.
You
know
they
are
probably
more
focused
on
application,
delivery
right
so
like
ci,
cd
and
helm,
and
dealing
with
the
kubernetes
resources
for
service
and
ingress
and
deployment
and
and
those
kinds
of
tasks
that
they'll
be.
You
know
releasing
and
deploying
and
promoting
across
environments.
B
C
B
C
Yeah,
that's
really
great.
Thank
you
so
much
for
mentioning
that.
We
have
like
one
of
the
things
that
we
added
to
the
survey
too
is
like
what's
your
job
role,
so
that's
definitely
like.
It
builds
on
that,
but
I
really
like
also
about
the
task
too,
like
what
is
your?
What's
your
goal
so
yeah,
what's
the
task
that
you're
primarily
working
on
so
thank
you.
C
B
A
B
One
last
quick
question
that
occurred
to
me
has
6
ccli
expressed
any
interest
in
ux
help.
You
know,
there's
a
mention
that
people
couldn't
remember
the
cube
control
syntax
or
that
they
found
it
unintuitive,
I'm
probably
to
blame
for
some
of
it,
but
the
designing
command
line
tools
is
very
different
than
designing
a
graphical
user
interface.
B
In
terms
of
the
you
know,
techniques
to
be
bring
to
bear,
and
actually,
since
kubernetes
started
nine
years
ago,
other
you
know
more
modern
clis
have
you
know,
introduced
techniques
that
weren't
common
back
then.
So
I
yeah,
I
just
wonder
if
it
might
be
worth
exploring
ways
that
we
could
improve,
keep
control,
compatibility
or
usability
compatibility
is
an
issue
for
some
automation,
but
there's
probably
things
we
could
do
for
people
who
are
using
it
interactively.