►
From YouTube: 2022-12-14 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
D
B
E
D
D
C
D
The
three
weeks
from
now.
C
F
B
Okay,
let's
start
first
Tyler,
you
are
first.
A
Yeah
I'm
just
bumping
this
issue
again
around
configuration
for
exporting
spans
from
The
Collector.
We
don't
have
to
have
a
discussion
about
it
today,
but
I
just
wanted
to
get
it
in
front
of
the
collector
approvers
and
maintainers
again
for
continued
discussions.
I.
B
G
This
has
not
been
discussed
in
the
configurations
like
last.
The
last
meeting
was
only
two
people
and
we
didn't
get
a
chance
to
cover
that.
G
But
if
you,
if
you
want
Tyler,
we
can,
if
we
can
talk
to
talk
about
it
at
the
next
one
which
I
guess
will
be
in
January,
but
that's
a
long
ways
away.
If
you
wanted
to
I,
can
probably
just
take
this
and
take
an
action
item.
To
actually
add
this.
As
an
example
in
the
in
the
repo
were
all
the
issues
for
the
configuration
working
group
are
currently
being
opened.
D
A
D
B
Do
we
have
do
we
have
anyone
with
the
auto
go
experience?
Can
you
add
an
exporter
to
a
provider
at
a
later
time
than
Construction.
D
B
B
B
A
Yeah
I'll
talk
with
Mike
and
Alex
and
get
it
to
wear
that
thing
and
then
I'll
just
keep
moving
forward
with
it.
Okay,.
B
I
will
and
I
will
comment
some
ideas,
because
I
want
to
make
sure
that
we
address
some
questions
like
do.
We
need
a
receiver
in
our
terminology
that
is
capable
to
of
receiving
data
directly
from
from
hotel
sdks,
and
then
then
that
will
be
then
will
be
natural
to
put
it
as
a
part
of
pipelines.
For
you
Tyler
for
example.
Another
approach
is:
do
we
create
an
expo,
an
auto
go
exporter
that
is
capable
of
exporting
into
a
pipeline
in
our
stuff
or
or
how
is
the
the
approach
like
that
anyway?
B
B
So
essentially,
the
the
car,
the
next
release,
which
the
next
release
will
be
next
week,
but
after
that
we
will
have
a
three
weeks
for
the
for
the
release,
not
two
weeks
as
normal.
That's
the
only
thing
that
changes
if
anyone
has
a
problem
with
that
or
an
opinion,
I'll
get
the
an
opinion
about
this.
Let
me
know,
but
otherwise
this
is
the
current
plan
that
we
will
put
will
execute
them.
Andre.
C
I'm
thinking,
maybe
instead
of
moving
things
one
week
later,
maybe
Skip
One
release
and
do
another
release
two
weeks
later,
so
to
keep
the
same
Cadence
but
I'm,
not
sure.
If
that's
a
good
idea.
B
That's
why
we
we
thought
so
initially
we
thought
that
just
to
cancel,
but
then
we
figured
out
that
if
we
cancel
then
then
this
will
be
a
month
may
not
necessarily
be
the
worst
thing.
But
it's
it's
a
long
time
and
usually
we
we
do
much
more
frequent
releases.
So
we
would
like
to
to
keep
the
Cadence.
B
And
the
last
item
is
also
mine.
It's
it's
about
the
the
capabilities
and
the
mutability
of
the
data.
So
I
don't
know
how
many
of
you
know,
but
in
the
past
few
months
we
have,
we
had
a
couple
of
issues
with
the
with
the
with
this,
and
the
problem
was
that
we
we
put
the
data
on
multiple
pipelines
and
and
each
pipeline
was
was
changing
the
data,
but
they
did
not
Mark
that
they
need
to
change
the
data
so
right
now.
B
B
They
can
clone
the
data
if
they
need
to
modify
them
and
use
the
Clone
data,
change
them
and
pass
the
Clone
data
to
the
next
component
or
if
they
don't
need
to
change
it
just
pass
the
the
share
data
to
the
next
component
as
well.
So
then,
every
component
will
be
responsible
of
cloning,
the
data
if
they
need
to
modify
otherwise
not
doing
anything
foreign.
B
This
model
has
couple
of
advantages,
the
advantages
being
that
you
we
do
not.
B
We
do
not,
for
example,
for
components
that,
in
rare
cases
they
need
to
to
change
the
data
right
now
they
had
to
to
say
that
they
they
are
changing
the
data,
so
we
always
gonna
clone
the
data
for
them,
but
in
this
new
model
they
can
check
some
conditions
and
if
the
condition
met,
then
they
clone
the
data
if
needed.
Otherwise
they
can
leave
the
data
unmodified
and
stuff
like
that.
So
there
are
a
couple
of
advantages
of
this
model,
but
it
makes
things
a
bit
more.
B
The
more
like
I
think
it.
It
is
a
bit
more
work
for
the
components
because
they
need
to
manually
check
for
for
these
things
versus
just
setting
a
property
there
anyway.
This
is
the
current
proposal.
I
would
like
to
hear
from
others
if
they
have
any
other
idea
and
if
not
I,
think
you
should
do
something
for
for
this.
H
Well
and
I
posted
some
like
just
additional
kind
of
a
proposal
that
slightly
slightly
different
approach
that
doesn't
require
panics
and
passing
the
state
down
the
all
these
trucks.
If
you
have
a
chance,
please
take
a
look.
Let
me
know
if
that
makes
sense.
H
For
those
like
this
is
like
the
upper
scope,
we
probably
do
the
same
there
like
moving
moving
to
would
keep
the
state.
If
you
move
from
one
to
another,
you'll
you'll
keep
the
state
right,
it's
still
likely
either
shared
or
not.
If
you
move,
we
reset
the
state,
so
it
was
like
share
it.
Now,
it's
exclusive.
B
Copy
of
the
whole
of
my
trigger,
so
so,
essentially,
you
want
to
duplicate
all
the
messages.
Correct
and
the
mutable
or
messages
will
will
have
Setters
thing.
Getters,
the
the
non
the
non-prefix
with
mutable
will
have
only
Getters
exactly.
H
Yes
and
it's
more
work
on
the
P
data,
but
we
have
generators
and
I.
Try
this
it's
not
it's,
not
a
big
deal
probably
can
transition
to
that.
It
may
be
a
bit
tricky
because
we
need
to
split
the
types
mutable
and
unmutable
and
that
potentially
can
be
considered
as
a
breaking
change,
as
we
discussed
before
for
the
previous
similar
issue,
but
otherwise
I
think
I,
don't
think
of
any
other
drawbacks.
D
B
A
H
B
H
B
H
Believe
we
should
change
mutable,
because
otherwise
we
will
we
will
force
everyone
cut
every
current
user
to
copy
the
data
if
they're
using
it
found
out.
So
we'll
probably
need
to
explicitly
introduce
new
formutable.
B
H
We
don't
like
double.
We
still
have
more
mutably
apis
than
immutable,
so
it's
like
some
thirty
percent
sure.
F
I
have
a
question:
is
it
desirable
that
once
the
data
becomes
mutable
that
it
will
remain
mutable
or
it's
the
idea
that
basically
each
component,
maybe
it
mutates
the
data,
but
then
it
do.
We
want
to
basically
turn
it
back
into
an
immutable
as
we
pass
it
to
the
next
component.
Oh.
B
No,
no,
no,
no,
that
is,
the
idea,
is
only
fan
out.
Components
will
change
the
state,
so
the
fan
out
components
are
the
ones
that
are
in
parallel,
putting
these
data
to
multiple
pipelines.
So
essentially,
once
you
share
the
data,
then
you
mark
this
as
a
shared
object.
If
you
exclusively
pass
to
the
next
component,
that's
why
I
use
exclusive
and
shared
like
you-
do,
have
an
exclusive
access
to
this,
or
do
you
have
a
shared
access
to
this
resource.
B
That's
why
I
use
using
the
analogy
with
the
messy
like
protocol,
which
is
exactly
like
these,
like
which
kind
of
access
do
you
have
to
this
data
and
once
you
have
exclusive
access
to
these
new
data,
so,
for
example,
if
you
had
the
shared
access
to
the
data
you
clone
them
now
you
have
exclusive
access
to
the
Clone.
You
will
pass
the
to
the
next
object
as
exclusive
access.
B
H
And
the
top
level
object
like
metrics,
traces
and
logs
there,
the
same
so
the
same
objects,
so
you
just
get
you
get.
You
get
an
method
that
provides
you
mutable
resource,
metrics
and
resources
Etc,
and
then
you
deal
with
them,
but
the
top
level
object
is
the
same,
which
is
will
be
passed
to
the
next
pipeline.
F
Makes
sense,
I
was
trying
to
think
about
it
from
the
point
of
view
of
connectors
and
how
this
would
change.
If,
with
that,
but
I
think
with
the
fan
out
point
being
the
the
point
where
we
Market
as
shared,
then
that
works
either
way
so
cool.
H
B
That
will
do
that
so
so
find
out
with
the
with
addition
to
the
connectors
right
now
we
have
found
out
in
couple
of
things
places
like
routing
like
the
routing
processor,
but
the
routing
processor
will,
in
my
opinion,
if
I
understand
correctly,
will
become
a
connector
in
a
way
that
that
or
maybe
not,
but
if
something
like
the
routing
processor
can
do
fan
out
to
multiple
to
multiple
exporters
and
that's
where
I
believe
we
we
have
to
to
have
this
notion
of
of
share
about
things.
F
Yeah
yeah
my
mind:
we
should
re-implement
the
routing
connector
or
the
routing
processor's
connector
and
get
away
from
having
individual
components
managing
it,
but
yeah
I
think
until
we're
there
I
don't
see.
Yeah
I
agree
with
you.
B
But
it
is
the
same
thing
in
Dimitri's
proposal.
You
still
need
to
Mark
the
data
shared
or
not
shared
I.
If
I'm
understanding
correctly,
the
only
difference
Dimitri
is
that,
instead
of
panicking,
you
you
you
don't
expose
that
API
for
for
users,
and
you
do
the
cloning
behind
the
scene
like
internally
in
the
when
you
call
the
mutable
version
yeah,
so
so
that
logic
doesn't
change
too
much.