►
From YouTube: 2022-02-02 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
B
B
Yes,
I
haven't
had
a
chance
to
take
a
closer
look
at
the
the
flakiness
that
we're
seeing
for
that
one
test,
but
I've
just
been
trying
to
collect
all
of
the
failure
instances
to
see
if
there's
any
patterns.
B
B
B
But
at
least
now,
usually
when
I
force
a
rerun,
things
pass,
which
is
better
than
it
was
before.
C
Yeah
we
have
our
internal
that
robert
created,
but
robert's
away.
B
C
B
C
D
C
Okay,
zach
is
not
going
to
join
us
and
it's
already
10
24.
So
I
think
we
are
good
to
get
started.
Let
me
share
and
in
my
in
my
little
screen
real
estate,
you
guys
can
see
everything
that
you
can
see
very
big,
very
big
types
and
and
fonts.
So
I
suppose
that
this
was
okay.
C
C
B
Yeah,
so
just
as
a
quick
note
for
that,
paulo
after
you
shared
with
me
that
one
line
of
code,
I
made
the
change
locally
and
ran
some
of
the
tests
that
we
don't
have
as
part
of
our
integration
test
pipeline
and
the
problem
went
away.
So
so
we
do
have
some
some
automated
tests
that
cover
it's
just
not
running
as
part
of
our
pipeline.
B
C
B
C
B
Yeah
I
was
planning
on
getting
a
pr
in
today.
C
C
B
C
Okay,
so-
and
that
was
the
only
new
item-
so
that's
good-
I
actually
we
have
some
stuff
committed
here,
but
I
just
want
to
move
one
item
yeah,
so
I
I
actually
created
a
small
pr
for
that.
I
think
it's
actually
a
good
to
really
clarify
what
we
do
in
in
this
repo.
Please
take
a
look.
C
It's
just
a
small
paragraph
that
I
wrote
and
put
there,
and
I
actually
think
that
this
gave
me
an
idea
about
how
to
improve
the
design
the
overview
of
the
design,
basically
separating
the
the
part
that
is
regarding
injecting
the
sdk.
So
we
can
talk
about
different
paths
via
startup
hook
and
profiler
profile
is
going
to
still
be
required
anyway
for
for
at
least.net
framework
and
also
talk
separately
about
bytecode
instrumentation,
but
that
that
you
come
separate.
This
one
is
just
about
getting
the
the
description
a
little
bit
better.
C
So
I
think
we
have
committed
stuff,
but
does
anybody
want
to
update
on
any
of
this
committed
stuff
or,
if
not,
if
we
didn't
start
it's
fine,
it's
just
to
see
if
somebody
has
anything
to
update
about
those.
B
Yeah
so
I'll
just
give
an
update
about
the
disabling
of
the
bootstrapping
via
the
profiler,
so
that
that
pr
is
ready
for
review.
So
please
take
a
look.
B
I
there
were
some
questions
brought
up
that
I
added
to
our
discussion
list
for
today
that
I
think
are
worthy
of
separate
discussions
and
then
there's
another
question
in
there
that
I
am
interested
in
what
other
people's
thoughts
are.
Regarding
some
of
the
naming
conventions
that
are
still
in
place
because
of
our
seeding
from
datadog.
C
Yes,
yes,
and
I
think
one
thing
that,
because
we
are
using
the
sdk,
I
think
a
lot
of
the
namespace
conventions
we
now
can
really
get
away
with
what
we
think
is
more
convenient
for
our
our
fork.
You
know
in
a
sense,
we
nowadays
have
a
fork
of
the
native
and
the
bicycle
instrumentation
the
load
and
everything
else,
it's
kind
of
very
free
to
whatever
we
think
it's
more
appropriate.
C
B
That
would
be
good,
yeah
and
then
there's
a
couple
of
other
pr's
out
there
regard
I
wanna
I've
got
some
questions
regarding
the
the
one
for
the
otlp
exporter,
and
so
I
I
think
there
were
some
some
big
questions
that
came
up
there
that
I
think
might
be
worth
bringing
up
to
the
whole
group.
A
A
We
are
releasing
our
auto
instrumentation
as
net
core
application,
3.1,
which
is
referencing.net
standard
2.1,
and
this
version
of
grpc
client
is
not
working
with
net
5.0.
A
There
are
two
possible
fixes
for
this.
The
first
one
is
to
create
a
full
version
of
auto
instrumentation
and
release
it
us
for
net
5.0
and
6.0,
and
the
second
option
is
to
manually
force.
A
Upgrade
to
probably
grpc
network
to
2.3
36,
because
this
version
is
released
as
a
net
standard
which
should
be
compatible
with
dotnet
5.0.
But
I
do
not.
I've
done
not
tested
it
yet
so
for
sure
the
option
with
releasing
new
version
of
our
auto
instrumentation
production,
fiber,
always
visible,
and
it
should
work,
and
the
second
option
is
trying
the
manual
upgrade
of
this
grpc
client.
C
Because
I
I
don't
remember
from
the
spec,
but
I
think
we
we,
the
default,
should
be
otlp
but
not
necessary.
We
could
use
over
http
instead
of
grpc
directly
if
they
speculate.
That.
B
I
I
do
believe
the
spec
allows
it,
because
I
want
to
say
that
javascript
sig
and
many
other
cigs,
or
at
least
a
handful
of
other
segs,
are
defaulting
to
otlp
over
http,
as
opposed
to
grpc.
A
B
Yeah,
I'm
still
struggling
with
trying
to
understand
all
of
the
use
use
cases
where
somebody
would
choose
grpc
over
the
yeah
http
flavor
of
it.
Some
of
my
thoughts
there
there
might
be
a
performance
thing,
but
even
otlp
grpc.
B
It's
still
doing
a
unary
unary
call
which
is
similar
to
http
1.1,
and
so
I
don't
know
if
there,
if
there's
a
lot
of
performance,
gains
there,
it's
not
something
that
that
I've
tested.
C
I
I
played
with
this
in
the
past
I
to
be
sincere.
I
my
preference
is
to
be
http
because
usually
http
is
much
better
for
the
back
ends
to
do
load
balance.
You
know
so
the
grpc
itself.
It
could
be
on
an
area,
but
it
creates
a
stream
anyway
and
holds
that
stream
so
to
at
least
some
time
ago
to
be
able
to
get
a
load
balance
proactive.
C
B
C
B
I
I
know
that
we
just
set
appropriate
timeouts
for
for
the
connection
but
yeah.
I
was
not
aware
of
the
stream
implicit
stream
behind
the
scenes.
C
Yeah,
so
what
what
I
find
bad
in,
that
sense
is
the
following:
even
if
it
is
operating
a
hundred
percent
fine,
because
you
need
somebody
to
cut
the
stream
they'll,
be
error
reported
you
know,
and
then
the
error
becomes
kind
of.
Oh
it's
benign,
but
then
you
have
to
have
that
background
errors
all
the
time
and
that's
not
nice,
it's
better
to
have
kind
of
hey
error
errors.
You
know
so
so
I
I
my
based
on
this
experience
and
okay.
C
This
is
about
two
years
and
a
half
ago
things
may
have
changed,
but
considering
that
I
tend
to
prefer
autop
over
http.
C
So
if
the
spec
allows
then
my
question
to
prto
you'll
be:
can
we
default
to
auto
auth
over
http
for
all
the
frameworks
that
we
support
and
if
you
don't
have
the
answer
right
now,
it's
totally
fine,
but
something
should
look
yeah.
A
A
We
have
a
working
example
in
our
instrumentation
for
protobuf
over
http
in
net
4.6
and
others.
So
I
suppose
it
should
work.
C
Yeah,
so
please
take
a
look
at
that,
if
that's
a
possibility,
because
the
only
thing
that
I
really
don't
like
it's
having
different
defaults
for
the
different
versions
of
the
framework,
you
know
so.
A
C
C
I
I
would
say
the
following:
if
the
spec
allows
us
to
do
http,
they
basically
are
requiring
just
one
otp,
and
then
we
support
the
grpc
only
where
is
easy
for
us
that
we
don't
need
to
make
all
this
gymnastics.
So
if
there
is
a
version
that
we
can
support,
I
think
five
or
six
that
we
can
support
without
going
out
to
the
hoops
assuming
that
we
can
have
http.
C
A
C
Yeah
yeah,
I
think
that's
the
best
call
for
us.
You
know
I
think
the
sdk
perhaps
opted
to
have
grpc
as
default,
but
I
I
think
it's
fine
for
us
to
have
http
actually.
C
B
The
long
run
too,
because
I
mean
I
I've-
seen
some
lonkiness
even
come
up
with
java
using
otlp
grpc
with
alpine,
I
see
on
alpine
alpines,
always
seems
to
be
the
problem.
Child.
C
C
B
C
Yes,
yes
yeah,
I
I
was
thinking
strings,
but
I
was
like
well
how
how
but
now
you'll
say
localization
yeah
a
hundred
percent
yeah,
so
I
think
my
preference
will
be
http,
you
know.
So
if
we
can't
get
away
with
that,
let's
make
that
the
default
and
report
that
and
then
later
perhaps
we
can
get
back
to
the
sdk
and
say
hey.
We
think
http
is
better.
So
we
have
consistent
regarding
the
dot
net
offerings,
but
I
don't
think
that's
required
anywhere.
B
C
Yeah
so
people
to
look
at
that
depending.
D
C
Answer
if
the
answer
is
no,
we
have
to
have
the
grpc.
Then
we
invest
on
the
pr
and
go
with
the
I
I
don't
like
it,
but
then
we
perhaps
go
in
stages.
We
have
different
defaults
for
some
time
and
then
we
figure
out
how
to
fix
the
other.
So
we
can
have
the
same
defaults
everywhere.
C
All
right,
let
me
see
if
we
have
and.
C
Okay,
so
I
think
we
have
the
prs
to
the
three
pr's
that
are
not
weep
or
the
bump.
I
think
we
we
cover,
then,
so
I
think
we
can
go
to
the
next
topic.
Then.
C
So
the
next
thing
assembly
naming
strategy.
B
Yeah,
so
this
was
something
that
was
one
of
the
the
things
brought
up
in
my
pr
was:
we've
got
this
open,
telemetry.instrumentation
prefix
and
that
matches
the
convention
that
the
sdk
is
using
for
its
source
code.
Instrumentation
and
the
question
is:
are
there
concerns
about
conflicts
with
any
of
our
packages
with
any
packages
that
the
sdk
will
release.
B
And
so
I
do
feel
like
there
is
a
potential
for
that,
but
at
the
same
time
I'm
just
gonna
pick
on
this.
The
startup
hook
as
an
example.
B
C
A
A
C
I
I
think
I
think
we
had
exactly
this
in
the
past
and
I
think
I
suggested
to
remove
the
auto
segmentation
because
we
end
up
removing
because
it
was
kind
of
the
names
are
pretty
big.
You
know,
but
I
think
it's
it's
a
good
point
that
there
is
the
potential
of
conflict
and
if
you
use
a
different
prefix,
we
avoid
all
of
that.
You
know
this
is
something
that
really
didn't
occur
to
me.
When
I
made
the
suggestion
I
I
kind
of
just
wanted
to
reduce
the
long
names
you
know.
B
Right
and
so
like
in
the
case
of
the
startup
hook,
would
it
make
sense
to
be
something
like
open,
telemetry,
dot,
startup
hook,
and
you
don't
have
that
instrumentation
prefix?
Or
do
we
want
to
follow
the
convention
that,
oh,
this
is
a
loader,
so
it's
opentelemetry.loader.startuphook.
C
C
You
know
so
for
distribution,
okay,
it's
a
very
nice
way
for
people
that
have
access
that
they
build
time
to
package
that,
even
even
just
as
a
nuget
package
content
for
people
that
don't
have
build
time
access
you
know.
So
I
think
we
need
to
think
about
putting
package
name
in
the
context
of
the
profiler.
C
You
know
so
I
I
tend
to
think
that
open
telemetry
dot,
startup
hook
maps
very
directly
to
the
future.
You
know
kind
of
they
start
up
hook,
but
I
I
I'm
afraid
that
kind
of
going
say:
hey,
let's
go
if
that
is
kind
of
I'm
missing
some
case.
You
know.
C
Yeah,
what
about
the
following?
Let's
create
a
issue
and
follow
kind
of
the
pattern
that
the
dotnet
and
the
hotel
follows
for.
Spec
is
kind
of
make
a
proposal.
On
top
start,
a
discussion
keep
updating.
So
we
can
see
how
the
things
look.
You
know-
and
I
think
not
just
the
name
of
the
assemblies,
but
let's
put
potential
for
future
nuget
package.
C
I
think
I
think
that
you
do
the
discussion,
I
think
for
the
pr
itself.
Let's
not
change
that
in
the
pr
right
now,
but
let's
create
this.
Can
you
take
care
of
creating
the
issue
chris.
C
B
C
And
and
then
we
go
from
there
and
let's
invite
cejo
the
guys
from
actually
the
more
eyes
that
we
get
on
that
the
better
you
know,
and
so
not
only
cesaro
but
the
the
whole
the
whole
folks.
Alan
should
have
some
alias
that
we
can
use
and
get
everyone
yep.
D
C
Yeah,
I
I
think
either
we
are
gonna
kind
of
having
a
prefix
but,
on
the
other
hand,
seems
very
wasteful
for
things
like
startup
hook.
You
know
open
telemetry,
startup
hook
is
very
informative.
In
my
mind,
you
know.
D
Or
we
can
just
add
the
auto
parents.
We
had
the
auto
instrumentation
nurses
like
a
complete
segment
in
the
name,
so
we
removed
it.
And
if
you
had
auto
instrumentation
change
the
instrumentation,
the
auto
instrumentation,
then
it's
just
that
for
yeah.
C
I
I
I
think
that
avoids
the
conflict,
so
basically
we
have
a
prefix,
that's
ours,
but
on
the
other
hand,
I
I
I
think
I
want
to
see
some
examples
to
to
see
how
it
looks
before
we
make
this
call.
You
know
after
we
create
some
new
get
package,
we
can
change
later,
but
it's
very
annoying.
You
know
change
a
nuget
package
because
the
other
one
keeps
existing
forever.
So
basically
you
create
a
new
you
know.
So
please.
A
Remember
that
we
have
also
the
contrib
repository
and
they
have
as
I
as
I
remember,
they
have
open
telemetry
instrumentation.contrib
namespace
reserved.
So
the
question
is:
if,
if
we
need
anything
from
them
also.
C
Yeah
yeah,
so
so
that
that
is
another
point
for
erasmus
proposal
of
having
a
a
shorted
auto
to
avoid
the
long
very,
very
long
names
but
create
a
prefix,
that's
ours,
you
know
and
we
avoid
these
conflicts
yeah.
So
I
think,
let's
create
the
issue,
discuss
this
with
the
proposals
and
come
to
agreement,
and
then
we
do
the
big
rename
again.
C
C
B
Yeah
and
hey:
it's
not
like
any
of
us
foresaw
it
either
so
you're
not
alone.
C
All
right
anything
else,
guys.
C
All
right
then
talk
to
you
guys
later
bye.