►
From YouTube: 2021-02-19 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
C
A
Yeah,
how
to
put
yourself
in
do
not
disturb
mode
for
notifications
yeah,
which
is
it's
super.
It's
weirdly
hidden
like
you
go
over
to
your
notifications
panel,
and
then
you
have
to
scroll
up
to
a
thing
that
you
there's
no
indication
that
it's
there
and
then
you
can
put
it
in
do
not
disturb
it's
very
strange.
C
I
should
look
for
I
wonder
if
there's
a
windows
do
not
disturb.
I
just
closed
my
outlook,
client,
but.
B
B
A
B
E
A
I
am
sorry
we
have
a
meter
and
hence
the
counter
in
the
base
spacer
for
counting
suppressed
bands,
which
I
think
is
a
good
idea,
but
I
really
don't
want
to
pollute
the
user's
metric
space
and
have
those
like
I
don't
know
if
they're
paying
per
data
point
or
whatever
we
don't
want
that
stuff
to
show.
We
don't
necessarily
want
that
stuff
to
show
up
in
the
universe.
A
Metric
back
end
nicely,
so
it
seems
like
there's
some
value
in
only
and
also
there's
value
in
turning
on
this
feature,
if
we
want
agent
debug
on
so
what
I
would
like
to
do,
and
I've
been
poking
around
the
code
base
and
trying
to
sort
out
some
way
to
accomplish
this
and
haven't
really
come
across.
I
haven't
figured
anything
out
yet
what
I
would
like
to
do
is
have
that
agent
initialization.
If
agent
debug
is
turned
on
to
create
a
independent,
non-global
meter
provider
and
inject
that
into
the
base
tracer.
A
A
So
that's
my
goal
and
then
maybe-
and
it
would
be
also
nice
like
if
a
user
who
wasn't
using
agent,
it
was
library
instrumentation
wanted
to
be
able
to
provide
their
own,
maybe
pass
in
the
global
or
whatever.
Then
it
would
be
nice
to
allow
them
to
do
that
as
well.
So,
anyway,
I
haven't
figured
out
any
way
to
any
place
any
spot
in
the
code
base
to
do
this,
so
I
was
hoping
that
you,
people
who
know
the
code
base
a
lot
better
than
I
do-
might
have
some
ideas.
A
Maybe
it's
going
to
be
nice
if
they
could
yeah
and
then
I
think
we
could
get
it
off
of
the
the
open
telemetry
instance
this
past
end,
and
that
would
work
fine,
eventually
yeah,
when
that's
public
right,
but
in
the
meantime
it
would
be
nice
if
asian
debug
is
turned
on.
If
we
just
had
a
logging
exporter
which
we
know
can't
live
with
other
exporters,
it
would
be
nice
if
we
had
a
logging
exporter
that
could
just
dump
that
data
out
on
the
debug
stream.
B
We
I
made
a
pr
to
automatically
enable
runtime
metrics.
Is
that
also
a
bad
idea,
because
users
wouldn't
want
to
automatically
export
this
stuff?
Well,.
A
This
is
a
little
different
because
runtime
metrics
are
actually
user.
Like
end
user
useful,
I
think,
but
this
is
something
that's
probably
more
for
us
when
we're
trying
to
debug
customer
issues,
and
they
might
not.
I
mean
maybe
they'd
want
to
see
this
in
their
back
end,
but
it's
probably
not
going
to
be
something
meaningful
in
their
back
end,
not
sure.
A
Well,
but
if
we
then
created
that-
and
they
also
were
using
a
prometheus
exporter,
though,
or
any
other
timed
exporter,
they
would
they,
you
can't
have
two
metric
exporters
on
two
separate
interval
metric
readers.
They
it
just
simply
will
not
like
you,
won't
get
rational
metrics.
They
get
mixed
up
between
the
between
them.
Sorry.
C
That's
not
what
I
meant
if
the
so
the
single
meter
provider
right
a
single
x,
meter
x,
metric
exporter,
but
in
the
base
tracer,
where
were
like
these
supportability
counters
just
conditionally,
create
only
create
the
counter
if
debug
mode
is
on.
A
A
Yeah
I
would
like
to
be
able
to
see.
I
don't
want
to
have
to
go.
Look
at
the
user's
back
end
to
get
this
data.
It's
if
I
could
just
ask
them
for
logs
like
turn
on
agent
debug
and
give
us
some
logs
for
the
first
five
minutes
of
running
or
whatever,
then
we
can
see
all
this
data
without
having
to
poke
into
their
back
end
without
having
to
maybe
you
know,
worry
about
privacy,
privacy,
stuff,
getting
access
to
their
data,
et
cetera,
et
cetera.
A
Yeah,
that's
I
mean
that's
what
my
thought
is
it's
just
for
this
sort
of
debugging
it
seems
like
that
would
be
incredibly
valuable
and
I
think,
there's
probably
going
to
be
more
than
just
suppressed
spans,
like
I
think,
there's
probably
going
to
be
a
whole
class
of
metrics.
That
would
be
really
useful
for
us
to
be
able
to
gather
and
dump
into
the
debug
logs
when
you
know
when
we're
trying
to
debug
customer
issues.
A
Yeah
new
relic
at
new
relic,
we
sent
all
that
data
to
the
to
the
user's
account,
but
I
think
we
didn't
charge
them
or
something
like
that.
But
I
don't
remember
how
that
worked.
Well,
they
weren't
paying
for
by
metrics
by
the
data
point
anyway
at
that
point,
so
it
didn't
really
hurt
them
at
all
to
have
extra
metrics
in
their
account.
A
Yeah
yeah,
especially
with
counters.
This
could
be
like
hundreds
per
second,
if
they're,
if
something
is
being
suppressed
by
like
the
the
call
depth
or
some
sort
of
recursive
call
enclosure-
or
you
know
who
knows
whatever
is
going
on
like
it's
nice
to
be
able
to
just
have
counters
that
the
very
super
lightweight
and
only
dump
out
the
data
when
it
gets
exported
rather
than
spamming.
The
logs
so
yeah.
C
Yeah,
I
really
like
the
idea
like
from
like.
I
would
love
to
log
our
keep
metrics
on
which
instrumentations
were
used
to,
because
you
would
get
a
kind
of
a
shape
of
the
user's
app
you'd,
see
oh
they're,
using
log
back
and
netty
and
webflux.
A
A
I
would
love
to
like
what
this
has
been
like
when
I
started
doing
instrumentation
work
like
this
is
the
biggest
pain
like
trying
to
divine,
what's
going
on
with
the
user,
so
the
more
that
we
can
get
into
the
actual
code
base
and
just
have
them
turn
on
debug
and
give
us
some
logs
ship
them
email
us
some
zipped
up
blogs
and
we
could
see
what's
going
on.
That
would
be
like
fantastic,
I'm
kind
of
making
this
my
little
bit
of
my
crusade.
A
B
A
B
B
I
wouldn't
be
really
against
either
of
those
like
if
it
seems
a
bit
too
hacky
I
it
would
be
good
if
we
can
avoid
getting
the
meter
provided
into
the
public
api,
because
we
would
like
to
release.
I
mean
I
don't
know,
I
don't
think
it's
practical
to
release
instrumentation
before
metrics,
but
we
also
don't
want
to
have
a
hard
time.
I
think.
A
I
mean
I
could
also
like
I
mean
to
your
first
suggestion.
I
could
just
create
a
little
like
a
subordinate
supportability
class
that
held
a
whole
a
bunch
of
atomic
atomic
integers
and
just
have
a
have
it.
You
start
it
up
at
run
time
and
like
at
startup
time
and
have
a
little
timer
that
ticks
it
out
every
I
don't
know,
second
or
third,
five
seconds
or
whatever
yeah,
and
puts
out
all
that
data.
That
I
mean
that's
a
sim,
certainly
a
simpler
solution.
A
B
So
I
think
it's
very
unlikely,
but
if
we
start
exposing
things
in
the
public
api,
it's
impossible
like.
I
could
imagine
us
adding
metrics
that
only
work
with
the
agent
and
not
with
library
instrumentation.
I
think
that
should
be
possible
and
like
that
is
better
than
us,
exposing
it
in
the
public,
apec,
instrumentations
right
away.
I
think.
C
B
C
Well,
no,
I'm
not
it's
not
so
much
timeline
that,
like,
I
think
we
could
definitely
stabilize
the
api.
My
concern
is
once
we
then
layer
in
metrics.
Exactly
the
api
will
need
to
change.
B
That's
the
problem,
so
yeah
I
mean
in
that
case
sounds
like
us
all,
agreeing
on
that
and
saying:
there's
no
way
we
can
release
instrumentation
before
metrics.
So
let's
not
worry
about
it,
and
then
that
opens
up
all
these
options
like
allowing
this
meter
provider
to
be
injected
and
that
I'm
I'm
fine
with
that.
Also
just
don't
want
to
make
sure
we
shoehorn
ourselves
unnecessarily,
but
it
might
not
matter
really.
C
Yeah
no
you're
right.
We
haven't
really
thought
through
it.
So
because
it's
like,
for
example,
say
you
did
pass
in
the
open,
telemetry
object
and
I
mean
inside
the
methods
where
we're
creating
the
spans
is
essentially
where
you
would
create
the
metrics.
B
A
I
think
this
dovetails
nicely
into
jason's
second
item
there.
Actually,
that.
E
Base
tracer,
I
put
it
at
the
bottom
because
it
could
go
off
the
rails
and
I
didn't
want
to
eat
up
all
the
time
with
it.
So
the
other
one,
if
we're
if
we're
moving
on,
is
something
I
I
that
occurred
to
me
as
we
were
running
out
of
time
this
morning,
and
that
was
does.
Can
we
spend
maybe
five
minutes
just
looking
at
the
bug
list
and
see
if
there's
anything,
a
gator
release
on.
A
Yeah
I
mean
I'll
put
that
together
and
see
what
it
looks
like
just
create
a
little
class
that
manages
that
stuff.
I
mean
okay,
because.
A
Well,
one
nice
thing
is:
if
we
wrap
this
up
inside
a
class,
we
can
change
the
implementation
so
yeah.
It
seems
like
there's
value
in
wrapping
it
up
anyway,
and
maybe
with
an
interface,
so
people
could
provide
their
own
if
they
want
so
I'll
I'll
start
working
on
that
see
how
it
looks.
C
Okay,
I
love
that
this
is
your
you're
making
this
your
mission.
I
fully
support
your
mission.
A
E
Just
write
it
and
let
somebody
else
double
shoot.
That's
the
best,
no
yeah.
So
the
answer
to
this
next
one
might
very
well
just
be
like
show
up
jason
we're
already
looking
at
this
all
of
the
time
and
we're
we've
already
gotten
wrangled,
but
I
think
there
are
like
20-something
bugs
that
are
open
and
I'm
I
don't
want
to
say
concerned
they
might
be
overstating
it.
E
E
E
B
E
So
yeah:
okay,
sorry,
it's
okay
to
have
observability
issues
that
might
even
break
spec
as
long
as
we're
not
breaking
the
app
cool,
because
then
we
can
always
follow
it
up
with
a
patch
release
right
or
I
guess,
every
patch.
Every
subsequent
release
after
1-0
will
have
the
fixes
that
everyone
wants.
Like
I,
I
love
that
approach.
I
think
that's
the
best.
The
best
world.
C
B
C
B
E
No,
it
wasn't
I'm
I'm
open.
I
mean
I
was
looking
at
a
database
thing.
I
think
it
was
related
and
I
found
it
pretty
difficult
to
reason
about
the
call
chain,
due
in
large
part,
to
the
multiple
levels
of
polymorphic
inheritance
in
that
whole
hierarchy,
which
you
all
are
very
familiar
with
and
is
a
little
bit
newer
to
me
and
while
certainly
I
can
understand
the
need
or
the
desire
to
not
reinvent
the
wheel
and
share
code
between
tracers.
E
I
think
that
inheritance
is
one
of
the
most
commonly
worst
ways
of
doing
that,
and
it's
it's
what
we
have
right.
So
I
had
been
spending
some
time,
thinking
about
and
experimenting
with
ways
of
de-inheriting
some
of
those
not
maybe
not
all
the
way
to
the
base
tracer.
I
was
starting
more
with
the
database
client
tracer
and
had
a
couple
of
you
know.
E
Reasonable
starts
that
did
not
end
well
due
to
complexity,
and
I
think
john
said
that
I'm
not
alone
in
having
tried
that
and
that
there's
at
least
some
consensus
around
that
inheritance
hierarchy
being
problematic.
A
One
of
the
ideas
and
why
I
thought
it
dovetailed.
Well
one
of
my
one
of
my
ideas-
and
I
this
is
just
in
my
head.
I
don't
know
how
exactly
the
code
would
work,
it'll
be
really
nice
if
we
didn't
have
to
rely
on
the
instrumentation
remembering
to
try
finally,
and
do
all
that
kind
of
stuff,
and
then,
if
we
made
it
really
easy
for
instrumentation
to
always
do
the
right
thing
make
sure
that
they
always
we're
closing
spans,
closing
context
and
ending
spans
without
having
to
remember
to
do
that.
A
So
I've
just
been,
you
know,
while
jason
and
I
were
chatting
just
brainstorming,
a
little
bit
about
ways
to
write
a
instrumentation
using
some
sort
of
life
cycle
like
span
life
cycle
or
instrumentation
life
cycle
ideas,
where
you
implement
some
a
few.
A
couple
methods
like
this
is
the
stuff
I'm
gonna
do
before.
I
want
the
span
to
start
here's
some
stuff
I
want
to
do
after
the
span
has
started,
etc,
etc
and
so
build
it
into
more
of
a
life
cycle
pattern
that
can
then
be
managed
with
all
of
the
try.
A
Finally,
and
all
that
stuff
in
not
having
to
be
in
every
instrumentation
and
not
have
all
the
instrumentation
have
to
worry
about,
it
probably
is
a
is
pie
in
the
sky
and
a
pipe
dream,
but
these
kind
of
thoughts
are
like.
I
want
to
make
it
easy
to
write,
instrumentation
and
easy
to
do
the
right
thing
and
hard
to
fail
and
make
sure
that
all
the
instrumentation
is
always
guarding
everything
against
npes
and
get
against
those
exceptions
in
the
right
way
anyway.
So
those
are
that's
why
that's
what
I've
been
thinking
about?
A
I
don't
have
any
concrete
ideas,
but
just
pondering
some
ideas
about
making
it
easy
to
write,
instrumentation
and
not
do
the
wrong
thing.
B
I
think
one
way
we
can
describe
this
problem
also
is
that
we
do
seem
to
have
an
expectation
that
there's
only
one
implementation
of
base
tracer
per
library,
which
doesn't
actually
fit
that
well
with
the
spec,
because,
like
you
have
http,
you
have
rpc
like
they,
you
might
fill
both.
You
might
fill
only
one,
but
if
we
always
inherit
from
the
base
tracer
to
start
our
spans,
I
don't
think
that
gets
modeled.
So
well
with
our
current
api,
and
sometimes
you
end
up
mixing
matching
these
two
classes.
E
Yeah
and
base
tracer
is
also
interesting
because
you
know
it's
abstract,
for
I
think
exactly
one
method,
which
is
name
which
is
something
that's
almost
always
almost
always
trivially
injected
like
it's
all.
In
most
cases,
it's
just
a
string,
if
not
every
I
didn't.
I
didn't
verify
that,
but
like
the
only
reason
for
that
base,
tracer
to
be
abstract
is
for
that
one
name:
instrumentation
name
method,.
E
Yeah,
I
guess
I'm
also
thinking
about
collaborators
coming
in
and
working
with
this
code
base
and
the
first
thing
they
might
see.
If
they're
investigating
instrumentation
based
on
library,
x,
they're
gonna
go
look
at
the
instrumentation
there,
they're
gonna
see
advice,
they're
like
okay,
this
makes
sense,
they're
gonna,
see
it
and
they're
gonna
say:
oh
okay,
it
uses
this
tracer
thing
and
once
they
start
scratching
at
it,
they're
gonna,
they're,
gonna
end
up
at
some
point
in
base
tracer
and
they're.
Gonna
see
that
for
me,
what's
also
confusing
is
the
bass.
E
E
C
E
B
B
B
E
Yeah,
so
when
I
was
looking
at
the
profile,
the
method
profile
of
the
database
client
tracer,
there
kind
of
seemed
to
be
like
this
chimera
of
responsibilities
between
these
on
methods.
There's
like
three
or
four
of
these
on
which
are
like
very
specific
for
database
clients
right
these
two
or
two
of
them
are
three
of
them
are
abstract
and
there's
like
one
or
two
that
are
defaulted
essentially.
E
C
Like
yeah
there's,
the
public
interface
right
should
start
span,
start
span
and
n
span.
Those
are
the
only
public
methods,
so
that's
sort
of
the
public
contract
and
then
yeah.
All
the
other
stuff
is
just
meant
for
overriding.
E
But
all
of
the
advice
that
I
saw
at
least
on
the
database
stuff,
all
of
the
advice-
uses
a
concrete
type,
a
concrete
subtype,
and
there
are
cases
where
the
concrete
subtype
exposes
methods
or
additional
like
public
api.
And
so
you
like
this,
isn't
a
contract
if
it
if
it
was
intended
to
be
and
it's
violated
in
a
few
places-
and
it's
also
just
not
a
very
strong
one
like
even
an
explicit
interface,
would
help
there.
I
think.
B
B
A
B
A
So
my
suggestion
to
jason,
which
probably
is
a
good
suggestion
who
anyone
anyone
wants
to
tackle
this,
which
is
to
take
one
piece
of
instrumentation
and
one-
that's,
maybe
not
super
complicated,
because
the
implementation
is
relatively
straightforward
and
just
try
to
build
out
a
thing
that
isn't
debate,
doesn't
use
the
base
tracer
but
uses
a
new
construct
and
then
just
show
that
it
works.
And
then
you
could
easily
once
that
has
been
proven
and
makes
sense.
And
the
api
is
clean
and
it's
easy
to
understand.
B
E
And
not
to
be
like
too,
you
know
idealistic
pedantic,
dogmatic
whatever
I
think,
there's
there's
some
cases
in
here
that
violate
you
know
open
close
principle
like
some
pretty
solid,
like
design
concepts
that
are
violated.
B
B
B
E
Yeah,
okay,
yeah.
I
think
I
somehow
wasn't
around
for
some
of
those
prior
conversations,
but
watson
definitely
knew
that
that
had
been
discussed
before
yeah
yeah.
A
B
C
B
E
B
E
But
I
think
it's
not
done
trivially
because
line
88
like
what
we're
doing
there
is
we're
escaping
the
constructor
like
we're
escaping
to
an
abstract
method
there,
which
is
like
kind
of
a
big
no-no
as
well.
So
I
was
like
well,
maybe
we
could
just
like
if
you
look
at
the
implementations
of
that,
it's
like
it's
almost
always
just
a
hardcoded
string,
and
so
the
string
could
be
passed
in
it's
just
at
this
point.
We're
all
the
way
in
base
tracer
and
it's
a
lot
of
touches.
You
know.
E
E
B
I
finally
got
the
experience
with
the
lambda
instrumentation
migrating
that
to
injecting
open
telemetry
and
it
wasn't
like
if
it
wasn't
the
sdk,
it
would
be
quite
clean
and
it
was
relatively
easy,
but
that's
what
we
have
to
do
to
every
single
library
before
we
can
delete
that
line.
70
constructor,
which
is
the
problem
here,.
E
A
E
A
E
E
C
Dude,
the
thing
I
think
remember
keep
in
mind
with
that
version
is
if
we
for
library
like
this
base,
tracer
is
shared
by
both
library,
instrumentation
and
java
agent
instrumentation.
C
Yeah
so
java
agent
instrumentation,
is
a
byte
code
that
ends
up
by
code
instrumentation
that
ends
up
in
the
java
agent.
It's
our
traditional
instrumentation.
What
we're
calling
library
instrumentation
is
things
like
we've
broken
out
grpc
into.
Let
me
show
you
that's
the
best,
a
good
example
where
there's
framework
or
library
hooks
yeah,
and
you
can.
E
C
It
without
the
without
the
java
agent
and
so.
B
C
B
A
B
C
E
B
B
Forgot
about
that!
That's
a
good
point,
scratch
scratch
that
this
needs
a
bit
more
looking
at
that,
it's
not
obvious
yeah.
A
B
So
technically
the
library
depends
on
the
api
and
not
the
sdk,
and
so
we
have
some
restriction
where
the
sdk
has
to
be
the
same
version
of
as
whatever
is
in
the
palm
we
publish,
but
once
it's
1.0,
this
problem
should
not
really
matter,
and
so
I
always
think
of
just
responding
with
once
this
1.0.
This
won't
be
an
issue
anymore.
We
don't
have
any
compatibility
table
for
zero
point
x,
stuff.
A
I'll
I'll,
let
you
handle
that
after
I
had
to
fend
him
off
over
and
yeah.
B
A
A
A
B
C
A
F
C
Wow
one
week
still
still
one
week
count
eight
days
until
1-0,
you're
feeling
good
john,
never.
A
A
A
The
only
apis
that
we
have
are
how
you
build,
how
you
construct
them
other
than
that,
it's
all
you
know
all
bets
are
off.
We
can
fix
buttons
till
the
cows
come
home,
yeah.
C
All
right,
well
happy
happy
releasing
on
our
I'll
keep
an
eye
out
for
merge
anything
any
prs
that
you
need
approval
on.
F
B
C
B
E
A
E
And
if
you're
stuck
on
java
8,
what
else
are
you
going
to
use?
I
mean
there's,
there's
very
little
out
there
to
help.
You
do
like
asynchronous
socket
programming
in
java
8.
for
http.
B
A
E
Also
so
one
thing:
that's
interesting:
if
you
go
to
the
neti
website,
they
have
under
get
involved,
they
have
a
list
of
adopters
and
from
there
you
can
get
a
sense
of
like
who's
using
it.
How
I
mean
most
of
those
are
our
additional
libraries
or
frameworks
sitting
on
top
of
it,
but
just
to
give
you
a
sense
like
there's,
a
ton
of
people
who
are
like
listed
on
the
adopters
page,
like
airbnb,
has
a
tool
called
plog,
which
is
like
fire
and
forget.
E
C
Yeah,
I
can
say,
like
the
azure
sdks
use,
neti.
C
B
D
B
B
A
C
Yeah
and
I
would
like
to
get
splunk's,
you
know
thought
on
older
versions,
because
you
know
if
you
have
ideas
of
customer
needs
on
older
versions,
because
I
think
honorary.
I
have
discussed
that.
C
I
think
we're
both
okay
with
deleting
dropping
older
versions,
but
I
think
one
I'm
guessing
probably
has
a
more
diverse
customer
base.
A
And
now
that
now
that
nikita
is
the
boss,
he
can
he
can
make
those
calls
you
all
did
he
is
he
leave.
A
He's
mostly
being
a
jira
wrangler
at
the
moment.
E
So
john
john
has
more
insights
into
the
answer
of
that
question
than
I
do
because
he's
been
here
longer,
but
in
my
experience,
if
you
ask
if
somebody
needs
something
like
oh
do,
customers
need
like
the
answer
is
always
yes
like,
of
course,
if
you
ask
they're
going
to
say
yeah,
we
need
that.
That's
been
my
experience.
A
A
Oh
yeah,
oh
yeah,
yeah
I've
been
I've,
been
supporting
our
sales
team
with
our
sales
engineering
team
with
java
six
installs,
which
is
just
like
zipkin
brave,
supports
java
6.
yep
the
option
key,
there's
no
auto
instrumentation
that
I
could
find
anywhere
that
had
to
export
like
a
a
standardized
export
pipeline.
I
don't
know,
is:
does
your
thing
trask
support
java
6
and
allow
you
to
plug
in
exporters
to
any
like
the
zipkin.
C
A
That's
what
I
was
I
was.
I
was
hoping
that,
like
there
was
a
zipkin
exporter
already
for
it,
so
we
could
just
say:
hey
here's
the
thing
we
could
use
because,
right
now
it's
like
yeah
manual
instrument
with
brave
or
annual
instrument
with
open
tracing
jaeger
and
zipkin
exporter
and
that'll
that'll
work.