►
From YouTube: 2021-10-07 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
E
E
E
Okay,
I'll
go
ahead
and
share
this
screen.
This
could
be
a
short
meeting.
You
know,
tyler
is
out
again
this
week.
I
will
be
out
next
week
and
the
week
after
the
only
agenda
item
I
see
currently.
Is
there
a
couple
of
pr's
that
I
would
appreciate
if
we
could
get
reviews
on
so
that
we
could
land
support
for
lambda
in
the
contrib
repository
this
first
one
provides
the
base
support
and
then
the
second
one
is
currently
marked
as
a
draft.
E
It
builds
on
top
of
that
one
and
adds
a
configuration.
You
can
see
just
the
changes
that
would
be
included
in
this
config.
Sorry
in
in
this
commit
here.
E
So
this
this
provides
a
way
to
get
default,
configuration
for
lambda
and
x-ray.
That's
separate
from
the
lambda
interpretation
itself.
We
wanted
to
do
that
to
ensure
that
lambda
could
be
used
generally
and
without
you
know
necessarily
being
tied
to
the
aws
services.
E
So
to
get
reviews
on
that,
I
would
appreciate
that
I
would
like
to
land
that
another
news
we
did
make
a
1.0
release
in
contrib,
releasing
detectors
and
propagators
that
are
fully
stable.
There's
there's
nothing.
We
could
change
about
their
interfaces
now,
since
the
the
implement
interfaces
that
are
in
1.0
core
sdk.
So
that's
all
good
and
yeah.
I
think
that's
that's!
Basically
the
news
that's
happened
in
this
week,
stephen.
I
see
you're.
D
Yeah
I
was
going
to
go:
try
to
dig
up,
there's
there's
a
an
issue
out
there
about
the
about
the
I
think.
It's
the
hotel,
propagators
environment
variable.
I
forgot
the
full
name
of
it.
D
It
acknowledges
that
the
go
sdk
doesn't
support
it
right
now
and
points
out
that
I
think
we
would
need
some
sort
of
registration
facility,
because
we've
shunted
those
propagators
off
into
separate
packages,
probably
with
the
intention
that
most
programs
wouldn't
wind
up
linking
in
propagators
that
they
don't
intend
to
use,
but
the
environment
variable
treats
it
as
if
there's
this
known
universe
of
shorthand
names
for
them,
you
know,
if
you
can
imagine
in
other
programming
languages,
might
be
easier
to
sort
of
load
in
dynamically
on
demand.
D
So
I'm
just
wondering
about
you
know.
I
understand
why
why
it's
kind
of
hard
initially,
but
what
what
designs
you
might
consider
here?
I
was
thinking
of
something
like
maybe
a
call
that
you
can
make.
D
That
would
say
basically
register
all
the
known
propagators
by
name,
like
you
know,
would
you
would
have
to
refer
to
their
packages
and
find
a
string
name
to
a
factory
function
or
something
like
that,
but
I'm
not
really
sure
how
you
could
even
offer
such
a
registration
function
in
a
program
where
you
know
when
you
link
it
without
calling
that
you
never
get
that
dependency.
But
if
you
do
call
the
function
or
something,
then
you
get
it.
Maybe
something
like
a
package
that
you
import
for
side
effect
that
handles
that
registration.
E
Yeah,
so
I
think
there's
also
something
that
needs
to
be
done
about
exporters
as
well,
and
I
think,
build
kit
here.
If
I
I
think
this
is
where
it
happens,.
E
E
Really
the
exact
mechanism
for
invoking
it,
but
here
you
know
it
is
the
the
otlp
exporter
registering
itself
in
an
embed
internet
method,
saying
here
I
am
otlb,
I'm
the
otlp
exporter
so
yeah
this.
E
This
is
a
similar
mechanism
for
saying
here's,
here's
a
place
where
you
can
register
well-known
names
that
can
then
be
referenced
in
an
environment
variable
or
a
config
that
something
can
look
up
and
say:
okay,
I'm
going
to
use
that,
and
I
think
that
yes,
so
for
for
propagators
for
exporters
and
as
dresses
for
for
aggregators
in
in
metrics,
those
could
be
very
valuable.
So
I
think
this
is
the
issue
you
were
talking
about
in
terms
of
propagators
that
liz
had
put.
D
In
a
while
back
right
and
just
to
back
up
to
that
code,
you
were
looking
at.
Isn't
it
the
case
that
if
the
program
didn't
the
program
has
to
somehow
introduce
a
dependency
on
this
package,
let's
say
right
or
either
that
I'm
not
sure
if
these
are,
if
all
these
exporters
are
just
included
in
every
program,
you
know
if
all
that
code
gets
linked
in
or
if
it's
something
that
you
have
to
deliberately
include
the
package.
E
So
so
it'll
be
important
for
side
effects
like
here.
There's
imports
tracing
detects,
which
I
think
by
default
called
an
oclp,
and
this
one
pulls
in
yeager
with
an
import
for
side
effects.
I
think
we
would
want
to
have
just
the
the
registry
that
has
nothing
and
allow
the
application
author
to
say:
here's
the
universe
of
choices
I
want
to
give
the
operator
I'm
going
to
import
all
of
them
for
side
effects.
They
can
choose
at
run
time
which
one
to
use
okay,
so
the
so
the
program.
D
Author
is
unfortunately
still
making
a
best
guess
or
saying
you
know.
I
support
that
environment
variable
you
could
not.
Maybe
I
elect
to
not
support
the
whole
universe
of
you
know
propagators
that
have
a
name
right.
A
Yeah
right
at
some
point
you
either
you
need
to
balance
either
everybody
gets
everything
so
that
you
can
use
whatever
variables
and
it's
even
then.
If
it's
extendable,
I
can
write
a
program
that
uses
an
extension
but
don't
doesn't
import
it
and
then
still
have
the
same
problem
or
we
can
say
you
at
some
point
have
to
choose
which
ones
that
you
want
to
be
able
to
choose
from
so
by.
A
In
this
case,
it
would
be
importing
with
a
side
effect
in
a
similar
way
that
I
would
say,
the
image
package
the
go
image.
So
if
you
want
to
get
jpeg
compression
you
you
import
the
jpeg
for
side
effects
and
you
still
use
images
in
the
base.
D
And
in
this
case,
we
have
a
dedicated
package
that
handles
the
registration,
just
to
look
at
the
example
same
with
built
or
yeah
the
detect
for
jaeger
there.
If,
if
you.
E
Would
the
way
I
would
do
it
is
that
I
would
have
our
exporters
in
their
you
know,
say
in
open,
telemetry
exporters
jager.
Have
it
register
itself
right
there,
so
that
if
you
import
the
yeager
exporter
at
all,
it's
registered
and
available
for
you
for
specifications
by
the
environment
variable
same
thing
with
all
the
propagators
yeah.
They
do
this
here
because
they've
they've
got.
E
You
know
this
is
their
own
implementation
of
this,
and
so
this
this
kind
of
it
it
provides
a
little
bit
of
configuration
through
environment
that
I
think
we
may
have
been
missing
or
that
they
they
had.
This
is
a
conversion
from
oh
open
tracing,
so
they
they
may
be
adjusting
for
some
of
the
the
variables
that
were
there
before
that
we
no
longer
support
yeah.
E
I
I
think
our
our
exporter
packages
would
do
this
so
that,
if
you
import
the
exporter
at
all,
whether
you
use
it
directly
to
set
up
your
default
or
you
just
import
it
for
site
effects
to
make
it
available,
then
it
would
be
available
for
the
the
detecting
exporter.
I
guess
you
would
call
it
right.
You
would
create
a
trace
provider
and
register
with
batcher,
detecting
exporter,
and
it
at
that
run
time
says:
okay,
which
one
should
I
actually
use
of
all
of
the
ones
that
are
available
to
me.
D
Would
you
still
propose
that
there
would
be
a
separate
package
for
registering
the
detection
if
it
sounds
like?
No,
because
if
you
you're
saying,
if
you
just
imported
the
say
the
propagator
package
to
actually
use
it,
that
should
register
it
as
well
right
well,
yeah,
with
a
circular
dependency
between
the
packages.
E
A
So
the
registry
would
live
inside
of
like
propagators
and
then
the
the
individual
types
of
propagators
would
register
with
the
propagators.
A
D
E
A
Wouldn't
the
exporters
wouldn't
that
registry
be
within
the
tracing
package
or
the
equivalent
metrics
patrick
it.
E
Could
could
be
an
sdk
trace
as
well
yeah?
That
might
be
a
sensible
place
for
it.
D
Yeah,
but
I
take
it
that
we
given
our
desire
to
not
force
all
of
these
into
any
one
program.
I
was
wondering
whether
it
would
be
feasible
to
offer
some
sort
of
registration
function.
That
was
like
give
me
all
of
them,
but
the
problem
is
that
all
of
them
is
a
an
evolving
set
right.
It
would
have
to
it
would
introduce
dependencies
on
contrib
I
mean
you
would
have
to
live
out
in
contrib
right
to
right.
E
So
it
would
probably
have
to
live
in
contrib.
Look
at
like
collector.
A
Control
what
my
suggestion
with
that,
for
that
would
be,
would
be
to
dedicate
a
specific
package,
probably
separate
from
both
well
maybe
in
contrib.
That
is
focused
solely
on
the
configuration
of
the
different
environments
of
the
different
components
of
the
sdk.
So
you
wouldn't,
you
would
probably
defer
through
that
to
actually
do
your
config
if
you
are
wanting
a
more
general
purpose,
library
where
it
could
export
whatever
you
want,
based
on
the
environment
variables,
whereas
the
sdk
is
very
focused
laser
focused
on
we're
pluggable.
We
can.
A
E
C
E
So
the
way
that
collector
does
this
both
collector
core
clock
decor
is
very
small
now
but,
contrary
by
load
it
up,
because
it's
got
this
big
list
of
packages
that
it
imports
each
one
of
these
defines
a
component
and
then
it
sets
up
factories
for
these.
So
these
would
be
analogous
to
the
registrations.
E
E
It
would
be
a
import
give
me
all
the
exporters
register
exporters,
whatever
that
package
ends
up
being
named
right
and
then
it's
able
to
make
use
of
it
here
and
then
we
could
similarly
see
you
know,
detecting
export
or
detect
or
whatever
that
interface
ends
up
being
yeah.
D
And
so
because
the
way
that
those
are
collected
in
that
components
package,
if
your
program
touches
that
package,
you've
just
grabbed
hold
of
everything,
but
if
it
does
not
touch
that
package,
your
program
could
be
much
slimmer
right.
So
it's
it's
like
an
opt-in,
it's
part
of
the
source
code.
But
if
you
don't
touch
it
you,
don't
you
don't
get
the
back
the
baggage
of
it.
It's
a
loaded
turner.
E
Let's
see
if
we
go
look
at
the
the
adot
collector,
it
has
the
same
sort
of
thing
right,
but
it's
in
its
main
package.
It
pulls
in
its
own
default
components
package,
and
this
here
is
going
to
pull
in
just
a
much
smaller
list
right,
so
they're
all
still
coming
out
of
collector
contrib,
but
these
are
the
the
curated
list
that
we've
pulled
in
I
mean
since
actually
collector
contrib.
This
is
an
in
an
internal
package.
Nothing
else
can
pull
this
in
any
any
other.
E
B
But
I
don't
think
you
should
be
required
to
use
an
sdk
that
has
that
or
that
loads,
every
single
type
of
aggregator,
for
example,
and
so
we
might
want
to
have
a
registration
so
that
you
could
use
the
views
configuration
but
keep
control
over
which
aggregators
are
actually
linked
in.
I
think
so.
All
this
sounds
good.
I'm
just
adding
to
the
the
need
for
something
like
this.
A
I
also
kind
of
wonder
like
what
is
the
difference
in
size
if
we
just
chose
a
single
set
of
packages
for
each
option
there
in
the
collector,
like
how
big
or
small,
how
much
of
a
difference
does
it
make.
C
But
I
think
the
collector
itself
is
70
megs.
E
Sizeable
difference,
yeah,
actually,
the
the
core
collector
might
be
even
smaller.
Now,
because
we've
moved
so
much
out.
Let
me
let
me
actually
check
out
maine.
D
It's
it's
encouraging
to
say,
you
know,
let's
see
how
small
we
can
make
it,
and
yet,
if
you
were
to
say,
publish
a
program
and
somebody
goes
to
use
it
and
they
say:
hey,
I'm
trying
to
use
the
such-and-such
propagator.
Where
is
it
and
you
tell
them
like?
Oh
well,
I
saved
10k
because
I
omitted
it
like.
I
don't
care.
A
So
but
the
the
counter
argument
to
that
is
we're
not
building
just
an
application
to
do
this,
we're
building
a
library
to
be
consumed
and
like
that
that
I
find
totally
reasonable
in
an
application
that
needs
to
have
that
kind
of
flexibility
like.
I
expect
that
to
be
in
the
collector,
but
I
would
be
hard-pressed
to
use
a
library
that
did
that
to
me.
D
Yeah
yeah,
I
totally
get
it
I'm
just
saying
it's
that
that
transition
from
into
the
sort
of
application
developer
mindset
requires
sort
of.
D
Sort
of
working
against
the
library's
choices
you
know
because
you're
you,
basically
you
have
to
go
shopping
eagerly
because
the
library
specifically
avoided
doing
so
disaggregating.
Everything
like
that.
E
So
the
the
core
collector
build
is
23
megabytes
and
the
contrib
build
is
125.,
so
that's
100,
megabytes
of
extra
stuff
that
comes
along
to
get
all
of
those
components.
I
don't
think
I
have
a
an
a
dot
collector
build
or
do
I
I
do.
Let's
see
what
that
size
is,
that's
that
pulls
in
some
of
those,
but
not
all
of
them,
and
that
is
a
hundred
megs.
So
you
know
there
are
probably
a
few
of
those
components
that
are
a
bulk
of
the
the
size,
like.
E
My
guess
is
that
prometheus
is
a
big
culprit.
There
prometheus
and
grpc.
E
I
think
that's
actually
gone.
It's
using
conf
now.
B
Oh
cool:
well,
it
used
to
be
a
really
large
dependency
there.
I
hope
that's
been
attacked.
E
Yeah,
the
the
collector
config
has
been
very
much
attacked
and
it
continues
to
be
attacked
and
restructured.
D
Well,
thank
you
for
entertaining
this.
You
know
this
is
like
a
topic
to
which
I
continually
refer
returned
to
through
different
angles.
Yeah.
E
This
is,
this
is
a
a
really
good
topic
to
discuss.
I
think
it's
it's
an
important
one
to
discuss,
especially
as
as
josh
mentioned,
we're
we're
going
to
have
to
tackle
it
for
metrics.
I
think
it's
really
nice
to
have
for
exporters
trace
exporters
and
propagators,
but
for
metrics
it
sounds
like
it's
going
to
be
a
must-have
yeah.
We're
gonna
have
to
do
something
there.
D
When
I
looked
at
the
specifications
supported
chart
for
the
environment
variables
and
I
saw
a
few
minuses
in
the
go
column,
I
was
initially
surprised.
Like
I
thought,
wow
I
thought
we
were
sort
of
leaders
of
the
pack
on
all
this
compliance
business
and
then
I
realized
well
but
again
we're
we're
participants.
D
So
some
some
of
those
language
issues
make
this
harder
to
support.
You
know
out
of
the
box,
I
almost
wish
there
was
an
asterisk
next
to
it,
explain
why
it's
a
minus
rather
than
a
plus
like
this
is
not
a
mistake.
This
is
not
laziness.
E
Yeah,
but
I
I
think
we
can-
we
can
get
the
best
of
both
worlds
there
and
and
give
as
much
flexibility
to
the
application
developer
to
choose
how
big
they
want
their
binary
to
be
by
choosing
what
packages
to
include
and
then
give
them
the
ability
to
give
the
operator
flexibility
to
say
at
one
time,
which
ones
do
I
actually
want
to
use.
So
so
would
you.
E
I
I
think
so
I
think
I
would
especially
with
propagators
where
we
would
include
you
know,
trace
context
and
baggage
out
of
the
box
they're
in
the
same
package
as
propagators
anyways
right.
So
if
you've
included
the
thing
that
has
the
registry,
you
you've
included,
trace
context
in
baggage
and
and
others
can
be
brought
in
easily
yeah.
So
I
I
think
we
could
say.
Yes,
we
support
this
environment
variable
it's
up
to
the
application
author,
how
feature-rich
they
choose
to
make
it,
but
that's
a
design
choice.
We've
decided
to
make
okay.
D
B
B
I
continue
to
not
have
prepared
for
a
major
presentation
on
the
state
of
the
metrics
sdk.
Thank
you
anthony
for
the
release.
I
have
two
prs
pending
they're
sort
of
to
me,
like
not
really
big
deals,
they're
they're,
both
both
just
refactorings
and
cleanups
of
the
structure,
but
I
don't
think
I've
really
done
my
enough
sort
of
filing
of
issues
to
to
at
this
point
in
time,
and
you
could
be
we
could
you.
B
I
would
be
justified
to
spend
some
more
time
writing
up
issues
for
what
needs
to
be
done
to
clean
up
the
sdk
you'll
note
that
there's
an
sdk
export
metrics
directory,
it's
completely
a
vestige
of
an
ancient
layout
of
the
package,
and
so
I
I
have
in
mind
cleaning
that
up.
So
one
of
the
pr's
is
just
a
proposed
move
to
start
that
work
and
then
the
others
is
continuing
on
a
path
that
I
discussed
previously.
B
It's
continue
to
assume
that
we're
going
to
keep
this
sdk,
it
just
needs
kind
of
minor
reshuffling
and
a
little
bit
more
development,
which
I
will
continue
to
plan
a
presentation
on
and
then
the
api
again
is
an
open
question.
Do
we
want
to
keep
what's
there?
Do
we
want
to
design
something
completely
new,
but
even
assuming
that
we
keep
the
sdk
there's
this
package
that
we've
created
and
started
creating
moving
stuff
into
called
sdk
api?
B
I
have
a
pending
pr
to
move
everything
else
into
the
sdk
api,
and,
if
you,
if
you
do
that,
what's
nice
is
you
can
you
can
pull
up
godoc
with
the
current
api
and
see
all
that's
there?
There's
nothing
out
like
superfluous.
At
that
point,
and
you
can
see
it
is
a
big
api
and
you
can
see
why
we've
talked
about
or
considered
updating
or
changing
it
or
re
redesigning
it.
B
So
I'm
not
I'm
not
like
there's
no
pressure
for
me
as
far
as
time,
but
if
we
get
this
merged,
you
can
then
begin
to
see
what
the
api
looks
like
the
the
other
pr.
If
you
get
that
merge,
you
can
begin
to
start.
The
sdk
packet
structure
begins
to
make
more
sense,
but
sort
of
they're
two
separate
threads.
B
Neither
of
them
are
major.
So
if
you
feel
like
minor
progress,
these
are
worth
approving.
In
my
opinion,.
B
But
I
do
owe
you
all
a
more
of
a
kind
of
major
presentation
and
I
keep
not
having
time
to
get
ready
for
that.
E
I
think
I've
looked
through
both
of
these
before
they're
all
very
much
just
there's
a
lot
of
things
that
get
renamed,
so
it
should
be
pretty
straightforward
to
review.
E
I
do
like
the
the
change
of
export
kind
selector
to
temporality
selector.
That
seems
to
make
more
sense
to
me.
B
Yeah
I've
been
working
in
the
code.
I
actually
found
a
couple
issues
just
in
the
last
24
hours
as
a
result
of
my
hack
week
that
are
related
to
the
sdk,
not
quite
meeting
my
needs,
and
I
think
they
would
be
uncovered
as
soon
as
you
run
into
the
view
and
try
to
implement
the
view
mechanism
as
well.
That's
stuff
that
I
plan
on
filing
issues
about
because
they're,
not
because
we're
hacking.
That's
why.
E
B
These
are
it's,
I
said
hack
week.
It's
actually
a
three
day
event
we're
in
day
two
right
now
and
I'm
actually
working
on
light
steps
code,
which
means
I
actually
tried.
Wiring
up
the
hotel
go
sdk
to
get
light,
step,
satellites
reporting,
hotel,
metrics
in
order
to
tear
out
some
very
old
code.
That's
actually
reporting
dog
stats.
B
I
did
there's
a
parakeet
living
in
the
house
there
here
it
comes.
B
Yeah,
I'm
not
sure,
but
I'm
I
my
I
work
from
home
now
and
everyone's
away
during
the
day
I
let
the
bird
out,
except
when
I'm
eating,
because
it
gets
on
my
nerves,.
B
Of
my
face
one
time
this
is,
we
got
this
as
a
pandemic
pet
about
a
year
ago,
so
I
don't
know
I
I
like
her.
This
is
named.
Her
name
is
nibble
yeah.
D
B
E
Cool
okay!
If
there
is
nothing
else
to
discuss,
I
think
we
can
I'll
take
a
half
hour
back.