►
From YouTube: 2021-11-05 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).
A
D
Yeah
jason
keller
could
show
up
too
and
and
johnarog.
E
Is
everyone
else
in
portland
on
this
call
or
in
west
coast.
H
I
live
right
kind
of
in
the
near
the
cbd
of
sydney.
B
I
was
did
some
of
my
research
for
my
phd
down
at
the
aat.
B
I
guess
up
from
sydney
perspective
at
the
tele
with
which
telescope
is
it
anglo
australian
telescope
in
kuna
baraban
in
kuna
barabran?
Where
is
caribou?
It's
about
five
little
puddle
jump
stops
on
a
plane
north
of
sydney.
I
B
When
I
was
there,
in
fact,
it
was
so
dark.
You,
like
I
got
almost
got
trampled
by
a
kangaroo.
H
Yeah
my
uncle
actually
owns
a
big
telescope
out
in
rural
queensland
about
three
hours
west
of
cairns.
Oh
there,
it
is
super
dark
out
there
as
well
yeah,
but
good
looking
at
stars.
E
H
B
B
H
A
B
D
C
Yeah
so
honorag
first
topic
jason
brought
up
getting
getting
rid
of
code
cov
slash.
Well,
I
think
jason's
proposal
was
to
reduce
it
down
to
the
percentage
just
so
it
stops
always
looking
like
the
build
is
failing
and
john
was
asking:
why
do
we
have
it
at.
A
C
G
A
A
C
E
A
Like
I
mean
like
our
code
base,
has
pretty
good
coverage,
mostly,
except
for
the
open,
tracing,
shim
and
open
sensation,
and
so
I've
always
had
that
red
mark
just
to
remind
me
that
we
have
these
stupid
gyms
that
aren't
really
maintained
and
should
be
maintained.
That's
the
motivation
for
the
red
marks.
For
me,
I
mean.
A
The
collector,
I
believe,
is
also
90,
so
that
was
one
reason
to
pick
that
number.
We
can
change
it
like.
If
we
really
don't
like
the
red
mark,
I
think
we
can
configure
it
for
folder,
so
those
shims
have
a
lower
number
and
I
think
that'll
make
the
red
mark
go
away,
though
I
still
wish
the
shims
had
more
coverage.
That
was
that's
the
better
fix
and
it's
just
no
one
wants
to
maintain
those
folders.
I
think
so,
if
there's
an
option
to
move
the
shims
to
country,
that's
of
course
my
favorite
option.
A
A
B
E
I
was
going
to
mention
that
is
that
I've
I
feel
like
I'm
being
gaslit,
sometimes
by
the
code
coverage
like
like.
I
don't
understand
how
it's
computed
sometimes,
and
you
know
I
click
on
the
link
and
I
try
to
I
try
to
parse
it,
but
I'm
I'm
seeing
you
know
in
what
should
be
the
diff
for
my
pr
code
that
I
haven't
touched
stuff
like
that
and
it's
it's
not
something
I'll
be
able
to
bring
up
an
example
of,
but
like
I've
noticed
it
in
passing
that
it's
not
always
completely
trustworthy.
B
For
example,
look
at
jason's
pr
for
the
clock
and
the
logs,
like
the
code
coverage
report
that
shows
up,
has
the
percent
escaper
in
it
from
baggage
propagation,
which
has
absolutely
nothing
to
do,
and
it
claims
it
isn't.
Five
four
and
a
half
percent
down
on
jason's
pr
like
it
literally,
has
absolutely
nothing
to
do
with
any
code
that
was
touched.
D
D
A
D
A
C
B
A
D
So
I
think
I
think
our
takeaway
from
this
morning
was
we
have
a
few
options
right.
It's
like
we
can
continue
ignoring
it.
We
can
reduce
the
percentage,
we
can
throw
some
excludes
in
there
or
we
could
get
rid
of
it
entirely.
I
think
those
are
like
the
ones
we
ended
up
with
yeah.
B
Be
in
favor
of
so,
can
you
can
you
reduce
it
reduce
the
percentage
on
a
folder
by
folder
basis?
It
should
be
yeah
pretty.
B
C
Do
you
get
issues?
Have
you
had
any
issues
in
the
sdk
repo
about
them?.
B
B
No
it
or
it
means
they're
perfect.
No,
no,
I
agree
yeah,
I
don't
think
anyone's
using
them.
Although
I
know
there's
definitely
been
questions
asked
about
them,
but
yeah.
I
don't
know.
A
B
I
mean
it
will
change
their
packaging
right
or
their
mod,
their
their
maven
coordinates.
That
sort
of
thing
I
mean.
A
B
Yeah
yeah,
I
would
so
I
would
just
I
guess,
I'd
ping
josh
surith
about
about
the
open
census
one
and
see
what
he
feels.
I
mean
I
don't
think
as
I'm,
not
a
user
of
either
of
them.
I'm,
like
I
don't
know
whatever.
I
don't
care,
yeah
exactly.
B
A
B
C
G
A
A
D
A
C
Cool
so.
F
C
Our
awesome
release,
so
the
proposal
was
to
there
was
a
proposal
to
skip
1.8
and
go
to
1.9,
and
but
that
would
we
would
want
the
sdk
to
go
to
1.9,
also
to
stay
in
sync.
F
F
B
F
C
They
must
push
to
the
directly
to
and
not
do
pr's.
C
So
that
would
be
next
week-
sdk,
oh
yeah,
I
I
there
was
also
some
bartering
going
on
about
metric
cardinality
limits,
because
the
josh's
pr
in
the
instrumentation
repo
is
adding
http,
url
and
http
target
as
dimensions
which
we
know
are
going
to
explode
a
lot
of
apps
dimensions,
and
so
we
agreed
to
put
that
in
for
now
as
long
as
there's
some
type
of
cap
added
in
this
release,
sdk
release
for
cardinality.
C
E
What
dot
net
does
is
just
like
a
naive.
You
know
implementation
of
cardinality
restrictions
or
is:
is
they
just
have
a
cap
per
instrument
where
it's
2
000,
and
if
you
reach
that,
then
additional
you
know
accumulations
or
distinct
sets
of
attributes
just
get
dropped,
and
you
know
I
I
think
the
the
sdk
spec
is
doesn't
have
language
about
how
to
handle
this
yet,
and
so
I
still,
I
think
that
you
know
what
we
do
and
what.net
and
what
python
do
are
going
to
inform
that.
A
E
My
thought
on
the
metric
space
is,
I
think,
having
some
sort
of
you
know.
At
least
hardcore
coded
limit
is
important
because
it's
just
it's
just
not
easy
to
to
protect
yourself.
So
it's
if
you
turn
on
metrics
with
by
just
like
setting
an
exporter,
it's
really
hard
to
configure
the
views
api
via
spi
service
providers.
Interface
to
to
you
know,
do
what
you
need
to
do
to
limit
the
cardinality,
and
so
I
don't
know
until
the
ergonomics
are
better
got
to
give
the
user
something.
I
think.
G
C
B
E
It's
my
priority
right
now
to
like
look
into
that
stuff,
and
so
you
know
I'm
not
as
familiar
with
that
code
as
josh's.
Obviously,
but
yeah
I'm
gonna,
try
and
understand
it
enough
to
make
that
type
of
change,
we'll
see.
A
B
But
it
does
have
an
lru
built
in
there
right,
but
it's
not
one,
you
can
it's
not
one
that
you
can
programmatically
call
it's
the
it's
an
api.
The
api
is
not
public
on
the
link.
B
C
A
A
C
Jack
should
we
go
over
the
your
topics
and
then
we'll
go
through
the
remaining
notes
from
this
morning.
I
think
there
might
have
been
one
or
two
other
things
to
chat
with
onrock
about
from
there.
E
Yeah
so
a
couple
things
related
to
logs
that
you
know,
I
think
it'd
just
be
better
to
talk
about
in
person
rather
than
just
asynchronously.
So
this
conversation
about
context
and
setting
context
of
logs.
So
you
know
originally,
there
are
currently
there's
a
trace
id
and
a
span
id
and
an
int
trace
or
an
inch
flags
field,
and
so
there's
a
pr
out
to
remove
the
or
replace
the
int
flags
field
with
a
trace
flags
field.
E
But
I
think
what
the
real
intent
is
is
kind
of,
like
you
know,
span
contacts
like
associate
that
like
a
whole
trace
id
span
id
and
trace
flags,
and
so
the
question
is:
do
we
have
a
setter,
for
you
know
either
either
a
single
setter
for
all
the
that
context
or
multiple
setters?
Or
do
we
just
call
context.current
when
we
are
building
a
log
or
emitting
a
log
through
the
log
emitter
to
just
get
whatever
context
is
currently
set
on
the
thread?
E
And
you
know
there's
the
question
of
async
versus
synchronous.
So,
like
all
these
log
frameworks
have
the
ability
to
take
an
appender
and
wrap
it
with
in
an
async
appender,
so
that
effectively
all
the
work
in
your
appender
is
being
done
on
a
different
thread,
and
if
we
were
to
author
appenders
in
these
frameworks
and
our
and
our
users
were
to
set
them
up
and
wrap
them
in
an
async
appender,
then
all
the
sudden
calls
to
context.current
wouldn't
resolve
correctly.
A
A
Like
I
wonder,
if
most
of
the
time
like,
if
you're
an
appender,
you
can
actually
detect
what
your
rapper
is,
we
could
fail
fast
in
that
case,
if
someone
wrapped
with
an
async,
because
there's
no
real
use
case
right,
because
we
use
the
batch
log
processor
anyways.
So
we
could
just
say
we
don't
support
async
mode,
so
don't
do
it
and
if
we
detect
it,
we
fail.
B
A
B
A
C
I
mean
from
the
the
appenders
that
we
produce
officially
yeah.
E
Well,
so
that
okay,
so
let
me
let
me
unpack
that
a
bit,
so
that
assumes
that
the
the
log
sdk
is
only
going
to
be
used
with
log
appenders
and
with
logging
frameworks,
and
so
like
one
thing
that
I've
been
talking
about
or
thinking
about
is
you
know
so
logs
in
open
telemetry
represent.
You
know,
application
logs,
but
also
machine
generated
events.
E
So
would
anybody
ever
use
directly
in
their
application,
the
log
sdk
to
emit,
like
named
events,
you
know
like
if
you've
ever
monitored,
like
kubernetes,
there's
events
that
are
emitted
when
you
know
a
pod
is
deployed
or
is
destroyed
or
something
like
that.
So
it's
not
like
a
metric.
It's
not
a
span.
It's
like
a
point
in
time
thing
right.
B
A
B
Okay,
like
I
think
we
haven't
we're
having
enough
trouble
in
the
eco
just
in
the
general
ecosystem,
getting
anyone
to
think
that
our
metrics
are
worth
using
when
there
are
so
many
alternatives
like
in
java,
micrometer
and
prometheus,
as
well
as
drop
wizard
and
logging
is
even
worse.
There's
like
super
well
established
logging
apis
and
no
one
is
going
to
change
over
to
use
ours.
B
To
so
so,
what
we're?
What
we've
been
talking
about
is
actually
building
a
very
specific
rum
api
that
will
not.
It
will
be
different
than
tracing
like
a
different
thing
than
tracing
metrics
or
logs,
like
a
very
specific
rom
api
that
will
hook
into
whatever
needs
to
be
hooked
into.
At
least
this
is
what
I'm
proposing.
C
B
C
B
Exactly
because
there
are
usage
usages,
especially
like
profiling
and
like
rom
and
like
jack,
was
saying
kind
of
system
sort
of
events
that
you
might
want
to
respond
to
which
there's
like
jdk
events,
which
are
not
necessarily
profiling,
related,
but
lots
of
jdk
events
like
gc's,
and
things
like
that
that
we
would
want
to
probably
emit
as
logs.
B
But
we
don't
necessarily
want.
We
don't
want
to
build
something.
That's
like
a
replacement
for
log,
j
or
slf
object.
E
Yeah,
I
agree
okay,
so
related
to
that
then
so
there's
the
there's
a
question
of
whether
we
should
have
like
a
setter
at
all
for
setting
the
contacts
that
even
our
penders
can
call
or
whether
that
should
all
be
embedded
within
the
sdk.
E
And
so
I
guess,
I
think,
having
a
setter
for
setting
the
contacts
is
more
the
more
flexible
solution,
because
then
you
know,
depending
on
whether
the
appenders
allow
you
to
store
like
a
raw
object
in
the
the
map.
Diagnostic
context,
or
you
know,
like
log4j2
force
you
to
convert
everything
to
strings.
You
just
have
the
flexibility
to
work
around
any
of
those
requirements.
C
Also
fine
yeah
to
support
reactive
types
of
things
where
people
don't
aren't
gonna
have
the
context
on
the
thread.
Local,
so
contacts
current
may
not
work.
A
Yeah,
it's
just
because
there's
no
api
again
like
that
conflicts
can't
really
be
passed
through
a
cell
effort
or
whatever
anyways.
So
I
think
the
use
case
is
much
more
limited
than
our
other
signals,
but
I'm
sure
it's
still
useful
to
have
this
editor
like
the
ram
api,
would
probably
use
it,
I'm
guessing
so
that
makes
sense.
E
A
B
A
B
B
A
B
Yeah,
I
mean
this
seems
natural
yeah.
This
does
kind
of
get
to
my
my
the
change
in
my
thinking.
Probably
six
eight
months
ago,
where
I
really
started
thinking
about
the
context
is
the
most
important
piece
of
all
of
the
open,
telemetry
apis
that
should
be
kind
of
the
currency.
That's
moved
around
between
everything,
rather
than
rather
than
focusing
on
span
or
metrics
or
whatever,
like
the
context
is
the
is
the
carrier
of
data.
It's
the
carrier
of
context,
maybe
even.
B
I
B
A
E
Yep
and
now
I
can
get
rid
of
several
fields,
I
can
give
it
a
trace
id
span
id
and
these
this
flags
and
collapse,
those
all
into
a
single
thing,
although
do
we
still
want
getters
for
those
individual
things
and
just
a
setter
for
the
context?
Like
that's
that's
a
question.
A
B
A
F
E
E
You
know
optional
in
and
I
guess
an
interesting
sense
because
we
don't
support
like
optional
yet
in
the
proto,
but
we
will,
but
for
now
it's
just
in
the
documentation
of
the
fields
in
the
proto
they're
marked
as
optional,
and
so
the
question
is:
should
I
go
ahead
and
make
all
the
fields
on
log
data
nullable
to
reflect
that
or
you
know
in
some
cases,
some
of
these,
like
objects,
have
kind
of
empty
default.
Values
like
severity,
for
instance,
is
an
enumeration
and
severity.
E
One
of
the
one
of
the
values
is
undefined
severity
number,
which
is
null
ish
right,
so
you
know,
should
should
that,
be
you
knowable
yeah
line
49.
E
A
A
E
Enormous
so
did
you
did
you
say
for
trace
id
and
span
id
use
like
the
invalid
trace
id
in
span
id?
Well,
I
think
in
this
case
we'd
use
the
invalid
span
context.
Good
chat.
E
Okay,
what
about
body
that
one's
interesting
and
attributes
like
attributes,
empties.
E
Not
yet,
but
you
know,
I
don't
know
where
they're
gonna
go
with
this,
so
you
know
right
now,
attributes
is
you
know,
all
fields
are
technically
required,
but
they
just
have.
I
don't
know
how
to
describe
it.
You
know,
there's
a
default
value
if
you
don't
set
it
right,
but
we're
going
to
go
to
a
proto
version
that
supports
optional
fields
and
at
that
point
the
log
proto
may
switch
all
these
fields
to
be
truly
optional,
in
which
case
there
would
be
a
difference
between
an
empty
attributes
and
a
not
present.
A
E
Well,
we
were
talking
about
honorable
brought
up
in
one
of
the
pr's
or
an
issue
that
you
know.
Perhaps
we
could
perhaps
we
could
get
rid
of
the
body
and
just
treat
it
all
as
strings
until
the
use
case
presents
itself
to
have
it
be
structured
and.
A
A
F
A
E
And
that
might
go
away
in
the
future,
we'll
see
so
yeah
that'd
be
nice.
A
B
Yeah,
that
name
field
is
one
that
rom
will
and
ramen.
You
know
kind
of
system
level.
Events
will
want
to
use
that
for
sure.
So,
hopefully
they
don't
get
rid
of
it
without
some
sort
of
replacement.
E
Yeah,
but
over
in
the
spec
there
was
a
log
data
model:
oh
okay,
yeah
you're,
you're
caught
up,
but
like.
E
One
of
the
mappings
you
know
that
they're
using
to
define
the
data
model
describes,
you
know
taking
logs
from
what
is
it
syslog
and
mapping
the
msgid
field,
which
I
don't
know
a
lot
about,
but
it
sounds
like
it's
high
cardinality
and
that
would
not.
E
E
C
B
C
Like
gen
machine
event,.
E
Or
whatever
you
were
talking
about
jack,
it's
it's
being
debated.
If,
if
it's
to
be
useful
for
rum
events
and
for
the
purposes
of
like
new
relic
event
types,
then
it
needs
to
be
that
and
if,
if
it's
not
that
and
folks
put
in
high
cardinality
values,
so
if
it's
basically
double
dipping
and
serving
two
purposes,
then
it's
not
useful
to.
C
I,
like
we,
we
have
our
back
end,
has
a
custom
event
that
would
that's
supposed
to
also
be
like
a
low
cardinality
like
business
event,
kind
of
a
thing.
B
Yeah
exactly,
I
would
definitely
want
to
be
perfect.
I
want
to
use
that
for
this
jack.
Are
you
thinking
of
mapping
logs
into
blogs
with
names
into
like
new
relic
incites
events,
yep
yeah?
That
totally
makes
sense.
D
E
John,
should
the
name
of
the
of
the
log
appender
go
into
the
instrumentation
man.
A
B
I
mean
the
interesting
thing
yeah.
I
think
that
the
appender
name
is
an
interesting,
certainly
an
interesting
thing
that
doesn't
really
have
a
place
in
the
data
model.
It
definitely
feels
like
if
I
were
building
a
log
like
as
a
everyone
knows
the
logger
api.
I
want
to
say
logger.getlogger
and
pass
in
the
name
I
mean
that
seems,
that's
analogous
to
tracer
dot
or
trace
provider.
Dot
get
tracer
with
the
name
right.
It
feels
like
exactly
the
same
kind
of
age.
I.
A
B
B
B
B
There
have
been
multiple
proposals
over
the
past
couple
years
to
use
the
tracer
name
to
do.
The
same
sort
of
thing
like
like
have
a
filtering
of
spans,
coming
based
on
tracer
name,
just
like
you
would,
with
a
logger
name
and
changing
the
log
level.
B
B
Good
things,
I
know
that
tristan
is
trying
to
put
together
tristan
slaughter,
is
trying
to
put
together
a
proposal
for
how
to
handle
that
sort
of
span.
Processor,
slash
sampling,
slash
whatever
in
general,
but
I
think
it's
moving
very
slowly
because
it
actually
is
pretty
complicated.
C
E
And
I
tried
it
out,
you
know
I,
I
updated
the
prototype
in
the
instrumentation
repository
for
to
log
for
jpender
and
I
published
that
to
maven
local
and
used
it
in
an
application,
and
it
was
pretty
slick
so
yeah.
I
think
people
are
going
to
like
it.
C
A
There's
the
topic
of
closing
the
repo,
I
wouldn't
add
a
manual
step
to
avoid
issues
with
manual
steps
I
think
like
if
we
want
to
add
some
verification
step.
If
we
can
that's
better
than
removing
the
automation,
I
think
at
the
same
step
that
verification
can
also
have
a
bug
like
our
workflow
did
this
time.
So
I
don't
think
you
can
just
be
100.
C
Yeah,
I
I'm
gonna
check
that
out,
though,
and
I'll
I'll
do
the
I'll
do
the
one
nine
instrumentation
release,
because
I
kind
of
figure
that
I
broke
something
in
that
anyway,
with
the
with
the
moving
away
from
nebula
and.
C
Out
the
steps
of
like,
if
we're
gonna
kind
of
think
through
if
we're
gonna,
do
a
release
branch
or
what.
C
And
then
yeah,
this
was
all
the
if
you
just
look
at
josh
updated
his
pr
with
basically
the
what
we
oh,
I
did
a
summary
down
here
at
the
bottom
yeah,
so
naive,
implementation
for
sdk
and
then
in
the
instrumentation,
we'll
use
the
url
for
client
and
scheme
host
route
for
server.
But
we
don't
capture
route
attribute
in
most
of
our
instrumentations
yet
so
for
now,
we'll
fall
back
to
target
but
that'll
be
on
our
agenda.
C
Oh
yeah,
this,
but
this
I
don't
think
the
time
for
now
there
was
just
a
proposal
for
monday,
so
that's
gonna
suck
for.
F
Know
east
coast,
I
don't
remember
exactly
which.
C
And
then
john
had
a
john
loves
annotations.
C
B
A
B
C
We
know
what
you
want
next
on
top
of
this
right
is
the
oh
it's
over
in
over
in
the
sdk
right
we
have
with
span,
but
then
we
also
have.
F
B
B
B
A
A
C
Meaning
group:
yes,
yes,
route.
Yes,.
A
A
C
C
C
A
C
So
to
the
question
about
the
route
yeah
yeah.
C
No,
we
so
all
of
our
route,
we
capture
route,
essentially
as
the
span
name,
but
we're
not
currently
setting
the
attribute
the
actual
http
attribute,
but
we
have
most
of
the
instrumentation
mechanism
there
in
place
because
we
already
we
go
through.
We
jump
through
all
these
hoops
to
capture
it.
Essentially,
as
the
span
name.
A
C
We
just
need
to
also
stamp
it
onto
the
span,
but
we,
when
normally
our
instrumentation,
does
server
spans
update,
name
right.
F
F
C
Yeah,
basically,.
C
A
A
C
A
A
D
A
C
A
A
C
Oh
that
one
I
saw
you
replied.
A
C
I'll
open
an
issue
to
discuss
updating
our
pattern
to
this,
and
then
we
can
update
the
docs
at
that
time.
I
agree
that
I
agree.
C
Cool
and
the
main
benefit
here
is
ending
after
closing
the
scope
first
and
also,
I
don't
know
like
this
kind
of
feels
weird
to
me
like
that
this
could
then
catch
the
throwable
from
there.
Also.
F
A
A
A
So
one
like,
for
example,
when
we're
trying
to
detect
the
scope
leaks
like
we
know
that
the
span
ends
after
the
scope
is
closed,
set
the
span
and
there's
a
signal
for
our
scope
leak
checking.
I
think
it
is
in
some
sense,
then,
that
helps
with
that.
A
C
A
C
I'm
gonna
make
nikita
press
the
merge
button
on
this
one.
A
You
don't
like
enum
singletons,
I
just
I
don't.
C
Yeah,
I
just
did
in
this
particular
case
now
that
we,
it
didn't
really
seem
like
they
were.
A
A
Well,
if
they've
been
looking
into
auto
instrumentation
in
the
coming
in
this
operator,
I
don't
know
if
I've
talked
about
that
before
so
we
just
merged
in
support
for
mounting
the
job
agent
automatically
in
kubernetes,
I'm
going
to
look
at
node.js
and
python.
Also
that's
sort
of
fun
to
get
more
auto
instrumentation.
C
So
are
you
doing
the
whole,
like,
I
forget
what
they're
called
and
operate?
Oh
okay,.
C
A
C
Got
it
now?
What
did
somebody
did.
A
A
Open
telemetry
now
for
java,
looking
forward
to
adding
more
languages.
C
C
Cool
well
have
a
good
friday,
and
thanks
for
thanks
for
going
through
the
hitting
the
button
yesterday
was
a
disaster.
C
C
A
A
That's
why
I
was
really
into
doing
this
patch
as
quickly
as
I
could
yeah
there's
some
talk,
there's
still
a
discussion
on
whether
to
use
hotel
for
integrations
internally
or
to
just
use
an
x-ray
custom
thing,
and
I
continue
to
try
to
push
for
hotel
one
of
the
arguments.
They
say
they
might
need
to
have
more
control
like
being
able
to
pick
some
issue
to
come
up
with
as
quickly
as
possible.
F
A
C
Yeah,
I'm
glad
I'm,
I'm
I'm
pretty
happy
about
nebula
going
away.
I
know
the
automation
is
nice,
but
I
think
that
will
make.
Of
course,
if
we
hadn't
got
away
this
problem
wouldn't
have
happened
yeah.
I.
A
C
Do
we
always
do
that
eternal.