►
From YouTube: 2022-12-07 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
D
Should
we
should
we
get
started.
B
E
So
cut
this
connector's
PR
breaking
off
a
part
of
the
overall
proof
of
concept
and
I.
Think
we've
just
gotta
identify
a
path
forward
on
this.
Basically
I
think.
The
question
here
is
I:
ask
for
context,
there's
with
connectors
right
we're
able
to
connect
pipelines
of
different
types.
So
we
sort
of
have
pairwise
combinations
of
each
type
of
data,
so
you
could
have
a
connector
connecting
a
traces
pipeline
to
a
metrics
pipeline
or
traces
to
traces,
traces
to
logs
Etc.
E
So
the
question
is
like:
do
we
need
to
how
do
we?
How
do
we
represent
that
in
code?
Basically,
is
this
necessary
to
have
interfaces
for
these
when
you,
when
an
author
writes
a
connector,
will
they
will
they
need
to
account
for
each
combination
or
just
the
specific
ones
they
want,
or
do
they
just
say
this
can
consume
traces
and
then
it
does
whatever
they
want
with
it
and
sort
of
in
one
function
that
they
write.
E
C
So
the
two
combination
that
the
combination
of
the
return
type
plus
the
the
incoming
argument,
would
be
the
one
that
gives
you
the
the
the
thing
that
you
want
and
for
me
it's
very
very
confusing.
Why
do
you
care
that
the
method
that
I'm
calling
is
called
this
or
like,
consume
traces?
Two
metrics,
when
the
signature
is
exactly
the
same.
C
Is
that
the
same
instance,
or
there
are
two
different?
It
doesn't
matter
the
instance
necessary,
but
here
what
I'm
trying
to
say
is
you
have
a
factory
that
can
construct
these
things
and
the
fact
that
you'll
have
two
methods,
one
which
is
consume
traces
to
metrics,
which
returns
me
only
one,
the
instance
that
has
for
me
I
care
only
about
consumed
traces.
That's
the
only
contract
that
I
have
with
you.
Does
it
make
sense,
like
I'm
I'm,
struggling
a
bit
to
see
why
you
need
all
the
the
the
the
methods
on
the
instance.
E
C
Otherwise,
because
that's
what
I
call
an
instance
of
the
component
versus
the
factory
that
creates
the
instances
of
these
things,
that's
how
like
okay,
sure
you
can
collect
connect,
so
so
the
factory
is
the
one
that
creates
connectors
and
I'm,
not
sure.
Why
do
you
need
this
on
the
connector
versus
on
the
factory?
For
me,
that's
that's.
Where
I
struggle
I
understand
that
the
contract
is
I
need
one
that
does
this,
but
that's
the
contract
that
we
have
with
the
factory.
Even
today
we
have
that
contract
via
the
factory.
E
Yeah,
we
might
be
able
to
manage
it
that
way,
I'm
just
trying
to
think,
because
we
have
to
also
validate
when
a
connector
is
actually
configured
in
in
the
config.
We
need
to
be
able
to
to
check.
Is
this
used
in
the
appropriate
ways
that
it
actually
supports,
but
I
I
think
we
can
probably
cross-reference
that
to
the
factory.
C
Yeah
we
right
now
in
the
factories
we
we
have
these
things
these
Notions,
so
so
it
depends
on
where
we
want
to
to
to
validate
that.
If
we
create
a
the
component,
the
connector,
then
the
factory
can
return
an
error
when
we
call
that
method
create
connector
traces
to
metrics
and
maybe
maybe
turn
an
error
to
say,
unsupported,
that's
an
option.
F
E
Look
at
it
some
more
so
I'll
try
to
find
a
way
to
to
do
it
at
the
factory
level.
C
E
C
C
So
here
is
what
you
need
to
do
next
with
this
next
component,
and
here
give
me
the
return
type
that
I
know
what
to
do
with
you
right
now,
like
that's
for
me,
where
the
contract
happens,
not
other
com,
like
the
connector
instance
level,
but
at
the
factory
level,
where
we
say
here
is
an
X
pointer.
Give
me
the
your
pointer,
essentially.
A
C
The
next
one
is
mine,
I
think
if
nothing
changed
I'm
on
my
phone,
so
sorry
for
for
having
troubles
to
present
other
things.
The
next
one
is
the
the
issue
from
tigran
about
related
to
Salt.
If
everyone
can
see
that.
C
A
I
actually
want
to
raise
the
same
issue
about
sort
when
I
raise
the
previous
one,
but
that
that
one
that
I've
raised
maybe
like
fixes
some
issues
with
sort,
but
not
not
ideal
steel,
so
I
would
ideally
I
would
agree
with
sticker
and
I
think
we
should
deprecate
start
and
make
range
sort
if
you
really
need
it,
but
all
the
places
that
I
checked
can
be
replaced
with
some
some
other
things
without
using
like
a
sorted
range
and
is
equal,
is
definitely
needed
to
replace
it.
A
I've
been
not
sure
about,
like
the
interface
is
sorted,
maybe
not
the
best
name,
but
we
can
think
about
it.
Right,
he's
like
well,
but.
C
A
A
C
C
A
B
D
A
Okay
does
go
like
I'll
I'll,
removing
from
one
point
RC.
Something
is
that
okay
from
gold
perspective
not
sure
from.
C
Rc
is
okay
to
to
to
still
do
breaking
change
during
RC,
because
that's
that's
that's
the
purpose
of
that.
It's
a
release
candidate,
where
you
get
more
feedback
from
public
and,
yes,
we
have
to
have
a
very
higher
bar
about.
When
do
we
accept
changes,
but
I
think
this
one
is
pretty
pretty
clear
that
we
shouldn't
do
this.
C
I
want
to
hear
from
others
as
well
if
they
feel
okay,
with
with
the
plan
of
releasing
RC
today
and
then
working
on
this
to
to
fix
it,
and
the
second
question
that
I
have
Alex
is
usually
during
RC.
You
are
allowed
to
do
breaking
changes
between
rc1
and
rc2.
Are
we
but
we
have
a
different
role
about
deprecation
in
our
report?
Are
we
going
to
follow
that
or
are
we
going
to
do
more,
more
aggressive
changes
here.
C
Or
at
least
not
C3,
to
fix
this,
otherwise,
which
is
fine,
but
I
I
would
rather
than
not
do
RC.
If
we
do
that,
we
at
least
do
not
have
to
to
go
to
rc3
for
for
no
good
reason,
but
I
think
at
any
point,
when
we
call
it
RC.
C
We
will
have
this
problem
that
if
feedback
will
come
and
we'll
have
to
resolve
something,
are
we
going
to
resolve
it
with
how
God
resolves
it
in
RC
mode,
which
is
you
break
it
because
that's
the
contract
or
we
follow
the
the
deprecations
that
which
is
also
fine,
but
we
we
need
to
understand
that
that
may
cause
us
to
go
to
RC
four
five.
Until
we
we
finish
things
which
is
maybe
acceptable,
I
think
I'm
I
find
staying
in
RC
mode
for
for
one
or
two
months
until
we
we
feel
very,
very
comfortable.
D
Yeah
I
think
that's
fine,
I
mean
if
we
wanted
to
reduce
the
number
of
RCs.
That's
straight
out
again.
We
could
just
marked
the
sword
deprecated
before
we
do
the
rc1,
so
that
we
at
least
have
like
sword
is.
C
That's
that's
actually
against
the
the
standard
you.
C
Yeah,
the
other
option
guys
is:
we
do
a
067
today,
normal
067,
where
we
deprecate
that
we
remove
the
deprecation
and
we
do
rc1
tomorrow,
for
example,
because
I
don't
think
we
need
necessarily
two
weeks
between
these
two
moments
but
Anthony
you.
You
had
concern
with
this.
Let
me
know
if,
if
that's
okay,
with
with
you.
F
So
I
we
go
ahead.
I
think
that
it
would
be
weird
to
release
one
version
today
at
a
deprecated
note
and
release
the
next
tomorrow,
rather
than
simply
extending
out
our
RC
I.
F
C
A
F
I
generally
think
we
should
follow
the
same
policies
for
RCS.
As
for
everything
else,
I
could
see.
Perhaps
if
we
are
ready
to
declare
a
release
and
there's
one
step
left,
maybe
then
we
make
a
decision
to
to
Short
Circuit
something
yeah.
If
we're
talking
rc1-
and
we
know
there's
going
to
be
more,
we
don't
see
any
reason
to
Short
Circuit,
okay,
yeah
thanks.
C
Okay,
guys
I
think
we
got.
We
got
Anthony
to
agree
with
us
on
this.
One
I
think
we
should.
We
should
then
move
forward.
I
will
merge
the
pr
after
this
call
and
we'll
do
the
rc1
release
for
p
data
and
then
and
then
we
Dimitri
in
in
parallel.
We
can
start
working
on
a
plan
of
what
is
the
the
final
state
with
this
sort.
C
B
C
I
think
I
think
what
I
heard
from
jurassi
on
that
discussion
is
that,
for
the
moment,
promptail
is
not
enabled
in
our
release,
which
means
we
don't.
We
don't
have
this
replays
in
the
in
our
release.
Binaries,
but
I
would
feel
uncomfortable,
adding
from
tail
to
the
binary
and
replace
everywhere
all
these
standard
libraries
for
everyone,
independent.
If
you
are
using
the
the
component
or
not.
B
C
For
now,
for
now,
and
that's
where
I
feel
I
will
feel
uncomfortable,
I
mean
just
for
the
test
here:
I,
don't
care,
it's
it's
fine.
I
mean
it
ideally
shouldn't
be
that
way,
but
it's
only
there
are
only
very
few
tests.
There
are
only
the
tests
for
star
stop
components
that
are
using
this,
because
those
are
the
in
the
main
go
mode,
the
other
one,
the
unit
tests
for
every
component
itself.
They
don't
have.
These
replaces
so
I
feel
okay
about
that.
C
G
Isn't
go
getting
to
dependency
version
to
find
at
the
top
level,
go
mod
and
apply
that
Downstream,
so
so
that
if
a
component
that
is
not
promptail
uses,
go
kit
and
prompt,
a
receiver
overrides
go
kit
and
the
main
goal
mod
file
replaces
gokid
whether
the
first
one
use
the
replaced
goal
kit.
Everyone.
G
C
So
that
component
has
its
own
go
mode
and
the
tests
are
running
inside
like
in
the
scope
of
that
go
mode
and
that
go
mode
does
not
know
about
the
repeats.
Now
now,
if
we
were
to
use
something
that
we
or
if
we
were
to
include
the
top
go
mode
somehow,
then
we
will
inhabit
the
replaces
and
will
be
different,
but
it's
not
it's
not
the
case.
So
the
the
unit
test
for
the
moment
for
all
the
components
except
the
the
promptail,
are
running
with
the
with
their
goalkeep.
C
G
C
We
cannot
ensure
that,
but
but
what
we
do
in
our
country
is
gold.
Has
this
notion
of
indirect
dependencies
the
indirect
dependencies
are
the
one
that
still
are
important
for
the
final
binary
or
used
in
the
final
binary?
So
then,
what
we
do
is
every
time
when
we
bump
versions,
we
bump
these
indirect
dependencies
to
run
the
unit
test
with
those
so,
for
example,
in
your
case
with
Prometheus.
C
So
let's
assume
the
lock
exporter
uses
under
the
need:
some
Prometheus
functionality,
okay
and
then
with
means
in
the
go
mode
of
the
Loki
exporter,
you
will
see
an
entry
with
the
indirect
keyword
and
we
bump
all
these
indirect
when
we
bump
the
major
things
we
bump
all
these
indirect.
So
we
ensure,
at
least
in
contribute
that
everyone
is
built
with
the
same
final
versions
as
that
we
don't
do
this
for
replace
statements,
but
we
do
for
for
any
indirect
dependency
Does.
This
answer
your
question,
yeah.
G
So
so
yeah
to
recap,
Frontier
receiver,
is
not
on
the
releases
repository.
So
it's
not
a
part
of
the
manifests
and
it's
not
going
to
be
I'm
sure
we
figured
something
out.
So
that's
that's
microservice
to
you.
G
Each
one
of
those
so
I
I
I,
took
a
look
at
all
of
the
replaces
the
replaces
the
statements
that
we
had
and
I
opened.
A
draft
PR
only
releases
removing
some
of
them
because
some
of
them
were
not
necessary
anymore
and
all
there
is
left
is
a
couple
of
replaces.
One
is
for
Prometheus,
I,
think
and
I
think
it's
similar
to
what
we
have
in
the
goal.
The
main
goal
mod
and
one
that
is,
that
is
temporarily
required
by
low
key
and
I.
G
Think
it's
only
been
used
by
Loki
but
I'm,
not
sure
now,
and
that
one
is
needed
for
the
Loki
exporter.
I.
Think,
okay,.
B
G
That's
that's
the
current
state
of
the
things
so
and
we
are
working
with
the
local
team
on
on
a
permanent
solution.
I
cannot
promise
that
it's
going
to
happen
for
the
next
release,
but
I
am
actually
taught
with
the
lucky
ducks
and.
C
I
mean
sorry
if
I
were
a
bit
brutal
and
saying
that
we
should
remove
this,
but
but
in
general,
I
want
to
raise
the
the
attention
and
sometimes
I'm
using
two
strong
words,
but
I
I
agree
with
you
as
long
as
we,
we
have
a
plan
in
place
and
we
are
working
towards
this
I
think
we
can
survive
couple
of
versions
with
with
having
this
the
the
one
that
worries
me
is
if
we
start
adding
all
these
four
Replacements,
which
especially
the
gokid
one
to
the
final
binary.
C
If,
as
long
as
we
don't
add
that
I
I
feel
like
we
can
stay
in
this
state
for
for
a
couple
more
versions
until
we
we
figure
out
a
plan
by
the
way
this
this
thing
we
should
discuss
this
about
the
other.
We
have
the
same
problem
with
the
other
I
raised
this
issue
generation.
You
may
be
able
to
help
me.
C
So
if
you
go
into
the
Jago
repo
I
raise
the
same
issue,
because
we
depend
on
their
model
thing
where
they
have
the
generated
Proto
Buffs
to
in
our
translations
and
yeah
Yuri
told
me
to
generate
the
protopuff
by
myself.
I
can
do
that,
but
there
are
lots
of
other
code
that
I
like
from
there
and
we
use
from
there.
C
A
couple
of
examples
are
the
trace,
ID
hex,
that
they
have
for
for
avoiding
allocations,
which
is
one
example,
and
then
the
biggest
one
that
we
have
is
the
conversion
to
from
Thrift
and
two
from
from
Json.
That
is
in
that
model
package.
So
it
will
be
good
to
do
the
same
thing
for
Jagger
and
not
depend
on
the
whole,
the
other
Machinery.
Just
because
we
need
a
model
model
package.
G
B
C
For
yoga
as
well,
I
think
it's
important
to
fix
that
foreign
as
well
and
and
same
thing.
We
should
consider
to
do
for
Prometheus
and
I
I
think
we
should
raise
this
to
to
the
Prometheus
owners.
You
know
an
RC
that
we
we
have
the
same
problem.
C
We
depend
on
the
whole
Prometheus
for
for
very
few,
like
not
for
everything
that
is
not
100,
true,
because
we
depend
on
a
scraper
a
bit
more
for
Prometheus
than
we
depend
on
the
other,
but
still
it
would
be
ideal
if
they
could
split
as
the
scraper
package
into
a
smaller
package.
G
Yeah
I
had
a
similar
discussion
with
them
last
week.
I
think
in
a
different
context,
and
the
message
that
I've
got
is
that
I've
gotten
is
Prometheus
was
never
meant
to
be
consumed
as
a
library
and
we
never
whenever
we
need
something
like
whatever
we
need
to
use
as
a
library
they
just
say.
Well,
we
are
not
supposed
to
use
it
like
users
like
that,
so
I'm,
less
confident
that
they're
gonna
change
that
I'm,
confident
that
Diego
would
accommodate
our
needs.
C
Yeah,
let's
start
with
Jagger
and
push
them
after
that
and
say:
hey
guys,
we
we
are
considered
removing
this
or
I
I,
don't
know
we.
We
can
see
a
way
to
push
them
a
bit
from
our
side
to
to
get
this,
because
it
will
be
ideal
for
us
to
to
not
depend
on
the
whole
Prometheus
for
this
yeah.
C
C
I
would
do
that
and
sorry
for
everyone,
if
you,
if
you
see
me
using
sometimes
a
bit
more
strong
word
than
I,
should
but
I'm
a
person
more
direct
person
than
I
should
be.