►
From YouTube: 2023-01-24 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
D
B
B
E
Feel
like
that's
the
way
it's
trending,
but
I
mean
I'm
sort
of
clearly
my
opinion
is
to
ship
it
because
I
did
all
the
work,
though
I'm
just
sort
of
waiting
for
you
and
see
Joe
to
stamp
it
one
way
or
another
I'm
pretty
happy
with
so
I.
Have
those
two
draft
PR's
reverting
some
of
this
stuff
and
then
I
think
we
should
probably
rename
the
extensions
dependency.
E
A
B
Yeah
I
agree
with
that
also
agree
with
the
renaming
of
that
package
if
we
can
come
up
with
a
better
name,
but
we
already
kind
of
talked
about
that
quite
a
bit.
So
that's
a
pretty
good
but
I
think
there
were
some
decent
other
candidates,
like
I,
think
you
tossed
out
something
like
open,
Telemetry,
Builder
extensions
or
something
along
those
lines.
E
Yes,
I
kind
of
like
if
it
starts
with
open
telemetry.api
so
that
it
kind
of
fits
in
you
know
the
lower
level,
because
if
you
look
at
nougat
like
the
UI
for
1.4,
like
the
latest
RC,
you
no
longer
see
open
telemetry.api,
because
it's
coming
transitive
with
the
extensions,
that's
kind
of
weird
so
I
feel
like.
If
we
just
put
open
telemetry.api
in
front
of
it,
it
would
fix
that
whatever
comes
after
that
I
don't
know
open,
telemetry.api.builders.
C
E
B
A
B
C
E
Yeah,
if
you
look
at
the
API
Library
as
it
exists,
it
has
Tracer
provider,
Builder,
meter
provider,
Builder,
Alan
and
I
have
been
kind
of
kicking
around,
but
maybe
those
should
have
been
in
a
separate
package
initially,
but
it
is
what
it
is
they're
there,
but
what
the
dependency
injection
package
is
doing
is
extending
those
Builder
providers
provider
Builders
to
support
like
three
or
four
operations.
You
can
register
instrumentation
with
like
a
generic
tea
pattern.
You
can
get
configure
services
and
you
can
get
configure
Builder
so.
A
E
D
C
This
might
be
a
dumb
question,
but
it's
the
I
guess
the
extensions
being
in
a
separate
package
as
opposed
to
near
the
the
Builder
or
sorry
the
Tracer
provider.
It
looks
like
was
that
because
there's
use
cases
for
the
extensions
being
in
another
Mega
package,
or
is
it
just
that
we're
managing
our
dependencies.
E
Did
have
a
giraffe
PR
a
long
time
ago,
where
I
was
just
adding
it
all
to
API,
and
people
didn't
like
that.
If
you
look
at
the
API
package,
it
doesn't
have
a
lot
of
dependencies.
It
might
not
have
any
it's
very
light.
I
guess
it
would
be
a
word
I
would
prefer
that
if
we
just
added
those
extensions
in
there,
but
to
do
that,
we
would
need
to
take
a
dependency
on
microsoft.extensions.dependency
injection.obstructions.
That
seems
to
be.
D
E
C
C
E
C
We
had
this
in
a
different
vein
of
thought,
similar
to
health
Diagnostics.
There's
the
there's
like
some
and
I.
Don't
have
the
answer
exactly
but
kind
of
I'll
give
you
what
the
response
was
initially
so
there's
some
models
in
the
Diagnostics
space
that
or
you
know,
used
with
the
framework
or
sorry.
The
I
want
to
use
the
wrong
word
here.
C
Maybe
some
of
the
logic
how
it
determines
health
status
it
we
did
get
some
initial
responses
where
a
lot
of
people
didn't
care
like
it
was
there
for
the
purists
like
myself,
it
felt
dirty,
but
at
the
at
the
end
of
the
day,
I
got
the
job
done.
Nobody
was
the
wiser
that's
that
was
me
like
over
a
year
ago.
Nowadays,
since
I've
our
organizations
moving
towards
keeping
track
of
our
cves
and
getting
those
in
front
of
everybody,
suddenly
I
start
feeling,
like
the
fear
of
the
dependencies,
the
better.
C
So
we're
not
I,
don't
know,
and
it's
a
little
bit
different
when
you
have.
You
know
some
of
the
BCL
and
it
is
stuff
like
this,
but
that's
kind
of
my
reaction
now
I
was
like
oh
man.
If
I
could
avoid
you
know,
20
other
libraries.
That
could
potentially
be
a
reason
why
we
have
to
redeploy
an
application,
because
one
team
might
service
a
ton
of
applications,
but
not
that
this
has
ever
happened
with
Microsoft
libraries
or
whatnot.
C
E
No,
those
that's
helpful,
I
think
if
we
keep
it
in
a
separate
package
and
keep
API
sort
of
pure.
It
just
allows
us
in
the
future.
If
we
want
to
have
sort
of
a
core
or
a
slim
SDK,
it
gives
us
more
flexibility
to
kind
of
split
it
up
into
lower
level
packages.
If
we
put
it
in
the
API,
we'd
have
to
split
up
API
it
just
pushes
it
like
one
level
beeper
so
feel
like
it
might
be
better
just
to
keep
it
separate.
I,
don't
know,
I,
don't
really
think
about
that.
B
E
C
B
I
think
yeah
I
think
at
this
point,
and
you
know
I
kind
of
left
a
long
comment
on
one
of
your
PR's
regarding
that
I
too,
had
kind
of
waffled
back
and
forth
a
lot
between
those
options
and
that
I
agree
in
the
end.
I
think
that's
that's
the
cleanest
approach.
It's
a
bit
academic!
I!
Guess
you
know
it
like
in.
A
B
C
No
I
I,
like
I,
mean
with
in
with
the
perspective
of
all
dependencies
a
package.
Could
you
know,
gather
it's
it's
nice
to
keep
the
I
know
we
I
guess
in
this
group
we
call
it
API
and
at
my
first
glance
that
I
didn't
I,
didn't
really
understand
the
naming
of
that
necessarily
a
lot
of
the
a
lot
of
traditional
namings,
usually
with
no
suffix,
or
it's
got
core
at
the
end
of
it.
C
So
it's
kind
of
like
sanctioned
like
this
is
like
the
nuts
and
bolts
of
like
what
we
do
not
want
to
change,
but
I
guess
it's
part
of
the
API
specification
when
I
got
an
API
entertainment
for
another
time,
but
I
would
agree
if
the
with
everything
I
just
said.
So
you
got
my
vote
on
keeping
them
separate.
I
didn't
I
didn't
realize
that
the
service
collection
was
in
that
list,
so
that
makes
sense
for
it
being
a
separate
and
I.
C
Don't
know
how
much
longer
people
are,
and
last
thing
I
will
say
about
the
full
framework
conversation
is
that
the
trend
right
now
is
we're
just
not
staying
on
full
framework,
for
if
we
can
avoid
it.
So
it's
like,
if
it's
around,
we'll
just
adopt
whatever
we
need
to
do
to
keep
it
going
and
keep
it
alive
and
type
thing,
but
we're
not
as
like
stingy
about
how
clean
it
looks
because
there's
already
a
lot
of
things
in
full
framework.
B
A
B
B
B
So
I
reviewed,
I
I
took
a
pass
at
all
of
our
packages.
That
down
here
is
a
list
of
all
the
other
packages
that
I
think
their
names
are
fine,
but
I
put
them
here
just
for
reference,
as
as
people
are
reviewing
this
between
this
repo
and
the
contrib
repo.
This
is
the
set
that
I
thought
should
be
considered
for
renaming
I
think
each
of
them
ultimately
makes
sense
as
kind
of
their
own
effort
own
issue,
but
I
wanted
to
kind
of
centralize
the
discussion
here.
B
B
C
C
Yeah
I
agree
that
it'd
help
if
there
was
more
descriptive
to
it
yeah
extensions
to
their
infrastructure
so
like
their
own
abstractions
are
usually
implied
or
something
used
within
that
Library.
It
seems
like
so
like
logging.
Abstractions
is
somehow
used
in
in
your
package
that
then
hooks
into
their
existing
framework.
So
it's
like
yeah.
It
does
show
up
a
lot
of
times
extension
methods,
but
it's
got
a
bunch
of
other
little
details
in
there
too,
but.
A
C
Oh,
maybe
last
comment
is:
is
there
like
a
this?
Is
me
coming
from
the
space
where
I'm
usually
doing
guidance
from
my
organizations
or
like
a
canonical
list
of
we'll
say
middle
tier
in
the
name
spaces
for
like
future
conversations,
I
don't
know
if
that
would
help,
but
that
was
just
what
this
is
for
me.
Thinking
about
the
next
person
who
contributes
I,
see
shims
in
there,
and
that's
these
resource
detectors
propagators
and
that's
for
a
terminology
used
explicitly
in
in
this
space.
I
see
some
question
marks
too.
B
C
I
was
thinking
if
there
was
a
canonical.
Whatever
we
come
up
with
with
epr
would
be
kind
of
like
here's,
the
list
of
approved.
You
know,
naming
conventions
we're
looking
to
use,
so
extensions
doesn't
cream
back
in
there.
That's
like
a
junk
drawer
when
we
don't
have
one
that
describes
something
anyway,
that
was
just
the
afterthought.
C
B
I
think
the
thing
that
you're
getting
out
here
is
is
something
that's
been
on
my
mind,
which
is
that
you
know
as
we
go
through
this
exercise.
It
would
absolutely
be
helpful
for
us
to
have
some
like
contributing
guidelines,
then
that
speak
to
package
naming
and
help
guide
the
thing
I,
don't
think
that
there's
any
like
going
to
be
any
fast.
B
You
know
quick
rules
that
you
know
this
is
the
set
of
things
and
everything
fits
within
this
set
of
things,
but
I
think
that
I
think
that
it
is
possible
to
write
some
sort
of
some
sort
of
guide.
I
mean
most
of
these
really
are
extensions
to
the
SDK.
So
my
my
thinking
here
is
that
Mo.
Of
course
the
package
starts
with
open
Telemetry,
but
then
really
the
second
thing
is
going
to
be
in
reference
to
kind
of
the
type
of
extension
that
it
is
right
and
is.
B
Is
it
a
resource
detector
propagator,
you
know,
is
it
something
totally
different?
It's
like
you
know,
isn't
really
like
a
an
extension,
that's
defined
in
the
sense
of
like
the
open,
Telemetry
SDK
specification,
but
is
an
extension
to
dot.
Nets
SDK
like
this
persistent
storage,
though
this
may
actually
become
part
of
the
spec
I'm,
not
sure
it's
just
not
today.
B
I
do
have
a
comment
about,
like
you
know,
vendor
specific
things,
I
I,
really
I,
don't
care
at
the
end
of
the
day,
like
vendors
I
think
know
their
domain
the
best
they
should
absolutely
be
the
ones
that
decide
what
their
things
should
be
called,
but
that
said,
we
are
still
in
the
position
to
offer
like
guidance
right
so
I
think
that
comes
back
to
your
point
of,
like
you
know
somehow
articulate
in
that
guide.
It's
probably
like
in
a
contribute.
C
C
Yeah
it
it's
just
the
further.
That
point
is
like
well
I'm,
even
though
I'm
not
I,
don't
work
for
a
company
that
authors
this
kind
of
thing,
but
sometimes
I.
It
helps
to
know
kind
of
sometimes,
when
you
want
to
make
your
own
like.
How
should
we
in
enhanced
for
our
own
organizations,
you
know
design
approaching
for
our
packages,
but
it's
usually
for
internal
use.
Only
pretty
much
but
I
like
it.
D
So
I
have
a
quick
question
and
then
I
haven't
followed
that
issue
on
the
contract
budget.
This
one
says
this
was
detectors
versus
that
should
be
our
service
Detective
yeah.
This
could
be
very
like
something
particular,
but
was
that
discussed
like
in
that
detail
or
that
there's
some
discussion
going
on
there
as
well,
because
like
for
the
cloud
providers,
I
would
think
there
could
be
multiple
detectors
and
the
same
package.
B
Yeah
I
think
that's
a
good
question.
I
I
do
have
a
comment
here
about
the
you
know.
Should
these
SDK
extension
packages
be
plural
or
singular?
You
know
we
do
have
a
prior
art
here.
In
specifically
in
the
context
of
our
exporter
packages.
You
know
we
don't
we
don't
pluralize
I'm.
Sorry,
let
me
see
if
we
look
at
the
list
of
other
packages.
You
know
like
this
is
this
is
effectively
an
SDK
extension.
It's
an
exporter,
we
don't
say
open,
Telemetry
exporter,
stop
in
memory.
B
B
C
B
G
A
B
B
Consider
using
plural
namespace
names,
where
appropriate,
so
again,
package
naming
I,
don't
think
of
as
being
quite
the
same
as
namespaces,
but
they're
kind
of
related,
oftentimes,
so
anyways.
If
we
were
to
adopt
this,
then
I
think
I
think
plural
would
be
the
way
to
go
and
honestly
I
think
at
the
end
of
the
day.
I
think
consistency
is
the
is
the
more
important
thing.
In
my
opinion,.
B
D
Yeah
I
think
that
kind
of
yeah,
because
I
think
this
was
detected
caught
my
attention
because
we
have
been
thinking
about
adding
back
for
Azure
so
that
I
just
started.
Thinking
like
we
might
have
multiple
ones,
especially
for
the
cloud.
So
that's
that's.
Why
I
I
thought
of
asking
that
question,
but
yeah
I'll
I'll
share
any
feedback.
B
D
Actually,
yeah
that
that
one
makes
sense
to
me
because
it's
not
really
an
extension
I
like
yeah.
It
doesn't
really
have
any
SDK
reference
right
now,
not
even
API,
but
I.
Don't
know
if
that
could
change
in
future
that
all
the
the
guy
stuff
that
we
are
doing
I
don't
know.
If
there's
any
way,
we
we
need
to
take
a
dependency
on
that
later
on
the
stage
but
like
right
now
it
has
I
mean
it's
definitely
not
an
extension.
A
F
B
B
There's
a
couple
of
other
PR's
but
they're
they're
ones
that
pieter
the
added
and
they're
pretty
minor,
cleanup
ones.
So
I
had
it
on
my
mind
to
get
these
through
today,
if
they're
ready
to
go,
merge
them
and
then
I
was
going
to
ask-
and
maybe
this
is
like
an
offline
conversation
amongst
like
see
Joe
Mike
but
I've
never
released
anything
from
the
control
repo
but
I'd
be
happy
to.
B
I
B
B
I
B
A
A
I
I
B
I
B
D
I
I
mean
my
major
question
was
like:
is
it
like
a
generally
good
practice
to
like
just
steal
the
code
from
the
original
package,
instead
of
maybe
as
a
technique
to
avoid
the
dependency?
Is
there
like
any
downsides?
We
should
be
aware
of.
We
have
done
something
like
this
for
the
Jaeger
exporter
to
get
the
thrift
serialization
like
we
pretty
much
like
copy
the
whole
code,
but
that
was
done
for
a
different
reason.
I
Like
clients
did
that,
and
eventually
we
quoted
off
that
as
well,
but
I
I
don't
know
if
there
is
any
other
thing
which
we
should
be
aware
of,
or
this
is
like
a
safe
thing
to
do.
For
now,
from
my
look,
it
looks
very
safe,
like
we
don't
have
like
tons
of
files,
it's
hardly
like
two
or
three
classes
which
you
need
to
copy
over.
E
I
B
I
I
We
were
having
the
dependency
injection
dependency
directly,
the
through
I
logger,
but
now
we
have
a
separated
load
into
an
extensions
dot,
TI
package
and
the
idea
was
to
the
whole,
like
motivation,
was
to
give
instrumentation
Library
others
support
da,
but
without
taking
the
SDK
dependency.
Is
that
the
one
line
Summary
of
why
we
need
this.
A
E
C
E
E
Somebody
wanted
to
set
that
via
I
configuration.
So
you
couldn't
do
that
before
so.
Just
sort
of
integrating
into
options
correctly,
like
this
code,
specifically
isn't
doing
anything
for
eye
configuration,
but
just
plugging
into
the
pipeline
sort
of
in
the
standard
way
then
allows
the
users
that
control
they
can
bind
that
to
their
config
if
they
want,
or
they
can
add
their
own
post
validations
based
on
other
things.
It's
just
it's
a
couple
lines
of
code,
but
it
enables
like
a
whole
range
of
user
scenarios
that
people
are
interested
in.
I
E
F
E
I
So,
even
if
you
were
to
do
that,
then
let's
assume
that
we
do
that.
Then
we
should
be
able
to
allow
the
instrumentation
libraries
to
take
a
dependency
on
the
APA
and
which
means
they'll
get
the
same
API
to
do
the
builder.configure
services
with
that
Lambda.
But
the
downside
is
that
we
are
now
forcing
a
dependency
on
the
API,
not
the
SDK
itself.
So
that
was
the
reason
why
we
decided
against
doing
a
extra
dependency
on
EPA,
but
instead
settled
on
the
SDK
itself.
E
I
Okay,
so
now
I'm
trying
to
like
think
like
what
would
be
the
road
which
in
instrumentation
library
of
this
are
going
to
take.
So
now
they
have
two
options.
So
one
is
the
lean
option.
We
still
take
a
dependency
on
API
or,
like
even
linu,
they'll,
just
take
a
dependency
on
diagnostics
of,
and
they
could
optionally
ship
a
configuration
package
which
depends
on
the
extensions.pa
package
from
open
telemetry,
and
then
they
could
offer
this
Advanced
configuration
stuff,
yeah.
E
E
So
if
you're,
that
type
of
instrumentation
users
can
just
call
adsource
on
their
provider
or
you
can
ship
a
little
Builder
extension
package,
it
just
calls
adsource,
you
don't
need
anything
but
API
to
do
that.
Only
time
you
would
need
dependency
injections
is,
if
you're
doing
what
SQL
here
is
doing,
you're
exposing
options.
That's
really
the
only
time
you
would
take
this
package.
If
you
have
like
complex
options,
perhaps
you
have
dependent
services
that
you
want
to
manage.
E
Maybe
you
have
your
metric
instrumentation
and
your
tracing
instrumentation,
and
you
want
to
share
something
between
the
two
and
you
want
that
life
cycle
managed.
That
would
be
a
good
time
to
use
this.
What
you
can
do
in
that
case
is
in
the
service
collection.
You
could
just
register
your
own
Singletons.
You
could
use
them
in
your
metrics
and
your
traces,
and
when
that
app
shuts
down
the
service
providers
disposed,
your
Singleton
will
be
disposed.
So
it
gives
you
a
way
to
do
cross-cutting
things.
E
I
Go
to
these
two,
how
that
lean
option
for
instrumentations?
Okay,
yep?
Okay,
so
like
Ellen,
if
you
do
not
have
any
questions,
so
that
boils
down
to
like
the
weirdness
about
the
core
open
Telemetry,
depending
on
something
which
looks
like
an
extension
to
itself,
but
it
indeed
has
a
dependency
on
that
package.
So
it's
it's
the
weirdness
about
open
Telemetry
depending
on
open,
Telemetry,
dot
extensions.da.
So
maybe
like
it's
a
naming
thing
which
we
might
be
able
to
find
like
a
different
name
or
something.
I
The
concern
is
not
the
fact
that
SDK
is
going
to
get
a
new
dependency
on
Microsoft
extensions.di.app
status.
That's
not
the
concept.
The
concern
is
the
fact
that
open
Telemetry
essay
package
is
depending
on
something
which
is
supposed
to
extend
it.
Okay,
we
did
suggest
that
yeah
I
do
recollect
this
one.
It's.
B
E
E
I
think
what
Martin
is
saying
is
what
I'm
saying
is.
What
other
users
are
saying
is
I.
Think
the
usage
of
that
stuff
is
a
lot
greater
like
anybody,
doing.net
core
or
creating
new
apps.
These
things
are
great
and
they
just
expect
them
so
I
have
a
lot
more
confidence.
I
think
renaming
will
help
with
a
lot
of
the
confusion,
but
I
think
what
Riley
is
really
pushing
for.
Is
we
don't
have
any
of
this
I
disagree
with
that
I
think
it's
all
really
good
stuff.
He
is
pretty
clear.
E
E
So
it's
like
somebody
came
to
us
and
they
asked
us
to
support
like
yaml
configuration,
we
would
say
no,
we
support
I
configuration
if
you
want
to
have
a
yaml
configuration
file,
you
just
implement
it
on
that
API
and
there's
probably
a
package
that
already
does
that
and
you're
off
and
running.
If
somebody
wants
to
say,
like
I,
want
to
build
an
enrichment
feature.
Well
then
we
say:
okay,
there's
the
I
service
collection,
you're
free
to
register
whatever
Services
you
want.
E
You
can
add
a
processor
that
then
uses
the
service
provider
to
retrieve
those
things,
and
then
it
executes
the
enrichments.
So
it
to
me
this
is
just
like
a
foundation
on
which
you
can
build
whatever
you
want.
That
was
sort
of
the
goal.
So
to
me,
it's
not
like
really
feature
creep,
it's
just
making
it
work
really.
J
E
Setting
the
expectations
supporting
it
across
the
board,
whether
or
not
you
use
the
hosting
package
or
the
sdk.create
style,
it's
all
there.
It's
all
going
to
work
really
nicely
and
deterministically
so
I
wish
Riley
was
here
to
kind
of
go
over
this,
but
my
vote
would
be
we
rename
it
and
we
ship
it.
Yep
I
know
anything
else
to
say.
I
Yeah
I
mean
I,
don't
think
like
we'll
need
to
like
indefinitely
delay
1.4.
If,
if
this
is
something
which
we
all
agree,
we
should
do
asraeli
himself
says
he's
not
the
maintainer.
We
are
at
least
because
he's
not
here,
but
the
rest
of
the
maintenance
are
here.
So
if
you
are
making
a
decision
like
we'll
just
document,
this
is
the
reasoning
why
we
believe
this
is
the
right
approach.
We
believe
this
is
so
fundamental
to.net,
just
like
ilogger
and
diagnostic
Source.
We
decided
to
bet
on
that.
I
We
are
going
to
bet
on
the
da
style
config
thing
as
well.
We
think
it's
too
fundamental.
It
cannot
be
like
outside
the
SDK
and
if,
in
the
future
we
all
were
proved
wrong,
and
then
we
will
do
the
open,
Telemetry,
SDK,
dot,
slim
or
light
or
core,
which
will
be
a
stripped
down
version
of
all
the
things.
I
So
if
you
have
a
way
out,
then
I
think
we
should
proceed
rather
than
delayage
yeah,
because
we
all
know
that
we
are
so
many
of
us
are
waiting
for
1.4
ship
to
sail
so
that
we
can
start
pumping
more
things
into
the
main
tripod.
Like
I
have
a
lot
of
metric
stuff
and
plans
already
has
mentioned
about
the
I.
A
I
We
can
discuss
in
the
issue
what
would
be
the
ideal
name
or
what
would
be
a
less
offensive
name
or
less
less
trouble
less
worrying
being.
But
additionally,
one
other
thing
which
you
want
to
like
comment
is
we
like
when
we
took
some
dependencies
on
Microsoft
extensions,
login
or
Diagnostics?
Was
we
had
the
upper
bound
capped
like
we
would
say
we
only
support
up
to
X
version,
but
these
right
now
we
have
a
direct
dependency
on
Microsoft
extensions.di.abstraction.
I
So
we
should
like
try
to
put
an
upper
cap
because
we
never
tested
it
with
higher
versions.
Dotnet
could
break
it
theoretically,
whether
they
will
actually
do
it
or
not.
That's
a
different
thing.
Maybe
we
should
be
like
a
little
bit
more
conservative.
We
should
close
the
upper
bound
and
if
there
is
no
Breaking
Chains
ones.net
feature
version
comes
out,
and
then
we
can
upgrade
the
upper
bound
because
we
have
left
extension
stored
loading
as
open.
I
B
Yes,
I
do
agree
that
this
is.
This
is
good
stuff,
I
think
it's
just
it's
just
the
nature
of
the
tunnel
ecosystem.
At
this
point
in
time,
I
mean
I,
I,
understand
what
Riley's
saying
and
that
you
know
this.
This
may
be
a
thing
that
passes
some
number
of
years
from
now,
but
I
I
think
we
need
to
use
our
best
judgment
and
do
what's
right
for
the
community
now
and
adapt
when
we
need
to
later.
I
I
Like
that,
that
requires
some
discussion,
because
I
think
we
are
starting
with
like
3.1
or
5..
Whatever
is
our
dependency?
We
need
to
make
sure,
like
I,
think
our
unit
test
or
other
tests
we
have
should
cover
if
a
user
is
bringing
like
a
higher
version
like
let's
say
six
or
seven,
because
we
are
by
default
testing
with
the
minimal
version,
but
user
could
be
bring
like
six
or
seven
first.
Questions
is
our
test
covering
that
scenario,
because
that's
very
likely
right.
I
I
So
our
upper
limit
should
be
seven
right
now
because
we
never
tested
with
eight.
So
when
a
Toto
is
out,
we
can
relax
the
upper
bound
to
be
a
total,
or
we
get
an
explicit
confirmation
from
the
dotnet
team
that
this
package
will
not
be
having
like
breaking
changes.
Even
when
they
do
major
question
bump.
We
had
that
explicit
confirmation
for
Diagnostic
Source.
We
did
not
have
it
for
extensions.loading
initially.
I
So
if
you
click
like
like
our
1.1
or
thing
1.2,
one
of
fed
releases,
we
were
like
really
trying
to
release
that
upper
bound,
relax
that
upper
bound
and
we
got
it
done
after
an
explicit
confirmation
from
the
BCL
owners
that
there
won't
be
any
breaking
changes.
So
this
is
like
just
just
to
prevent
us
from
hitting
any
trouble
with
all
the
dependencies.
That's
the.
I
B
I
We
had
the
same
trouble
right.
You
might
remember
that
we
had
the
same
trouble
with
extension
sloking,
so
the
only
mitigation
as
we
can
do
is
like
as
soon
as
1.4
is
out,
we'll
do
1.5
with
the
relaxed
upper
bound.
So
if
someone
is
doing.net
8
preview,
they
should
be
relatively
comfortable,
taking
a
beta
version
of
open
Telemetry
as
well
and
by
the
time
electronically
it
actually
ships.
We
should
make
sure
we
ship
our
question
as
well.
I
We
usually
commit
to
release
around
November
so
that,
like
people
in
the
newer.net
can
safely
bet
on
us,
but
like
due
to
some
issues,
we
usually
have
one
to
two
month
delay,
but
it
should
be
like
relative.
It
should
be
getting
better
like
every
year
because
we
have
solved
the
most
painful
issues,
so
we
should
be
doing
like
relatively
good
on
our
Board
of
at
least
releasing
something
along
with
the
dotnet.
I
I
Maybe
I'll
leave
a
comment
in
the
PRS
or
issues
so
that
we
won't
forget
it,
because
we
only
have
like
less
than
10
days
or
actually
Much
More
Much,
it's
already
24,
so
we
have
approximately
a
week
before
the
committed
date.
So
at
least
we
should
do
the
final
RC
on
that
day,
then
maybe
that
actual
stable
can
equate
one
or
two
days
that
should
be
fine.
I
Yeah-
and
you
also
put
I,
didn't
write,
notes,
I,
usually
write
notes
in
the
meeting
notes
page,
but
today,
I
I
joined
on
if
I
had
it.
So,
let's
maybe
like
you,
can
help
write
the
note.
So
this
is
what
we
are
deciding
on
the
Fig
meeting
on
XYZ,
like
anything
which
has
like
where
there
were
alternate
opinions.
Let's
just
make
sure
it's
recorded
in
the
sigmatically.
I
We
did
that,
like
even
from
our
first
release
itself,
because
there
are
a
lot
of
issues,
even
the
1.0
stable,
so
we
just
made
sure
it's
all
documented
and
we
decided
as
a
community
that
we
are
going
for
XYZ
reasons
so
balance.
Can
you
help
that
write
that
notes
into
the
the
Google
Docs
we
have
as
well
and
mentioned
in
the
issue
that
has
decided
on
this
meeting?
We
are
proceeding
with
the
following
approach:.
L
L
K
K
K
K
Okay,
I
think
we
can
go
ahead
and
get
started.
I
was
hoping
Tyler
to
join,
but
Anthony.
Can
you
kind
of
give
us
a
knowledge
here
about
the
EU
meeting?
Is
there
anything
we
should
be
aware
of
kind
of,
as
a
group
I
saw
esf's,
potentially
doing
the.net
assessment
but
yeah
any
any
action
items
for
us
to
discuss.
L
I,
don't
think
so
so
Tyler
and
I
discussed
event
to
carrier
versus
event
of
context
and
came
to
the
agreement
that
event
the
carriers,
the
the
right
abstraction.
We
think
I
still
do
need
to
provide
a
definition
of
that
in
the
lender.
Repo
haven't
done
that
yet,
and
we
also
discussed
a
bit
whether
for
the
context
that
comes
from
the
Lambda
runtime
environments.
K
K
K
But
I'm
hoping
that
the
the
messaging
Sig,
when
they
Define
those
conventions,
that'll
kind
of
force,
the
vendors
to
adopt
them
and
if
they
use
Spam
links
as
part
of
that,
then
that's
kind
of
just
a
working
function
to
say:
okay.
Well,
we
have
to
support
spam
length
in
some
form,
so
yeah
I'm,
not
sure
if
we'll
go
to
like
fully
divest
the
Lambda
stuff
from
the
async
messaging
group.
K
In
that
respect,
okay,
spec
review
status
checks,
I
Tristan,
you
and
Tyler
have
been
doing
some
great
work
on
kind
of
assessing
where
the
spec
could
potentially
be
improved.
Where
changes
need
to
be
made
and
I
know.
Rohit
joined
us
as
well
to
share
kind
of
that
Azure
perspective.
So
if
you
want
to
share
your
screen
or
just
like,
send
me
a
link
in
the
chat
to
like
open
a
shared
document
and
kind
of
give
us
a
status
update
here,.
G
K
H
A
H
Or
if
anybody
in
here
uses
has
used
Google
functions
and
funds,
that's
an
accurate
statement
that
it's
pretty
different
from
Lambda
or
Lambda.
You
can
just
write
something
that
grabs
events
over
HTTP
wherever
they're
from
doesn't
matter
and
then
handle
them.
As
you
see
fit
well,
Google
functions
seems
you
are
pretty
tied
into
their
sdks
and
each
trigger
type
is
fairly
different
than
how
it's
handled.
It's
got
different
metadata.
The
HTTP
one
seem
to
come
over
actually
with
HTTP
and
instead
of
being
grabbed
as
a
block
of
events
and
stuff
like
that,.
A
H
This
base
page
is
just
some
of
the
terms
we
use
that
we're
trying
to
flesh
out
in
other,
because
we
want
to
have
generic
terms
within
in
the
spec
for
things
and
then,
if
you
go
to
like
the
Azure
and
gcp
I,
think
gcp
is
the
most
fleshed
out
of
questions
and
difference
of
trying
to
figure
out.
You
know:
where
do
we
get
the
trigger
attribute
from
in
these
different
environments,
and
should
we
continue
to
call
a
trigger,
or
is
that
too
Lambda
specific?
A
G
G
Base
say,
for
example,
we
have
service.
First,
we
have
a
welcome,
so
actually
you
actually
get
the
particular
type
from
the
SDK.
So
if
you're
using
Azure
service
bus,
so
in
your
function
you
get
a
type
that
is
from
the
Azure
Azure
service
bus
SDK
for
that
matter.
If
it
is
event
Hub,
you
get
a
type
from
the
Azure
event
of
SDK,
so
it
is.
It
is
very
much
specific
to
the
trigger
it's
a
typed
input.
There
is
function
metadata
as
well
that
tells
about
the
type
of
the
function,
and
there
are
other
details.
G
There
are
details
about
input
binding,
and
then
we
do
have
a
concept
of
output
binding.
So
I
don't
know
it's
little
complex
I
was
doing
some
some
POC
on
lambdas
as
well,
so
Lambda
seems
decoupled
in
in
that
way,
when
you
create
your
function
and
you
don't
worry
about
what
trigger
it
is
coming
from
right.
A
G
So
there's
another
thing
that
I
wanted
to
talk
about:
I,
don't
know
if
we
talked
about
it
earlier
or
not.
So
in
Azure
conscience
we
have
a
durable
function.
So
it's
more
for
orchestration
and
long
running
functions,
so
you
can
create
a
durable
function
and
Define
your
orchestration.
There
are
activities
as
part
of
that
orchestration,
so
the
function
will
start
the
orchestration
will
run.
It
will
run
all
the
activities
as
part
of
that
orchestration
and
then
it
will
finish
so.
Do
you
have
something
similar
in
Lambda.
H
H
Maybe
it
might
be
so
different
in
Azure
that
it
could
be
if
it's
so
similar
to
the
function.
If
it's
I
mean
it
almost
also
sounded
like
I
mean,
is
it
more
for
setting
things
up
before
calling
the
function
orchestration
around
that
or
is
it
for
actually
walking
through,
like
a
state
machine
calling
different
functions?
It's.
K
D
G
H
G
You
know
It's
tricky
in
case
of
azure
as
well,
because
we
have
a
host
that
encapsulates
most
of
the
logic.
So
most
of
the
information
is
is
with
the
host
and
worker.
Only
get
part
of
the
information
so
host
will
have
everything.
Worker
will
have
some
of
the
information.
So
if
you're
looking
at
some
of
our
public
documentation,
you
will
not
be
able
to
see
everything,
but
then
we
do
have
all
those
information
with
our
host.
L
H
I
took
that
to
kind
of
mean
it
was
somewhat
not
documented,
but
that
it
was
there,
which
I
guess
is
something
we
can't
rely
on,
because
it
could
change
in
that
case,
but
the
yeah
we're
trying
to
discern
a
certain
information
like
like
here.
We
have
the
invocation
ID,
that's
something
that
I
hope
this
past
two,
yes,
it
is
okay,
I
mean
so.
A
H
K
K
G
L
G
K
L
Yeah,
there
are
a
couple
of
things
there
right
so
there's
the
extension
with
the
collector,
which
is
like
a
sidecar,
and
then
the
layers
are
kind
of
just
like
a
a
layer
in
a
container
where
you
just
add
in
some
additional
stuff
to
the
file
system
that
you
can
use
I.
Think
that
may
be
an
approach
we
can
take
with
with
Azure
and
gcps.
H
H
Is
there
for
Azure
the
Ada
Lambda
has
the
Telemetry
API,
which
allows
you
to
retrieve
things
like
the
logs
from
the
underlying
AWS
Lambda
about
what
things
are
going
on
and
timings
for
invocation
when
it's
called
how
many
events
things
like
that?
Is
there
any
API
for
that
kind
of
information
like
logs.
K
G
G
K
G
A
H
L
G
So
that's
how
it
is
right
now,
but
then
our
intent
is
to
make
sure
this
information
is
available
to
all
the
all
the
APM
systems.
So
it
shouldn't
be
only
specific
to
Azure,
monitor
I
know
we
have
a
very
tight
coupling
with
Azure
monitor
now,
but
that
is
something
that
we
want
to
get
better
at
and
and
save
if
the
customer
is
using
New,
Relic
or
data
or.
G
G
About
it,
so
so
we
had
a
meeting
yesterday
we
had
a
meeting
today,
so
this
is
a
priority
for
us,
especially
with
open
Telemetry,
because
the
customers
are
going
to
be
very
demanding
with
open
telemetry.
So
and
it's
a
it's
a
pain
for
our
customers.
We
understand
it
so
we'll
do
it
sooner
sometime
this
year.
This
will
take
time
because
the
way
things
are
set
up
and
how
we
do
things,
it's
actually
very
difficult
to
to
support
open
telemetry.
G
G
G
K
Yeah
I
think
we're
happy
to
contribute.
You
know
how
we
can.
Obviously
our
domain
expert,
so
we'd
probably
defer
to
you
to
an
extent
but
we're
very
much
interested
in
bringing
more
complete
instrumentation
to
functions
in
general.
So
we'd
be
more
than
happy
to
work
with
you
on
anything
to
produce
documentation
or
you
know,
experiences
and
best
practices.
So,
just
let
us
know-
or
if
you
need
any
sort
of
vendor
push
as
well
on
the
functions
team
to
say
you
know,
walk,
let's
go
light
step.
Etc
need
this
that'd
be
great
sure.
K
M
That's
fun:
it's
fun!
If
you
want
to
share
it
and
just
put
the
like
the
document
view
or
whatever
and
then
can
scroll
down
to
the
The
Matrix
itself,
I
put
a
link
to
it
in
the
the
document
as
well
yeah.
So
this
is
currently
the
the
state
of
it.
I've
got
some
feedback
from
Anthony
and
Tristan
and
others.
So
thank
you
for
that.
M
This
is
my
proposal
for
the
feature
Matrix
as
of
right.
This
moment,
I
think
there
was
a
discussion
with
Anthony
around
whether
or
not
I
should
include.net
and
go
since
those
won't
have
any
kind
of
Auto,
instrumentation
or
any
kind
of
automatic
context.
Propagation
built
in
and
folks
have
to
you
know,
compile
things
manually,
I
think
it's
worthwhile
having
the
the
layer
listed
out
here.
M
Otherwise,
I
I
worry
that
we
would
get
questions
about
why
they're
not
listed
or
you
know,
what's
the
limitations
of
them
I
think
this
makes
it
very
clear
that
you
know
it's
just
a
layer
with
an
Hotel
collector.
That's
that's
really
all
you're
getting
here
and
then
for
the
rest
of
the
features.
I
have
put
together
a
very
brief
description
above
the
support
Matrix
of
each
one
of
the
features.
K
M
I
look
I
looked
at
the
auto
instrumentation
documentation
they
have
in
their
repo
and
from
what
I
can
tell
you
still
need
to
manually,
compile
like
there's
tools
to
help
you
download
all
of
the
auto
instrumentation.
But
then
you
have
to
manually
compile
the
the
code
anyways
like
there
isn't
any
kind
of
Runner
or
any
kind
of
agent
as
far
as
I
could
tell.
Maybe
it's
maybe
I
just
misread
the
documentation.
L
I
think
all
of
these
features
are
still
applicable
to
net
and
go
it's
just
that
they
don't
have
a
layer
that
brings
them
automatically
to
you.
You
have
to
build
them
and
do
you
you
have
to
use
the
instrumentation
directly
in
your
application.
So
I
wonder
if
maybe
we
should
just
add
another
row
for
layer
with.
K
Yeah
that
makes
sense
to
me
so
I
know
we
just
kind
of
parceled
out
some
of
these
assessments.
Alex
I
think
we've
done
some
work
on
the
Java
one,
but
it
probably
hasn't
just
been
added
to
the
pr.
Yet
are
there
any
other
people
actively
working
on
assessing
these
layers?
I
know
you
know,
Siff
might
be
doing.net.
K
F
K
K
M
K
Awesome:
okay,
so
we'll
continue
to
work
on
this.
If
you
know
anyone
has
any
feedback
for
Alex
on
this
PR
that'd
be
great.
Otherwise,
let's
try
and
get
this
merged
and
start
doing
some
of
these
assessments
and
the
data
in
there
foreign,
so
the
next
one
is
kind
of
for
Anthony
and
Alex.
So
I
know
we
have
I.
Guess
it's
not
that
many
PRS
as
open,
but
are
there
any
specific
ones
that
y'all
want
to
call
out
that
just
need
some
Community
review
attention?
K
K
M
L
L
K
You
nice,
okay,
so
another
item,
that's
kind
of
ongoing,
so
we
do
have
a
community
ticket
if
they
went
to
cmcf
to
get
an
AWS
account
once
again.
I
don't
have
visibility
into
it.
I'm
kind
of
pushing
cut
and
Morgan
to
give
me
updates
around
it,
but
kind
of
in
parallel
I
want
to
start
doing
some
of
the
planning.
So
we
can
actually
start
producing
Community
artifacts
from
the
repo
itself,
so
Tyler's
I
think
doing
some
prototyping
just
on
his
personal
AWS
account
or
his
light
step.
J
L
Not
really
a
lot
of
what
the
8
out
repo
is
using
already
exists
in
in
this
repo,
so
the
8
repo
pulls
in
this
as
a
sub
module
makes
some
patches
to
it
and
then
utilizes
the
the
existing
terraform.
That's
there
yeah
I,
don't
know
that.
There's
too
much
that
we
would
really
need
to
add
to
this
to
be
able
to
publish
layers
out
of
this
repo.
H
A
J
H
L
H
H
J
C
J
H
H
M
Yeah
I
would
say
my
only
my
only
thought
here
is.
If
we
ever
end
up
using
this
repository
for
generating
other
artifacts,
then
you
know
Lambda
layers
terraform
might
be
a
better
tool
than
something
that's
AWS
specific,
but
I
don't
know
who
would
end
up
with
like
a
different
repo
for
like
gcp,
in
a
different
repo
for
Azure
functions
or
or
whatever.
K
Yeah,
it's
it's
a
little
tough
with
the
Lambda
repo,
just
because
I'm
not
sure
if
we
can
even
rename
it
so
it
might
still
be
open
until
Lambda.
Then
you
have
broken
link
issues
and
things
like
that.
So
you
know
maybe
it
makes
sense
to.
Maybe
if
we
want
to
do
everything
in
one
repo,
we've
created
a
new
One
Import
things
over
to
it
kind
of
progressively
rather
than
repurposing
the
Lambda
one
itself.
K
K
K
Okay,
silence
is
nothing
so
we'll
leave
it,
as
is
open.
Action
items
just
to
clean
up
the
zoom
account
that
we're
using
in
terms
of
ongoing
effort.
So
anything
specifically
Tristan
Tyler
wrote
it
from
the
spec
review
side
that
y'all
are
going
to
do
like
in
the
next
week
or
you
think,
needs
to
be
closed
on
that'd,
be
good
to
call
out.
J
L
J
Cool
yeah,
sorry,
it
was
a
little
bit
late
to
the
meeting,
but
like
I
guess
just
to
give
you
a
little
bit
more
context
here.
The
reason
that
I
created
those
other
three
tabs
is
to
try
to
get
the
vocabulary
in
place
so
that
we
can
potentially
come
up
with
a
better
terminology
so
like,
for
example,
in
my
opinion,
what
we
currently
called
the
execution
would
probably
be
more
consistently
called
like
an
invocation
ID
just
to
to
have
consistent
across
the
the
various
service
providers.
J
H
J
G
G
G
J
J
L
Right
because
the
regions
in
the
yarn
yeah
the
the
function
iron
will
stay,
the
same
request.
Id
will
change
the
instance.
Id
will
change
I,
think
we
just
merged
a
change
that
indicates
that
that
in
society
can
come
from,
or
at
least
an
in
node
that
it
can
come
from
like
the
log
stream
name,
which
is
effectively
the
same
as
an
instance
ID.
It
provides
a
unique
identifier
for
that
run
time
that
may
be
used
for
multiple
invocations.