►
From YouTube: Scalability demo 2021-07-28
B
B
B
But
it
helps
us
kind
of
set
up
lots
of
other
infrastructure
like,
in
particular,
we'll
have
to
start
figuring
out
the
cause
stuff,
which
is
actually
another
thing
I
I
was
kind
of
surprised
by
when
I
was
looking
into
this
now,
but
that's
another
question
and
you
know
we
can
start
setting
up
the
the
way
we
collect
the
data.
We
can
start
feeding
it
into
error,
budgets
and
all
of
those
parts,
but
you
know
I
don't
want
to
get
stuck
on
on
making
it
too
perfect.
B
Yet
because
there's
so
many
other
things
that
like
we
can
unblock.
If
we
just
do
the
simple
thing,
and
so
I
put
together
a
a
merger
quest
which
is
quite
a
lot
of
fun
because
I
haven't
played
with
webpack
in
many
years,
and
it
basically
sends
that
that
information
through,
but
once
it
arrives
on
the
server.
The
problem
is
that
that
that
information
is
set
statically
on
the
graphql
controller,
and
I
was
wondering
whether
we
should
have
a
I
was
thinking.
B
What
we
could
do,
maybe
is
hey,
feature
category,
and
then
the
value
is
like
dynamic
or
something,
and
if
it's
dynamic
it
actually
like,
I
don't
know,
calls
the
class
and
asks
it.
You
know
hey
what
feature
category.
Are
you
or
something
like
that
or
alternatively,
we
can
use
like
thread
local
values,
which
isn't
I
don't
really
like,
but
it,
as
you
know,
looking
at
the
code,
it
might
just
be
easier
than
refactoring
everything.
A
B
A
Yeah
wow
yeah
effectively
the
same
thing
if
it
gets
reset.
I
guess
I'm
just
going
to
check
how
we
actually
do
this
right
now,
but
I
think
the
other
option
is
we
can
make
it
so
that
we
act
as
if
this
is
an
instance
method
on
the
controller
like
you
mentioned,
but
that
instance
method
by
default
just
calls
the.
B
A
Yes,
so
so
at
the
moment,
in
application
controller,
for
instance,
we
do.
We
have
a
feature
category
instance
method
that
just
calls
feature
category
for
the
action
on
the
class
which
uses
that
with
feature
category
thing
that
you
mentioned.
So
it
would
be
relative,
relatively
easy
to
say,
override
that
for
the
graphql
controller
or
for
all
controllers
to
say,
look
and
see.
If
there's
something
in
the
request
data
that
says,
we
should
use
something
otherwise
go
back
to
the
class.
B
A
B
B
C
A
C
A
The
feature
category
of
the
worker,
so,
if
like
the
the
merge
worker,
is
called
by
a
pipeline,
so
you
know
motor
and
pipeline
succeed
say
a
pipeline
worker
calls
the
merge
worker
the
merge
worker
should
be
source
code,
even
though
the
pipeline
worker
is
continuous
integration,
because
we
know
what
the
worker
is,
but
for
reactive.
Caching,
because
it's
not
owned,
we
actually
want
the
inheritance,
and
bob
did
mention
that,
and
I
was
like
I'm
making
that
out
of
scope,
but.
A
C
B
A
A
If,
if
a
web
controller
or
api
endpoint
calls
create
schedules
a
worker,
we
can
get
the
feature
category
from
that
context,
which
is
what
we
want
and
then
we
can
say
if
this
worker
is
not
owned.
Use
that
feature
category
otherwise
use
the
feature
category
defined
on
the
worker.
Yes,
because
it's
defined
on
the
that
we
consider
that
more
reliable,
so
yeah.
Let
me
create
an
issue
for
that
later,
because
I
can
just
do
that.
Yeah.
A
C
A
A
A
B
B
B
C
A
B
A
B
B
Think
so,
because
we
aggregate
by
I
don't
even
think
we
even
include
the
endpoint
in
any
of
those
aggregations
so
should
be
fine.
It
might
be
that
it
looks
a
bit
funny
on
some
of
the
stage
group
pages
where
it's
got
like
a
series
per
endpoint
or
something-
and
there
might
be.
I
don't
know
something.
No,
no.
A
B
A
One,
the
graphql
controller
should
be
relatively
easy
with
just
overrated
feature
category
in
there
now,
having
I'm
pretty
sure,
that's
the
that
feature.
Category
method
is
the
entry
point
for
metrics
and
for
logs,
but
it'll
be
worth
testing
that,
but
even
if
it's
wrong
we'll
see
it
when
we
deploy
it
so
yeah
cool
cause,
cool
cause.
B
This
is
just
if
anyone's
got
a
pointer.
This
isn't
really
a
scalability
thing,
but
I
just
if
anyone's
got
a
few
in
particular,
so
I
was
kind
of
expecting
that
calls
would
be
managed
by
the
application
and
the
application
would
kind
of
emit
the
headers
that
it
allowed
clients
to
send
back,
and
you
know
all
the
loud
access
allowed,
headers
controls
and
all
those
things.
B
But
it
looks
as
though
omnibus
doesn't
seem
to
do
it
and
we
do
it
on
gitlab.com
in
chef,
which
is
kind
of
surprising
to
me,
and
it's
kind
of
decoupled
from
the
application,
and
it
also
means
that
our
customers
don't
get
the
same
cause
headers
as
we
get,
but
I
don't
know
if
anyone
it's
just
surprising.
I.
A
C
B
A
A
A
And
then
the
epic
I
linked
is
about,
I
guess,
baggage
in
the
context
of
tracing.
So
I
think
igor
was
looking
at
this
a
while
ago,
and
so
was
I
and
then
I
sort
of
dropped
it
because
it
would
have
been
a
bigger
project
and
it
looks
like
that.
Bigger
project
is
happening
so
yeah.
This
is
about
propagation
in
general,
so
that
would
be
if,
if
the
feature
cast
becomes
to
the
graphql
controller
from
the
front
end,
then
that
feature
category
will
go
down
to
italy
and
up
to
workhorse
and.
B
If
that
makes
sense,
because
it
feels
like,
like
the
the
trace
baggage
is,
is
like
a
very
much
like
a
tracing
concern
and
at
least
that's
my
kind
of
initial
take
on
it,
and
so,
if
you're
just
using
it
for
tracing,
I
think
it's
good.
I
mean,
I
also
don't
know
if,
like
does,
is
baggage
guaranteed
to
be
passed
when
a
trace
when
trade,
when
it
when
a
when
a
trace
isn't
being
sampled
when
tracing
is
all
for
this
request.
A
B
Example,
so
so,
like
it
sort
of
feels
like
we're
kind
of
breaking
the
abstraction
to
pass
our
own
data
through,
and
then
that
becomes
a
slippery
slope
like.
Oh,
you
know,
it'd
be
really
nice
if
we
could
just
know
all
these
other
things,
let's
pass
it
through
the
baggage
and
and
I've
heard
that
that
it
can
become
like
a
a
real
pain
point,
and
you
know
people
dealing
with
like
8k
baggage.
A
A
B
And-
and
I
I
I
have
heard
of
of
really
bad
kind
of-
you
know
where
people
it's
it's
kind
of
like
I
mean
it's
not
quite
the
same,
but
it
kind
of
reminds
me
of
like
when
people
discovered
threat
locals
and
it
was
like.
Oh,
this
is
great.
We
want
to
pass
something
from
here
to
here,
we'll
just
stick
it
in
a
thread:
local.
We
don't
need
to
change
anything
and
then
all
of
a
sudden
it
was
like.
Oh
what
have
we
created
here
yeah,
it's
like
that
with
serialization.
It's.
A
B
A
I
think
initially
we're
planning
on
just
using
it
for
the
current
application
context,
which
does
include
feature
category,
but
the
idea
being
that
the
application
context
gets
down
into
downstream
services
and
then
up
into
workhorse,
which
I
think
is
the
only
upstream
service
really
that
we
that
we're
interested
in
here,
so
that
we
can.
We
can
look
in
the
workhorse
logs
and
say.
Oh,
this
was
this
user
because
it
was
passed
back
from
rails
to
workhorse.
B
B
Yeah,
which
is
basically
the
meta
fields,
the
yeah
and
then
but
then
be
fiercely
kind
of
protective
over
what
gets
added
to
that
and
not
allow
yeah
as
long
as
yeah
as
long
as
it's
that,
and
it's
not
just
a
random
sort
of
bag
that
an
application
developer
can
push
things
into
and
then
retrieve
in
gidley
or
something
like
that.
Then
I
think
it's.
B
A
B
A
B
Okay,
okay,
yeah,
then
I
think
we're
all
done
yeah!
That's
that's!
That's
cool
yeah
as
long
as
it's
not
the
right,
because
because
what
I
was
thinking
about
like
when
you
said
baggage
is
the
the
baggage
that
like
open,
tracing
and
and
open
telemetry
have
is
quite
like
it's
basically
an
arbitrary
bag
of
like
a
hash
map.
A
A
B
B
It's
just
one
other
thing
that
I
just
wanted
to
raise
and
kind
of
make
sure
that
it's
kind
of
understood,
which
is
a
comment
that
I
made
in
the
infra
dev
call
yesterday
about
error
budgets
and
not
relying
only
on
them
yet,
and
I
don't
want
it
like
I,
I
don't
want
to
take
it
in
the
wrong
way
or
out
of
context,
and
I
I
kind
of
wasn't
sure
whether
to
say
it
even
to
say
it
or
not.
But
I
could.
B
I
could
see
the
conversation
going
in
one
direction
and
so
basically
what
it
is
is
at
the
moment.
You
know:
we've
had
a
few
really
big
incidents
and
there's
a
lot
of
pressure
at
the
executive
level
to
address
this,
and
you
know,
we've
got
we've
got
error
budgets
now
as
a
tool
that
we
can
use
to
do
this.
But
my
only
point
was
that
error
budgets
are
really
nice,
but
it's
still
like
early
days,
and
we
can't
just
you
know,
because
I
saw
one
conversation
where
it
was
like.
What
does
every
budget
say?
B
C
B
Yeah,
so
so
it's
kind
of
like
I
just
wanted
to
like,
and
also
it
got
me
thinking
like
how
can
we
start
improving
this
and
adding
like
those
things
in,
and
I
think
that
that
at
some
point,
there's
going
to
have
to
be
like
a
human
factor,
but
I
haven't
thought
it
through
it
all,
but
I
just
wanted
to
yeah.
It's.
A
B
B
B
A
C
B
C
Yeah,
so
the
problem,
the
problem
I
have
with
this
now
is
that
it
actually
derails
a
bunch
of
conversations
to
a
wrong
direction
and
actually
puts
us
back
to
what
we
did
last
year.
So
one
of
the
suggestions
that
one
of
the
senior
leaders
in
development
now
has
is,
let's
go
and
look
through
the
incident
issues.
We
already
did
that
we
already
do
that
multiple
times
and
we
all
know
how
unreliable
that
is
and
also.
C
Furthermore,
we
all
know
how
much
work
it
is
to
ensure
that
those
incidents
that
are
manually
created
also
have
the
correct
metadata,
attribution
and
so
on
and
so
on.
So
my
my
my
very
big
concern
right
now
is
that
people
are
going
to
start
completing
things
which
is
already
happening
and
that,
instead
of
talking
about
exactly
what
you
just
said
andrew,
which
is
how
do
we
ensure
that
we
pull
some
of
these
things
in
and
if
it's
manually,
it's
manual,
that's
okay,
but
it's
part.
B
C
A
A
A
B
B
Yeah
very
much
and-
and
there
was
a
there-
was
a
discussion
yesterday
about
well,
you
know,
infradev
is
important,
but
so
is
performance
label
and
so
is
and-
and
my
point
to
that
was
like,
but
infradev
is
the
only
one
that
is
like
aggressively
triaged
there's
1
500,
open
issues
with
the
performance
tag,
there's
67
issues
within
with
infradev,
and
that's
too
many
like
we're
trying
to
work
it
down.
But
you
know
it's
about
having
like
a
very
aggressive
kind
of
like
focus
on
on
those
infrared
ones.
Yeah.