►
From YouTube: Ops Section AMA - Configure
A
B
B
You
don't
have
to
spend
your
sick
time
on
teach
me
the
first
one
is
what's
next
and
why
so
I
came
at
this
I'm
familiar
with
the
kubernetes
space.
I
I
attended
the
first
cubicle
and
I
still
have
the
bag
fond
memories
of
it
and
it's
come
a
long,
long
way
flow
and
and
all
the
other
things,
but
I
still
had
a
little
bit
of
a
hard
time
understanding
from
a
user
perspective.
B
Why
a
feature
would
be
valuable
when
I
was
reading
the
what's
next,
I
understand
the
feature,
but
I
would
I
would
ask
you
to
like
focus
on.
The
here
is
the
pain
point
you
have
with
the
alternative
mechanism,
and
this
is
what
we
saw,
because
that
will
hopefully
invite
more
conversation
to
you
towards
you
from
everybody
inside
and
outside
gitlab,
on
your
direction
page.
So
it's
just
a
small
suggestion
and
then.
A
The
second
one
was
just
a
net,
so
happy
everyone
for
so
thanks
for
the
feedback
yeah
you
mentioned
kubantas
here.
I
can
imagine
that
this
is
the
situation
everywhere.
So
we'll
check
it.
That's
one
thing.
The
other
thing
is
that,
do
you
have
any
specific
place
where,
where
you
even
miss
the
y
and
and
you
would
like
us
to
to
tell
it
or
it's
enough,
if
you
do
it
in
the
direction
page.
B
So
what
I
am
encouraging
every
pm
is
like
in
even
in
the
issues
like
this,
the
y
is
less
prevalent
than
the.
What
and
I
think
like
articulate
like
that.
Here
is
the
pain.
If
you
didn't
have
this
feature
and
then
the
reason
is,
it
will
be
super
helpful
for
solution,
architects
or
marketing
people
just
to
take.
B
In
general,
I
see
that
I
mean
there
are
some
good
examples
too.
So,
like
I
think,
plan,
if
you
look
at
plans
direction,
page
I've
seen
really
good
callouts,
where
this
is
what
we
are
doing
and
a
y
sentence,
which
is
pretty
clear,
and
it's
so
clean
that
you
know
sales
solution
architect
can
just
cut
and
paste
it
in
their
conversation
with
the
customer.
So
it's
helpful.
B
A
C
C
Is
we
have
these
additions
that
you
can
make
to
your
pipeline
that
generate
a
report
about
code
quality
and
then
it
shows
in
the
merge
request,
diff
any
changes
to
code
quality
today
you
know
if
a
user
wants
to
do
that,
they
have
to
go
kind
of,
follow
the
instructions
and
add
that
to
their
ci
email,
adding
something
like
auto
code
quality
would
say.
If
you
turn
autodevops
on
that
would
just
be
a
part
of
devops.
Auto
devops
would
also
include
in
auto.
C
C
B
C
Pretty
early
it's
pretty
early
one
of
our
there's
another
issue.
I
can
send
you
that's
about
autodevops
adoption
that
many
of
the
team
members
here
are
very
familiar
with
where
the
pattern
we've
seen
is
that
product
managers
of
other
groups,
despite
this
group
ownership
model,
don't
consider
adding
things
to
auto
devops
to
be
a
high
priority
because
they
don't
actually
see
usage
from
it.
C
So
we
want
to
change
that,
but
this
status
today
is,
I
think,
if
you
asked
james,
you
know
like
what
is
the
first
iteration
for
auto
devops,
adding
code
quality
to
auto
devops.
I
think
auto
code
quality
is
already
there,
but
something
new
that
he
wasn't
doing
like
auto
usability
testing.
Let's
say
he
would
say
I
don't
really
that's
not
my
robot.
It's
not
an
important
thing
that
drives
usage
for
me.
B
In
competitive
landscape
we
say
that
there
are,
you
know,
leading
players
with
best
piecemeal
solutions
that
offer
a
particular
stage.
I
was
just
wondering
if
we
have
some
that
we
look
at
and
say:
oh
they're
doing
this
well
in
their
stage,
and
let
me
just
give
some
more
context
for
the
reason
you
know
we
did
this
netflix
video,
where
we
looked
at
how
netflix
is
doing
publishing
and
we
compared
that
to
pages
now.
B
I
know
the
much
broader
use
cases,
but
we
also
through
that
process
discovered
some
good
usability
things
we
can
do
in
pages
like
low
hanging
fruit.
That
will
just
help
our
pages
customer.
So
I'm
wondering
if
we,
if
we
have
identified
those
players
and
what
they
do
well,
that
we
want
to
incorporate.
A
Yeah,
I
would
say
that
first
of
all,
today
was
not
one
of
our
focus,
so
we
were
not
updating
it
recently.
The
the
direction
page.
One
thing
that
I
wanted
to
mention
here
is
the
heroku.
Clearly
we
always
describe
all
to
devops
as
a
heroku-like
experience
for
all
the
gitlab
features
and
even
in
cd,
we,
we
fall
short
on
this
nikolas,
just
typing
hashicorp
waypoint
waypoint,
which
was
released
a
few
months
ago,
and
we
we
mentioned
it.
We
had
a
call
with
kenya
by
that
once
so.
C
C
I
think
I
would
categorize
her
answer
as
about
auto
deploy,
which
is
that's
what
heroku
does
well
that's
what
hashicorp
does
well,
but
our
like
auto
sas
scanning
is
a
whole
different
set
of
competitors.
What
we're
really
doing
in
autodevops
is
combining
what
we
would
say
is
the
prescriptive
best
way
to
run
your
ci
pipeline
into
one
process
that
can
smartly
choose
based
on
what
your
code
looks
like
to
make
the
right
decision,
but
it
spans
the
whole
platform,
maybe
except
for
plan.
D
All
right
there
was
a
video
created
recently
by
someone
in
the
ux
group
I'm
trying
to
find
it
now,
but
it
was
comparing
kind
of
the
initial
onboarding
experience
of
revo
and
github
to
repo
and
git
lab,
and
the
github
experience
was
very
much
here's
some
out-of-date
vulnerabilities
and
automatically
create
mrs
and
basically
just
done
it
at
you
know
initially,
whereas
our
experience
was
a
little
rougher,
so
he
wasn't
able
to
get
the
security
standing
up
and
running
for
reasons.
I
I
don't
know
christy.
If
you
know
I
I.
E
A
E
A
E
B
A
E
D
Exactly
what
will
be
the
next
step
there?
I
guess
one
point
I'd.
Make
too,
is
that
I
think
at
gitlab
we're
very
good
at
kind
of
breaking.
You
know
creating
teams
that
have
a
clear
charter,
and
you
know
they
drive
a
gmail
metric
that
that's
a
very
natural
motion
for
us,
in
other
cases,
where
stuff's
more
cross-cutting
and
I
put
on
devops
in
that
category,
the
incentives
get
a
little
bit
strange
right.
You
know
what
you
could
look
at
it
from
the
configure
team's
point
of
view
say
well.
D
If
they
really
want
to
drive
gmail,
you
know
things
that
are
very
specific.
To
configure
are
going
to
help
that
more
than
say
a
cross-cutting
experience
that
is
kind
of
unifying.
You
know,
gitlab
and
driving.
That
type
of
adoption
like
that
would
be
a
may,
make
sense
strategically
at
the
company
level,
but
I
think
our
teams
aren't
set
up
that
way
with
metrics.
So
that's
one
thing
we've
been
thinking
about
too,
is
like:
how
do
we?
What
what
are
the
right
metrics
to
draw
or
kpis
for
auto
dev,
ops,.
C
Yeah
one
of
the
things
we
talked
about
in
the
vision,
the
like
business
value
of
auto
devops,
is
that
it
would
singularly
drive
stages
per
user
right,
because
if
you
get
somebody
to
turn
on
autodevops,
you've
just
turned
on
five
stages
for
them,
but
yeah.
We
don't
have
a
structure
for
saying,
that's
why
we
should
prioritize
this
capability.
Within
a
specific
group,
we
used
to
have
a
whole
group
just
for
auto
devops
and
we've
since
disbanded.
It.
C
B
About
it
as
well,
I
think
one
of
the
I'm
glad
you
brought
this
up
sam,
because
one
of
the
things
that
if
he
had
a
measurable
metric
for
auto
devops
and
then
we
said
hey
a
particular
team-
is
really
only
accountable
for
that
particular
metric.
Then
I
I
hope
that
that
bursts
through
our
sort
of
single
threaded
ownership
model,
because
then
now
you
have
the
ability
to
you
have
to
move
ado,
and
you
will
do
what
you
think
is
right
for
it.
B
If
it
still
requires
contributions
from
other
teams,
one
model
that
fabian
is
working
on
and
I'm
sure
some
of
you
are
aware-
is
he's
created
some
contribution
architecture
for
on
jio
and
I'm
sort
of
excited
to
see
that
roll
out
and
see
if
that
sort
of
model
works
for
some
use
cases
where
here
is
a
canned
sort
of
framework
on
how
you
contribute
to
it
and
makes
it
easy
for
you.
It
makes
it
easy
for
the
other
team.
D
B
A
Thanks,
unfortunately,
we
don't
have
data
by
that
we
are
just
implementing
a
bit
better
metrics,
it's
still
not
mobile
based
at
all,
but
to
have
at
least
metrics
to
know
that
which
templates
are
used
and
how
often
they
they
are
used,
because
everything
that
you
see
in
periscope
today
is
actually
from
gitlab.com
yeah.
But
given
the
kubernetes
focus
of
after
devops,
it's
it
might
not
be
the
our
users
might
be
actions.
We
don't
know.
A
Yeah,
it
was
based
on
past
assessment,
so
I
already
inherited
the
category
as
such
and
user
research
was
only
added
later,
I
would
say,
there's
actually
one
use
case
where
I
would
concentrate
viable,
which
is
when
the
templates
are
not
looked
at
as
a
product,
but
it's
a
set
of
best
practices
that
others
can
can
build
their
own
templates
on,
and
this
is
the
way
I
see
our
social
architects
present
out
of
the
hooks,
quite
often
as
well
from
product
point
of
view.
I
would
say:
it's
not
viable.
G
That
being
said,
if
auto
devops
is
more
important
and
we
think
that
it's
it's
more
of
a
driver,
a
business
driver
for
us-
that
is
a
conversation
we
could
also
have
now.
I
want
to
also
say
that
does
not
mean
that
this
is
the
only
cross-product
research
effort
that
we
can
do
in
fiscal
year
22,
but
we're
at
least
trying
to
get
something
where
we're
like
hey
as
product
and
ux
teams.
We
are
aligned
around
like
this
is
a
thing
that
we
have
to
know
about.
C
Yeah
thanks
for
that
chrissy
I
will
flop.
I
feel
like
we
need
to
get
like
a
new
talked
about
the
contribution
architecture
and
the
kind
of
what
team
is
assigned
aligned
before
we
would
make
that
request.
Just
as
a
clarification
is
that
outside
of
the
kind
of
ux
research
prioritization
that
we're
already
doing
directly
with
lori
and
andre
who
are
assigned
or
is
that
in
replacement
of.
G
It
all
comes
from
the
same
bucket
right,
okay,
there's
only
so
many
people
to
do
the
work,
so
I
think
more
than
anything
this
is
saying
like
hey.
This
is
something
that
we
as
leadership
teams,
think
is
something
that
is
so
important.
We're
going
to
say
now
we're
going
to
prioritize
this
thing
and
then
adam
will
work
with
the
product
leadership
team
to
figure
out.
Okay,
where
do
those
resources
come
from?
How
do
we
iterate
on
it,
because
we
don't
have
to
do
it
all
in
one
chunk?
You
know
we
can
do
it
over
time.
D
Just
to
add
to
that
there
is
a
lot
of
overlap
between
the
things
you
said
upgrades
and
signups,
and
you
know
that
kind
of
user
growth
metrics
and
at
least
what
auto
devops
could
be,
is
something
that's
kind
of
a
you
know,
helps
you
maximize
your
usage
and
expand
that
and
kind
of
shepherd
you
in
best
practices.
So
anyway,
I
see
a
connection
there.
I
can
see
those
dovetailing
well
together.
C
You
pointed
out
to
me
something
that
I
think
is
important,
that
I'll
just
verbalize
for
you
but
like,
but
when
you
joined
autodevos,
was
a
really
compelling
portion
of
why
you
joined
gitlab,
because
it
is
a
big
vision
for
what
it
means
to
be
a
single
devops
platform
and
we've.
Definitely,
I
think
it
was
our
2018
funding
round
that
we
made
a
big
deal
about
how
we
were
going
to
do
this
other
devops
thing.
C
It
was
going
to
make
devops
easier,
like
our
platform
was
just
going
to
automatically
do
it
for
you
and
we've
definitely
de-prioritized
that
effort
and
I
think,
at
some
expense
to
our
expansion
to
of
users
to
other
stages.
So
it's
important
to
me
that
we
pursue
this
vision.
We
need
to
figure
out
how,
at
the
moment,.
B
B
Are
we
ready
to
go
to
it
yeah,
so
cluster
cost
management?
I
have
a
lurking
sense.
I'm
not
really
sure
if
I
don't
have
enough
data
to
prove
it
yet
that
our
users
may
be
let's
say
a
large
enterprise
may
pay
us
500
000
for
gitlab,
but
their
ci
cd
pipelines
cost
us
cost
them
10
times
of
that,
and
so,
if
we
can
save
them
even
10.
B
E
A
A
We
have
a
really
truly
minimal
solution
here,
which
means
that
we
have
documentation
to
deploy
an
application
called
cubecost
and
that
application
its
features
and
provides
promises
metrics
and
with
the
gitlab
metrics
dashboard.
We
can
reach
those
metrics
and
show
it
to
the
user
that
these
are
your
course.
C
And
I
think,
from
a
runner
perspective,
the
general
answer
is
no:
most
of
our
users
aren't
attaching
their
kubernetes
cluster,
even
if
they
were
using
a
kubernetes
cluster
to
scale
runners
aren't
attaching
that
to
gitlab.
So
if
I
were
to
say,
where
are
we
answering
the
question
of
how
are
you
optimizing,
the
usage
of
your
runner
fleet?
That's
actually
in
runner
enterprise
management
that
darren's
working
on.
B
A
A
B
C
I
have
the
last
question
and
this
is
to
all
three
of
you
nicholas
victor
and
maria
there's,
a
lot
of
breadth
in
configure,
there's
a
lot
of
places
where
we
could
go,
but
you
seem
to
have
found
success
like
going
to
very
deep
and
identifying
user
problems
and
then
tackling
those
directly.
I
think
of
like
the
education
that
all
three
of
you
did
for
the
team
to
get
on
board
with
terraform
and
then
kubernetes
agent
and
now
we're
talking
about
secrets
management,
just
wondering
victor
and
the
team.
A
What
we're
doing
now
is
we.
We
want
a
lead
engineer,
let's
say
who
who
leads?
These
initiatives
will
be
tiger,
probably
who
gets
to
know
the
code
base
gets
to
know
the
product
and
we
start
shipping
features.
While
we
are
learning
really
our
user
base
and
they
they
need,
and
we
don't
have
a
vision
there.
Yet,
at
the
same
time,
so
we
I
intend
to
build
it
up
during
the
next
two
months,
as
we
know
more
and
we
get
more
feedback.
A
D
A
These
are
still
there,
so
this
is,
you
can
think
about
this
as
deep,
but
these
are.
This
is
actually
breadth.
These
are
three
separate
directions.
Inside
in
such
as
code,
we
have
have
a
fourth
one,
which
kind
of
integrates
these,
which
is
a
infrastructure
automation
where,
on
the
ui,
you
can
do
stuff,
but
I'm
not
sure
you
want
to
follow
along.
Instead
of
focusing
on
other
areas
like
plastic
cost
management
or
who
knows
what
we
come
by
then.
E
E
That
has
probably
some
pre-existing
knowledge
that
they
can
seed
in.
You
know
utilize
and
they
kind
of
dive
in
and
explore
it
maybe
do
a
poc
and
then
try
to
understand
the
opportunities
from
the
technical
side,
and
then
we
leverage
a
lot
of
cross
training.
We
try
to
cycle
people
in
to
different
projects,
so
there's
not
a
lot
of
siloing
of
information
and
as
well
like
when
that
starts
to
happen,
there's
a
kind
of
a
network
effect
of
people
seeing
opportunities
between
the
different
product
areas.
So
we
can
start
to
build.
E
Like
kind
of
these,
you
know
build
features
that
link
together
and
support
each
other.
I
think
that's
where
we're
headed
really
when
we
look
at
the
terraform
features
in
addition
to
the
agent
we'll
be
able
to
build
a
lot
of
things
off
of
that,
and
then
also
we
leverage
pair
programming
a
lot
so
there's
again
that
kind
of
cross-training
that
can
happen
in
those
contexts.
F
Well,
from
my
perspective,
considering
our
kind
of
low
adoption,
not
for
terraform,
but
at
least
for
the
agent
I'm
trying
my
goal-
is
to
reach
out
other
stages
and
see
how
we
could
inject
ourselves
in
their
user
journeys.
So
it
could
be
a
seamless
experience,
at
least
on
the
upside,
maybe
from
the
dev
side
as
well.
But
so
that's
my
long-term.
C
C
Kenny,
you
know
sorry,
I
said
thanks
for
that
time,
but
I
also
want
to
say
thank
you
to
the
three
of
you
nicholas
maria
and
victor.
I
consider
the
agility
in
the
configure
group
to
be
like
a
model
that
we
want
other
groups
to
follow
so
that,
like
ability
to
identify
a
problem,
go
deep
on
it
and
shift
the
whole
group
to
a
new
one
is
a
really
amazing
capability
that
you've
all
created.
So
thank
you
for
that.
Every
single
you're
thinking.