►
From YouTube: 2022-05-09 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
Well,
I'm
technically
on
vacation
so
can't
complain.
A
A
Thanks
for
doing
that,
repo
research,
though
I
took
a
look
at
the
document
put
together,
it
seemed
pretty
comprehensive.
B
Cool
yeah,
I
I'd
like
to
share
a
bit
with
everyone
later
on.
I
think
we
will
have
some
time
for
that
right.
A
A
All
right,
we'll
give
everyone,
probably
two
more
minutes
to
join,
looks
like
we're
at
10.
16
right
now
feel
free
to
go
to
the
google
doc
and
put
in
you
know
you
as
an
attendee
and
also
have
any
agenda
items
that
are
top
of
mind.
I
think
we're
going
to
start
off
with
a
demo
recommendation
from
giuliano,
but
we'll
give
it
a
couple
minutes.
First,.
D
A
Okay,
so
I
think
we're
about
ready
to
get
started.
I
know
morgan
usually
joins
about
like
15
minutes
after
since
he
has
some
sort
of
conflict,
so
hey
everyone
good
morning,
good
afternoon,
thanks
for
joining
this
is
our
second
meeting
of
the
community
demo
sig,
which
is
really
exciting
for
our
agenda.
Today,
I
put
together
a
quick
kind
of
draft.
A
The
first
thing
we're
going
to
do
is:
have
giuliano
who's
been
putting
in
a
lot
of
work
along
with
james
and
pierre,
I
think
michael
to
go
through
the
existing
demos
and
understand
what
the
what
the
existing
ones
have
to
offer,
and
also
what
our
recommendation
would
be
to
start
with,
like
a
fork
or
a
copy
over
into
our
repo.
A
Hopefully
I
think
I
already
reviewed
the
documentation,
but
hopefully
we
can
close
on
whatever
chosen
demo
app.
We
want
sometime
this
week
and
go
ahead
and
get
that
in
the
repo,
so
we
can
start
hit
the
ground
running
and
then
kind
of
continue
on
from
there.
After
that
it
would.
We
have
two
items
kind
of
around
the
application
and
the
system
requirements.
I
think
the
system
requirements
item
probably
won't
take
that
long.
I.
A
A
bit
about
what
our
kind
of
minimum
system
requirements
may
be
and
if
they're
different
from
docker
in
any
way
and
then
finally,
if
we
have
the
time
at
the
end,
we
can
start
the
architectural
conversation.
I
think
part
of
that
would
be
ensuring
that
for
the
application
requirements
either
any
open
questions
are
surfaced
or
we
can.
A
Sounds
like
a
no
okay
giuliano,
I
will
stop
sharing
my
screen
and
I'll.
Let
you
take
it
from
here
for
a
quick
presentation.
B
Awesome
thanks
first
of
all,
thanks
pierre
and
thanks
so
also
james.
That
is
not
here,
but,
as
is,
it
is
recorded.
So
we
went
through
a
couple
of
samples,
basically
the
main
gcp,
the
light
step
fork.
This
plant
fork,
honeycomb,
fork
and
well
the
fork
that
I
have
and
observe
kate's
demo
from
all
of
those
we
kind
of
took
into
consideration
a
couple
of
criteria
like
how
to
deploy
how
much
we
need
to
change
to
become
that,
so
the
sample
becomes
becomes
vendor
vendor
agnostic.
B
How
up
to
date
is
the
project,
how
many
technologies
that
is
common
to
all
of
them
if
hotel
is
already
present
and
any
extra
thoughts
that
we
had.
During
this
analysis
and
after
a
couple
of
reviews,
we
got
some
conclusion
here
that
the
fork
that
I
have
would
be
the
cleanest
one.
So
there's,
as
I
mentioned
in
the
previous
call,
there
is
no
vendor
or
anything
in
there.
B
Only
open
telemetry
and
my
first
commit
was
cleaning
up
all
the
google
stuff
or
we
could
even
go
to
the
main
gcp
repo,
because
that's
where
the
we
have
more
people
like
more
community
involved,
so
that
would
require
some
cleaning
up
first
and
adding
the
open
telemetry
that
I
already
have
some
sort
of
in
my
fork,
but
in
the
main
ripple,
maybe
we
could
send
a
pr
later
on
like
hey.
This
is
the
open,
the
lantern
instrumentation,
if
you
guys
would
like
to
to
to
merge
or
not
but
kind
of
contributing
back.
B
Another
thing
that
james
considered
was
that
my
fork
is
a
fresh
fork.
Sort
of
so
I
do
not
have
that
much
history
in
honeycomb
and
also
lightstep.
B
B
Feel
right
but
yeah
we
went
through
and
it's
good
that
I
have
er
here
because
he
revealed
my
fork
so
maybe
pierre
they
would
like
to.
Would
you
like
to
add
some.
F
Things
no,
I
I
actually
call
my
king
waking
up
and
coming
up
to
this
before
even
reading
your
recommendations,
that
your
fork
should
be
the
one
that
we
start
with,
because
it
is
the
cleanest
it's
closest
to
what
we
have
in
gcp's
main
repo.
Today,
I
like
the
approach
of
perhaps
doing
a
feature
branch
on
gcp,
but
I
I
don't
know
what
the
kind
of
complications
that
has
and
given
that
there's
two
distinct
goals.
This
one
here
is
to
show
off
open
telemetry
that
wants
to
show
off
more
gcp
technologies
but
yeah.
B
Cool
awesome
thanks.
We
also
added
some
some
stuff
here
that
it's
really
great
from
the
from
the
records
that
we
checked,
so
we
could
kind
of
have
it
as
well.
So
in
the
honeycomb
there
is
a
lot
of
mock
individuals.
B
What
is
nice,
but
maybe
we
should,
if
we
would
like
to
have
some
dv
calls,
maybe
add,
adb
and
then
have
a
really
instrumented
db
call,
and
then
we
have
like
something.
That's
real.
B
I
also
liked
a
lot
the
readmes
on
the
honeycomb,
so
maybe
something
that
we
could
take
a
look
and
add
into
our
because
they
really
detailed
everything
in
the
in
the
hack
in
the
repo
and
well
lightstep.
They
really
used
a
lot
of
their
own
stuff.
B
E
What
version
for
giuliano
for
yours,
what
version
of
the
hotel
instrumentation
is
it
at
and
how
I
said,
two
questions,
one:
what
version
of
a
hotel
is
it
just
cause?
I'm
looking
at
your
fork,
and
it
seems
like
a
couple
months
ago
for
a
lot
of
this
stuff
yeah.
E
Yep,
the
second
one
is
istio.
You
kept
istio
in
this.
B
I
tried
to
kept
as
original
as
the
main
record
as
possible,
but
I'm
not
using
it
and
I
haven't
touched
it
okay.
So
that's
also
a
good,
a
good
point
hosting
that
I
forgot
to
mention
in
my
case
I'm
only
using
the
automatic
instrumentation.
So
there
is
no
manual
response.
E
B
And
in
honeycomb
they
have
manual
response
as
well,
so
something
that
we
it's
nice
to
bring
to
the
to
the
group.
F
E
G
Giuliano
is
the
all
the
languages
for
the
the
project.
Those
are
all
the
same
from
the
gcp
for.
A
One
of
the
issues
with
using
the
google
or
updating
the
google
version
is,
I
think
they
own
open
census,
and
so
this
is
kind
of
technically
like
an
open
census
demo.
So
I'm
not
sure
if
they
would
be
open
just
to
ditching
that
support
and
their
demo
itself.
It
would
probably
be
simpler
just
to
start
if
we're
going
to
do
that,
just
start
with
our
own
and
go
from
there.
If
I
can
talk
to
aaron
or.
E
Josh
the
whole
point
of
this
was
that
open
tracing
and
open
census
merge
into
one
thing
so.
G
E
Census
then
we
need
to
go
back
in
time
and
have
some
conversations.
I
think
that's
the.
C
Common
understanding,
but
as
far
as
I'm
aware,
there
is
no
timeline
for
the
sunset
quite
yet,
and
that
will
most
likely
depend
depend
on
that.
One.
E
I
thought
it
was
metrics.
Ga
was
their
timeline
so
next
week,
but
yeah
whatever
that's
a
separate
point.
I
would
actually
agree,
though
we
don't
need
to
necessarily.
E
E
Things
so
backwards
compatibility
shouldn't
be
an
explicit
goal
or
easy
up
streaming
back
to
google
like
this
should
be
the
fork
that
we
built,
or
this
should
be
the
new
foundation
that
we
and
other
people
build
off
of.
C
A
A
Any
other
feedback
from
the
team.
H
Yeah,
I
think
I'm
lalit
from
one
of
the
c
plus
plus,
so
I
think,
I'm
more
interested
from
the
perspective
of
c
plus
plus,
which
is
one
of
the
language
missing
in
this
demo
micro
service
application,
and
I
think
it
would
be
missing
in
all
of
them.
So
I
don't
think
that
should
be
the
criteria
for
selecting,
but
I
just
want
to
see.
I
haven't
gone
through
this
micro
service
demo
application,
but
I
do
see
some
of
the
languages
represented
multiple
times
like
node.js
python,
go
anybody
who
has
gone
through
this
application.
H
I
mean:
do
you
think
that
we
can
replace
one
of
them?
That
would
be
one
of
the
way
out
that
if
we
can
use
c
plus
plus
for
one
of
those
applications,
I
mean
which
have
been
already
have
a
service
there.
We
we
have
discussed
this
in
our
secret
place
community
and
we
thought
about
multiple
options.
One
of
them.
One
of
the
options
I'm
saying
is
to
have
a
separate
service
for
c
plus
plus,
so
we
can
replace
one
of
the
existing
languages.
H
Other
options
could
be
hosting
the
existing
one
of
the
existing
services
using
nginx
or
apache
web
server
in
c
plus
plus.
We
do
have
nginx
and
apache
webseveral
instrumentation
available,
so
that
could
be
other
other
way
of
integrating
c,
plus
plus,
or
probably
we
can
use
and
c
plus
plus
library,
and
we
can
call
that
library
from
say
python
as
existing
service
and
that
would
show
us
how
how
we
can
have
spam
properly
propagation
across
multiple
languages
in
process
and
propagation
across
multiple
languages.
H
F
Of
the
10
core
services
plus
load
generator,
so
11,
if
you
think
about
it
in
this
stack,
only
two
of
them
have
real
logic
to
them,
which
would
be
the
front
end
and
the
checkout
service,
which
are
both
in
golang.
Everything
else
is
really
just
it's
it's.
F
You
know
it's
serving
up,
grpc,
it's
doing
very
simple
responses,
back,
there's,
no
real
business
logic.
To
any
of
this,
I
don't
see
any
big
lift
in
rewriting
any
of
the
services
outside
of
checkout
and
front
end
within
another
language,
so
that
that
could
be
an
option
as
well,
rather
than
trying
to
fit
another
kind
of
service
or
a
call
out
to
this.
E
Design
thing
my
thought
was
actually
that
we
could
pretty
easily
integrate
c,
plus,
plus
and
erlang
and
php,
and
things
into
a
new
set
of
services
that
exist
kind
of
like
an
admin
service
right
that
exists
separately
of
this,
but
actually
make
it
for
feature
flagging,
so
that
effectively
write
a
little
companion
service
that
has
like
a
php
front
end
and
then
a
c
plus,
plus
or
erlang
backend.
That
services
can
register
to
to
control
feature
flags
right
in
real
time.
That
kind
of
solves
the.
E
You
know
messing
with
existing
stuff
or
trying
to
you
know,
fantabulize,
some
c
plus
plus
version
of
the
checkout
or
the
redis
or
whatever
or
not
redis.
But
you
know
one
of
one
of
these
microservices
and
say
like
okay.
Well,
here's
just
like
a
new
c
plus.
You
know
service
running
behind
nginx
right.
A
It
seems
to
be
getting
into
kind
of
the
architectural
discussion
part
and
I
do
love
it.
Thanks
for
surfacing
some
kind
of
options
for
c
plus
plus.
We
want
to
close
on
the
system
and
application
requirements
first
and
then
start
the
full
kind
of
proposal
for
service
replacement,
and
things
like
that.
H
A
Yeah,
I
think
we'll
need
proposals,
probably
in
the
next.
You
know
week
or
two
for
new
services
and
language
support,
and
things
like
that.
So
definitely
you
know.
A
Right
there
at
the
moment,
but
let's
just
try
and
use
our
time
effectively.
Okay,
so,
let's
start
with
system
requirements,
so
it
has
to
support
windows,
linux
or
mac.
We've
talked
about
using
docker
compose
and
docker,
it's
kind
of
an
easily
leveraged
technology
to
run
locally
and
also
run
it
on
maybe
a
platform
vendor,
or
something
like
that
as
well.
So
I
know
actually
linked
to
it.
Doctor
docker
has
specific
requirements
for
like
linux,
windows,
mac,
etc.
Do
we
want
to
go
below
those
requirements?
Austin?
A
I
know
you've
talked
about
like
a
graceful
degradation
like
say,
you're,
on
a
lockdown
corporate
laptop,
but
do
we
really
envision
supporting
you
know
below
docker.
E
The
more
I
think
about
it,
the
more
that
I
think
the
degradation,
the
degradation
pathway
here
is
simply
that
you
have
to
run
it
in
the
cloud
right,
because
if
you
are
on
some
machine
where
you
don't
have
you
know,
docker
access,
let's
assume
worst
case
scenes
like
you,
don't
have
docker
and
you
can't
install
docker,
because
you
don't
have
those
buttons
from
your
it
people,
then
your
only
real
option
in
that
case
would
be
a
cloud
deployment.
E
E
Right
but
that's
kind
of
the
I
intended
way
to
do
it,
and
then
local
local
run
is
more
for
people
that
have
that
kind
of
flexibility
or
are
doing
development
or
whatever.
E
C
Is
a
reasonable
requirement
and
if
that's
not
the
case,
going
going
in
the
cloud
with
with
some
with
some
deployment
guidelines
like
pierre
mentioned
should
be
the
way
to
go.
A
A
Okay,
how
close
it
is
awesome,
okay,
application
requirements,
let's
see
so
every
supported,
open,
telemetry
language
that
has
a
ga
sdk
for
traces,
which
essentially,
I
think,
every
language.
At
this
point
I
think
I
checked
with
all
the
communities,
so
it
must
have
at
least
one
service
example.
A
B
Gonna
keep
going
until
I
hear
just
one
thing:
what
about
php,
because
I
know
that's
not
ga
for
traces.
B
E
C
And
also
we
have
great
king
from
the
php
maintainers
to
help
us
out
there.
A
Yeah,
unfortunately,
bob's
not
on
the
call
right
now,
but
he
seems
to
be,
you
know,
really
passionate
about
the
area
and,
of
course,
as
a
phd
maintainer
as
well.
So
I
think
we
should
definitely
plan
on
support
for
them
and
making
sure
that's
represented
too.
So,
let's
reference
a
carve
out
for
php
for
now.
E
Also,
as
a
side
note,
I
think
it'll
be
beneficial
in
showing
a
collector
deployment
that
is
doing
both
grpc
and
http
otlp,
because
I've
talked
to
customers
who
can't
do
grpc
due
to
like
proxy
security
proxies
or
stuff,
and
they
have
to
use
http,
so
I
think,
being
able
to
have
a
demo
of
like
hey.
This
is
how
this
is
http
otlp
versus
grpc
otlp
will
be
useful.
A
Yeah
we
can
call
that
out
and
one
of
pierre's
readme's
they're
one
of
the
added
ones
too,
but
yeah.
I
think
that
dovetails
nicely
into
kind
of
trying
to
keep
the
application
language
processes-
language
independent,
if
possible.
So
we
already
talked
about
using
grpc
where
it's
supported
but,
of
course
introducing
http
as
well,
where
it's
not
supported
for
things
like
php.
A
I
think
we
should
all
are
all
be
agreed
here
at
least
see
any
other
comments.
Nope,
okay,
keep
going
so
services
should
be
architected
just
to
be
modular
in
general.
I
think
that
we
already
talked
about
how
the
business
logic
is
fairly
simple
for
a
lot
of
these,
but
we
should,
I
think,
plan
on
having
multiple
services
or
multiple
languages
available
per
some
of
these
services.
So
I
think
austin
had
a
comment
of
a
lot
of
customers
in
the
wild
or
in
production,
or
only
using
like
three
languages
or
something
like
that.
A
A
Okay,
no
comments
there.
I
believe
we
already
have
a
load
generator
available,
at
least
in
juliano's
versions
application,
but
we
need
to
ensure
that
you
know
if
a
customer
deploys
an
application,
traces
and
metrics
and
that
type
of
thing
are
actually
being
generated,
and
this
is
finally
kind
of
more
of
an
architecture
question.
But
it's
a
requirement.
A
We
should
plan
on
possible
integration
for
generic
platform
components,
whether
that's
a
sql
database,
a
redis
cache.
You
know
queue,
something
like
that.
I
don't
think
we
have
a
specific
requirement
around
what
must
be
implemented,
but
we
should
at
least
plan
for
some
of
these.
You
know
components
to
be
generated
unless
anyone's
I'm
specifically
passionate
about
one
or
the
other.
A
Okay
sounds
like
that's
confirmed
as
well,
so
we
have
a
stretch
goal.
I
think
this
was
recently
mentioned,
I'm
not
sure
cyril's
on
the
call,
but
we
talked
about
integrating
like
traceable,
continuous
integration
into
things,
as
well
kind
of
probably
more
on
the
stretch
goal
end
austin,
I'm
not
sure
where
you
exactly
envisioned.
It's
probably
not
like
a
p0
to
me.
If
I
had
to
guess.
E
I
wouldn't
say
it's
a
p0,
but
I
do,
I
feel
like
to
kind
of
achieve
the
the
one
thing
that
all
of
these
do
speaking
generally
about
these
sort
of
demo.
E
Apps
is
they
they
do
do
a
good
job
of
like
showing
instrumentation
at
the
service
level
right,
but
a
big
part
of
open
telemetry
is
the
collector
story
and
a
part
of
that
is
the
operator,
and
so
I
think
we
that's
why
I
kind
of
went
out
ahead
and
said,
like
oh
we're,
gonna
have
to
use
kubernetes
at
the
end
of
the
day,
but
if
we
have
kubernetes,
if
we
have
these
things,
then
we
should
you
know
we
can
resolve
a
lot
of
pain
points
about
like
development
deployment.
E
Things
like
that
by
baking
in
ci,
cd
and
making
this
as
close
to
a
kind
of
you
know,
production
system
is
possible
right,
so
I'm
not
saying
we
have
to
do
it
for
you
know
when
we
start
talking
about
this,
but
I
do
think
we
should
at
least
plan
the
work,
and
you
know
put
it
out
there
and
say
like
this
is
a
design.
This
is
a
goal.
B
So
can
I
just
bring
some
concern.
I
I'm
just
worried
about
the
the
size
of
this,
because
the
hipster
shop
is
already
big.
It
requires
a
bit
of
memory
and
cpu
to
run,
and
if
you
take
a
look
at
the
key8
demo,
they
have
prometheus.
They
have
the
operator
the
open
telemetry
operator.
They
have
graphene
at
tempo.
They
have
fluent
operator
in
lucky
so
like
that
just
builds
up
on
top
of
the
hipster
shop.
That
is
already
big.
E
I
mean,
I
think
it's
one
of
those
things
where
it's
like
you
just
have
flags
right,
like
you
probably
wouldn't
want
to
like
that's
what
I
was
getting
at
earlier
when
I
was
saying
like
the
the
preferred
deployment
method
should
be
to
the
cloud
like
if
you're
deploying
this
into
some
managed
kubernetes,
then
you
get
the
whole
enchilada
right,
but
if
you're
running
this
locally,
then
you
get
the
baby
enchilada
and
the
baby
enchilada
doesn't
come
with.
You
know,
argo
or
jenkins
or
whatever,
but
yeah
sounds
good.
E
I
think
observe
you
know
for
if
this
is
like
again,
if
we're
talking
about
observability
right
and
we're
talking
about
like
trying
to
do
we're
trying
to
do
something
that
shows
off
open
telemetry
as
this
foundational
observability
component,
then
I
think
it
does
behoove
us
to
consider
like
people
that
aren't
app
devs
also
want
observability
people.
You
know
esser
people
that
are
running
ci
cd
systems
want
it.
E
You
know,
there's
this
big
range
of
kind
of
use
cases,
so
I
want
us
to
make
sure
that
we
are
being
as
broad
as
we
can
in
terms
of
like
what
can
be
traced
right.
How
can
we
hand
people
something
that
can
say
like
look?
This
is
what
you
can
do
when
you
kind
of
take
observability
as
like
a
day,
zero
concern
and
you
integrate
it
everywhere
and
now
you
have
all
this
visibility
in
the
stuff
and
it
also
puts
a
lot
of
hooks
in
for
future
development
right.
E
If
you've
got
an
instrumented,
ci
cd
system,
then
you
could
start
to
like.
So
we
could
go
off
and
write
a
bunch
of
like
unit
tests
and
trace
those
right,
and
then
you
could
kind
of
see
that
in
your
ci
cd
traces.
So
there's
a
lot
of
interesting.
You
know
opportunities
for
people
to
expand,
but
I
think
we
have
to
build
with
that
in
mind
and
to
me.
A
Okay,
cool
seems
like
we're
settled
here,
and
I
put
some
notes
on
the
other
google
doc
as
well:
okay,
so
for
open
telemetry
requirements.
I
think
a
lot
of
y'all
have
seen
these
already
and
the
first
one's
kind
of
rehashing
then
slightly
different
wording,
the
first
one,
but
essentially,
if
a
signal
sdk
is
ga,
it
must
be
represented
and
if
it's
beta,
we
may
optionally
add
that
if
we
so
choose
and
in
general
native
native
hotel
metrics
should
be
produced
out
of
the
box.
A
A
That
sounds
good.
So
I
I
originally
had
core
er
logs
as
kind
of
a
stretch
goal,
but
I
was
talking
to
josh
ceres
and
he
was
talking
about
how
you
know
one
of
the
main
benefits
of.
If
you
identify
something
that
goes
wrong,
saying
specific
trace.
You
would
have
that
trace
id
and
then
correlate
that
back
to
a
log
as
well.
So
I
know
like
the
log
sdk
and
api
space,
maybe
isn't
quite
as
mature,
or
it
definitely
isn't
across
like
the
different
languages.
A
A
Requirement
we're
available
we'll
put
that
we'll
include
logs
here,
too
traces
and
logs
out
of
the
box.
Okay,
I
think
the
next
item
is
requirements
around
auto
instrumentation
or
instrumentation
libraries.
It
gets
kind
of
confusing
where
we
use
the
terminology,
sometimes
and
manual
instrumentation
must
be
present.
I
believe
I
think,
for
giuliana's
example:
we'd
have
to
manually
instrument
some
traces,
so
that
would
be
like
a
gap
there,
but
we
should
try
where
possible,
to
demonstrate
kind
of
both.
So
customers
always
have
that
example.
H
Sorry,
I
think
for
auto
instrumentation.
Can
we
say
that
wherever
possible,
because
languages
like
c
plus
plus
which
are
natively
compiled,
they
cannot
have
auto
instrumentation
yeah.
E
D
E
A
Yeah,
but
thanks
for
that
call
out
lala,
that's
that's
good
wording
choice
there.
Definitely
something
to
be
aware
of-
and
I
think
this
was
kind
of
agreed
on
by
everyone
that
plus
one
a
comment,
but
so
all
data
will
be
sent
to
the
collector
first
we're
going
with
a
reference,
collector
architecture,
and
I
believe,
there's
also
some
comments
around
kubernetes
as
well,
but
essentially
a
gateway
collector
will
be
present
to
collect
all
the
data
and
then
forward
that
to
our
favored
or
chosen
configured.
What
have
you
visualization
experience
any
concerns
here.
A
Nope
sounds
good.
Okay,
final
one,
that's
exciting!
So
to
close
our
requirements,
so
we're
using
open
source
kind
of
we'll
have
probably
some
sort
of
preferred
open
source,
visualization
experience
and,
of
course
you
can
add
in
you
know,
configurable
whatever
your
options
are
as
well,
so
for
traces,
it'll,
probably
be
jager
out
of
the
box
and
then
for
grafana
or
for
metrics,
we'll,
probably
use
grafana
out
of
the
box,
or
something
like
that
as
well,
and
then
also
optionally,
give
customers
just
the
flexibility
to
change
that
too.
A
F
E
I
I
wouldn't
know
sorry
it
does
not,
it
would
have
to
be
open,
search
or
elasticsearch
or
something.
A
E
Like
our
native
experience,
I
don't
think
there's
anything
out
there
free
other
than
like.
I
guess
grafana.
Would
let
you
like
your
final
lets.
You
query
es
or
os
right,
so
you
could
like
create
a
grafana
dashboard
that
let
you
search
logs.
I
believe.
A
Okay
I'll
list
it
as
yeah
I
listed
as
an
open
question
for
now,
and
we
can
go
ahead
and
close
that
before
we
move
on
to
architecture.
I
think
I
captured,
like
our
target
personas
from
last
week,
essentially
we're
looking
at
enthusiasts.
So
this
is
like
individual
devs
trying
to
like
advocate
for
open
telemetry
within
their
group,
so
they
you
know,
potentially
need
a
full-fledged
example
to
kind
of
show
off
into
the
details.
A
We're
also
looking
at
developers
just
at
a
kind
of
more
scoped
level,
they're
trying
to
see
outside
their
maybe
service,
how
things
integrate.
We're
also
optionally,
looking
to
support
apm
vendors.
But
if
you
can,
you
know
explore
adopting
open
telemetry
for
their
own
services
and
then
also
for
existing
open,
telemetry
apm
vendors.
A
They
can
use
this
as
kind
of
a
hub
to
build
their
own
demo
off
of
and
whereas
gcp
kind
of
had
a
bunch
of
forks
going
off
of
that
and
then
finally,
just
enterprises
looking
to
adopt
the
new
instrumentation
from
a
more
sophisticated
perspective
they
may
want
to
like
holistically,
see
what
production
app
looks
like.
So
these
are
the
users
we're
targeting
and,
of
course
we
have
the
application
requirements
as
well,
so
before
I
hand
it
over
to
the
architectural
discussion,
any
any
final
comments,
questions.
A
Okay,
so
the
application
requirements
are
settled.
We
have
our
system
requirements
settled,
we
will
be
forking
or
copying
over
giuliano's,
open,
telemetry
application,
and
I
think
the
only
kind
of
open
questions
we
have
now
besides
vlogs
are
around
our
architecture
and
then
finally
making
a
roadmap
and
prioritizing
that
from
there
so
austin.
You
want
me
to
go
ahead
and
open
up
the
document
you
shared
or
would
you.
E
E
Up
to
you,
you
can
go
ahead
and
drive
it's
pretty
basic
right
now.
I
only
had
a
little
bit
of
time
to
work
on
it
and
I
sent
it
to
morgan
and
then
I
don't
know
if
morgan
have
a
chance
to
look
at
it.
E
E
A
E
There's
also,
we
want
to
do
if
we
want
to
talk
through
these,
so
the
the
four
like
top
level
ones
are.
We
want
a
robust
sample
app
for
developers,
learning
hotel
instrumentation.
We
want
to
give
vendors
kind
of
a
canonical
reference,
something
that
they
can,
because
I
know
like
pierre.
You
were
saying,
like
it'd,
be
great
to
have
an
aks
it'd
be
great
to
have.
You
know
digitalocean
things
like
that.
E
I
don't
necessarily
want
us
to
be
on
the
hook
for
having
to
provide
all
those,
but
I
do
want
us
to
have
a
base
that
someone.
You
know
that
someone
at
honeycomb
could
take
it
and
say:
oh
we're
gonna
make
that
we're
gonna
cr
easily
create
like
the
aws
deployment
scripts
for
this
right
or
the
stuff
that
you
need
to
do,
to
throw
it
onto
amazon,
kubernetes
service
and
then
contribute
those
upstream.
E
So
the
goal
is
making
this
easy
for
people
to
contribute
back
to
third
goal,
the
sort
of
living
artifact
that
demonstrate
that's
kept
up
to
date.
That
demonstrates
the
features
also.
I
think
this
resolves
tension
on
the
maintainers
and
each
sig
to
give
them
a
place
to
be
like
a
good
demo.
App
or
not,
I
mean,
might
say
good.
E
I
mean
real,
I
guess
more
real
than
just
like
hello,
world
or
fibonacci
sequence
or
or
whatever,
so
that
when
they're
doing
updates,
they
can
go
back
and
make
changes
here
to
see
how
they
work,
which
goes
into
the
fourth
one,
which
is
actually
to
give.
You
know
when
people
want
to
do
an
otep
right
or
they
want
to
like
prototype
some
new
piece
of
functionality.
Then
here's
kind
of
this
sample
application
that
they
can
go
and
demonstrate
those
concepts
in
with
something
that
people
kind
of
know
and
understand.
A
Okay,
do
we
want
to
just
or
quickly
discuss
maybe
some
service
recommendations
or
changes
based
on
specific
languages?
I
know,
while
it
kind
of
already
approached
the
topic
by
talking
about
some
of
the
the
c
plus
side
giuliano
pierre,
do
you
all
have
any
sense?
I
know
you
already
mentioned
a
lot
of
these
applications,
or
you
know
business
logic,
simple
or
simple.
Business
logic
in
general
did
any
stand
out
as
potential
replacements
off
the
box
or
out
of
the
box.
F
Currency
is
pretty
simple.
Email
service
is
fairly
simple
as
well
and
the
shipping
service.
It's
simple,
you
know
I
I'm
one
thing.
We
didn't
really
mention
in
all
this
and
I'm
sorry
I
just
brought
it
up.
Is
what
about
cloud
functions?
A
The
vendor
specific
kind
of
version
that
like
austin,
was
talking
about
to
where
you
have
like.
We
provide
the
initial
sample
app
and
then
maybe
there's
like
an
azure
fied
version
of
it
to
where
you
use
like
functions
for
stateless.
You
have
like
apps
services
for
the
website
front
end
and
then
maybe
you're
using
something
else
for
some
other
services
as
well.
So
I
kind
of
consider
that
to
be
a
vendor
issue
or
vendor
choice,
but
I'd
be
open
hearing
what
the
group
thinks.
F
I
know
that
was
something
that
was
brought
up,
but
just
it's
an
idea
and
I
think
we
could.
I
think,
when
you
get
a
little
bit
more
in
their
weeds,
and
it
would
probably
be
something
that
perhaps
when
you
say,
hey,
here's
the
eks
deployment
script
and
it
comes
with
a
lambda.
Here's
a
gcp
deployment
script
and
it
happens
to
come
with
a
google
cloud
function,
option
as
well,
so
so
yeah
that
could
probably
be
in
when
you
get
into
the
the
cloud
specific
deployment
models.
E
Although
I
do
think,
if
we
wanted
to,
then
we
should
base
it
on
k
native
and
then
say
like
okay,
the
default
is
there's
a
k
native,
you
know
function
as
a
service
type
deal,
and
then
people
can
swap
that
out
through
some
sort
of
shim
or
layer,
but
I
also
don't
know
if
k
natives,
how
much
of
like
hotel
k-native
supports
right
now,
that's
probably
a
research
task.
E
Optimized
towards
net
new
stuff
and
trying
to
focus
on
the
things
that
I
didn't
see
a
lot
of
like
deployment
options
with
collector
or
like
orlang,
php
c
plus
right
rather
than
spending
a
bunch
of
time,
swapping
things
out.
F
A
Okay,
well,
I
think
we're
at
time
so
thanks
everyone
for
joining.
I
know
it'd
be
tough,
no
matter
what
time.
A
So
the
the
kind
of
mission
for
this
week
is
to
start
the
or
not
start.
The
architectural
discussion
has
been
started.
It's
really
just
to
mature
it
and,
to
you
know,
propose
different
services
for
different
languages
and
also
ensure
that
we're
you
know
getting
our
plan
set.
So
we
can
hit
the
ground
running
I'll
work
with
juliana
to
get
his
code
copied
over
into
our
demo
and
then
we'll
start
going
to
make
changes
and
updates
there,
and
maybe
even
before
we
add
you,
know
other
services
and
things
like
that.
A
That's
fine
with
me
yeah.
Do
we
need
to
do
anything
from
an
open
telemetry
like
community
process
perspective?
For
that,
because
I
know
it's
on
the
calendar.
E
C
A
E
A
We'll
do
awesome
all
right
guys
we'll
enjoy
kubecon.
Hopefully
you
all
get
to
meet
thanks.