►
From YouTube: 2022-06-27 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
A
B
Hey,
hopefully,
we
have
some
more
people
join,
trying
to
figure
out
all
the.
B
Let's
see,
I
think,
we're
pretty
much
ready
feel
free
to
keep
adding
some
agenda
items.
I
know
we
have
a
lot
overall
and
I
probably
missed
a
couple
so
feel
free
to
go
ahead
and
grab
them.
We
can
go
ahead
and
probably
get
started
too.
B
So
we
have
a
lot
of
items
and
I
think,
first
of
all,
since
it's
fourth
of
july
next
week
it
probably
makes
no
sense
just
to
cancel
the
meeting,
because
I
think
you
know
pretty
much.
Every
american
will
be
out,
so
we
can
go
ahead
and
make
that
decision.
At
least
I
don't
think
james
is
on
the
call,
but
he
had
a
couple
developer
quality
items.
We
also
there's
a
load.
B
B
There
is
an
issue
for
that
yeah,
I
think
dimitri
from
splunk
like
I
opened
it,
and
then
I
took
a
look
and
tried
to
build
it
on
my
own,
and
I
also
had
issues.
B
B
Come
on
here
we
go,
we
have
a
default
feature
flag
set.
We
need
to
talk
about
so
tristan
and
the
erlang
sig
implemented
the
feature
flag
service,
but
we
don't
have
a
default
feature.
Flag
kind
of
use
case
set
yet
so
we
need
to
spend
some
time
talking
about
that.
We
can
also
spend
some
time
on
v1
metric
requirements.
B
I
know
ziki
just
implemented
metrics
using
prometheus,
our
back
end
and
our
front
ends,
but
now
we
want
to
go
to
grafana
at
some
point
and
then
we
need
to
set
the
v1
requirements
like
we
did
for
tracing.
This,
probably
isn't
like
a
huge
priority
for
us
today,
so
we
can.
We
can
probably
move
it
down
if
we
need
to,
and
the
documentation
structure
is
kind
of
not
really
like
thought
out
at
this
point.
B
So
if
anyone's
really
passionate
about
like
setting
up
our
docs
in
a
more
sustainable
way,
I
definitely
love
some
feedback.
Otherwise
we
can
create
some
issues
around
it
and
then
also
I'll
spend
some
time
thinking
about
how
we
can
align
like
the
service
docs.
You
know
like
generic
hotel
demo,
you
know
kind
of
feature
docs
and
then
maybe
some
of
the
components
as
well
and
then
finally,
there's
also
this
kind
of
ongoing
grpc
health
probe
kind
of
feature
request.
B
C
Yeah,
I'm
not
for
adding
service
names
to
the
attribute
names
yeah.
I
am
for
adding
context
names
for
them,
though,
and
I
think
maybe
I
should
be
more
clear
in
the
comments
like
I
think,
there's
one
question
there:
it's
like
something
that
adds
that
count.
Well,
that's
counting
the
number
of
ads.
Yes,
the
service
is
called
the
ad
service,
but
it's
counting
the
number
of
ads
as
well.
So
what
do
we
call
that
attribute.
B
C
E
Pack,
every
everything
is
going
to
have
the
service
dot
name
resource
and
it's
a
service.name
resource
filled
in
so
we
automatically
get
so
any
anything
will
have
the
service
name
embedded
in
it.
My
two
cents
is.
E
Like
I
think,
there's
a
difference
between
the
service
name
and
the
contextual
actions
captured
by
the
terminology,
so
saying
like
app
ads
is
fine
like
maybe
we
could
you
know
if
we
wanted
to
really
bite
shed
like
what
does
that
look
like
in
terms
like
what
happens,
for
example
in
I
don't
know
card
service
right,
or
maybe
we
do
a.
E
The
reason
I
would
think
you
need
to
name
space
this
stuff
is
because
you
would
have
multiple
uses
of
the
context
of
the
last
thing
in
the
name:
space
or
the
actual
primary
key
being
used
in
multiple
services,
so
that
you
would
need
a
way
to
disambiguate
between
service,
a
and
service
b.
For,
like
an
alerting
situation
where
you
can't
do
multivariate
alerting
right,
because
but
I'm
multiple
area
learning,
because.
E
C
C
So
what
a
document
which
is
also
we,
I
think
we
logged
an
issue
for
this
already,
but
a
a
document
that
has
all
the
attribute
names
listed
which
service
they
belong
to
is
something
we
can
reference
to
make
sure.
As
we're
developing
this,
we
don't
find
ourselves
in
the
we're
going
to
shoot
ourselves
a
foot-
I
guess
yeah.
So
we
make
sure
that
we're
doing
this.
C
E
E
A
E
A
C
With
all
the
custom
attribute
names
that
we
have
maybe
even
details
on,
why
we're
speeding
up
spaces
or
certain
spots,
and
eventually
we
have
the
custom
metric
names
where
they
are
and
how
we're
naming
them
with
the
quick
description
for
each
one.
So
I
think
what
I'll
do
is.
C
Going
on
that,
and
as
we
do
more
instrumentation
we'll
fill
out
that
that
document,
so
we.
A
B
Okay,
so
let's
talk
about
the
default
feature
set
for
erlang,
so
we
need
to
come
up
with
some
requirements
for
tristan
to
actually
implement,
and
then
we
can,
you
know
maybe
make
write
like
some
sort
of
blog
or
announcement
piece
for,
like
specifically
the
erlang
aspect
of
it,
because
I
know
we
introduced
it
like
a
week
ago,
but
there's
not
really
much
going
on
in
it
now
so
do
we
have
any
specific
desired
scenarios
you
want
to
start
with,
maybe
some
fault
injection
or
something
like
that.
E
Yeah
here
you
have
like
here's,
the
stuff
that
you
all
just
get
kind
of
gesturing
here
in
the
real
world.
A
C
Yeah
ours
was,
we
did
a
lot
to
make
it
break.
I
learned
breaking
a
demo
is
not
easy,
especially
if
you
want
to
repeat
it
on
a
consistent
basis
to
make
the
brake
feel
real.
What
we
did
was
we.
A
C
C
But
there
would
be
three
or
four
hours
of
calm
period
before
the
event
would
happen.
Then
it
would
repeat
itself
because
once
you
own
the
box,
you
bring
cash
back
down
to
zero
and
then
you're
good
and
we
would
grow
cash
exponentially.
So
the
higher
it
got,
the
faster
it
grew,
and
so
it
created
kind
of
like
a
little
hockey
sticker.
C
D
C
A
lot
of
really
specific
code
in
there
to
do
that
and
we
don't
have
users
necessarily
right.
We
have
sessions.
E
E
A
E
E
E
C
You're
giving
me
an
idea
to
this
and
right
now
the
load
generator
only
generates
an
order
for
a
single
person
or
single
address.
We
can
absolutely
add
more
addresses
to
the
load.
Generator
generate
more
different
kinds
of
data
coming
into
the
app,
and
we
could
do
this
where
we
have
a
problem
in
the
shipping
service
where,
for
whatever
reason,
we
cannot
all
of
a
sudden
ship
to
a
specific
destination
and
that's
your
problem
and
that
would
show
up
in
ohio,
probably
even
owen
seconds.
C
E
C
I
think
we
have
to
figure
out
how
to
mop
that
up
a
little
bit,
but
because
we're
going
to
tie
a
database
to
that
shipping
service
who
can
make
it
feel
like
we're,
calling
a
third-party
shipping
company
and
that's
where
the
problem
happens.
B
Yeah
that'd
be
cool,
michael
armand.
Do
you
all
have
any
potential
scenarios
you'd
like
to
see.
A
No
not
really-
and
I
have
a
bit
of
a
hard
time
following
with
all
of
the
the
noise
in
the
background-
to
be
honest.
Sorry
about
that,
but
I
think
you're
they're
getting
along
well
with
each
other.
So
no
problem.
B
Great
so
michael
since
you're
already
talking,
let's
go
ahead
and
switch
to
the
grpc
health
probe
question
real,
quick.
D
Yeah,
so
the
idea
is
to
add
the
grpc
health
probe
binary
to
the
repository,
so
it
did
live
in
like
the
get
of
the
repository
so
yeah
at
the
bottom
of
this
bug.
I
listed
some
of
the
some
of
like
the
main
points
that
I
like
accumulated
yeah.
So,
like
one
of
the
reasons
I
thought
was,
you
know
just
keep
it
simple.
D
D
I
thought,
like
everybody,
can
do
the
git
clone
the
same
way,
regardless
of
like
operating
system
and
whatnot,
and
then
some
other
things
was
no
network
dependency
to
build
the
images
after
cloning.
D
The
repository
so
like
yeah
you
get
clone
is
the
only
like
actual
thing
you
actually
have
to
do,
and
then
you
can
unplug
your
ethernet,
cable
and
then
yeah,
just
reducing
the
the
the
need
to
even
have
like
wget
or
curl
in
the
build
image,
and
then
just
another
like
perk
was
so
currently
how
it
was
being
done
was
there's
like
a
w
get
command
in
each
of
the
docker
files.
That's
basically
the
same,
and
then
keeping
the
same
version
number
between
those.
It's
just
a
little
bit
easier.
D
If
you
have
just
the
one
file
in
the
repository
rather
than
having
to
download
it
from
the
the
github
releases,
every
time
and
yeah,
the
downside,
I
guess
is
like
saving
binaries
into
into
get
repositories
is
usually
like
considered
a
no-no,
and
you
know
this
that'll
increase
the
size
by
the
10
megabytes
of
the
of
the
executable.
E
So
a
quick
question:
I
is
there
a
reason
like
this
is
the
same
binary
and
it
needs
to
live
at
roughly
the
same
place
for
android.
E
Yeah,
so
why
can't
we
create
a
image
layer
and
that
way
like
it
only
gets
to
be.
We
create
an
image
layer
and
docker
or
through
a
container
image
layer.
You
push
that
and
then
you
don't
push
it
like.
You
can
just
define
it
once
and
as
long
as
it's
the
same
between
all
of
the
things
like
it
would
get
cached
and
reused
by
the
right
plate.
E
But
if
we
assume
that
you
have
network
access
to
get
phone,
then
we
probably
should
assume
that
you
have
network
access
like
you
can't
build
without
network
access
anyway,
because
you
need
all
the
runtimes.
Oh,
you
need
all
of
our
container
images
so,
like
yeah,
like
I
get
wanting
to
not
have
to
read
downloaded
every
time,
we
definitely
don't
want
to
re-download
that
layer
every
time,
but
we
should
be
able
to
just
create.
D
D
E
I
you
know
like
normally,
I
would
agree
with
you,
but
given
sort
of
that
there's
been
some
pushback
on
this.
I
think
we
should
find
like
something
that
is
both
simple
and
elegant,
and
I
think
the
shared
image
would
be
the
best
for
the
simplest
simplicity
and
elegance.
B
A
E
I
I'd
have
to
go
look
up
how
you
do.
I
don't
have
to
go.
Look
up
exactly
the
way
that
they
cache
things,
but
I
think
if
you
either
there
are
two
options
would
be
one
is
that
we
define
it
in
a
separate
docker
file
and
then
the
build
scripts
kind
of
merge
the
docker
files
together.
E
The
other
is
that
we
can
just
have
an
action
to
publish
just
that
one
thing
to
docker
hub
or
whatever
I
don't
know.
I
think
maybe
someone
should
like.
I
could
look
into
this,
but
it's
not
going
to
be
until
this
week.
If
someone
has
time
to
investigate
this,
you
know
maybe
I'm
maybe
it
would
be
more
trouble
than
it's
worth
and
if
it's
more
trouble
than
it's
worth,
then
I
think
our
fallback
option
should
be
in
the
init
or
like
pre-build.
D
E
E
B
B
E
D
B
Okay,
so
let's
talk
about,
I
guess
metric
requirements
and
maybe
our
metrics
set
up
generally.
Let's
see
metrics
should
not
be
duplicative
shouldn't
that
multiple
business
metrics
were
appropriate
exemplars.
So
this
is.
This
is
fairly
high
level.
I
don't
know
if
we
want
to
have
a
requirements
based
around
specific
metrics
being
collected.
Maybe
should
we
have
like
a
multiple
instruments
to
be
present
requirements,
or
something
like
that?
B
I
see
like
multiple
business
metrics.
How
can
we
a
bit
for
the
teams
to
understand
what
actually
should
be
implemented
or
would
we
prefer
to
give
them
more
flexibility
and
what
we're
doing.
B
B
A
But
I
I
could
imagine
that
we,
I
don't
know
yes,
says
not
no
trace
derived,
so
we
won't
be
counting
requests
and
I
can
come
up
with
anything
other
than
request
counting
for
a
counter
right
now.
But
I
guess
we'll
like
gauge
the
request
size,
for
example,
and
there
will
certainly
also
be
something
about
errors,
like
maybe
counting
errors
or
something.
B
B
A
Don't
really
know
how
to
how
to
interpret
it
either.
Maybe
we
can
ask
austin
on
slack
if,
if
he
can
refine
it.
B
Yeah,
I
think
I
think
he
just
dropped
because
he
probably
had
to
move
somewhere
for
the
conference,
so
I'll
follow
up
on
the
baggage
requirement,
but
it
seems
from
like
a
actual
metric
requirement
perspective.
It's
really
just
service
metrics
should
not
deduplicate
multiple
business
metrics
and
then
also
trace
exemplars,
and
I
guess,
push
metrics
technically,
but
besides
that
that
should
only
be
the
only
service
requirements,
at
least
I'm
aware
of.
Do
we
do
we
have
any
more
we
would
like
to
put
on
them
or
do
we
think
this
is
like
an
appropriate
representation.
B
I'm
gonna
make
a
note
to
follow
up
with
austin
about
what
he
intends
for
the
the
baggage
for
metrics,
I'm
just
not
familiar
with
metric
package.
I
can
also
look
into
it
electric
baggage
and
then
all
these
service
requirements
are
probably
down.
B
Maybe
that
for
now-
and
I
think
james
nolan
had
some
developer
quality
of
life
items,
I
don't
think
he
or
julianna
were
here,
so
we
don't
need
to
address
those
right
now
with
weight.
I
guess
we're
two
weeks.
B
I
think
we're
pretty
much
covered
most
of
our
agenda
once
again,
please,
let's
get
some
eyes
on
the
generator
bug,
so
we
can
ensure
that
the
demo
application
is
actually
working
correctly
when
everyone's
trying
to
get
clone
it,
and
then
we
can
kind
of
push
forward
on
all
these
other
work
items
that
I
think
we
already
delineated
to
have
some
ownership
on
any
other.
Like
items
they're
top
of
mind
kind
of
thoughts,
perspective.
D
B
Beautiful
yeah,
I
think
it
was
some
sort
of
like
python
version
change
or
something
like
that,
but
yeah,
okay,
we
can
call
it
here,
really
appreciate
y'all
taking
a
time
to
join,
and
I
hope
you
have
a
nice
rest
of
your
day
or
night
and
no
meeting
next
week
and
I'll.
C
I
should
probably
clarify
this
as
well:
I'm
gonna
be
on
vacation
for
the
following
week:
okay,
so
I'll
miss
that
but
I'll
be
around
I'll,
be
in
the
slack
channel
I'll,
be
trying
to
find
this
job
and
I'll
definitely
get
them.
Some
of
these
bugs
the
pr's
and
the
documentation
thing
that
going
to
do
this
week.
B
Okay,
yeah
just
make
sure
to
out
of
your
vacation.
I
think
there's
like
a
maintainers
like
vacation
excel
sheet,
or
something
like
that.
I
think
artman
probably
knows
better
than
me,
but
just
go
ahead
and
add
your
time
on
it,
and
hopefully
we
can
start
kind
of
building
that
muscle
memory
to
use
it.
But.