►
From YouTube: 2022-05-23 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
D
E
C
I
went
ahead
and
put
some
agenda
items
coming
up.
The
first
thing
I
wanted
to
quickly
discuss
is
we
have
an
upcoming
american
holiday,
so
I
wasn't
sure
if
we
potentially
wanted
to
cancel
the
meeting
or
if
our
european
friends
still
wanted
to.
You
know
continue
working
through
that
holiday,
I'm
personally,
okay
joining
the
meeting
on
memorial
day
next
week,
but
I
just
wanted
to
check
to
see
if
there
is
any
sense
that
they
wanted
to
hold
it
up
for
the
holiday
or
not.
A
C
D
D
C
Okay,
well,
let's
continue,
I
guess
with
our
report
even
and
I
hope
that
that's
enough
for
the
people
that
need
to
work,
asynchronously,
okay,
so
quick,
repo
update,
we
have
the
code
donated
to
it.
Some
further
cleanup
and
a
review
is
potentially
needed
giuliana,
I'm
not
sure
if
you
and
james
were
able
to
get
a
chance
to
just
look
at
it
and
check
that
the
services
have
all
the
dependencies
removed.
C
C
Let's
see,
michael
maxwell
couldn't
make
the
meeting
but
he's
working
on
setting
up
the
docker
compose,
and
that
would
be
the
first.
You
know
kind
of
big
step
of
we
have
v0
of
our
demo.
We
don't
have
any
of
the
services
changed,
but
we're
able
to
run
the
demo
from
a
docker
compose
and
probably
have
it
on
docker
hub.
F
C
He
has
a
pull
request
open
right
now:
it's
not
ready
to
be
merged
or
reviewed,
or
anything
like
that.
He's
making
good
progress
on
go
and
javascript,
but
is
running
into
some
issues
on
setting
up
docker
on
python,
and
then
he
probably
needs
some
help
validating
he's
following
the
correct
docker
approach
there
too.
So
this
is
a
really
big
step
when
kind
of
getting
our
first
like
public.
C
C
Please
start
trying
to
drive
traffic
and
items
towards
the
repo
start,
opening
issues
and
maybe
having
discussions
and
things
like
that,
the
more
attention
the
repo
is
getting,
the
better
kind
of
from
all
our
perspective,
that
we
will
get
more
contributors
and
also
just
attention
in
general,
and
I
think
with
that,
ready
to
just
review
the
architecture
doc.
The
architecture.
D
D
Pretty
much
ever
all
of
the
comp
like
the
comments
and
feedback
and
everything
that
I've
kind
of
seen,
but
I
just
want
to
go
through
sort
of
a
high
level
point
by
point.
What's
changing
to
the
main
app
to
the
sort
of
the
microservice
demo
app,
there
were
several
services
that
were
duplicative
in
terms
of
language
so,
like
there
were
like
three
python
services
right.
What
we
can
do,
I
think,
is
we
can
swap
out
those.
I
think,
an
eventual.
You
know.
D
That
doesn't
take
away
any
language
coverage,
but
it
covers
those
three
php
would
come
in
as
sort
of
an
admin
panel
for
something
there
is
one
kind
of
question
here,
which
is
a
stateful
component
that
I
need
to
add
in,
but
I
kind
of
feel
like.
If
this
is
microservicey,
then
we
shouldn't
necessarily
have
shared
stateful
components
like
that
and
that
we
would
want
to
either
say
to
basically
for
maintainer
for
a
maintainer
or
someone
that
says.
Oh,
I
want
to
do
you
know
in
my
mind.
D
D
D
Okay,
so
we
can
have
like
the
product
catalog,
my
thought
would
be
is
if
you
did
have
something
like
okay,
there's
a
product
catalog
the
product
catalog
is
talking
to
a
database
that
it
has
stood
up
behind
some
sort
of
abstraction.
Then
either
the
product
catalog
itself
can
expose
some
endpoints
for,
like
the
php
service
to
go
in
and
read
those
you
know
to
do
crud
on
or
vice
versa.
D
D
It
also
lets
us
extend
in
the
future
by
putting
a
mobile
client
version
of
this
repo
that
someone.
You
know
that
we
could
someone
could
write
a
swift,
little
swift,
app
that
could
run
the
ios
simulator
to
replace
the
front
end.
All
I'd
have
to
do
is
talk
to
the
same
endpoints.
The
front
end
does
that
could
also
be
like
a
kotlin
java
or
kotlin
thing
for
android.
D
To
handle
the
case
of
creating
interesting
situations
and
data,
I've
synthesized
a
couple
of
ideas
and
also
tried
to
incorporate
other
things
going
on
in
the
industry
and
suggested
a
feature
flag
service
written
in
erlang,
elixir
and
phoenix
live
view.
I
believe
tristan's
already
kind
of
gone
off
to
the
races
in
this
one.
So
I
hope
we
like
it,
but
this
would
be
something
that
everyone
could
have
running
in
the
application.
D
As
you
know,
other
devs
could
go
and
say
like
okay,
I
want
to
add
a
flag
for
whatever
you
know
this
database
problem
or
this
latency
problem
that
would
show
up
and
then
this
service
would
actually
handle
managing
those
flags,
and
you
know
turning
them
on
and
off
and
so
on
and
so
forth,
and
targeting
all
that,
the
other
nice
thing
about
doing
this
is
it
lets
us
comport
with.
If
has
anyone
heard
of
open
feature,
I
think
so?
D
Okay,
so
open
feature
is
basically
an
attempt
to
standardize
feature
flags,
semantics
and
you
know,
definitions
and
so
forth.
In
the
vein
of
open
telemetry,
they
actually
that
one
other
things
is
creating
future
flag
semantic
conventions
that
align
to
the
hotel
semantic
conventions,
so
I've
linked
those
down
later
in
this
document,
but
as
a
best
practice.
You
know,
I
think,
highlighting
how
people
should
think
about
observability
and
feature
flags
together
makes
a
lot
of
sense
with
this
project
and
it
fills
the
need
of
like
fault
injection
for
orchestration
and
deployment.
D
There
are
some
difficulties
in
supporting
both
of
those
from
the
same
compose
files,
though,
because
I
mean
I
guess
you
could
do
it,
but
there
was
like
differences
in
how
you
would
need
to
deploy
the
collector.
What
collector
configs
you
would
use
for
like
kubernetes
resource
detection,
and
things
like
that.
So
that
is
a
question
of
how
we
want
to
solve
that.
Do
we
want
to
use
someone
in
the
comments
that
suggested
using
compose
to
convert
the
compose
file
to
yaml,
but
again.
D
D
I
need
to
extend,
I
want
to
add,
like
a
custom
attribute
to
an
existing
span,
or
I
want
to
extend
a
trace
coming
from
automatic
instrumentation
with
my
own
span
like
how
do
I
actually
do
that?
I
see
questions
like
this
a
lot
and
talking
to
people,
so
I
think,
having
something
really
specific.
We
can
point
to
in
code,
saying
like
look.
Here's
how
it
works
is
good.
D
Spam,
I
don't
know
what
the
status
of
it
is,
but
I
know
the
sampling
spec
has
a
hint
in
it
to
tell.
I
don't
know
how
supportive
this
is.
This
is
something
that
needs
more
research
first
off
in
the
specific
case
of
this
demo,
I
don't
think
we're
going
to
be
doing
sampling,
so
it's
irrelevant,
for
something
we
should
investigate,
though,
is
that
the
sampling
hints
spec.
D
I
believes
encodes
the
sampling
rate
in
such
a
way
that
downstream
things
like
the
expand,
metrics
processor
could
look
at
and
then
perform
the
calculations
with
respect
to
the
sampling
rate.
So
as
a
simple
example,
if
the
sampling
rate
is
set
to
1
in
100
and
for
a
given
span,
that
would
be
in
the
headers
somehow
or
that
would
be
somewhere
contained
in
the
stuff
that
gets
sampled
in
and
then
when
the
spam
metrics
processor
gets
it
and
calculates
you
know
says:
oh
I'm
going
to
turn
this
into
a
red
metric.
D
C
D
D
I
do
think
in
this
specific
case.
You
know
we
can
be
a
little
aspirational
like
if
we
expect
that
hotel
itself
is
going
to
have
the
necessary
information
to
pass
downstream.
To
say
like
this
is
what
you
need
to
multiply.
Whatever
this
calculation
is
to
get
you
the
true,
you
know
the
true
number
based
off
of
whatever
factor,
then
it's
fine
there's,
also
no
reason
that
we
couldn't
come
back
to
this
and
then
like
a
v1.1
or
whatever
and
build
in
hotel.
D
D
D
Yeah
baggage,
we
should
use
baggage
for
services
we
should
so
for
logs,
because
logs
was
kind
of
underspecified.
I
tried
to
push
a
lot
of
the
logging
questions
out.
I
think
we
should
try
to
right
now.
If
you
look
at
the
microservices
demo
stuff,
it's
extremely
log
heavy.
I
think
we
should
try
to
attach
logs
to.
We
should
turn
logs
into
span
events
where
we
can,
rather
than
have
them
be
logs
for
things
that
we
can't.
Then
we
need
to
use
the
collector
to
capture
the
to
bring
those
in.
D
The
other
thing
that
I
don't
think
is
controversial,
but
I
want
to
call
it
out
is
the
idea
of
having
the
collectors
be
where
most
of
the
kind
of
first
pass
filtering
is
and
not
doing
so?
For
example,
there's
health
checks
in
those
there's
a
health
check
url
and
that
c
sharp
service
that
gets
hit
pretty
constantly.
D
My
suggestion
was
that
we
kind
of
put
all
the
filtering
logic
onto
the
agent
collectors
rather
than
doing
it
both
in
the
sdk.
Some
of
this
would
be
to
reduce
the
complexity
of
the
audience
of
the
instrumentation
and
would
let
us
use
agent
instrumentation
for
stuff,
like
c
sharp,
since
we
wouldn't
have
to
worry
about.
D
Like
how
are
we
gonna
configure
the
instrumentation
if
we're
doing
it
through
auto
instrumentation?
I
think
this
is
one
of
those
things
that
will
probably
evolve
a
little
bit
like
it
might
not
be
possible
in
all
cases,
but
in
general,
if
we're
trying
to
make
it
opinion.
If
we're
trying
to
be
opinionated
about
how
you
should
do
this,
I
think
there's
a
good
argument
for
separation
concerns,
like
the
agent
kind
of
does
the
heavy
lifting
sorry
the
collector
does
the
heavy
lifting
in
terms
of
filtering
and
processing.
D
D
It's
a
non-cncf
thing,
but
I
guess
the
open
feature
is
also
cncf
thing,
but
they're
trying
to
create
a
specification
for
slo
definitions,
so
I
think
it'd
be
good
if
we
shipped
like,
I
think,
it'd
be
really.
I
mean
I
think
we're
gonna
have
to
ship
something
like
in
terms
of
visualization,
so
we're
going
to
need
jager
grafana
prometheus
whatever,
but
I
think
it
would
also
be
good
to
say,
like
okay,
well,
here's
slos
for
sort
of
the
user
journeys
on
this
app.
D
D
People
seemed
really
into
the
docker
compose
stuff.
I
I
don't
think,
there's
a
I
don't
think.
Personally,
I
don't
think
the
overhead
of
running
mini
cube
or
something
is
like.
I
guess
I
haven't
seen
a
great
argument
for
like
why
docker
compose
is
more
lightweight
than
just
running
minicube,
especially
given
the
docker
desktop,
will
install
a
kubernetes
cluster
for
you
like.
It
strikes
me
that
we
would
reduce
complexity
a
lot
by
just
using
kubernetes,
rather
than
docker
plus
kubernetes,
but
there
would
seem
to
be
a
lot
of
momentum
for
docker.
D
A
Daniel,
I
think
I
think
the
main
the
main
point
here
is
like
trying
to
make
as
easy
as
possible
to
non-tech
people
to
spin
up
the
sample,
because
it's
way
easier
to
just
run,
docker
compose
up
then
spin
up
a
cluster
with
mini
cube.
Okay,
it's
one
comment
but
then
running
a
comment
to
deploy
everything.
Well,
I
guess
it's
actually
not
that
much
and
we
could
like
create
a
start
strip
or
whatever.
I
don't
know.
If
people
like
that
approach,
but
yeah,
I
I'm
open
to.
F
D
Just
in
terms
of
like
so
I
tried
I,
I
started
experimenting
with
trying
to
do
some
of
the
like
fancier
collector
stuff,
with
docker
compose,
like
I
tried
turning
on
docker
stats,
receiver
with
docker
compose
and
that
turned
into
a
bit
of
a
headache-
maybe
opera,
probably
operator
but
like
if
you're
running.
If
you're
trying
to
run
the
docker
stats
receiver
on
the
collector,
then
it
needs
to
it
needs
access
to
the
docker
socket.
D
D
Kubernetes
at
least
has
an
easier
integration
story
I
feel
like
because,
regardless
of
how
what
type
of
kubernetes
you're
doing
mini
cube,
k9s
whatever
like
the
api
server,
the
metric
server
like
the
metric
scraping
are
all
just
kind
of
there
and
they
all
work
the
same.
Regardless
of
how
it's
deployed.
B
D
I
mean
I
I
feel
like
you
could
kind
of
get
around
the
storage
problems.
In
my
mind,
the
heart,
the
bigger
thing
with
kubernetes,
like
the
the
thing
that
is
less
good
from
a
ergonomics
perspective,
is
building
and
deploying
like
that
part,
does
suck
more
on
kubernetes
compared
to
you
know,
docker
compose
up
or
docker
compose
build.
G
E
G
Yeah,
I've
had
to
write
a
script
to
specifically
get
around
that
where
I
would
change
to
the
local
repository
rebuild.
It
switch
back
to
the
remote
repository
and
run
that
just
so,
I
can
keep
local
cache
healthy.
It's
it's!
I,
I
think
argo
cd
would
be
a
better
avenue
here
and
it's
a
cncf
thing
as
well.
D
D
F
I
think
what
you
mentioned
earlier
about
the
slos.
I
think
I
write.
I
suggest
that
they're
in
the
channel
with
captain,
I
think,
there's
integrations
between
captain
and
argo.
I
kept
in
watching
the
repository
and
then
triggering
a
deployment
with
argo,
but
I'm
not
an
expert
now
on
this
either,
but
potentially
something
we
could
use
to
solve
both
issues,
but
for
sure
it
supports
not
using
scaffolds
because
for
us
in
donations
we
have
issues
with
the
pull
rate
limits
with
scaffold.
D
So
if
someone
pull,
let's
just
imagine,
someone
pulls
this
and
then
runs
it
without
changing
any
of
the
code.
Ideally,
they
would
pull
whatever
the
current
version
is,
or
whatever
the
match.
Whatever
version
on
docker
hub
or
whatever
container
registry,
you
use,
matches
the
tag
of
the
repo.
So
if
they're
on
main
then
it
gets
whatever
latest
is
from
the
container
registry
and
runs
that
rather
than
having
to
build
everything
locally.
D
H
D
Yeah
I
mean,
and
that's
another
point
I
guess
to
kubernetes-
is
that
it
just
lets
us
use
helm
like
the
bootstrap
scripts
get
smaller
and
smaller,
because
we
can
just
say
like
okay,
well,
here's
the
helm
chart
and
we
could
even
do.
I
would
probably
need
to
do
an
operator.
We
would
do
the
operators
for
the
you
can
tell
helm
to
install
an
operator
for
you
do
all
that
yeah.
H
D
H
D
I
think,
if
we're
on,
if
we're
going
to
specify
only
one
like
if
we're
gonna,
if
we're
gonna
say
like
okay,
this
is
the
only
way
this
deploys
and
then
it
scales
up
gracefully,
which
is
my
preferred
result
then
yeah.
It
should
be.
How
can
we
get
this
to
run
a
mini
cube
because
in
my
mind,
then
your
deployment
scenarios
would
be
local
on
mini
cube
and
then
two
to
some
sort
of
like
managed
cloud
kubernetes.
So
that
would
give
you
your
digital
ocean,
your
gc,
you
know
your
gke,
your
aks,
your
eks.
D
No
yeah,
that's
definitely
like
a
problem,
but
I
think
I
mean
I
think
if
I
mean
part
of
like
this,
I
think
it's
also
probably
important
to
say
like
this
architecture,
stuff
vision
is
sort
of
like
a
v1
like
I'm
trying,
and
I
wanted
to
capture
everything
that
would
let
us
build
into
the
future,
because
I
think
that
there
was
during
sort
of
the
requirements
and
sort
of
like
what
do
we
want
to
do
part
of
this.
There
was
an
expressed
desire
for
like
well.
C
H
C
D
B
Maybe
we
have
one
comment
still
for
the
kubernetes
side,
so
I
think
I
would
have
the
docker
option
as
well
made,
but
the
kubernetes,
if
you
just
create
let's
say,
standard
kubernetes
deployment
so
that
it
runs
on
any
on
mini
cube
and
aws
and
wherever
and
and
yeah,
if
the
load,
balancer
or
or
other
things
need
to
be
done
on
top.
But
we
would
at
least
have
the
very
basic
kubernetes
deployment
to
be
done
in
the
in
the
beginning.
C
C
B
D
C
A
D
Yeah
I
mean
yeah.
This
is
mostly
my
next
steps
on
this,
for
everyone
to
clarify
is
like
I'm
gonna
go,
translate
this
into
github
issues
and
projects.
So
you
know
if
we
want
to
change
some
of
those
to
be
like.
If
I
go
make
a
open,
slo
issue,
then
we
can
move
that
to
a
different.
You
know
we
can
say
like
okay,
this
isn't
blocking
for
v1
or
whatever
right.
C
D
C
D
Cool
I
said
I
will
get
some
probably
later
today.
I
will
go
get
these
some
issues
I'll
start
getting
some
issues
and
projects
built
on
the
repo,
so
that
people
can
start
I'm
probably
going
to
make
like
pretty
wide
ranging
ones.
And
then
people
can
create
sub
issue.
You
can
create
smaller
ones
for
individual
tasks
they
want
to
tackle,
but
I
want
to
make
sure
that
we
have
like
some
high
level
ones
to
be
able
to
throw
into
a
project
board.
C
D
C
And
then
okay,
so
austin's
gonna
be
adding
some
github
issues.
So
we're
gonna
move
the
discussions
there,
giuliano
james.
They
could
maybe
give
michael
a
little
bit
of
feedback
on
his
docker
approach.
So
we
can
hopefully
get
that
closed
at
least
an
initial
version
pretty
soon
and
then
we'll
we'll
continue
from
there
awesome.