►
From YouTube: 2021-01-27 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
Oh
yeah
and
the
open
telemetry
calendar
it
doesn't
require
you
to
enter
the
passcode
manually.
A
Yeah
because
I
think
they
put
the
link
there
with
everything
you
know
so
yep.
I
think
it's
just
if
you
go
to
the
one,
that's
just
the
number
I
I
was
in
the
meeting
with
the
the
first
meeting
of
the
hotel
number
and
it
was
zoom
bombed,
it
was
horrible
and
then
unfortunately
I
I
know
the
guy
that
does
the
youtube
stuff
and
I
said:
hey:
please
delete
that
one.
It
was.
B
A
And
and
then
you
think
people
do
that
just
to
screw
up.
If
somebody
meeting
you
know
there
is
no,
there
is
no
hacking.
There
is
no,
I'm
not
saying
that's
better
if
there
was,
but
for
nothing.
It's
just.
You
cause
trouble
exactly.
B
A
A
A
B
A
A
A
Yeah
but
but
for
instance,
for
this
meeting,
I
simply
close
my
slack
because
it's
right
dave,
I
I
think
we
can
start
I
I
will
have.
I
ask
for
you,
if,
if
you
have
somebody
that
can
do
that,
there
is
upcoming
change
into
the
open,
telemetry
collector
in
which
they
are
going
to
collect
the
dotnet
core
metrics,
so
they
already
have
matrix
collections
for
a
lot
of
stuff
and
they're
gonna
add.net
core.
A
This
is
on
the
collector
repo,
but
is
basically
just
looking
at
the
code
that
interacts
with
the
server
of
those
metrics
and
enumerate.net
core
processes.
You
know,
if
you
have
somebody
that
can
take
a
peek
at
that
you'll
be
great.
You
know
it
it's
in
goal,
but
I
I
think
it's
more
about
the
protocol
and
and
see
if
it's
interacting
with
the
server
in
the
correct
inspected
format.
A
Yes,
I
put
in
the
dark,
but
I
I
o,
let
me
get
you
the
exact
link
I'll
put
here
on
this.
A
A
So
basically,
I
I
think
what
I
pointed
to
the
guys
doing
it.
I
know
then,
and
they
asked
me-
I
pointed
to
the.net
tools
as
a
reference
that
used
that
so,
if
they
I
didn't,
have
a
chance
to
look
at
the
internals
yet,
but
they
should
be
following
the
same
conventions
whatever
they
are.
B
All
right,
yeah,
so
paulo
one
of
the
questions
that
I
have
there
so
there's
work
to
try
to
pull
in
the
metrics,
but
there's
other
diagnostic
tools
there,
and
I
was
just
wondering
if
anybody's
thought
about
trying
to
extract
information
from
those
in
the
same
way
that
those
other
tools
do
to
try
to
generate
spans.
I
mean
you,
obviously
wouldn't
get
a
distributed,
trace
able
to
be
built,
but
you
could
get
insight
into
a
process.
A
I
I
can
tell
that
this
came
from
some
people
that
we
talked
about
that
are
moving
through
docker
linux
because
they
have
some
old
stuff
that
collects
from
windows
those
metrics
and
it
was
very
targeted
to
the
metrics.
So
I
don't
think
there
is
anything
looking
at
the
other
data.
But
that's
that's
an
interesting
point
and
after
you
have
the
the
thing
talking
to
that
enumeration
of
processes
and
everything,
then
I
think
we
open
that
possibility.
You
know
so.
A
Yeah,
so
one
thing
that's
also
good,
for
that
is
that
aws
has
a
distribution
with
the
collector
so
that
you
make
very
easy
to
collect
the
dotnet
metrics
on
aws,
just
using
the
stuff
that
they
provide.
You
know,
so
I
think
it's
a
win-win
for
various
sites
here.
If
that
works
well,.
A
A
It's
an
interesting
scenario
unless
somebody
has
some
other
question
about
that.
I
had
one
topic
that
I
wanted
kind
of
to
go
over.
I
kind
of
let
me
share
here
the
the
talk
so.
A
So
last
time
that
actually
not
last
time,
but
we
had
a
meeting
on
monday
with
tony
from
datadog
that
presented
to
us
the
status
of
call
target
and
we
talked
about
what
we
need
kind
of
to
have
a
prerelease
that
perhaps
we
can
kind
of
start
really
dog
fooding
that
stuff
and
but
we
need
to
do
to
to
deploy.
We
need
to
do
kind
of
the
minimum
stuff
to
call
it
open
telemetry,
and
I
was
trying
to
release
those
you
know.
A
I
can
start
to
dog
food
in
very
small
scale
before
that,
but
I'm
I'm
trying
to
look
a
few
more
ahead
and
independent
of
the
work
that
we
need
to
do
to
consume
to
consume
active
source.
That
is
the
thing
that
I've
been
working
with
greg
and
that's
kind
of
progressing
slowly,
but
I
think
we
can
work
on
this
other
side
without
blocking
you
know.
A
A
The
protocol
itself-
I
think
I,
since
we
don't
have
public
kpis
and
zac-
can
correct
if,
if,
if
I
I'm
mistaken
about
that-
but
I
think
just
to
are
more
in
the
sense
of
making
clear
that
slope
and
telemetry,
although
is
based
on
data
dog,
I
don't
think
we
need
to
change
any
of
the
internals
regarding
space
or
anything
like
that.
A
But
I
think
to
avoid
any
confusion
or
side
by
side
things.
We
need
to
kind
of
change,
name
of
files,
deployment,
folder
and
guides
for
install,
and
this
kind
of
thing
and.
C
A
It's
going
to
be
clear,
that
is
the
data
dog,
but
just
have
that
layer.
That's
really
visible
to
the
user,
with
the
proper
name.
A
Besides
that,
we
talked
about
this,
the
dock
that
greece
mentioned
and.
C
A
Not
me
wrote
about
following
the
conventions
and
one
thing
we
need
to
create
our
abstraction
via
build
a
way
to
separate
the
convention,
so
we
can
build
either
with
the
data
door
conventions
or
with
the
open
telemetry
conventions,
and
just
because
we
need
this
to
kind
of
be
able
to
call
it
open
telemetry.
A
A
Probably
the
idea
is
that
a
runtime,
but
at
least
we
have
a
configuration,
could
be
built
or
could
be
runtime.
I
think,
ideally,
is
runtime
very
what
greg
mentioned.
If
I
understood
correctly,
because
he
was
mentioned
that
down
the
line,
I
think
even
data
dog
if
they
have
customers
that
want
to
open
telemetry,
they
can
say.
Oh
okay,
use
our
code,
but
flip
the
convention
to
open
telemetry.
A
So
if
we
have
a
client,
a
web
request,
client
we
need
to
emit
with
that
convention
and
also
for
the
server
side.
We
need
to
to
be
able
to
receive
that
context.
So
that's
the
least
that
came
to
my
mind,
of
course,
is
just
a
first
kind
of
proposal
to
do
that
and
actually
doing
them.
The
today
I
was
doing
a
cherry
picker
of
the
chains
from
upstream,
and
actually
I
think
I
I
have
to
do
some
work
there
to
make
the
the
separation
easier.
A
I
I
think,
some
files-
eventually
you
have
to
have
two
pieces
for
both
data
dog
and
open
telemetry,
but
I
want
to
minimize
that
you
know
kind
of
I
think,
for
instance,
the
exporters
I
any
code
related
to
the
open,
telemetry
export,
as
I
can
put
in
a
folder,
and
I
think
that
some
of
the
changes
will
be
simple
stuff.
You
know
kind
of
oh
I'll,
declare
this
as
a
partial
class
and
in
open
telemetry.
A
You
have
a
folder
with
the
extra
configuration
for
the
export,
for
instance,
you
know
some
some
of
this
because
that
you
make
the
picking
up
changes
up
streams
and
in
both
directions.
Much
easier.
You
know,
so
I
think
that's
what
is
in
my
mind,
kind
of
where
I
would
start
with
this,
but
I
wanted
to
put
this
list
for
discussion.
A
You
know,
so
I
I'll
send
a
message
to
greg
so
he's
on
top
of
that
and
we
have
the
recording
here,
but
I
wanted
to
kind
of
really
start
working
on
this,
so
we
can
start
to
push
to
have
some
pre-release.
You
know
even
before
it
we
do
the
activity
source
stuff.
A
Of
course,
in
that
case,
we
are
not
to
interoperate
with
the
open
telemetry
menu,
because
we
are
not
supporting
direct
the
stuff
that
they
do
there.
But
what
I'm
seeing
I've
been
talking
to
a
lot
of
people
that
are
using
dotnet?
A
A
It's
typically
people
start
with
auto
instrumentation,
and
then
they
can
oh
I'd
like
to
enrich
the
data.
Then
they
they
they
want
to
go
and
kind
of
put
extra
stuff
there,
and
then
anyway,
this
you'll
be
done
under
the
umbrella.
What
I
think
should
be
called
a
pre-release,
so
we
can
really
start
to
talk
food
and
have
more
people
using.
So
I'm
not
too
concerned
about
that
scenario,
not
being.
A
Supported
any
thoughts
that
you
guys
may
have
about
this
any
concerns
yeah.
B
So
my
my
only
thought
and
concern
is
that
so
we
want
to
support
two
different
standards
within
this
project.
One
is
the
open,
telemetry
standards
and
the
other
is
the
data
dog
standards
and
being
able
to
configure
back
and
forth,
which
means
some
added
complexity
for
this
project
and
for
the
the
data
dog
project
too,
and
all
of
that
was
decided
to
make
it
easier
to
merge.
B
I'm
still
not
convinced
that
there's
going
to
be
a
big
merge
problem.
If
we
chose
one
standard
over
another,
I
mean
looking
at
the
instrumentation
walkthrough.
That
tony
gave.
I
mean
we're
really
talking
about
the
instrumentation
at
this
point
and
there
isn't
a
lot
of
code
in
there
other
than
okay
we're
instrumenting.
This
call
call
target
and
we
need
to
extract
this
piece
of
data
from
this
other
property
and
performance
wise.
B
A
Yeah
I
so
I,
if
I'm
understanding
correctly
you
you
are
kind
of
wondering
if
there
is
it's
worth
the
extra
abstraction
or
a
build
to
have
this
difference
to
support
both
correct
yeah.
I
I'm
I'm
starting
that
as
kind
of
the
initial
target,
because
what
I
heard
from
gregor
perhaps
I
misunderstood
is
that
from
datadork
perspective,
he
would
like
to
be
able
to
switch
back
and
forth
as
a
configuration.
A
So
that
that's
kind
of
why
I'm
starting
that
and
I
think,
except
perhaps
for
package
size,
I
think
we
can
do
this
at
runtime
at
relatively
low
cost.
You
know
what
comes
to
my
mind
is,
for
instance,
in
the
example
that
tony
shared
with
us.
There
was
the
create
scope,
factor,
create
http
context
or
scope.
Something
like
that,
and
I
think
that,
for
instance,
what's
going
to
be
different
between
the
versions
is
going
to
be
one
that
creates
different
span,
name
and
different
attributes.
A
You
know
so.
Can
we
set
the
instance
of
the
factory
at
start
via
the
configuration?
So
then
we
could
have
kind
of
a
extra
set
of
files,
just
leaving
the
open,
telemetry
and
and
then
datadog
can
pick
up
that
that
set
if
they
want
and
then
when
the
configuration
is
set
for
that
we
create
the
proper
instance.
A
You
know,
but
but
to
be
fair,
I
think
we
need
to
kind
of
do
a
a
small
design
discussion
or
perhaps
a
small
prototype
for
this
kind
of
things
and
and
discuss
with
the
concrete
things
at.
B
Hand,
you
know
yeah,
because
just
taking
a
look
at
the
instrumentation
for
some
of
them,
it
feels
like
you
could
get
away
with
a
lot
of
the
same
code
within
the
instrumentation,
but
then
there's
likely
others,
and
I
suspect
that
it
would
be
things
like
database.
A
A
C
From
yeah
from
my
my
point
of
view
in
the
hotel
project,
like
it
doesn't
seem
like
there's
much
of
a
need
to
be
able
to
switch.
If
we're
you
know
we're
focused
on
the
open
symmetry
spec
here,
and
I
can't
imagine
a
lot
of
the
paradigms
from
datadog
would
be.
I
mean
maybe
there's
some
relation
like.
Maybe
some
of
the
base
sort
of
like
attributes
and
properties
might
be
the
same,
but
what
we
do
in
our
project
won't
directly
translate.
C
So
it
doesn't
seem
out
of
the
question
to
me
to
have
our
data.
Repo
does
one
thing
and
then
the
hotel
does
another
one.
A
A
If
that's
not
correct
you
know,
then
we
can
choose
a
different
approach.
You
know
yeah
so
so
I
think
I
think
this
is
a
good
initial
discussion.
I
think
I'm
going
to
be
looking
prior
to
the
next
meeting
kind
of
some
small
stuff
to
make
this
path
easier,
and
I'm
gonna
start
to
play
with
some
of
these
ideas.
A
You
know
so
I
can
put
some
kind
of
draft
pr,
so
people
can
look
at
the
things
and
I
think
perhaps
there
will
be
if
we
confirm
this
case
about
having
this
as
a
configuration.
Perhaps
I
will
have
some
draft
prs
directly
on
the
datadog
branch,
just
to
show
the
things
to
the
rest
of
the
the
team
and
we
go
from
there.
You
know
I.
I
wanna
really
kick
start
this
discussion,
so
we
can
kind
of
have
this
pre-release
down
the
road
not
far.
You
know.
A
Okay,
I
think
I
think
we
touch
it.
I
think
the
actual
item
is
actually
for
me
to
try
to
kind
of
start
working
on
this
yeah
and
I'll.
Try
I'm
changed
to
other
subjects.
If
you
guys
want
to
go
to
that,
I
wanna
I
need
to
think
with
greg
about
the
active
source
rapper.
I
don't
know
because
he
was
doing
the
next
steps
and
I'm
not
sure
where
he
is
with
that
you
know.
A
All
right
and
dave,
if
you
really
get
somebody
to
look
at
that
pr
you'll
be
great.
You
know
just
to
confirm
that
they
are
in
the
right
path.