►
From YouTube: 2022-12-15 meeting
Description
OpenTelemetry Prometheus WG
A
C
Was
reinvent,
it
was
yeah,
I
mean
it
went.
It
went
well.
D
C
That's
a
lot
of
lots
of
bells
and
whistles
of
like
all
the
booths
and
everything
is
pretty
interesting,
but
they.
D
Had
yeah
like
in
EDM,
what
was
it
Martin
Garrix
like
played
like
I,
mean
yeah.
They
just
I
mean
yeah.
They
really
brought
out
all
the
stops,
but
yeah.
C
Yeah,
that
is
why
I
was
not
able
to
to
make
the
8am
meeting.
C
Coley
here
from
the
the
go,
people
and
I
don't
know,
I
think
we
have.
B
602
and
it
seems
like
once,
we
have
like
little
more
clarity
on
the
how
we
deal
with
the
different
formats
and
we
can
probably
split
the
group
up
into
smaller,
more
focused
groups
to
deal
with.
How
does
like
JFR
and
P
Prof
protocol
work,
protocol
wise
and
then
some
people
can
go
and
figure
out
how
the
new
hotel
format
could
look
like.
A
D
And
the
next
one,
which
I
also
put
on
here
that
we
may
skip
will
be
fairly
light
just
because
of
end
of
year.
You
know
plus
holidays,
all
that
stuff,
so
yeah,
but
I
think
I
think
it
actually
kind
of
works
out
nicely
too,
because
I
think
you
know
yeah,
we
can
kind
of
come
back
next
year
and-
and
you
know,
hit
the
ground
running.
C
I
will
release
the
edge
in
the
dark
in
the
chat.
I
need
to.
C
C
D
D
You
know
the
probably
the
the
biggest
kind
of
step
forward
that
we
took
is
is
figuring
out
like
back-ends
advertising,
which
format
they
support
versus
each
format
having
its
own
signal
type,
yeah,
I,
guess
we'll
get
into
that
in
a
second
as
we
go
through
the
notes
which,
with
context,
will
make
more
sense
and
then
figuring
out
when
to
talk
to
other
cigs
and
then
yeah,
just
some
like
I
guess,
administrative
stuff.
D
As
we
decide
you
know
on
meetings,
I
guess
for
the
rest
of
the
year,
so
I
can
I
did
take
a
bunch
of
notes,
I
guess
partially
just
for
my
own.
D
Go
you
guys
see
Slack
yep
yeah,
so.
C
D
So
yeah,
basically
I
guess
yeah
I,
don't
know,
maybe
click
since
you
were
I.
Wasn't
there
but
I
don't
know
yeah.
If
you
want
to.
D
If
there's
anything
in
particular,
you
want
to
dig
in
but
yeah
I
guess
so
the
go
one
of
the
go:
runtime,
maintainers
right,
I,
hope,
I'm,
saying
that
right
came
in
and
was
you
know
kind
of
just
gave
his
thoughts
on
a
new
format
which
you
know
initially
we
were
kind
of
I
guess,
leaning
towards
this,
but
from
Felix's
proposal
we've
started
to
lean
towards
a
slightly
different
architecture.
Here,
I
guess
not
completely
removing
the
idea
of
a
new
format
but
I
guess
making
it
less
required.
I
don't
know.
D
B
Yeah
some
sorts
yeah,
so
yeah.
The
reason
why
I
brought
Michael
nicheck
in
from
the
go
runtime
team
was
to
sort
of
get
a
better
understanding
on
if
we
develop
a
new
format
and
it's
amazing
and
it's
great
and
we've
got
it
ready
with
the
go
run
time
sa
runtime,
that
we
are
interested
in
be
willing
to
implement
something
like
that
and
the
answer
from
Michael
who
he
clarified.
He
was
not
speaking
on
behalf
of
the
whole
go
team
there.
B
He
would
have
to
go
back
to
them,
but
his
intuition
was
no
like
until
this
is
like
really
widely
used
in
industry.
That
would
not
be
something
that's
a
good
runtime
would
jump
on
immediately
and
for
us
it
would
be
a
problem,
because
how
is
this
going
to
be
wildly
used
in
industry
if
the
runtimes
don't
use
it
like?
It's,
you
know
chicken
and
egg.
B
So
that
being
said,
he
was
open
to
the
idea
of
making
more
data
from
the
runtime
available
in
more
structured
apis
which
might
allow
to
get
that
data
without
Force,
getting
it
in
people
often
than
having
to
convert
it
on
the
client.
So
that
seems
like
it
might
be
playing
in
our
favor.
B
If
we
want
to
go
in
a
new
format:
Direction
but
yeah,
we
don't
have
any
such
insights
into
Java
yet,
but
it
seems
like
I,
don't
know
if
we
have
anybody
here
who
can
really
petition
the
the
jvm
people
at
the
end
of
the
day.
I
think
we've
got
a
good
connection
to
the
go
team
and
we
might
be
able
to
if
not
get
them
to
implement
the
format,
but
maybe
give
us
apis,
so
we
can
implement
it
ourselves
that
might
be
doable,
but
for
the
jvm.
That's
still
a
question
mark
I.
D
Suspect
just
on
a
sort
of
relative
basis,
if
it's
not
going
to
happen
and
go,
it
probably
is
much
less
likely
to
happen
in
Java
I,
don't
know,
I
think
that
would
be
a
pretty
fair
estimate
and
so
yeah
I
mean.
But
but
it
sounds
like
you
know,
I
mean
that's
fine
and
it
sounds
like
we.
D
B
Yeah
I
think
what
we
need,
as
a
group
like
to
to
I,
guess
make
a
group
decision
on
is:
do
we
really
want
P,
Prof
and
JFR
to
be
first
class
formats
in
hotel
profiling,
as
in
backends,
have
an
ability
to
request
getting
P,
profs
or
jfrs?
Is
that
the
use
case
we
want
to
support
it's
something?
B
That's
near
and
dear
to
my
heart
for
reasons
tied
to
my
employer,
but
I
also
think
it
makes
sense
for
the
overall
Community,
but
that's
something
where
we
need
to
make
a
decision
once
we
make
that
decision.
That
sort
of
that
is
the
capability
you
want
to
have.
B
If
we
accept
the
first
premise,
which
is
shave,
R
and
P,
Prof
should
be
natively
supported,
which
I
think
we
should
partially
also
because
there
are
industry
standard
formats
today,
and
it
would
be
weird
to
completely
ignore
them,
but
I
I'm
happy.
If
people
disagree
with
that,
that's
just
my
my
two
cents.
That's
it
yeah.
D
I
think
I
would
agree
with
that
as
a
minimum,
not
as
like.
Only
supporting
those
but
yes
I
mean
I,
just
think
like
I
I
I
imagine
it
would
be
wasted
effort.
If
we
got
to
the
end
of
this
and
we
were
like
you
know,
yeah
and
we
ignored
especially
P
Prof,
but
even
JFR.
You
know
if
it
was
just
totally
left
out,
people
would
I
think
it
would
kind
of
undermine
the
sort
of
I
guess
like
credibility
of
a
lot
of
things.
If
it's
like.
D
Oh
you
don't
even
support
like
the
two.
You
know
two
of
the
biggest
sort
of
Standards
here,
but
I
also
do
think
that
adding
something
you
know
additional
to
it
is
important
too
and
so
I
think
yeah
like
I,
know,
yeah
like
on
the
ebpf
side
or
whatever
like
yeah
I.
Guess
I,
don't
know
how
what
format
bucket
that
falls
under
I,
don't
know.
Maybe
the
elastic
folks
can
can
jump
in
there
or
Felix.
If
you
had.
B
Someone
yeah
just
a
quick
after
I,
didn't
talk
about
a
potentially
new
format,
but
I'm
also
very
much
in
favor
of
that,
because
even
if
the
clients
don't
speak,
the
new
format
having
the
collector
speak,
it
would
still
give
bandwidth
advantages
to
clients,
so
they
send
in
inefficient
P
Prof
to
The
Collector.
But
then
the
collector
does
smart
things
to
send
the
data
on
to
a
backend
and
Bend
Wisconsin
I'm
in
favor
of
that
as
well.
That's
it!
Maybe
the
last
box
have
more
slots.
Yeah.
D
And
I'll
add
one
more
thing:
yeah
I
mean
I'm
curious
to
hear
from
the
elastic
side
that
yeah
it
seemed
like
a
lot
like
up
until
you
know,
maybe
a
meeting
or
two
ago
we
were
kind
of
stuck
on
yeah
like
what
to
do
with
like
statefulness
versus
non-statefulness,
and
it
was
kind
of
lightly
proposed
that
we
could
like
handle
those
potentially
separately
in
in
and
moving
forward
here,
and
that
there
was
some
precedent
for
that
as
well
with
I
believe
it
was.
D
Forget,
oh
yeah,
like
metrics
versus
logs,
you
know
yeah
that
there
was
like
some
precedent
that
we
could
potentially
do
both
and
either
treat
them
as
separate
signals
or
find
some
kind
of
way
of
doing
that
and
yeah
I'm
also
kind
of
curious
that
if
that
might
get
us,
you
know
sort
of
unstuck
and
everybody's
use
cases
you
know
covered
there
Jonathan
you
had
something
you
want
to
add.
E
Yeah
I
watched
a
couple
of
comments
from
the
jf's
office
side.
I've
talked
to
some
of
red
Hat's
Java
people
where
they,
the
second
largest
Java
contributors
after
Oracle
in
and.
C
E
Done
some
some
work
on
flight
recorder,
stuff.
E
Okay,
it's
possible
to
to
have
a
new
format
supported
were
particularly
interested
in
the
performance
problems
that
arrives
from
jfr's
existing
event,
API,
which
basically
means
you
have
to
pull
things
up
from
the
sea
level
up
from
the
the
internals
of
the
jvm
into
Java,
put
them
on
the
Heap
just
so
you
can
serialize
them
to
product,
but
often
send
them
back
out
on
the
wire,
which
seems
crackers
so
being
able
to
to
kind
of
pre-assemble
stuff
and
just
say,
here's
an
opaque
bunch
of
bites.
E
Let's,
let's
send
this
out
would
be
nice
performance
wise,
but
that
raises
another
issue
which
is
kind
of
more
general,
which
is
that,
if
we're
going
to
support
multiple
formats,
is
there
such
a
thing
as
an
API
to
them?
So
we
can
do
things
like
Implement
policy
on
the
network
Edge,
so
we
can
filter
information
for
security,
and
if
so,
what
does
that
look
like
when
there's
multiple
underlying
formats?
How
do
we
come
up
with
a
common
API
to
them
that
isn't
simply
that
format's
native
API.
D
Yeah
I,
guess
I,
don't
know
if
you
have
or
are
able
to
I,
don't
know
track
someone
down
who
is
I,
guess,
like
close
closer
I,
don't
know
yeah
to
that
decision,
making
on
their
side
that
you
know
similar
to
as
a
Michael
who
came
before
that
we
might
be
able
to
just
you
know,
pick
their
brain
and
see
sort
of
what
they
think
about
this,
but
that
either
way
that's
good
to
know
that
it's
not
out
of
the
question
and
for
the
second
piece,
I
think
that
I
don't
know
if
we
would
necessarily
need
to
decide
that
ahead
of
time,
I
guess
I,
don't
see
why
we
wouldn't
be
able
to
do
that,
but
yeah
I
mean
yeah
I,
guess
definitely
you
know
I
I
think
the
probably
the
next
step
if
we
are
able
to
like
move
forward
whether
it
says
like
kind
of
two
separate
streams
or,
however,
we
move
forward
is
going
to
be
making
this.
D
You
know
this
official
Otep
or
two
oteps
I,
guess
maybe
and
I
think
in
that
we
would
probably
sort
of
yeah.
That's
where
we
would
explore
those
ideas
of
like
security
and
and
that
kind
of
stuff
and
kind
of
layout
that
we
have
to
come
up
with
a
solution
that
at
least
meet
some
minimum
goals,
as
it
relates
to
security
and
that
kind
of
thing
I,
don't
know
that
would
be
my
thought
on
that
I
don't
know
if
anybody
else
has
something
you
know
opinions
there.
F
E
Yeah
I'm
not
sure
it's
going
to
be
a
requirement,
it's
it's
something
you
can
do
with
the
other
signal
types
that
hotel
currently
defines
the
they've
got
some
form
of
apis.
You
can,
you
know,
create
the
data
and
put
it
into
the
pipeline
profiling's
a
little
bit
weird
and
the
the
profile
thing
that
actually
creates
the
data
is
kind
of
a
third-party
component.
E
We're
not
trying
to
specify
that,
and
so
it
feels
like
we
can
go
the
route
of
more
or
less
saying
the
same
thing
HTTP
does
with
web
sockets,
which
is
just
yeah.
We
give
you
a
mechanism
to
establish
an
end-to-end
connection,
but
it's
it's
basically
a
tunnel
and
what
you
send
through
it
is.
E
You
know,
out
of
scope,
we
can
try
to
you,
know
Define
what
actually
gets
sent
and
I
think
there's
a
different
tasks
and
it
seems
like
currently
we
we're
trying
to
do
both
we're
saying
yes,
there'll,
be
a
format
we
Define,
that's
the
the
official
Hotel
one,
but
also
will
allow
you
to
Tunnel
other
formats.
E
I,
don't
know
whether
we
want
to
to
have
some
kind
of
ability
to
to
have
a
common
API
for
those
two
use
cases
or
what
we
just
say
yeah,
if
you're
using
your
own
format,
sorry,
you
can't
filter
it.
You
can't
look
inside
it.
That's
you
just
have
to
live
with
that
limitation.
F
I
guess
just
to
follow
up
on
the
point
when
you
start
to
look
inside
it
I'm,
not
that
familiar
with
the
the
rest
of
the
the
hotel,
architectures
but
I'm
wondering
like
what
is
doing
the
the
looking
inside
and
to
to
what
because
I
guess
to
give
some
context.
F
In
my
mind
the
the
kind
of
architecture
for
how
you
set
these
things
up
is
you
have
a
whole
bunch
of
agents
and
then
you
have
collectors
living
somewhere
and
the
job
of
those
collectors
is
perhaps
to
do
some
amount
of
enrichment,
but
largely
just
to
try
and
shovel
as
much
data
into
a
database
as
fast
as
it
possibly
can
and
I
guess.
So
we're
not
doing
any
kind
of
like
introspection
on
that
data
or
filtering
so.
E
Hand
in
hand
with
enrichment
right,
if
you
can't
see
the
data
you
can't
either
add
to
it
or
subtract
from
it.
The
Collector
currently
can
do
that.
E
My
question
really
is:
do
we
want
to
be
able
to
to
do
that
for
profiling
data
in
all
cases,
or
are
we
comfortable
with
the
idea
that
some
users
might
want
to
sell
it
where
all
they're
really
doing
is
the
equivalent
of
a
socks
proxy
they're,
just
you
know,
saying
yeah
the
data
flows
through
this
thing,
but
we
don't
really
know.
What's
going
on
we're
just
forwarding
shoveling
packets
around.
A
E
I
think
that
is
probably
problematic
for,
for
some
customer
use
cases
where
they
expect
their
their
Telemetry
to
be
visible
and
they
they
have
certain
organizational
policies.
That
say,
you
know
we
have
to
be
able
to
audit
this
to
make
sure
we're
not
inadvertently
sending
out
stack
tracers
that
have
you
know,
sensitive
information
in
them
where
we're
not
leaking
anything
we
don't
want
to.
It
may
be
that
they
don't
need
to
filter
it,
but
if
they
can't
see
it,
they
don't
know
that
right.
E
They
have
to
be
able
to
audit
it
at
least,
and
some
of
you
providers
you've
got
a
better
idea.
What
your
customers
say
in
regard
to
this
than
than
I.
Do
your
products
currently
have
the
ability
to
intercept
this
stuff
before
it
hits
some
kind
of
permanent
storage
or
even
leaves
the
organizational
boundary,
and
is
that
some
of
the
customers
pressure
you
for
or
are
they
saying,
yeah
it's
fine?
We
trust
you
we'll,
send
you
whatever
your
agent
generates,
and
we
don't
really
know
what
that
is.
But
it's
okay.
F
F
E
A
E
P
Pro
for
JFR,
whatever
they're
just
gonna,
have
to
trust.
It's
not
capturing
anything
that
I
wanted
to
capture
yeah.
We.
D
Have
run
into
that
before
too
that
some
of
you've
been
yeah
like
I,
guess
built
other
sort
of
systems
in
I,
don't
know
demon.
Maybe
you
can
speak
to
it,
some
like
they.
What
I
don't
know
if
they
ever
told
us
exactly
what
they
were
filtering
out,
but
they
were
I
believe
using
like
yeah
like
Kafka
to
kind
of
like
I.
Don't
know,
yeah
sort
of
have
been
intermediary
to
be
able
to
filter
things
out
in
between
sending
it
to
us
and
where
it
was
coming
from.
Initially,
even
you
have
any
yeah.
D
A
lot
I
mean
I.
Imagine
there
will
be
some.
There
will
certainly
be
some
use
cases
for
people
wanting
to
filter
something
out,
even
whether
it's
you
know
something
that
should
be
there
in
the
first
place
or
not.
You
know,
I
could
see
that
being
something
that
people
would
want.
B
Yeah
I
came
across
only
one
use
case
for
filtering
out
data
and
profiling.
So
far,
mostly
customers
are
just
like.
Oh,
this
is
just
stack
traces.
We
don't
consider
this
pii
that
they're
fine
with
it.
The
only
case
where
that
was
potentially
not
true
was
the
connection
that
we
built
that
data
dock
for
between
tracing
and
profiling
in
particular,
because
tracing
is
prone
to
picking
up
pii.
A
E
The
other
known
issue
we've
seen
is
that
it
allows
attackers
to
audit
what
versions
of
Frameworks
people
are
running.
So
if
there's
known
cves
in
you
know,
log4j
or
whatever
and.
E
B
Yeah
but
the
point
I
was
going
to
make.
There
is
maybe
a
few
cases
where
this
is
interesting,
but
I
think
that
we're
not
ruling
out
some
features
for
that
in
the
collector
in
the
future,
because
P
Prof
is
a
pretty
semi-standardized
format,
so
putting
in
people
of
filtering
and
policy
capabilities
in
terms
of
The
Collector
should
be
relatively
easy
to
do.
E
B
E
Is
not
necessarily
running
in
the
same
language
that
the
profile
was
so
with
JFR,
for
example,
the
profile
is
in
go
so
we're
going
to
need
a
a
go
lag
API
to
JFR
the
jfr's,
not
a
standard
format,
deliberately.
E
D
I
would
say
we
could
add
it
to
the
we
haven't
got
there
yet,
but
that
we're
planning
to
ask
like
The,
Collector
Sig,
some
questions
and
I
think
they
might
also
be
good
to.
You
know
sort
of
just
ask
how
they
feel
about
this.
As
you
know,
obviously
they
know
the
underlying
reasoning
and
motivations
for
why
they
added
this
elsewhere,
and
so
that
might
be
a
good
place
to
to
ask
them
and
see
sort
of
just
if
they
feel
like
this
is.
D
B
Yeah
but
but
one
more
thing
like
JFR:
yes,
of
course
it's
not
a
standard
API,
but
it
depends
on
the
Fidelity
that
you
need
for
this.
In
some
cases,
all
you
need
to
do
is
go
through
all
the
strings
that
are
contained
or
the
user-defined
strings
and
filter
them.
B
D
Back
to
sharing
here
so,
let's
see
where
are
we
so.
D
D
Yeah
I
guess
maybe
we
should
go
start
talking
about
the
I
guess,
yeah
I,
don't
know
which,
which
part?
Do
you
think
we
should
go
to
next
I
kind
of
wrote
this
down
sort
of
just
word
for
word?
Maybe
if
you
can
give
some
context
here,
Felix
I
feel
like
yeah.
This
probably
is
a
good
segue
into
yeah,
like
also
The
Collector
Sig,
and
what
we
need
to
talk
to
them
about
in
the
coming.
You
know,
weeks
months.
B
B
These
questions
in
particularly
well
but
I
think
we
kind
of
want
some
guidance
from
the
collector's
sake
on
how
they
feel
about
content
negotiation
aspect
of
a
protocol
where
maybe
the
receivers
advertise
which
formats
they're
willing
to
receive
and
The
Collector
that's
sitting
in
between,
might
be
able
to
add
something
to
that
list
formats,
because
it
can
do
conversions,
which
was
sort
of
my
original
proposal
from
previously.
B
And,
alternatively,
it's
the
last
meeting.
The
idea
came
up
of
having
separate
profiling
signals
like
one
for
each
format
and
if
we
do
that
it
becomes
a
little
bit
less
unclear
how
conversions
would
work
if
that
would
be
something
that
the
client
has
to
explicitly
request
like
hey
I
want
to
convert
because
I
just
tried
the
endpoint
for
my
format
and
they
can't
something
like
this,
or
that
would
still
be
some
sort
of
content
negotiation
just
how
they
feel
about
those
topics.
B
Considering
that
we
might
want
to
post
these
existing
formats
through
the
collector
yeah,
yeah
I,
think
that's
my
summary
and.
B
Well,
I
think
each
format
would
be
its
own
signal
type
so
for
p,
Prof
and
shape
R.
It
would
be
very
simple
signals
that
basically
have
one
sort
of
endpoint
where
it's
like:
hey:
here's,
a
p
Prof
and
a
bunch
of
metadata
associated
with
it
or
same
for
me
of
HFR
for
the
let's
call
it
Oprah
the
new
hotel
profiling
format.
B
For
that
it
would
be
more
more
yeah
stateful,
where
there's
potentially
multiple
endpoints,
where
one
is
like
hey.
Let
me
send
you
a
stack
Trace
with
a
hash
ID
for
it
and
in
the
future,
I'll
call
that
stack
Trace,
just
the
hash,
ID
hey.
Let
me
send
you
some
symbols
for
program,
counters
and
hey.
Let
me
send
you
an
event
like
a
CPU
sample,
and
that
would
be
a
separate
signal,
but
that
signal
would
maybe
offer
several
message:
types
that
could
be
sent
over.
B
That
signal
channel
at
least
that's
how
I
imagine
in
my
mind
and
yeah
yeah.
D
Of
course,
ready
Sean:
what
do
you
think
about
because
it
seemed
like
our
initial
kind
of
path
we
were
going
down
felt
like
it
wasn't
getting
as
close
to
adjusting
I
guess
like
elastics
model
as
and
perhaps
Kamal
I,
don't
know
yeah,
maybe
on
the
Parker
side
too,
but
yeah
I,
don't
know
I'm
curious.
What
do
you
think
of
this
this
path?
F
I
mean
I
think
in
in
concept
it.
It
definitely
does
I
think
it's
one
of
those
things
where
the
devils
in
the
details
a
little
bit.
I
guess
what
we're
essentially
saying
is.
F
We
would
have
somebody
would
be
able
to
say
hotel
compliant
by
advertising,
that
they
say
support,
say
Prof,
jf4
or
or
this
other
format,
but
the
the
effort
and
the
honors
would
still
be
on
the
the
vendors
or
developers
like
open
source
developers,
whatever
to
actually
go
and
Implement
these
things
and
I'm
I'm
wondering
because
we've
practically.
F
Mean
yeah
or
the
or
the
or
this
new
format
and
I'm
wondering
because
I
guess,
there's
partially,
the
idea
of
we
can
have
a
collector
in
the
middle
that
can
sort
of
do
some
sort
of
conversion
between
the
two
and
I
think
that
perhaps
works
for
the
state
list
ones,
but
for
the
for
State
film
I
think
that's,
there's
a
fair
chunk
of
work
in
that
so
I
guess
I'm
yeah.
F
What
I'm
wondering
is,
let's
say
we
project
into
the
future,
is,
is
what
we're
imagining
like
in
an
ideal
outcome
that
we
would
say?
Let's
just
imagine
it's
people
of
TR4
and
then
the
Oprah
format,
which
supports
like
it's
a
stateless
or
sorry.
A
stateful
protocol
is
the
our
idealized
outcome
that
each
vendor
would
or
each
open
source
maintainer
would
Implement
like
both
a
like
a
client
and
the
back
end
for
these
for
kind
of
most
most
optimal
user
experience.
B
Yeah
I
think
the
last
beating
the
somebody
from
The
Collector
Jonathan
I
forgot.
The
name
brought
up
the
idea
that
if
something
becomes
compatible
exclusively
through
the
collector
doing
the
compatibility
it's
not
compatible
like
it,
it
needs
to
be.
If
you
take
the
collector
out
of
the
picture,
it
should
still
work.
Otherwise
they
don't
consider
that
hotel
compatibility.
We
need
to
confirm
that
that's
really
the
case,
but
if
that's
really
the
case,
it
Narrows
down
our
choices
here
and
well
makes
our
life
a
little
bit
easier
on
the
decision
making.
I
guess
yeah.
F
That
makes
sense,
I,
guess
I,
wonder
maybe
I'm
misunderstanding
some
Nuance
here,
but
is
say:
we
go
down
this
route,
obviously
like
it
kind
of
feels,
like
everybody
involved
kind
of
gets
what
they
want
in
the
sense
of
we.
E
F
You
know
our
stateless
protocol
will
become
somehow
compliant.
The
somebody
using
people
off
will
become
compliant.
Somebody
using
or
sorry
our
state
for
protocol
somebody
using
JFR
will
become
compliant
boss.
I'm
kind
of
wondering
is
that
what
we're
aiming
for,
where
everybody
kind
of
just
sticks,
with
the
they're,
like
one
individual
protocol
and
kind
of
they
get
the
hotel
rubber
stamp.
B
So
I
think
out
of
the
box.
Nobody
would
get
an
Hotel
rubber
stamp
because
you
will
still
need
to
implement
the
hotel
oltp
or
whatever
it's
called
protocol.
So
whatever
your
current
endpoints
are,
those
would
have
to
change
to
get
any
level
of
compatibility
and
then
the
question.
B
The
big
question
is
to
me:
is
there
like
lot
one
level
of
Hotel
compatible
as
in
like
your
either
compatible
or
not,
or
do
we
split
it
into
smaller
capabilities,
and
then
it
becomes
a
game
of
competition
as
well
between
the
vendors
and
implementers,
because
well
you
can
get
three
stars,
one
for
people
of
one
for
chafe
or
one
for
the
Opera
format
and.
B
D
And
I
mean
I
think
it
does
still
have
the
benefit
of
then.
In
that
case,
because
as
of
right
now,
you
know
yeah,
like
none
of
I,
think
each
individual
agent
could
not
yeah,
like
you
know,
send
data
to
a
different
vendor
and
I
guess,
that's
kind
of
you
know.
One
of
the
big
goals
of
otel
is
being
able
to
be
sort
of.
D
You
know
make
it
easy
for
people
to
choose
sort
of
which
direction
they
want
to
go,
and
this
gets
closer
to
that
I
wouldn't
say
yeah
that
it's
a
it's
a
cop-out,
but
just
you
know
kind
of
you
know
a
maybe
the
most
realistic
way
that
we
can.
You
know,
move
forward
and
get
closer
to
that,
along
with
some
of
the
other
goals
that
we
mentioned
in
the
in
the
original
Otep
that
we
did
and
you
know
without
it,
it
sort
of
includes
everything
and
in
different
levels.
A
B
Mean
one
one
more
thought
is
also
the
the
idea
of
such
a
approach
would
also
be
that
the
new
format
would
have
to
prove
itself
in
the
real
world
and
if
it
really
offers
benefits
over
people
and
JFR,
that
will
convince
people
to
start
using
it.
It
will
convince
runtimes
to
adopt
it
and
we
can
kind
of
start
pulling
more
people
in
that
direction
without
giving
up
on
where
people
are
coming
from
right
now,
yeah.
F
B
F
Conceptually,
it
makes
sense,
I
think
the
the
kind
of
the
thing
that
we're
getting
a
little
bit
hung
up
on
before
on
the
kind
of
stateful
side
was
the
kind
of
the
concept
of
trying
to
sort
of
do
stateless
to
stateful
transformation
in
The
Collector,
where
you
would
just
have
to
move
so
much
logic
into
that
collector.
That
I
think
it
would
have
been
pretty
onerous,
multiple
streams
or
multiple
I.
B
Think
the
last
meeting
we
decided
all
that
this
was
probably
not
a
good
idea
to
try
that
going
from
a
stateful
protocol
to
a
stateless
one
might
be
okay,
but
the
other
way
around
seems
like
a
huge
nightmare.
Yep.
C
D
Let's
see
you
so
where
do
we
go
from
here?
So
we
talked
a
little
bit
about
the
collector
Sig
doc.
B
I
guess
we
could
try
to
figure
out
what
time
we
want
to
meet
with
the
collector
sick
and
kind
of
agree
on
a
date.
So
we
all
have
a
chance
to
attend
that
we
want.
D
Yeah
I
think
that
would
be
good
I
do
not
know
when
they
meet.
Let
me
see
if
I.
B
Have
the
I
think
I
saw
something
about
every
Wednesday,
every
Wednesday,
okay,.
B
D
So
I
guess
yeah
I
guess.
The
first
question
is:
when
will
we
next
meet?
You
know,
technically
we
are
supposed
to
be
meeting
on
the
20
9th
of
December
I
would
propose.
We
don't
meet
on
the
25th
of
December
unless
somebody
feels
very
strongly
otherwise,
and
we
just
skip
that
one
and
meet
again
in
January.
Okay,
no
naysayers,
so
yeah
something
our
next
one
would
be
January
12th.
D
There
is
a
so
we
could
either
meet
these
the
Wednesday
right
before
that
January
11th
or
if
we
want
to
kind
of
regroup,
January
12th
and
we
could
meet
the
Wednesday
right
after
that,
January
18th
I.
Don't
know
that
is
a
little
I
mean
it's
a
month
away,
but
I
guess
yeah
it'll
be
holidays
and
stuff.
So
I
think
that
could
be
fine.
I,
don't
know.
What
do
you
all
think.
D
Yeah,
if
we,
if
we
don't
meet
with
them,
I
mean
we
could
also
meet
with
them.
I
guess
next
I
mean
I.
We
probably
want
to
give
them
a
chance
to
I,
guess,
read
through
and
and
give
them
some
background.
So
I
feel
like
that
kind
of
rules
out
December
meeting
with
their
with
the
collector
Sig.
So
then,
if
we
meet
with
the
collector
Sig
actually
yeah,
if
we
move
the
collector
Sig
in
January.
C
Let
me
see
if
I
can
remove
a
bunch
of
stuff
okay.
Here
we
go.
D
D
If
we
want
to
meet
the
day
before,
but
I
don't
know,
maybe
we
want
to
meet
and
sort
of
just
like
regroup
before
we
meet
with
them,
which
would
push
it
to
the
18th
so
either
I
would
say,
probably
the
the
11th
the
day
before
our
next
meeting
or
the
18th
the
first
time
they
meet
after
our
next
meeting
would
be
my
vote.
I,
don't
know
openness
suggestions
if
other
people
want.
D
11.
and
we
can
maybe
reach
out
to.
B
Think
Josh
was
Josh,
service
was
who
we
talked
to
last
time,
not
Jonathan.
B
And
I
just
see
in
our
notes
that
we
should
also
reach
out
to
tikran
and
Bogdan,
which
yeah,
maybe
that.
C
C
Do
a
week
with
collector
Sig
January
11th
reach
out
to
Josh
about.
G
D
It's
like,
and
then
you
said,
also
meeting
with
the
TC.
B
D
Okay,
is
that
soon
Fair,
these,
it's
all
I
mean
I,
can
just
message
Josh
and
slack
after
this
and
then
yeah
we'll
figure
out
when
to
meet
with
the
TC.
Well,
we
can
I'll
see
if
they
have
a
I
guess
yeah
see
if
they
have
a
slack
Channel
I
suspect
they
do.
A
D
Right
well,
I,
don't
know,
yeah
I
mean
I,
think
that's
yeah
I
mean
I
feel
like
we
are
moving
at
a
good
Pace.
Hopefully
the
conversation
with
the
collector
said
goes
over
well
and
it'll.
You
know
make
clear
what
we
can
and
can't
do
and
how
we
can
or
cannot
move
forward
and
yeah.
You
know
I'm
hoping
yeah
the
you
know.
We've
talked
about
it,
a
bunch
I'm
hoping
that
at
the
beginning
of
next
year
we
can
sort
of.
D
You
know,
pick
up
some
more
momentum
and
then
I
don't
know.
Last
time
it
was
kind
of
nice
to
be
able
to
give
an
update
at
the
last
kubecon
when
all
the
hotel
stuff
was
happening.
So
you
know
maybe
I
know
there's
one
and
I
believe
the
end
of
April
next
year.
D
D
I,
don't
know,
that's
just
my
General
thought
on
a
potential
good
timeline
that
we
could
aim
for
to
make
good
progress,
yeah
but
yeah
anything
else.
Anybody
else
want
to
talk
about
before
we
sign
off
for
the
day.
C
D
Well,
happy
holidays.
Everyone
and
yeah
I
guess
see
you
all
next
year.