►
From YouTube: 2022-07-25 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
C
B
B
A
B
Yeah,
except
it's
that
kind
of
vacation
where
I
don't
have
any
child
care,
so
it's
mostly
just
been.
Oh.
A
A
D
Let
me
put
together
the
agenda
real
quick,
I
already
put
it
and
on
the
slack
channel,
just
grabbing
it
real
quick.
A
D
Why
why
are
we
making
this
difficult?
Okay,
that's
good!
Okay,
I'm
gonna
type
it
out,
because
okay,
so
we're
gonna,
do
front
end
feedback.
So
some
of
the
guys
from
trace
test
put
together
a
pretty
interesting
mock-up.
I
don't
want
to
get
the
front
end
refresh
kind
of
blocks
just
on
the
aesthetics
of
it.
So
I
was
hoping
we
could
go
ahead
and
dig
into
that.
I
also
wanted
to
discuss
kind
of
big
release.
Rocks
remaining
for
the
v1
release
right
now.
It's
pretty
much
from
a
services
perspective.
I
think
it's.
D
D
Needs
flags
and
then
finally,
we
from
an
open,
telemetry
signal
perspective.
I
think
we
still
have
tracing
and
metrics
outstanding.
We
can
take
a
look
at
the
issues
and
see
from
a
tracing
perspective.
How
we're
doing
I
think
most
of
the
services
have
have
at
least
kind
of
one
or
two
tasks
already
checked
off.
I
like
to
go
ahead
and
dive
into
those,
maybe
in
august,
and
get
that
cleaned
up,
and
then
we
can
focus
on
metrics
kind
of
going
forward.
D
Let's
see
giuliana,
I
know
you
and
michael
have
talked
about
like
some
items
around
a
grouping
build
and
like
death
quality
in
general
and
maybe
adding
some
sort
of
testing
to
our
releases.
That
would
be
interesting
to
discuss
and
then
also,
let's
see,
let
me
just
write
this
down.
What
is
that
blankie?
It's
a
little
too
early
for
me
right
now
discuss
so
we
have
a
bunch
of
readmes
across
the
different
services
and
there's
not
really
consistent
information.
D
Sometimes
you
can
build
a
service.
Sometimes
it
says
to
be
added
and
I
just
think
from
a
project
maturity
perspective.
We
should
define
some
sort
of
standard
information
we
want
in
the
readmes
just
so
they
don't
look
like
complete
trash
right
now.
The
open
telemetry
features
earns
a
kind
of
centralized
documents,
so
I'm
not
sure
exactly
what
we
want
to
put
in
the
services
we've
made,
but
it'd
be
good
to
kind
of
just
clean
it
up.
So
once
people
start,
you
know
kind
of
cloning,
it
more
consistently.
D
There's
more
helpful
information
there,
so
standard
info
and
then
blank
on
oh
yeah,
build
a
death
body
cool.
Does
anybody
else
have
any
other
items.
D
No
cool
welcome
back
michael,
I
see
you're
here
too
well,
we
can
go
ahead
and
start
with
the
front
end.
I
know
oscar
wanted
to
quickly
review
kind
of
his
proposal.
He
would
stop
in
some
issues
around
like
grpc
and
react
so
oscar.
Take
it
away.
E
Yeah
sure
thank
you,
so
let
me
just
have
a
screen.
I
have
some
slides
for
you
guys.
Okay,
do
you
mind.
E
Okay,
so
I
think
we
discuss
this.
Let's
click
a
little
bit
in
terms
of
kind
of
the
well
the
ideas
that
we
have
in
terms
of
rebranding
or
refreshing.
The
front
end
as
it
is
currently
a
go
application
ssr
that
just
has
some
templates
that
get
printed
by
by
by
the
server.
E
So
what
we
want
to
do
now
is,
instead
of
instead
of
having
a
fully
ssr
application
when
something
that
is
more
like
commonly
used
something
like
react
and
have
like
a
way
for
us
to
showcase
how
to
instrument
a
react
from
their
browser
side,
application
right.
E
So
basically,
I
started
by
describing
what
are
we
building
here?
So
the
idea
is
there?
It's
an
astronomy
web
store,
matching
the
star
guide
from
open,
telemetry,
io
right
so,
and
we
I
have
the
links
for
the
female
designs
that
we
can
talk
about
them
afterwards
and
then.
E
The
second
point
is
a
real
live
example
of
an
hotel
open
retrospective
web
application
following
the
initial
requirements,
the
requirements
I
found
them
on
the
github
repo-
and
it's
just
like
how
like
the
targeting
of
the
people,
that
we
want
to
get
involved
and
the
system
returns
that
kind
of
stuff.
So
we
are
considering
everything
that
is
described
here
as
well.
E
Okay,
so
I
know
the
proposal
is
divided
into
this
actually
first,
this
is
the
the
current
features
that
the
application
has.
So
it
has
a
broadcast
and
detail
view
a
currency
switcher.
It
has
a
card
management
for
adding
removing
all
of
the
items
or
just
viewing
it.
We
have
a
placing
order,
feature
recommended
products,
promotional
discount
and
products,
so
these
seven
features
is
basically
where
we
can
see
when
we
start
running
the
application
right.
E
So
probably
most
of
you
guys
have
already
seen
this
okay,
so
this
proposal
is
composed
by
these
five
topics,
that
is,
framework
and
tooling
code
like
iteration
structure
in
instrumentation
deployment
and
distribution
and
testing
at
the
end.
So
let's
start
with
the
framework
and
tooling.
So
if
you
have
any
questions,
please
let
me
know
I
can,
I
can
stop
and
we
can
discuss.
E
The
idea
is
to
have
so.
The
initial
idea
was
to
have
a
fully
react
application
only
from
the
browser
and
that
kind
of
stuff.
The
situation
that
I
found
that
I
found
is
that
as
we're
using
geared
pc,
I
think
we
still
need
to
have
some
sort
of
back-end
layer
that
would
communicate
with
internal
services
through
your
pc
and
and
expose
some
sort
of
breast
application
for
the
front
end.
So
in
this
case
we
have
the
key
points
that
we're
going
to
follow
with
this
proposal.
E
That
is
usually
using
something
widely
widely
unknown
right
for
all
other
developers
to
get
familiar
with
easy
to
get
going
and
something
that
we
can
extend
and
customize.
The
proposal
is
to
use
nexus.
E
So
we
have
these
layers.
The
two
is
two
layers
in
one
we
have
using
some
typescript
for
styling.
We
are
going
with
style
components
and
for
io.
I
wanted
to
use
something
that
is
pretty
simple
and
nothing
like
fancy.
That
is
react,
query
and
not
using
state
management,
so
not
involving
stuff.
Like
redux
or
any
type
of
stats
management
that
can
be
more
can
make
this
more
complex
and
it
should
be
pretty
straightforward,
something
that
everyone
can
start
looking
at
and
get
familiar
with.
E
So
this
is
for
the
climate
and
tooling.
Then
we
have
the
code,
architecture
and
structure.
So
the
idea
of
the
key
points
is
to
have
the
files
to
be
easy
to
identify.
So
if
I
want
to
find
some
a
component,
I
can
just
easily
just
click
ctrl
p
and
find
that
component
that
I
want,
or
that
gateway
or
that
unit
is
whatever
following
so
following
some
of
the
best
practices
in
terms
of
okay
business
encapsulation.
E
There
are
in
simple
ways
to
extend
the
code
base
that
kind
of
stuff,
and
the
proposal
is
to
have
separation
concerns
by
creating
services
for
princess
logic,
adding
gateways
for
data
layers
that
I
can
I'm
going
to
explain
that
a
little
bit
more
like
in
details
in
the
next
slide,
auto
generated
types
from
back-end
sources,
so
in
this
case
the
whole
application.
E
The
whole
front
application
is
using
the
types
that
come
from
the
proto
file,
that's
from
the
demo,
so
we
don't
create
any
types
like
ourselves
like
manually
and
separating
the
ui
between
components
and
pages,
so
we
have
reusable
components
and
that
kind
of
stuff,
okay,
so
next
slide,
is
kind
of
the
front-end
data
flow.
A
little
bit.
How
I
explained
you
in
the
in
the
previous
slide,
where
the
next
gs
application
is
going
to
encapsulate
these
two
sites.
E
These
servers
are
rendering
and
it's
going
to
going
to
also
provide
a
bundle
for
the
front
end.
You
know
browser
side
and
nextgs
supports
api
routes,
so
these
api
routes
will
be
something
like
a
middleware
between
the
client
side
and
the
earpiece
year.
Pc
services
are
in
the
in
the
back.
So
next
in
this.
In
this
api
routes
from
the
server
side,
it's
going
to
be
connecting
to
cart
service
product
catalog
recommendations
that
kind
of
stuff
and
provide
this
that
data
in
aggregated
form.
E
So
it
will
be
kind
of
an
aggregation
layer
to
the
front
end,
for
instance,
identify
that
we
have
the
recommendation.
Services
service
returns
a
list
of
ids,
so
we
need
to
merge
those
ids
with
the
pro
catalog
to
produce
kind
of
the
the
different
blocks
in
the
front
end
right.
So
this
kind
of
aggregation
stuff
is
being
made
by
these
api
robs
as
well.
E
Okay,
so
now
that
we
have
a
functional
application
that
does
something
and
that
we
can
showcase,
we
need
to
start
thinking
about
instrumentation
right,
so
the
idea
is
to
have
at
least
some
spa
instrumentation
as
well,
not
only
in
the
back
end
ability
to
visualize
the
end-to-end
process,
all
the
way
from
the
front
end.
E
So
if
I
click
on
order
or
add
to
cart,
I
want
to
see
that
spam
being
generated
propagated
over
the
packing
service
on
this
on
the
next
layer
and
then
over
the
rest
of
the
services
that
are
through
our
gear,
pc
right
all
the
way
to
the
back
in
the
to
the
databases,
locate
the
best
practices
so
also
kind
of.
If
this,
this
front-end
application
will
will
be
a
guide
for
someone
new
that
wants
to
get
involved
into
open,
telemetry,
and
so
the
proposal
is.
E
I
think
this
really
matches
what
the
requirements
say
on
the
in
the
kit
for
repo
that
is
having
auto
instrumentation,
but
also
adding
some
examples
of
more
control,
instrumentation
on
certain
parts
of
the
app
and
include
the
hotel
proprietor
that
is
kind
of
part
of
it.
Okay,
so
the
deployment
distribution-
and
this
is
pretty
much
just
describing
that
we
want
to
follow
the
same
pattern
that
we
have
with
the
rest
of
the
services.
E
We
don't
want
to
have
like
anything,
that
the
same
docker
compose
the
same
docker
image
produces
the
same.
The
exact
same
result
as
the
current
fronted
applications
does
so
there's
no
like
change
changes
on
that,
and
it
should
be
pretty
straightforward
and
just
calling
out
how
we
can
start
deploying
or
distributing
this
next
cs
application
with
a
link
over
here.
E
And
the
last
piece
is
testing,
so
obviously
we
want
to
have
some
sort
of
unit
tests,
so
the
idea
is
to
have
guests
for
unit
tests.
Maybe
we
can
have
something
around
cypress
for
end-to-end
tests,
just
a
pretty
small
like
smoke
tests
and
then,
as
someone
mentioned
in
last
week,
we
can
maybe
start
thinking
about
how
how
we
can
use
some
sort
of
thresh
trace
validation
like
trace
test
right,
okay,
so
right
now,
I'm
going
to
show
you
the
demo,
a
quick
demo.
E
So
what
I
have
here
is
is
the
same
application,
the
same
demo
application,
but
it's
filled
with
next,
so
it's
already
wired
up
with
the
backing
services
and
it
already
has
a
front-end
client-side
application
running
it
it.
It
has
kind
of
the
same,
look
and
feel
I
I
didn't
want
to
kind
of
copy
one
to
one,
because
I
know
that
we're
changing
styles
and
that
kind
of
stuff-
I
I
didn't
want
to
kind
of
spend
too
much
time
on
that,
but
basically
it
has
everything
working.
E
It
has
the
the
currency
changes
feature
it
has
the
product
views
the
products
view,
so
you
can
add
to
the
card.
E
It
has
the
sections
for
the
recommended
products.
It
has
the
footer.
It
has
this
flag
that
actually
we're
using
to
kind
of
showcase
the
platform
that
this
is
running
on.
We
have
the
ad
service
already
wired
up
as
well,
so
this
is
kind
of
a
replica
or
just
the
same
thing
that
you
currently
have
with
go
but
builds
on
an
xgs
and
react.
E
Next
steps:
that's
basically
what
you
say,
update
the
design
think
about
how
we
went
to
the
do
the
deployment
for
this
and
how
we
can
we
want
to
start
instrumenting
yeah.
That's
what
I
want
to
show
you
today
and
maybe
I
guess
lasting
is
just
showing
you
if
you
haven't
seen
it
the
proposal.
So,
within
the
three
system
we
we
have
a
a
designer
she's.
Her
name
is
ollie
and
she's
been
helping
us
with.
We
thought
if
she
got
some
someone
with
you.
E
Can
she
can
help
us
with
this
some
sort
of
design
for
for
the
web
store
following
the
same
styles
and
colors
that
we
have
on
on
the
open,
telemetry
website?
So
she
came
up
with
this,
but
it's
like
kind
of
recording
the
telescopes
and
and
planets,
and
that
kind
of
stuff
that
we
can
add
having
the
colors
keeping
things
like
the
flag.
So
so
this
is
more
like
a
technical
website
right,
it's
not
like
we.
E
We
actually
want
to
send
sell
something,
keeping
the
same
kind
of
session
ideas
and
things
information
that
we
want
for
someone
to
start
debugging
and
that
kind
of
stuff.
But
it
looks
like
closer
to
a
web
store.
B
D
B
B
You
know
kind
of
implementation
and
is
certainly
more
true
to
what
someone
would
probably
use
in
day
to
day
than
what's
there
now,
and
I
think
that's
good,
but
I
think
there's
also
you
know
that
incurs
a
maintenance
burden,
so
I'm
I'm
okay
with
it.
B
I
think
we
would
just
want
to
be
really
sure
that
when
we
bring
it
in
that
you
know,
there's
documentation
and
sort
of
quality
is
is
pretty
high
so
that
someone
that
isn't
familiar
with
you
know,
I'm
I'm
as
anyone
that's
looked
at
the
hotel
site
can
tell
you
I'm
a
danger
to
myself
and
others
with
html
and
css.
I
just
want
someone,
that's
kind
of
my
skill
level
to
be
able
to
take
this,
and
actually
you
know,
modify
it
or
work
with
it
and
not
be
like.
B
E
Okay,
yeah,
it
makes
sense.
Yes,
let
me
just
take
some
notes
like
to
have
start
thinking
about
documentation,
and
so
it
is
easy
to
do.
One
thing.
A
B
E
So
the
idea
around
next
is
that
we
have
this
api
layer
that
communicates
the
client
side
to
the
backend
grpc
services,
the
front-end
side,
all
of
the
pages
and
components
it's
built
in
the
same
way
that
you,
you
will
build
any
react
app.
E
Actually,
I
started
this
place
using
create
direct
app
and
I
just
copy
pasted
the
code
and
just
continue
from
there.
But
yes,
I
understand
your
point.
Yeah.
C
E
D
Is
everyone?
Okay,
with
that
sigma
design
in
mock-ups
that
we
saw
I'm
personally?
Okay
with
it?
I
think
I
prefer
every
product
to
not
be
a
telescope,
so
I
looked
up
some
like
astronomy
items.
That's
a
very,
very
small
yeah!
I
small
item
there.
B
B
Also
I
mean
those
products
are
being
loaded
down
like
those
products
are
coming
from
the
catalog
service
right,
so
there's
and
then,
and
also
when
I
say
about
the
documentation
too,
like
that's
part
of
it
just
right
like
how
do
we
have
you
know
someone
wants
to
go
in
and
add
something
those
are
all
being
coming
through
the
admin
service
or
whatever,
making
sure
that
it's
pretty
easy
for
people
to
add
and
maintain
things
but
yeah.
I
feel
like
the
overall
look
and
feel
is
pretty
good.
D
Yeah,
well,
we
really
appreciate
you
putting
that
together,
oscar
and
I
know
ollie
put
in
a
lot
of
work
as
well,
so
make
sure
you
thank
her
for
us
yeah,
the
front-end
design
looks
great,
definitely
look
forward
to
getting
the
feedback
or
you
know
some
additional
feedback
on
the
different
client
app
itself,
but
it
seems
like
we're
in
a
pretty
good
place
now,
so
should
be
good
you're,
not
blocked
on
the
design.
D
Anything
else
you
want
to
cover
around
the
front.
End
client.
D
D
Okay,
well,
that's
great
looks
like
we're
getting
really
good
progress
there.
I
guess
the
other
kind
of
remaining
item
we
already
mentioned
it,
so
the
admin
service
and
php.
Now
I
haven't
been
able
to
talk
to
timo
the
dev
who
had
volunteered
for
creating
that
service,
but
I
did
see
that
he
forked
the
repo
yesterday,
so
I
kind
of
consider
that
to
be
a
tacit
acknowledgement
of
my
things.
So
hopefully
he
starts
working
on
that.
D
You
know
sometime
this
week
or
next
week,
I'll
kind
of
continue
to
keep
an
eye
on
that
and
see
if
we
can
push
that
forward.
But
that's
really
the
only
remaining
kind
of
outstanding
piece
we
have
and
then
they'll
give
us
a
lot
of
ability
to
update
our
items
and
other
things
and
have
some
fun
with
it
too.
D
So
that
should
be
at
least
mostly
covered
and
we'll
ideally
have
that
you
know
maybe
third
week
august
or
something
so
that
covers
two
of
our
kind
of
big
release
rocks
pierre.
I
know
you've
been
out
on
vacation.
Have
you
had
a
chance
to
think
more
about
the
feature
flag
service
at
all
and
kind
of
a
default
set
of
features,
or
is
that
something
you're
gonna
pick
up
kind
of
going
forward.
F
No,
I
got
I've
got
two
of
them
that
we're
gonna,
I'm
thinking
about
doing
one
of
them
is
going
to
be
just
a
straight
up.
Failure,
the
other
one
will
be
a
latency
issue.
The
state
of
failure
is
I've
got
the
code
written
already
to
do
it.
Do
that
inside
the
product
catalog
service,
basically
we're
going
to
just
fail
on
a
product
and
we'll
just
add
a
product
to
the
load
generator
that
gets
picked
up,
and
it's
going
to
generate
some
kind
of
failure.
F
D
D
Call
at
some
point,
but
I
would
just
create
an
issue
and
probably
like
ping
him
on
the
slack
channel
and
he'll,
be
pretty
responsive
and
then
there's
another.
I
think
elixir,
maybe
erlang
dove
too,
and
I
can't
pronounce
his
name.
I'm
gonna
butcher
it
it's
like
polish.
I
think,
but
he
is
also
very,
very
responsive
and
works
very
closely
with
tristan,
so
those
two
guys
should
be
able
to
get
you
going
pretty
quickly.
F
The
other
one,
which
was
a
perhaps
a
little
bit
more
of
a
complicated
mode.
What
I've
come
up
with
with
try
to
making
it
realistic
as
well
is.
Perhaps
we
cannot
ship
the
actual
jwst
outside
of
the
united
states.
F
So
when
you
have
a
specific
product
combined
with
a
specific
address,
the
shipper
gets
stuck
in
whatever
it
is,
and
latency
comes
back
to
40
seconds.
I
started
going
on
that
path.
I
I
need
a
really.
I
need
to
take
a
rust
tutorial.
Unfortunately,
wrestling
is
a
different
kind
of
language.
Just
like
elixir,
I
look
at
it.
I
go
a
little
screwy,
but
those
are
the
two
scenarios
for
addresses.
I
started
just
coming
up
with
a
bunch
of
addresses
from
very
popular
company
headquarters.
F
The
current
one
in
there
is
google's
headquarters.
For
example,
they
wrote
this
third
thing.
Of
course
their
address
is
inside
there,
so
I
had
amazon
apple.
You
know,
if
you
think
of
like
the
fang,
whatever
door's
all
on
there
netflix
as
well,
any
concerns
about
doing
that.
Just
picking
up
a
bunch
of
big-name
tech
companies
and
using
their
hqs
in
the
addresses.
D
F
Something
like
that,
so
I'll
probably
use
shopify
for
the
one
that
we
can't
ship
to
made
an
address
and
then
we'll
just
call
them
stupid.
Canadians,
I'm
canadian.
So
what
am
I
doing?.
A
A
F
All
right,
so
that's
we're
going
down
that
path.
I
do
have
one
more
question
right
now
what
I
was
doing
inside
the
product
catalog
service.
I
was
just
creating
the
feature
flag.
When
the
thing
starts
up,
that's
likely
not
idea.
How
are
we
what's
the
intent
on
how
we
control
the
feature
flags
and
which
ones
are
enabled
at
startup?
Is
that
gonna
be
like
a
post
scrub
script.
B
Yeah,
I
would
have
thought
it'd
be
part
of
the
edit
script
for
the
database.
Bootstrapping.
B
B
There
is
a
there
is
a
ui,
for
you
could
just
go
in
and
put
it
in
manually,
but
I
would
assume
that
for
stuff
that
we
want
like,
if
I
I
would,
my
assumption
would
be
that
when
you
create
a
flag,
I
mean,
I
suppose
this
there's
a
second
part
of
this.
That
is
the
actual
question,
but
when
you
create
a
flag
in
another
service
and
you
need
to
actually
create
the
flag,
then
flag
creation
should
go
in
the
bootstrapper
for
the
database
and
that
should
actually
create
the
target.
B
Now
I
would
imagine
we
would
want
to
set
everything
by
default
to
like
off.
If
we
just
are
assuming
that
on
means
that
you're
serving
the
variation,
then
everything
should
default
to
off
and
then.
B
A
F
F
I'm
going
to
look
for
the
word
create
here
right,
that's
how
you
create
schema.
B
B
D
F
So
yeah
yeah,
I
would
be
in
the
mindset
of
it's:
it's
everybody's
targeted
it's
off
by
default
and
I'll
even
raise
my
hand
and
saying
you
could
probably
even
with
an
environment
variable
somehow
and
when
we
bootstrap
it
and
elixir,
we
we
turn
them
on
as
well,
instead
of
forcing
them
to
go
into
a
ui.
So
that
way
there
you
can
docker
compose
it.
F
B
That's
the
create
table
so
and
then
I
think
you
could
add
another
migration
and
I
think
it's
just
like,
if
you
add
a
migration
there,
it
just
like
creates
it.
So
what
I
would
imagine
is
we
would
anytime
someone
adds
a
feature
flag,
they
would
add
a
new
migration
script
to
that
and
then,
whenever
it
gets
run
for
the
first
time
it
would
apply
the
migrations.
A
B
F
D
Yeah
we
can,
we
can
take
it
offline,
but.
D
So
I
think
we
had
a
couple
remaining
items,
so
I
first
just
wanted
to
cover
the
the
currents
or
the
service
readme,
so
I
just
opened
up
kind
of
a
selection
of
them.
This
is
the
currency
service,
for
example,
and
I'll
read,
so
you
know
that,
but
it's
a
checkout
service
and
then
we
have
the
cart
service
readme
and
finally,
we
have
the
ad
service
readme.
So
there
are
some
themes.
D
So
I
don't
really
care
if
it's
a
lot
of
info,
but
I
do
feel
like
we
should
have
some
sort
of
like
just
basic
information
available
and
then
we
can
kind
of
enhance
it
from
there
here
and
I
spent
a
lot
of
time
on
the
front
end,
for
example,
and
making
like
the
actual
instrumentation
part
of
the
documentation,
I'm
not
sure
if
we're
there
yet
so
maybe
you
know
whatever
a
kind
of
starting
point
is
and
then
we
can
mature
it
from
there.
C
I
do
have
some
points
that
I
would
like
to
say
when
we
we
did
the
initial
research
to
choose
which
fork
to
use.
We
we
mentioned
that
honeycomb
readmiss
were
really
good,
so
maybe
we
could
try
to
follow
some
some
some
of
the
the
same
approach
that
they
have
where
whenever
we
have
like.
I
don't
know
if
that's
exactly
what
they
have,
but
my
suggestion
would
be.
C
Whenever
there
is
a
auto
instrumentation
or
the
auto
instrumentation,
we
define
there
how
to
use
it
so
or
how
we
use
it
within
the
code
so
like
here
we
create
this
pen
in
a
node,
for
instance,
and
then
you
have
a
snippet
of
the
how
kind
of
re
kind
of
the
docs,
but
in
the
readme,
so
with
the
snippet
of
how
the
trace
is
created,
the
it's
been
attributes-
and
I
don't
know
if
that
in
the
end
will
be
a
lot
of
maintainability
issue,
because
every
time
we
change
that
we
will
need
to
update
the
rhythm
as
well.
F
So
there
was
three
parts:
four
parts,
maybe
even
to
the
our
reviews
that
we
did.
First,
we
talked
about
how
you
bootstrapped
open
telemetry,
and
then
we
talked
about
the
there's.
There's
some
parts
of
the
instrumentation
you
know
for
golang,
specifically
for
other
languages
might
not
be
so
much
but
goaling,
because
everything
is
very
explicit,
there's
no
auto
instrumentation.
F
So
we
we
had
sections
in
there
which
specified
overall,
hey
to
to
instrument
all
the
grpc
endpoints.
This
is
what
we
did
to
instrument
all
the
their
service
and
then
there's
incoming
and
outgoing
endpoints
right.
This
is
what
we
did
for.
This
is
what
we
did
for
that
and
then
the
last
session
was
here's
all
the
things
we
added
manually,
where
you'll
find
them
in
the
code.
F
So
those
are
the
three
sections
we
had
per
service
go
lang
being
so
explicit,
nothing
is
auto,
instrumented.
Clearly,
there's
a
lot
more,
but
if
you
go
in
some
of
the
other
languages
like
java
or
no
there's
very
little
code
to
instrument
things,
it's
just.
How
do
you
bootstrap
it
you're
done.
B
A
B
D
B
D
B
B
It
is
not
intuitive
for
the
amount
of
like
readmes
in
subdirectories
that
we
use
as
a
project
like
people
get.
Our
people
are
very
surprised
when
it's
like
okay,
you
need
to
go
like.
If
you
want
to
find
out
how
to
use
this
particular
collector
component.
You
need
to
like
first
figure
out
which
repo
it's
in
then
you
need
to
figure
out
what
type
of
thing
it
is.
Then
you
need
to
go
into
it.
B
B
B
F
F
Yeah
yeah,
I
just
meant
we,
we
categorize
it
by
language,
whether
it's
done
by
file
or
stuff
headings
inside
of
one
it's
fine.
But
if
I'm
coming
in
to
look
how
to
write,
you
know
how
did
you
intimate
your
grpc
endpoint
and
ruby
yeah?
That
doesn't
exist,
but
you
know-
or
you
know,
how
did
you
instrument
that
in
this
language
I
would
probably
think
about
the
language,
not
the
service
name,.
D
C
C
Like
like
the
austin
idea
of
putting
back
into
the
hotel
website
website,
because
then
in
here,
we
can
keep
the
readmes
to
whoever
wants
to
build
the
app
locally
or
like
modify
it.
If,
for.
C
C
To
the
contributors
and
to
point
people
to
instrumentations,
we
just
point
everyone
to
the
official
docs.
B
Yeah
for
for
1.0
like
when
this
for
1.0
definitely
we
need
to
make
sure
that
these
docs
are
living
on
the
hotel
site
and
that
there's
really
a
great
presentation
for
this
whole
thing
on
the
hotel
site
presentation,
just
like
not
like
a
presentation
like
the
slides
or
whatever,
just
like
the
way
yeah,
we
have
content
built
on
the
site
for
it,
but
yeah,
just
speaking
from
experience
here,
like
my
preferred
way
to
kind
of
treat,
this
is
have
internal
document
readmes,
and
things
like
that
in
the
repo
should
be
internal
documentation
for
people
using
the
code
stuff.
B
A
D
Yeah
we
talked
to
ad
nauseam,
so
I
quickly
wanted
to
discuss
tracings.
That's
probably
like
the
open
telemetry
signal
that
we
need
to
focus
on
next.
D
So
if
you
just
look
at
a
lot
of
tasks,
we've
done
a
decent
amount
of
progress
and
I
need
I
do
need
to
update
these,
because
I
think
one
of
the
tasks
is
not
necessary
at
the
moment
or
at
least
being
covered
twice,
but
I
would
really
love
if
you
know
like
over
august,
we
could
get
to
the
point
where
all
these
tasks
are
done
and
then
we
can
focus
on
metrics
kind
of
going
into
september
to
finish
up
around
there.
D
I
know,
like
the
php
admin
service,
isn't
available
right
now,
so
to
worry
about
that
and
then
the
front
end
service,
even
though
it's
the
most
well
intermittent
one,
it
will
be
replaced
at
some
point,
so
any
suggestions
or
feedback
on
how
we
can
kind
of
push
some
of
these
tasks
to
be
done.
So
we
break
them
up
into
like
individual
issues
and
sort
of
signing
out
kind
of
from
there
or
hoping
people
pick
them
up
any
kind
of
suggestions
from
like.
I
guess
project
governance
of
how
we
can
encourage
this.
D
I
think
part
of
it,
I
think
kind
of
ken
and
the
trace
test
team
had
this
experience.
They
didn't
really
know
where
to
get
started
or
how
to
like
start
helping
until
like
they
talked
to
me,
for
example.
So
maybe
there's
you
know
a
poor
intake
process,
essentially
where
we're
not
doing
a
good
job
of
funneling
people
to
like
the
right
areas.
B
A
B
To
have
a
better
like,
I
think
we
should
talk
about
this
offline
a
little
bit.
But
how
do
we
create
like
a
better
hey,
so
you
want
to
help
out
here's
what
to
do
yeah
yeah
and
then
we
can
maybe
rank
the
priority
of
things
a
bit
more
and
try
to
direct
people
to
it,
and
so
they
know
like
this
is
the
next
most
important
thing.
D
B
E
Yeah
also,
one
thing
is,
I
guess,
good
in
charge
of
moving
the
cards
along
the
way
like
from
doing
progress
like
who
do
we
ask
or
assign
ourselves
or
can
someone
just
are
looking
at
a
ticket
and
assign
themselves
to
it?
What
would
be
the
process?
No,
I
don't
that's
not.
D
Okay,
interesting
yeah,
we
can
talk
about
this
offline
as
well.
I
don't
think
we
have
a
good
answer
right
now,
but
we
should
definitely
start
taking
advantage
of
this
in
some
way.
That
might
be
a
good
way
to
kind
of
push
things
forward.
Yeah.
C
B
I
think
that
would
be
a
great.
You
know
what
I
think.
That
would
be
a
great
thing
to
post
in
the
community
demo
in
the
demo
channel,
and
we
will
all
attempt
to
explain
it
and
through
our
attempts
we
will
come
up
with
the
answer.
B
Yeah,
I
also
have
to
drop
off,
but
it
was
great
seeing
everyone
again,
I'm
really
thrilled
the
progress
here.
I
think
it's
looking
great.
D
Yeah
appreciate
everyone's
support.
Oscar,
please
put
your
powerpoint
like
in
a
slack
channel
or
something
like
that.
So
we
have
our
on
the
meeting
notes.
Just
so
we
have
access
to
it
and
we
can
reference
that
on
our
own
too
that'd
be
really
appreciated,
but.