►
From YouTube: 2021-05-27 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
A
If
people
can
be
sure
to
add
themselves
to
the
attendees
lists
in
the
sick
dog
here-
and
I
will
give
we'll
give
it
another
couple
of
minutes-
I
think
they
might
be
running
a
little
bit
late.
I
know
I
said
he's
gonna
be
a
little
bit
late
as
well,
so.
A
All
right
laden's
here,
thanks
for
thanks
for
joining
leighton,
I
thought
I
would
have
to
drive
and
I
have
background
music
going
on.
So
I
was
hoping
you
could
live
yeah
sure.
C
C
Hi
yeah,
we
kind
of
awkwardly
put
everyone
on
the
spot.
Who's
new
here
to
just
do
like
a
little
intro
and
then.
A
A
C
Yeah,
no
no
yeah.
D
C
Tell
us
a
little
bit
about
yourself
and
we'll
we'll
introduce
ourselves
as
well.
D
Okay,
hi
everyone.
My
name
is
eunice,
I'm
a
intern
at
aws
right
now,
so
I'm
part
of
the
open,
telemetry
aws
team.
I
guess
so.
I've
just
been
trying
to
work
on
some
issues
like
good
first
issues
on
python
and
like
collector
so
yeah.
A
Nice
to
meet
you
guys,
awesome
nice
nice
to
meet
you
as
well
welcome
I'll
go
next,
I'm
alex
I'm!
A
I
work
at
lightstep
and
I've
been
the
maintainer
of
the
open,
telemetry
python
project,
for
I
don't
know
how
long
now
but
yeah
working
on
all
things
python
and
a
little
bit
all
over
the
place
with
open
telemetry.
So.
C
Yeah,
I
can
go
next
hi,
I'm
leighton.
I
work
at
microsoft,
I'm
the
other
maintainer
for
python
yeah,
not
a
whole
lot.
Interesting
about
me.
It's
that
those
those
are
like
actually
just
my
defining
factors.
So
yeah,
if
you
have
any
questions,
feel
free
to
reach
out.
You
know
we're
pretty
small
but
pretty
engaging
friendly
community.
B
Well
thanks:
yes,
I
work
at
lightsaber
with
alex.
I
am
not
a
maintainer.
I
am
an
approver,
it's
very
important
that
that
distinction
is
clear,
so
yeah
sure
the.
If
there's
anything
I
can
do
to
help
feel
free
to
reach
me.
Welcome
and
good
to
have
you
here.
D
F
You
all
right
I'll
go
next,
I'm
shaykhan!
I
I
work
on
open
telemetry
in
my
free
time.
Welcome
feel
free
to
reach
out
to
any
of
us.
If
you
need
some
help.
C
Feels
sick
wow,
it's
better
how
that
usually
goes
so
yeah
cool
anyways,
all
right,
let's
just
jump
into
the
topics
that
we
have
today
looks
like
someone
put
a
pull
request
in
the
list
of
topics,
but
I
did
pretty
sure
there
was
a
discussion.
A
That
needed
to
be
yeah
yeah.
So
the
reason
why
I
go
ahead
put
this
in
in
the
issue,
issues
that
I
want
to
own.
The
topic
that
I
want
to
talk
about
was
that
the
so
there's
this
pr
that
unes
opened
around
creating
key,
which
I
think
is
good
as
implemented
the
the
problem
that
we're
to
have
is
currently
the
instrumentations
are
using
a
string
as
a
key,
which
is
a
little
a
little
bit
cheating,
because
you
know
it's
a
shared
key
that
the
that
the
instrumentation
just
happened
to
know
about.
A
And
so
the
reason
I
want
to
bring
this
up
in
this
discussion
is
because
we
kind
of
talked
about.
Well.
Maybe
we
put
the
key
as
a
member
in
the
sdk,
which
then
would
mean
that
we
now
have
instrumentation
dependent
on
the
sdk,
which
is
not
great,
and
I
know
there
was
a
discussion
about
this
exact
topic
around
suppressing
instrumentation.
A
B
B
C
It
was
a
there's,
a
related
one,
that,
oh
sorry,
it's
right
here,
yeah
I
was.
I
was
so.
C
Yeah,
like
we
thought
red
dead
like
oh
yeah,
but
it's
just
purple,
we're
looking
for
purple
man,
purple
yeah
that
sucks
so
yeah
they're
still
talking
about
this
and
haven't
really
closed
on
it
yet
or
made
a
decision,
so
it
doesn't
seem
like
there's
any
progress
with
it.
After
that
pr
got
closed
too
so
yeah
so
anyways
like
our
whatever
implementation
that
we
do,
it
will
be
possibly
changed,
based
off
of
the
the
results
of
this
discussion,
anyways
so
like.
C
If,
if
hypothetically
we
choose
to
like
move
it
to
the
like,
maybe
the
instrumentation
package
and
as
alex
is
pointing
out
like
then
the
sdk
would
depend
on
it,
even
if
we
have
that
weird
dependency
tree
and
stuff,
it's
kind
of
like
just
a
temporary
measure.
C
A
I
guess
so.
The
nice
thing
is,
if
we
put
it
in
the
instrumentation,
then
at
least
we're
able
to
move
ahead
with
the
createkey
method,
and
it
just
means
that
at
some
point
we're
going
to
need
to
change
the
import
path
or
whatever.
C
Which
is
which
is
okay?
I
feel
it's
just
that,
like
other,
are
there
any
repercussions
of
like
the
sdk,
take
a
dependency
on
the
instrumentation
library?
It's
the
other
way
around.
C
C
B
Yeah,
so
are
we
should
we
assume
that
this
key
will
never
be
placed
in
the
sdk?
As
far
as
the
specification
is
concerned,.
B
A
A
That
was
also
proposed
that
I
can't
remember
now,
but
I
guess
the
the
nice
thing
is,
if
we
put
it
in
the
instrumentation
package
like
the
open,
telemetry
instrumentation
package,
then
at
least
even
though
we
added
dependency
on
the
s2k
on
the
instrumentation,
we
can
still
change
our
minds
later,
since
that's
not
a
one
dot.
Whatever
package.
B
I
I
just
feel
like
yeah:
we
could
do.
A
A
B
But
that
that
means
this
is
just
it
has
more
than
a
year
being
open.
That
means
it's
just
about
to
be
solved.
C
Good
joke
good
joke
yeah,
but
regardless,
like
we
have
like
this,
the
reason
why
this
was
brought
to
light
was
because
we
were
actually
not
spec
compliant,
for
you
know
our
keys
that
we
create
in
context,
and
it
was
brought
up
because
eunice
made
a
pr
to
change
all
of
that
with
a
kind
of
like
a
hacky
solution
that
we
made
to
be
spec
compliant
but
retain
like
the
string
structure
we
have
for
keys.
C
So
as
part
of
that
cleanup,
you
know
we
found
that
we
needed
to
change,
suppress
instrumentation
as
well.
C
B
C
B
A
F
F
Yeah
still
so
it
has
like
you
know,
leading
underscore,
so
we
we
don't
expect
like
the
end
users
to
rely
on
this.
If
you
are
doing
that,
only
instrumentations
rely
on
it,
so
it
doesn't.
F
So
look
at
the
appear
in
the
main
repo
so
like
right
now,
it's
it's
there
in
sdk
like
if
we
move
the
same
to
the
api,
given
that
it
still
has
the
leading
underscore.
That's
that's
fine.
I
guess.
C
You
mean
in
spam,
processor.
F
C
B
B
C
F
C
B
B
F
B
Maybe
we
should
well,
I
don't
know
how
urgent
this
is,
but
I
kind
of
feel
that
the
right
path
is
just
to
go
through
the
specification
path.
Discuss
this
in
the
specification,
find
a
solution
there
and
then
implement
it
right.
C
C
C
I
mean
that's
fine,
it's
more
like
like
what
I'm.
A
I
guess
the
one
the
other
thing
we
could
do
is
just
like
make
a
decision
and
support
this
as
like
one
way
of
suppressing
instrumentation
and
if
the
spec.
If
and
when
the
spec
decides
of
doing
it
differently,
then
we
can
figure
out
how
to
support
that
instead.
But
I
don't
know
that
might
be
confusing
for
people.
B
Yeah,
but
if
we
do
what
strickland
says
it
won't
be
breaking
because
we
will
just
be
importing
from
a
private
attribute
from
the
api
and
we
don't
add
the
sdk
dependency
to
the
instrumentations.
B
The
instrumentation
package
depend
will
then
depend
on
the
sdk
and
we
don't
want
to
settle
around
no.
C
B
B
A
C
I
guess
the
instrumentation
package,
because
it's
like
all
the
instrumentations
depend
from
it
right.
Another
option
we
could
do
is
just
come
up
with
the
random
dummy
package
like
a
util
package,
or
something
that
you
know
you
know
all
instrumentations
can
extend
from
and
the
sdk
and
it
can
extend
from
two
right.
C
But
I'd
much
rather
not
introduce
new
packages
and
just
for
now
put
this
in.
C
D
A
And
I
mean
I,
you
know:
if
we're
going
to
get
really
technical
here,
I
think
technically,
this
is
actually
a
breaking
change
anyway.
It's
because,
if
someone
out
there
has
an
instrumentation,
that's
using
the
string
because
they've
looked
at
the
code
of
other
instrumentations
and
this
will
be
breaking
them.
D
G
D
A
B
Yeah,
I
think
it
is
equivalent,
if
we
add
it
into
a
package
that
is
still
in
beta
or
if
you
just
prefix
it
with
an
underscore.
I
mean.
B
Yeah
sure
it
is
so
okay
adding
it
from
adding
it
to
the
instrumentation
package.
It
does
not
have
that
disadvantage.
A
I
feel
like,
if
we're
importing
from
a
private,
a
private
member
from
a
public
package,
we'll
just
have
to
add
a
like
fix
me
comment
everywhere.
We
import
it.
B
I
think
no
one
of
us
considers
considers
it
to
be
ideal,
because
we
don't
want
the
sdk
to
depend
on
the
instrumentation
package,
but
it's
the
most
ideal,
most
ideal
solution,
right,
yeah.
F
F
C
Okay
sounds
good,
yeah
we'll
have
this
as
a
temporary
solution.
Okay,
next
thing
is:
do
we
want
eunice
to
do
this?
This
is
it's
kind
of
waiting
on
that.
So
I
guess
you
know,
does
that?
Does
everything
make
sense
about
what
we
were
talking
about
and
why
it's
that
was
blocking
what
you're
doing.
B
A
A
D
C
A
A
C
C
So
everything
else
uses
create
key,
except
this.
A
A
C
Okay,
that's
fine
with
me:
that's
cool
cool
yeah
eunice,
so
you
have
a
ample
time
to
do
this.
It
will
help
you
out
yeah.
D
Awesome
should
I
just
slack
you
guys
on
the
python
channel.
If
I
have
questions
or
how
should
I
go
about
that.
A
I'll
also
have
a
note
in
the
in
the
pr
as
well
regarding
the
decision
to
try
and
clarify
that
for
anybody
who
wasn't
part
of
the
stick,
nice
thanks.
C
Well,
yeah,
speaking
of
that,
so
moving
on
the
next
release,
we're
planning
for
is
june
1st,
so
that
would
be
like
after
the
holidays
for
the
us
guys
so
yeah.
This
is.
B
C
Of
our,
like,
I
guess,
monthly
release
cadence
so
no
surprises
there
also
alex
do
you
know
if
we
wound
up
adding
like
a
note
or
somewhere
that
tells
users
that
we
have
a
monthly
release
cadence.
A
C
C
Okay
cool
remind
me
to
do.
C
C
Nice,
okay,
cool.
Does
anyone
else
have
any
other
topics
that
they
want
to
discuss
before
we
jump
into
the
two
prs
that
we
have.
A
Oh
yeah,
I
just
wanted
to.
I
mentioned
this
in
the
in
the
description
of
the
pr,
but
I
just
wanted
to
make
sure
that
we're
we're
okay
with
the
new
metrics
proto
that
are
going
to
be
made
available
for
the
proto
package.
A
I,
if
you
look
at
the
files
changed,
there's
there's
like
a
you
know,
a
bunch
of
small
changes
here,
but
there's
there's
a
path
in
here.
That's
experimental,
metrics,
config
service
pbs,
which
I
wasn't
sure
if
we
wanted
those
as
like
part
of
the
package
or
not.
A
But
the
but
the
proto
is
stable,
so
this
is
for
the
config
met
like
the
config
service,
which
I
don't
like
it's
not
the
same
as
the
metric,
the
metrics
path,
yeah.
B
B
B
B
C
Yeah,
I'm
pretty
sure
this
is
it's
not
like
a
like
a
misstep
that
they
did
or
something.
A
Yeah
I
mean
there's
a
whole
experimental
folder
in
the
and
the
protos
themselves,
which
is
what
generated
this
code
here.
Okay,.
A
Yeah
my
question
was
just
like:
if
so,
if
we
were
to
release
this,
it
means
that
someone
could
potentially
import
like
protozoa
protos.metrics.experimental.whatever
is
in
this
package
and
like
we
have
the
ability
to
prevent
that
from
happening.
I
guess
but
yeah
I
I
don't
know
what
the
right
thing
is.
C
Right
exactly
yeah,
I
don't
think
this
is
super
important
either.
Oh
well,
my
vote
is
to
just
manually
delete
this.
Remove
these.
A
A
D
A
The
metrics
themselves
are,
except,
for
I
think,
everything
that's
in
this
folder,
or
at
least
I
would
based
on
the
name.
I
would
hope
that
that's
not
actually
that's
not
actually
stable,
because
it
would
be
weird
to
have
that.
F
C
C
Yeah,
okay,
I'm
still
fine
with
removing
it.
A
C
C
F
Yes,
so
like
this
is
pretty
straightforward.
One
question
that
I
wanted
to
ask
is
so
we
have.
We
have
some
classes
which
end
users
don't
really
use
it
directly.
We
only
use
it
so
I
I
made
a
change
which
is
which
is
technically
breaking
but
but
that
that
was
a
little
annoying.
So
I
was
wondering
like
do
we
commit
to
backward
compatibility
for
such
classes
as
well.
C
Can
you
be
a
bit
more
specific
about
the
change
that
you're
referring
to?
I
don't
think
everyone
has
looked
at
this
pr.
F
And
just
right
here
so
this
this
unit
has
a
thrift
url
empty
string.
So
I
I
change
this
to
collector
endpoint,
mandatory
argument.
F
I
I
reverted
it
back,
but
earlier
that
was
the
change
so.
F
C
C
G
It
is
technically
a
break
change,
even
even
though
no
one
is
using
this
yeah,
I'm
sure
no
one
is
using.
This
mgr
will
not
break
anyone's
setup,
but
I
think
if
we,
if
we
make
the
like,
if
you
make
this
breaking
change,
it
will
set
a
precedent
that,
like
yeah,
yes
to
case
basis,
we'll
just
keep
discussing
this
over
and
over
and
over.
So
as
a.
G
It's
better
to
just
follow
like
the
december
and
python
python
conventions,
and
if
it's
a
breaking
change,
even
that
just
don't
don't
do
it
yeah.
A
C
A
I
think
I
feel
like
version
two
of
the
python
remedies
for
open
telemetry
is
gonna,
have
a
lot
more
private
classes,
because
I
feel
like
this.
Collector
class
should
have
been
private,
but.
A
B
C
B
A
A
A
C
Yeah,
diego,
do
you
think
you
can
make
an
issue
for
that?
Just
like
a
tracking
issue.
C
C
Okay,
cool,
so
does
the
what
we
discussed
make
sense
for
this
yeah.
C
Okay,
yeah,
I
think
that's
pretty
much
all
the
discussion
topics
we
have.
Does
anyone
else
have
any
topics
they
want
to
talk
about,
bring
up
or
anything.
C
I
guess
one
thing
that
I
just
bring
up
real,
quick,
so
yeah
so
like
I
added
the
list
of
stuff
that
people
should
look
out
for
when
adding
instrumentations
to
the
contributing,
so
take
be
a
look
out
for
this
and
add
anything
that
you
feel
like
is
mixing,
especially
if
someone,
random
or
new
adds
a
new
instrumentation.
This
would
be
like
a
good
page
to
refer
to
so
yep
just
be
mindful
about
it
cool
right.
C
So
if
no
one
has
any
other
topics,
I
guess
we
can
get
10
minutes
back
and
I'll
see
you
guys
next
week.