►
From YouTube: Cancel manual roll out based on Alerts discussion
A
A
A
A
But
that's
it
like
major
alerts,
don't
and
at
some
point
we
would
want
the
users
to
manually
configure
what
they
want
the
trigger
to
be
because
even
critical
alerts
it
may
be
too
general
and
maybe
there's
specific
critical
alerts.
They
want
to
stop
the
pipeline
and
specific
ones
that
they
don't
care
as
much
right.
A
Also,
it's
very
important
to
say
that
the
alerts
have
to
be
for
a
specific
environment,
because
different
environments
have
they're
just
different.
The
interest
in
them
is
different,
so,
for
example,
if
I'm
doing
a
deployment
to
my
development
environment,
I
really
don't
care
if
there's
an
alert
there,
I'm
sorry
to
say
that,
but
that's
the
truth
and
then,
when
I
go
up
into
staging,
I
care
a
little
bit
more,
but
the
one
that's
the
most
interesting
is
production.
A
So
I
think
as
if
we
want
to
do
an
automatic
way
to
do
that,
which
is
not
this
issue.
We
would
probably
start
with
critical
alerts
on
production
or
unprotected
environments,
but
this
specific
issue
says:
okay,
now
we're
not
going
on
an
automatic
approach,
but
the
user
is
now
in
the
environment
page.
They
see.
Something
is
wrong,
and
now
they
want
to
do
something
about
it.
They
want
to
stop
right
or
roll
back.
Those
are
the
two
options,
so
that's
kind
of
like
an
overview
of
what
what
we're
trying
to
accomplish
here.
C
A
C
C
And
then
this
channel
gets
her
notification
from
the
problem
sales,
and
this
is
very
generic
workflow
that
actually
gitlab
sres
does
the
same.
They
have
a
production
channel
and
like
there
are
many
bunch
of
notifications
like
this.
So
imagine
that
you're
in
you're
one
of
the
series
and
then
look
at
that
alerts,
and
then
you
see
this
critical
log
right
and
open
it.
C
C
C
C
C
A
C
A
C
Yeah,
so
this
is
something
we
are
lacking
in
environment,
page
index
page
today.
You
have
no
idea
if
the
if
a
development
pipeline
is
running
or
not
so
sorry
needs
to
visit
here
like
oh,
it's
a
success.
The
latest
implemented
success,
which
means
there
are
no
ongoing
running
deployments.
So
there
are
nothing
to
stop
right.
So.
A
C
C
A
C
C
They
don't
know
about
incidents,
it's
a
matter
of
ops,
ops
guide,
so
they
don't
care
and
then
create
a
modular
guest
and
then
maintainer
merges
that
without
noticing
the
ongoing
instance.
Then
it
runs
a
pipeline
new
diplomatic
pipeline
right,
okay
and
then
new.
It
gets
a
new
deployment
and
there's
a
risk
condition
that
it
sorry
wants.
A
rollback
developer
wants
to
create
a
new
deployment
right
and
then
so.
These
are,
you
know
it's
basically
dangerous
operation,
like
operators
doesn't
want
any
developers
to
deploy
dwelling
like
they're
doing
the
roadblock
stuff.
A
C
Yeah
yeah
yeah,
so
it's
which
is
the
issue
but
so
yeah
again.
Even
if
operators
can
stop
the
current
running
deployments,
it
doesn't
mean
that
they
can
prevent
for
a
future
deep,
deep
limit.
So
this
is
a
second
concern
in
this
issue,
so
how
we
can
prevent
the
future
deployments,
for
example,
as
an
ops
operators,
we're
trying
to
roll
back
right
so
visit
the
environment
deployment
page
and
then
what
do
you
enroll
back
putin.
C
B
I
I
don't
have
too
much
to
add,
but
I
do
think
that
the
two
problems
you
highlighted
are
the
ones
that
I
fall
over
as
well
into
finding
the
solution.
Yes
or
no,
because
it
is
like
like
we
are
we're
spearheaded
or
focused
at
like
stop
a
deployment,
but
stopping
deployment
does
not
fix
the
problem.
The
problem
is
you,
as
a
user,
want
to
do
something
about
this
alert
in
your
production
level,
environment,
right
whatever
that
is
it
automatic
rollback,
rollback,
stopping
an
environment
that
does
that
is
all
solutions.
B
It
is
about
us
finding
the
right
solution
in
there
and
there's
two
problems:
stopping
us
right
now.
That
is
one.
We
cannot
see
whether
deployment
is
in
progress
and
b.
Stopping
a
single
deployment
doesn't
do
anything
because
there
is
will
be
a
future
rollout
that
will
create
a
new
deployment
that
will
override
that
race
condition
right
like
do
you
say
that
right,
like.
B
A
A
A
The
second
thing
that
I
think
we
need
to
do
is
at
the
moment
only
handle
the
the
sre
point
of
view
and
not
the
developer,
even
though
there
could
be
a
race
condition.
We
can
solve
that
later
and
and
there's
a
bunch
of
issues
that
you
opened
up.
That
will
also
probably
solve
that,
like
the
like,
deploy
freeze
during
an
incident
would
will
solve
a
problem,
the
problem
of
a
developer,
trying
to
deploy
when
there's
an
incident
going
on
right.
A
A
So
so
going
back
to
the
sre
person,
one
of
the
things
that
you
highlighted
and
it's
a
really
good
point-
is
that
the
sre
may
be
looking
at
the
slack
channel
and
not
necessarily
going
to
the
environment
page
where
they
can
actually
take
some
action
as
phase
one.
I
do
think
we
do
need
to
add
something
to
the
environment
page
and
then
phase
two
would
be
add
a
link
from
the
incident.
But
before
creating
the
link,
we
actually
need
to
create
the
action.
B
A
A
It's
a
fair
question
and
the
answer
is
that
you
can't
generalize
the
entire
persona
into
one
workflow
and
at
least
as
part
of
the
user
research
that
we
did
looking
into
this,
a
lot
of
the
people
were
saying
when
they
look
in
production,
they
look
at
the
environment,
page
first,
the
environment
dashboard.
They
look
at
you
know
some
kind
of
overview.
A
A
A
B
B
I
have
I
have
some
doubts
in
terms
of
like
solution
validating
this,
because
I
think
if
we
would
implement
this
solution
on
its
own
and
then
like
isolating
this
out
in
terms
of
like
a
solution
validation,
I
don't
think
we
would
ever
get
a
positive
result
out
of
it,
because
it
has
not
yet
become
part
of
the
flow
of
our
sres
unless
we
make
it
so
like
unless
we
give
enough
incentive
towards
the
user
to
say
all
right.
The
environments
list
is
super
helpful
to
you
like
you.
A
A
I
want
to
go
back
to
the
user
research
part
and
and
maybe
go
back
on
what
I
said
about
the
sres.
So
the
starting
point
from
the
research
was,
you
have
an
incident
in
production.
What
do
you
do
now?
Who
needs
to
be
involved?
Who
needs
to
take
action?
What's
the
flow
right?
That
was
what
I
was
asking:
the
users
and
and
what
they
told
me
was
a
you
know.
There's
different.
The
different
environments
have
different
levels
of
people
that
you
need
to
report
to,
and
people
that
are
have
actually
access
to
it.
A
Everyone
gets
notified,
so
it
could
be
slack,
it
could
be
email,
it
could
be
an
sms.
Whatever
people
know
that
something
is
going
on
and
then
and
then
whoever
has
access
will
take
immediate
action
in
order
for
the
production
issue
to
be
solved
as
quickly
as
possible
and
when
I
say
solve
as
quickly
as
possible,
it
could
be
a
hotfix
which
means
you
know.
A
So
drilling
down
is
also
a
really
nice
question
to
say
what
do
you
mean
by
drill
down,
because
some
people
will
look
at
the
environment
dashboard?
These
are
people
who
are
not
necessarily
sres.
This
will
be
the
release
manager,
the
product
manager,
someone
who
just
wants
to
look
at
production,
and
then
they
see
that
it's
all
red
and
then
they
get
like
really
hysterical
and
start
calling
on
people
on
the
phone
and
then
there's
people
that
are
going
to
go
into
the
logs
and
try
to
figure
it
out.
A
So
it's
very
very
different.
I
do
like
the
incidence
response
approach
where
we're
saying:
okay,
we're
starting
from
slag
slacklinks.
Just
to
the
alert
the
alert
looks,
it
links
us
to
opening
up
an
issue
or
viewing
the
one
that
exists
and
then
taking
action
from
there.
However,
when
we
look
only
on
a
alert
specific
alert
few,
I
kind
of
feel
like
we
lose
context
of
the
environment,
which
is
super
critical
here,
because
different
environments,
you
know,
have
different
metrics
and
different
alerts
that
are
interesting.
A
A
B
B
It
is
interesting
that
devs
has
a
certain
different
flow
like
what
I
get
from
your
story,
which
is
super
valid,
but,
like
I
like
there's
a
lot
of
assumptions
is
there
a
way
that
we
can
potentially
test
that?
That
is
indeed
the
way
that
we
want
users
to
potentially
drill
down,
or
that
is
part
of
their
flow
that
they
want
to
look
at.
You
know
the
alert
specific
page
and
they
lose
context,
slash
or
missing.
That
contact
like
I'm
feeling
like
we're
we're
trying
to
move
somewhere,
but
it
is.
B
A
C
C
A
C
A
There's
a
dashboard
I'll
send
a
link
for
it,
but
I
also
talked
to
jackie
about
the
fact
that
once
we
have
alerts
in
the
environment,
page
it'll
be
propagated
to
the
dashboard,
which
is
like
really
cool
because
it
may
it
colors
the
the
environment
red.
You
know
that
you
need
to
handle
something,
and
it
gives
you
a
lot
of
added
value
of
what
you
can
do
there.
C
C
B
C
C
A
A
I
went
into
the
slack,
I
saw
a
message:
there's
a
cpu
over
95
percent.
Now
it's
very
minimal
information
that
I
haven't
slack,
so
I
click
the
link
it
opens
up
in
gitlab
I
get
to
that
general
page,
yeah
and
then
and
then
so.
This
is
even
a
step
after
the
first
step
was
I
got
to
this
very
general
page.
That
said
view
thank
you
shinya
yeah
there.
So
I
got
here
now
this.
C
A
Very
minimal-
I
can't
do
anything
from
here.
I
the
first
thing
that
I
would
do
is
open
an
issue
right,
and
this
is
the
button
that
you
see
on
the
top.
It
says
view
issue
because
she
already
did
it
so
your
view
issue
and
all
the
data
that
I
had
from
the
alert
is
copied
into
this
issue
and
it
gets
assigned
to
someone
to
handle
okay
now
without
touching
this
flow,
we
want
to
add
a
link
here
or
even
in
the
previous
step
that
lets
you
take
action
on
right.
B
A
A
rollback
or
something,
but
it
needs
to
link
somewhere
and
shenya
in
the
beginning
of
our
conversation,
had
suggested
that
this
links
to
the
environment
page,
where
we're
going
to
add
that
action.
Now,
I'm
okay
to
discuss
revisiting
it
and
adding
a
different
length,
like
maybe
the
deployments
page.
A
B
B
C
A
Sounds
really
really
powerful
dimitri,
but
it
sounds
really
really
complicated
and
something
that
we
can
probably
accomplish
in
many
many
milestones
ahead.
I'd
like
to
break
break
this
down
to
what
we
can
get,
because
if
we
can't
even
figure
out
alerts
per
environment,
finding
out
an
alert
per
deployment
would
even
be
more
complicated
now
tying
into
which
monitor
is
already
working
on
and
already
has
like
some
kind
of
support.
They
have
annotations
that
they're
adding
to
to
their
dashboard
charts.
A
A
B
A
The
way
that
I'm
thinking
of
it
hopefully
someday
yes,
because
that
would
be
like
super
powerful.
It
would
be
amazing
you
could
even
see
like
with
which
version
ruined.
You
know
the
performance
of
the
behavior,
which
would
be
awesome,
but
the
way
that
I'm
seeing
it
is
you
have
a
lot
of
developers
applying
and-
and
you
know
the
metrics
they
they
happen,
all
the
time,
they're
being
pulled
all
the
time.
It's
really
hard
to
to
point
your
finger
and
say:
okay,
this
specific
degradation
happened
because
of
this
merger
question.
C
B
A
C
C
Not
only
diplomats
like
deploying
a
bad
code
is
not
only
reason
but
also
like,
for
example,
some
external
service
is
had
an
incident,
for
example
like
a
gcp
gcp
had
a
production
incident
and
then
of
course
your
infrastructure
is
affected
yeah
and
then
you
got
a
tons
of
alerts,
but
there
are
nothing
you
can
do
right
and
then,
of
course,
your
diploma
is
unrelated
at
all.
So
in
this
case
you
don't
want
to
roll
back
at
all.
C
It
is
impossible,
I
I
don't
think
so.
Sometimes
it's
tangled,
like
even
any
deployment
gitlab
case,
we're
still
like.
We
need
to
investigate
at
first
like
what's
wrong
in
our
code
or
like
something
different.
We
need
to
spend
like
sorry.
I
need
to
dig
into
that
problem,
so
it's
impossible
to
automatically
deduct
it
or
maybe
even
so,
like
it's
going
to
be
your.
I
don't
know
unreliable
feature
so.
C
Yeah,
it's
very
good
idea.
Yeah,
I
100
percent
agree
with
it
so,
like
even
like
you
know
overview,
we
can
see
your
environment
right
in
the
link
like
we
have
no
idea
like,
for
example,
we
have
two
environments
right
staging
the
production.
Can
you
say
that
which
environment
is
really
due
to
do
this
arts?
No
right,
so
we
want
to
see
something
here,
the
it's
relative
to
production
or
it's
ready
to
do
staging
or
none
of
them.
B
In
that
case,
I
would
say
that
if
we
make
the
link
from
an
alert
to
an
environment,
if
that
is
there,
if
that
is
existing,
then
it
would
also
make
sense
to
be
able
to
loop
back
and
navigate
back
from
the
environments
page
towards
the
alerts
page
in
that
way
validating
the
original
idea
of
the
other
issue
right.
The
other
issue
of
alerts
shown
on
the
environments
page
and
then
this
the
other
way
around,
but
we're
losing.
On
the
other
hand,
I
would
say
like
all
right:
we
got
this
down.
A
B
A
At
for
this
first
iteration
we're
not
going
to
let
them
choose,
oh,
unless
we
go
to
the
deployment
page
where
you
can
choose
whatever
you
want
to
roll
back,
but
the
way
that
I
was
envisioning
this-
and
this
is
something
that
I
also
validated
during
research.
Was
people
just
want
to
go
back
to
the
last
successful
deployment?
A
They
don't
want
to
select
the
version.
It's
a
feature
that
spinnaker
has
that
you
can
select
the
version,
but
every
single
person
that
I
asked
told
me
they
always
go
to
the
previous
successful
deployment.
They
don't
ever
go
backwards,
so
we
may
explore
that
in
the
future,
but
I
don't
think
that's
part
of
the
nbc
in
any
way.
B
C
The
thing
is
that,
as
you
said,
it's
hard
to
figure
out
which
one
it
is
stable,
latest
stable,
like,
for
example,
this
deployment
run
for
a
week
and
no
users,
no
android
users
figured
out
that
there
is
a
bug,
but
it
could
rebuild
at
the
the
next
week.
So
it's
very
it's
really.
You
know
challenging
to
label
what
is
a
later
stable
thing.
C
A
The
reason
is,
there's
always
going
to
be
a
bug.
There's
no
such
thing
as
a
bug-free
version,
but
the
more
you
go
away
from
what
you
have
currently
in
production,
the
the
more
you're,
far
away
from
master,
which
makes
it
even
more
complicated.
We
don't
want
to
try
to
go
into.
You,
know,
conflict
and
resolving
you
know,
code
that
came
out
and
that
you
need
to
take
out.
So
I
think
it's
simpler,
just
latest
green,
regardless
of
how
long
it's
been
sitting
there.
Different
companies.
A
B
A
B
B
B
A
A
B
A
I
think,
but
even
for
the
kubernetes
use
case,
we
still
need
to
really
be
really
clear,
saying
that
something's
running
it
should
just
show
the
same
thing
as
the
pipeline
right.
It's
just
the
same
icon
like
when
you
see
an
emerge
request
that
it's
you
know
the
pipeline's
running.
Probably
something
of
that
of
that
sort.
B
B
A
We
can
work
on
the
new
issue.
First,
that's
okay!
In
any
case,
the
first
issue
that
we're
working
on
is
even
before
this
is
just
showing
the
alert
in
the
environment
page
itself
without
taking
any
action,
so
this
one
should
follow
anyway.
What
we
didn't
discuss
in
the
nine
minutes
that
we
have
left
is
that
the
icon
that
you
you
suggested
here,
which
is
a
frozen
icon
like
the.
B
Moment
if
we,
if
we
have
an
action
on
the
an
environment
list
page,
so
that
is
like
that
issue
is
now
in
some
way
not
like
it's.
It
doesn't
mean
anything
more
anymore
like
I,
I
purposely
made
it
look
awful.
So
it's
a
wireframe.
It
is
not.
It
is
not
a
design
intended
to
be
final
or
like
anything
more
than
an
idea.
C
I
think
the
current
deployment
freeze
feature
is
a
bit.
It
is
too
specific
to
the
the
the
purple
cell.
It
should
be
a
very
generic
that
you
know
even
like
a
lot
of
didn't
happen.
Maybe
they
want
to
freeze
at
some
occasion
so
like
a
freeze
deployments
or
I
don't
know
whatever
like
lock
deployments
kind
of
thing
look
environments
feature
should
be
like
an
independent
future
right
and.
A
B
I'm
perfectly
fine
with
that.
I
had
no
intention
to
say,
like
I
was
just
like
all
right.
This
is
a
freeze,
let's
put
on
some
icon,
to
show
something,
but
it
once
again
says
like
all
right.
I
should
just
put
it
in
words
ideally
and
then
we're
going
from
there
anyway,
like
just
to
come
back
real
quickly
on
the
issue
like
we
have
the
cancel
rollouts.
A
A
New
issue
so
the
way
that
I'm
seeing
it
is
we
want
to
go
from
every
direction.
We
want
people
to
stop
clicking
around.
That's
that's
the
idea,
I'm
an
sre.
I
have
a
problem.
I
want
to
get
as
quickly
as
pro
as
possible
to
the
problem.
The
way
that
we're
doing
it
now
is
you
need
to
open
the
incident
now.
You
need
to
link
to
something
from
the
incident
which
will
go
probably
to
the
environment
page,
which
will
make
you
point
on
the
deployment
page,
which
is
really
annoying.
A
It's
an
annoying
user
flow,
so
whatever
we
can
do
to
shorten
that
cycle
is
better.
So
if
an
sre
starts
from
the
incident,
I
would
try
to
point
at
the
deployment
page
directly
from
there
and,
if
we're
starting
from
the
environment
page,
then
I
would
start
from
there.
I
think
there's
two
different
starting
points
and
I
think
they're
both
valid.
A
C
I
don't
think
there
are
two
start
points
as
long
as
I
see
the
gitlab's
sres,
they
always
start
from
slack
or
something
very
responsive,
place,
a
service
and
like
chat
service,
and
then
they
started
digging
into
the
environment's
details.
So
I
do
not
think
that
they
constantly
look
at
the
environment,
page
or
environment
dashboard
and
then,
like
an
environment.
Page,
is
a
great
place
to
take
an
action
right,
stop
lock,
environments
or
robux.
Whatever
things
they
can
take
user
can
take
there,
it's
yeah.
These
things
should
be
in
environment,
page.
B
B
B
B
Three
minutes:
four
minutes
all
right
so
after
this
is
done
after
we
have
a
navigation
item
like
we
have
a
like,
we
can
see
the
alerts
in
the
environments
page.
We
can
link
from
the
alerts
page
to
the
environments
page
and
now
we
still
want
to
give
the
users
like
a
like,
even
better
way
to
act
on
their
alerts
on
their
environments
right.
That
is
the
idea.
A
So
the
logical
next
step
is,
is
the
two,
the
three
actions
actually
there's
three
two
or
three
accents:
oh,
that
was
scary,
so
the
first
action
that
we
first
of
all.
I
also
want
to
remind
you
that
this
is
for
manual
action
and
we
still
have
another
issue
for
automatic
action.
Okay,
so
we
put
that
aside
and
now
we're
talking
about
someone
manually
taking
action
so
manually
taking
action.
A
One
of
them
would
be
to
roll
back
redeploy
a
previous
pipeline,
so
what
we
want
to
do
is
make
it
really
really
easy
for
a
user,
seeing
an
alert
either
press
a
button
that
does
that
for
them
directly
from
the
environment
page
or
make
them
through
go
through
the
extra
step
of
going
into
the
deployment
page,
which
is
less
preferred
by
me.
But
if
there's
any
concerns,
then
we
can
talk
about
it.
So
that's
one,
the
second
action-
and
this
is
also
divided
by
non-kubernetes
and
kubernetes,
so
for
regular
deployments
that
are
non-kubernetes.
A
A
C
How
should
I
say
that
it's
it's
very
generic,
it's
just
like
all
about
pipeline
definitions
and
language
of
diplomatic
jobs
are
simply
the
part
incremental
role
or
percentage,
and
then
they
get
it's.
Only
just
deployment
target
is
kubernetes,
but
ideally
it
should
be.
It
should
be
re-deployable
raw.
It
should
be
available
to
roll
back
with
just
kill
up
future.
It's
regardless
of
kubernetes
or
non-communities.
A
No,
I'm
just
I
agree.
It
should
shouldn't
matter
to
the
user,
what
technology
they're
using
behind
the
hood.
My
my
only
concern
the
only
added
benefit
that
a
kubernetes
user
guess
is
that
they
can
scale
down
they
don't
like
it
doesn't
have
to
be
in
a
one-shot
right.
So
a
if
they
have
incremental
rollout
configured
in
the
yaml
file
for
autodevops.
A
We
can
say,
like
don't,
do
the
time
to
roll
out
right.
Just
stop
the
time,
roll
out
for
example,
or
stay
at
20.
Don't
continue!
So
that's
like
really
nice!
A
nice
benefit
that
you
get
from
using
kubernetes
that
you
don't
usually
have
on
a
regular
deployment,
because
you
can
just
stop
the
pods
and
don't
let
them
continue.