►
From YouTube: 2021-11-04 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
C
D
I
thought
somebody
was
asking
about
once
again
about
this
meeting
in
alternate
time
zone
friendly
slots.
I
don't
know
if
that
would
be
any
better
for
me,
but
interested
to
see
what
we
come
up
with.
C
Yes,
that's
a
topic
that
probably
should
get
on
the
agenda,
but
probably
should
also
wait
until
tyler
is
around
to
discuss
as
well.
I
think
it
could
be
good
to
go
back
to
an
alternating
schedule.
I
don't
think
we
could
fully
shift
the
schedule
later,
because
there
are
people
who
are
east
coast,
I
believe
or
yeah
errands,
I
think
central
time.
So
we
don't
want
to
make
it
too
late
every
time,
but
being
able
to
support
people
who
want
to
be
involved
from
asia.
Pacific
would
also
be
good.
C
All
right
I'll
give
a
couple
more
minutes
to
see
if
anybody
else
shows
up
and
then
we
can
get
started.
A
I
heard
they
just
announced
their
blizzcon
like
thing
and
it's
gonna
be
in
iceland.
I
believe.
C
Oh,
have
they
announced
a
new
fantasy?
I
haven't
heard
that,
but
it
wouldn't
surprise
me
they've
done
that
I
mean,
obviously
they
didn't
do
it
in
2020
or
2021,
but
getting
a
back
going
again
would
be
nice.
I've
gone
a
couple
times,
reykjavik's
interesting
place.
They've
got
a
really
cool
convention
center.
There.
C
All
right,
if
anybody
else
joins,
they
can
join
light,
and
I
guess
we'll
get
this
conversation
started
eric
you
want
or
aaron.
You
want
to
take
us
away
and
talk
to
your
logging
proposal.
A
A
If
you
actually
turn
those
off
it
really
comes
down
to
their.
I
added
a
namespace
of
debug.
I
didn't
want
to
step
on
the
log
or
logging
namespace,
because
this
is
literally
for
internal
debugging.
Only
and
I
made
a
very
small
api
for
application
developers
to
set
a
logger
of
a
particular
type
to
get
local
logs
from
the
sck
and
then
in
the.
A
Document
just
a
little
bit
of
documentation
internally,
I
expose
the
logger
that
the
user
has
access
to
set
and
I
also
added
a
couple
helper
functions.
I
don't
know
if
those
would
be
useful
and
then
I
only
instrumented
literally
one
spot,
just
to
give
kind
of
an
example
of
how
this
would
show
up
in
the
rest
of
our
code
base
and
then
also
added
setting
up
a
debugger,
the
setting
up
the
debugger
in
the
name
tracer.
A
A
A
Just
to
kind
of
get
information
from
the
hotel
sdk
as
it
is
in
an
application,
a
kind
of
apart
from
everything
else.
So
I'm
looking
for
feedback,
is
it
good?
Do
we
want
something
different,
those
kind
of
thrusts
and
then
there's
a
whole
other
discussion
that
we
probably
need
to
have
at
some
point?
If
we
go
this
route,
is
the
log
r
implementation
uses
a
verbosity
of
like
v1
is
the
default?
V2
is
a
little
bit
more
and
v3
v4
v5
all
the
way
up
to
v10.
A
That
is
exactly
opposite
of
how
we
map
logging
levels
in
the
sig.
So
there
may
be
some
confusion,
but
there
may
not
be
because
that's
closer
to
how
most
of
the
other
go
logging
libraries
work.
A
C
Cool
yeah,
I
I
think
the
sort
of
very
minimal
interface
is
probably
pretty
much
exactly
what
we're
looking
for
right,
something
to
allow
the
the
end
user
or
the
the
application
author
to
say
here:
here's
where
you
go
set
the
logs
and
then
we
can
start
peppering
internally
statements
to
use
it.
I
wonder
if
the
the
debug
package
is
even
needed
if
those
two
functions
that
are
there
for
setting
the
logs
could
just
live
in
the
hotel
package,
but
that's
something
we
can
discuss
I'll.
C
Try
to
leave
some
comments
on
the
the
pr
about
things
like
that.
Thank
you.
B
Yeah,
so
I
guess
three
things
that
I
wanted
to
talk
about.
We've
been
so
I'm
at
care
and
we've
been
using
hotel
package
since
last
may
we
try
to
stay
really
close
up
to
date
and
we
usually
run
into
issues
pretty
quick,
and
so
this
race
condition
one.
This
was
a
bug
that
happened
when
philip
he's
one
of
my
team
members
created
this
pr
to
fix
the
force
flush.
B
B
The
other
thing
is
this
is
the
pr
he
has
it's
actually
now
passing.
I
guess
because
it
is
a
flaky
test
and
we've
got
a
cla
now
so
before
and
now
we
have
a
cla
for
all
of
care.
We
just
got
legal
to
approve
that
last
week
so
before
I
was
contributing
under
a
just
a
personal
cla,
but
now
you
know
our
org
and
my
team
can
contribute
under
care.
Cla
and
that's
the
that'll
be
the
fourth
item
I
wanted
to
talk
about
and
then
the
second
one
was
this
resource
merged
semantics.
B
B
As
a
good
bit
of
work
just
on
our
teams-
and
so
the
fourth
thing
was
you
know,
I've
talked
to
our
cto
about
us,
dedicating
like
more
time
to
help
contribute
with
celery,
go
right
now,
philip-
and
I
we've
been
doing
it
on
this-
you
know
side
of
our
desk,
but
in
q,
starting
in
2022.
We
should
have
dedicated
time.
B
You
know
that
we
can
four
team
members
can
actually
try
to
help
contribute
more
to
this
push
mainly
help
push
the
metrics
package
forward.
You
know
right
now,
that's
where
we're
kind
of
stuck,
you
know
not
everything's
ready,
metrics
tracing
seems
like
it's,
it's
pretty
solid,
but
we
have
a
lot
of
teams
wanting
to
want
to
utilize
metrics,
and
you
know,
there's
just
some
gaps
there
that
we'd
like
to
help
fill
in.
C
Yeah,
that
sounds
wonderful,
any
help
that
we
can
get.
We
are
very
appreciative
of.
I
think
I've
commented
on
this
particular
issue
that
this
is
it's
a
known
gap
that
we
have,
that
the
resource
merged
semantics
right
now
are
not
really
in
a
great
space
kind
of
since
we
we
added
the
schemas
having
to
say
you
know
if
there
are
different
schemas
when
you
try
to
merge
as
an
error
is
not
a
good
result.
C
C
Chigren
has
been
doing
some
work
to
to
get
us
the
the
foundation
of
that
capability,
but
he,
I
think,
is
also
is
working
in
in
his
spare
time
on
the
side
on
this.
I
don't
think
we've
had
anybody
who's
been
dedicated
to
working
on
this
issue.
I
think
it
would
be
great
if,
if
we
could,
in
the
gosig,
provide
a
good
example
of
here's,
how
it
should
be
done
for
for
other
languages,
because
other
languages
are
also
going
to
have
to
do
this
right.
This
is
this
is
going
to
be
a
problem.
C
That's
going
to
come
up
in
every
language.
That's
that's
done
this,
and
this
problem
is
going
to
come
up
in
the
collector
as
well,
because
there
are
going
to
be
resources
coming
in
from
multiple
different
implementations,
multiple
different
services
that
are
at
different
levels
and
for
you
know,
perhaps
an
operator
wants
to
ensure
that
all
of
the
the
data
coming
out
is
at
a
particular
schema.
B
C
Yes,
I
I
think
that
taking
what
tigran
has
done
to
this
point
is
built
a
parser
for
the
schema
definitions.
Basically,
the
the
files
that
say
from
version
1.6
to
1.7
here
are
the
the
fields
that
were
renamed
or
here
are
the
the
events
that
that
need
to
be
changed
into
into.
C
I
forget
exactly
what
sort
of
transformations
are,
but
there's
probably
a
half
dozen
or
more
transformation
types
that
are
defined
in
that
schema,
so
he's
got
a
parser
that
will
give
you
a
data
structure
that
represents
the
transformations
that
are
supposed
to
happen
and
all
the
metadata
necessary
to
affect
them.
C
C
C
Was
basically
all
I
had
well
yeah
that
help
would
be
very
much
appreciated.
I
know
it's
going
to
be
become
more
and
more
of
a
pain,
as
I
think
there's
going
to
be
a
1.8
version
of
the
of
the
spec
and
it's
so
many
conventions
that
are
going
to
be
released
soon
and
those
will
get
updated
and
we'll
try
to
make
sure
that
we
don't
make
the
mistake
of
updating
things
in
core
and
not
updating
the
detectors
and
the
like
and
contrib
again
apologize
for
that.
C
But
it
it's
a
thing
that
may
still
happen
or
you
know.
Maybe
there
will
be
custom,
created,
detectors
or
custom,
creative
resources
that
have
a
particular
schema
version
and
not
having
that
migration
is
going
to
be
more
and
more
painful.
As
time
goes
on.
I
think.
B
Okay,
cool
yeah-
maybe
we
can.
We
can
also
try
to
test
some
of
these
things
before
they
get
released.
You
know
because,
like
so,
we
have
a
lot
of
services.
So
there's
we
have
a
lot
of
areas
where
we
could
try
to
pull
down
a
pr
or
pull
down
a
a
branch
and
then
test
it
on
our
services
and
see
what
breaks
and
what
doesn't.
B
C
All
right
cool
yeah-
and
I
think
that
kind
of
rolls
into
my
next
topic
here,
which
is
a
contrib
release
that
will
be
primarily
to
get
out
the
changes
to
update
all
of
the
components
and
contrib
to
using
the
1.7
semantic
conventions.
I
think
we've
just
got
one
approval
on
that.
Oh
aaron
has
also
approved
it
now
great,
so
we
have
two
approvals.
The
tests,
for
some
reason
have
not
run.
I
will
have
to
kick
those
again,
but
I
will
try
to
get
that
out
this
afternoon.
D
Updated
a
bunch
of
my
code
this
week
to
to
use
that
semantic
conventions
version
and
it
required
no
changes
on
my
part.
C
Yeah
there
haven't
been
a
lot
of
changes
from
one
four
to
one.
Seven,
even
I
think
some
of
the
rpc
conventions
changed.
Some
of
the
kubernetes
convention
names
changed,
but
I
think
that
a
lot
of
them
would
have
changed
in
ways
that
were
transparent
to
the
way
we
generate
them
like
we
do
a
bunch
of
normalization
of
the
identifiers
when
we
generate
the
constants,
so
the
capitalization
of
some
things
have
changed,
but
that
doesn't
affect
us
because
we
re-capitalize
everything
so
yeah
for
from
the
end
user
perspective.
C
And
then
I
think
the
the
other
thing
that
was
in
that
the
the
release
is,
there
was
a
apr
to
enable
the
http,
client,
instrumentation
client
server
instruments,
the
hotel,
http
instrumentation
to
take
a
tracer
provider
out
of
the
currently
active
span
from
the
context,
if
it
wasn't
provided
one
explicitly,
which
I
I
think
is
an
interesting
approach.
C
So
it
decouples
that
from
needing
the
global
tracer
provider
and
can
grab
the
tracer
provider
out
of
a
span
if
one
exists,
which
can
enable
applications
that
might
want
to
run
multiple
tracer
providers
and
not
have
to
worry
about
configuring,
separate
clients
or
separate
servers
to
deal
with
each
of
them.
C
So
as
we
release
that
it
should
be
largely
transparent
to
anybody
who's
using
it,
but
it
would
be
nice
to
know
if
anybody
runs
into
any
issues.
With
that
I
mean,
I
think
that
that's
a
pattern
we
may
want
to
spread
to
more
of
our
instrumentations
as
well,
because
it
can
you
just
take
away
one
more
step
of
configuration
that
people
may
have
to
do.
C
Cool
okay,
so
I
think
we've
made
it
through
all
of
the
agenda.
Is
there
anything
anybody
wants
to
talk
about
any
interesting
use
cases
they've
heard
about
new
wild
applications,
they've
heard
about
using
open,
telemetry
or
anything
like
that.
C
Nope
all
right:
well,
I
guess
we
get
to
end
before
steven
has
to
go
and
everybody
gets
40
minutes.