►
From YouTube: 2021-06-16 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
C
A
C
A
B
By
the
way,
bob
is
it
all
right,
I
might
be
I'm
going
to
be
doing
a
presentation
on
my
design
for
my
project
information.
All
right
sounds
good.
A
Oh,
you
want
to
do
that
in
this
meeting.
Yeah
yeah
sounds
great,
we'll
save
that
to
the
we'll
save
that
to
the
end,
because
I'm
not
sure
hey,
I'm
not
sure
who's
going
to
be.
I'm
not
sure
who
wants
to
what
watch
that,
but
yeah
at
least
I'll
be
here
for
it
for
sure.
B
Yeah
yeah
elite
time
might
be
coming
in
so
we'll
see
all
right.
A
E
A
A
And
a
face
face
to
the
name
nice
to
meet
you
nice,
to
meet
you
too,
all
right,
so
we're
five
we're
at
five.
After
so
we
can
get
rolling
on
our
discussion.
So
the
things
that
I
have
for
us
today,
we
have
not
very
many
open
prs.
Sean's
otlp
http
first
pass
is
up
there.
If
people
are
interested
in
how
he's
planning
on
implementing
the
http
version
of
the
open
telemetry
line
protocol,
you
can
check
out
that
pr.
It
seems
like
it's
right
on
track
and
not
to
do
similar
to
his
grpc
implementation.
A
Alex
perez-
who
isn't
here
but
he's
one
of
the
new
amazon
interns
has
an
exporter
factory
pr
open.
So
I'm
excited
for
that.
One
to
get
merch
just
has
like
a
couple
more
fan
errors
to
slog
through
and
then
we
should
be
in
good
shape.
Saktib's
pr
has
been
up
for
a
month
and
he
hasn't
been
active.
So
we'll
see
how
that
udp
and
thrift
one
goes.
We
might
just
like
put
that
back
in
an
open
backlog
and
darla
darla
borders,
mutation
testing
pr
has
been
up
there
for
six
months.
A
I'm
gonna
follow
up
with
him
and
see
if
he
wants
me
to
do
anything
about
her,
if
we
just
don't
want
to
deal
with
it
at
this
time
we
have
some
new
open
issues
that
are
available.
A
A
There's
one
for
the
otlp
grpc
exporter
implementation.
I
think
sean's
going
to
take
a
look
into
that
one
and
then
the
event
attributes
one
has
been
around
for
a
little
bit.
That's
the
one
that
pronabc
had
opened
with
event
attributes
not
showing
up
in
the
exporter,
but
that
is
earth
not
in
the
exporter
in
the
zipkin
and
jager
front
ends,
but
that's
something
that
is
not
hyper
critical
but
something
we
want
to
fix
eventually.
So
those
are
the
main
new
open
bugs,
and
so
let's
see
what
else
do
we
have
computers?
A
Having
bugs
open
discussion?
Tobias,
you
had
a
question
about
the
api
as
a
decoupled
dependency
and
I
think
you
would
probably
have
some
questions
for
amber.
Who
is
also
here.
I
don't
know
if
you
know
jayla
ember
works
for
new
relic,
tobias.
Are
you
or
do
you
work
for
a
specific
company?
Are
you
independent?
F
A
So
that's
good,
so
you
had
a
question
about
yeah
this
issue,
356
on
the
api
as
a
decoupled
dependency.
F
Yeah
the
specification
sensor
api
must
be
completely
decoupled
from
the
sdk
as
well
as
some
of
the
exporters.
As
far
as
remember
and
yeah,
the
question
is:
if
this
should
be
done
in
one
repository
or
mult
modern
one
people.
A
So
the
one
of
the
main
things
that
and
alolita
you
might
be
a
good
person
to
ask
about
this
too,
but
one
of
the
main
things
that
I
saw
with
this
is
when
we
were
started
like
when
we
had
started
this
repo.
This
was
not
a
requirement
and
I
think
that
it's
been
added
as
a
requirement
within
you
know
not
within
like
a
specific
time
frame.
A
So
I
think
it's
something
that
we
should
certainly
figure
out
and
like
figure
out
the
right
way
to
decouple
them,
but
the
reason
that
they're
not
is
because
that
wasn't
like
an
initial
specification
thing.
So
so
I'm
wondering
if
we
should
just
like
if
we
should
have
separate
apis
and
sdks
available
like
have
separate
repos
for
apis
and
sdks
now
or
if
we
should
split
them
up
later
or
whatever.
But
I'm
open
I'm
open
and
willing
to
listen
to
suggestions
or
comments,
but
I'd
love
to
hear
from
others.
E
I
think
so
far,
bob
at
least
in
most
of
the
language
like
repost,
the
metrics
traces
and
logs
implementations
for
the
api
sdks
have
been
within
the
you
know
core
repo.
So
but
there
are
folders,
you
know
like
some
subfolders,
so
that
they're,
you
know
modular
enough
to
be
built
and
tested.
You
know
in
interim
stages,
but.
A
E
A
C
A
So
I
think
that,
while,
while
that
seems
like
a
fruitful
endeavor,
I
don't
think
that
that's
actually
gonna
help
us
at
all.
I
understand
that
we're
not
following
the
specification
exactly
in
that
that
bit,
but
with
different
language,
different
languages
have
different
idioms
and
I
think
that
those
packages
being
available
separately
is
like
that's
going
to
be
very
difficult
for
php.
E
Yeah,
because
in
php,
when
would
you
actually
use
an
api
without
the
sdk
I
mean
that's,
you
know
again
it's
language
dependent
right,
but
if
you
have
a
specific
use
case,
that's
super
helpful
to
understand.
C
A
F
E
A
A
But
I
think
that
I,
like
my
perspective,
is
I'd
prefer
to
keep
them
in
one
repo,
unless
we
have
like
a
very,
very
important
need
to
separate
them,
because
I
think
it
would
be
a
pain
for
all
of
the
maintainers
like
try
and
maintain
them
separately
and
php.
You
should
never
need
to
use
them
in
two
separate
pieces,
so.
A
B
Yeah
for
sure,
should
I
be
sharing
the
screen,
or
should
I
just
go
through
it.
E
B
A
By
the
way,
tobias,
while
we're
waiting,
thank
you
so
much
for
finding
that
environment
variable
fix,
but
I
know
omniam
was
working
on
that
and
he
just
like
was
banging
his
head
and
you
thank
you
very
much
for
finding
that
that
would
have
been
a
lot
of
searching
for
not
a
lot
of
effort.
So
I
really
appreciate
that.
B
So
in
this
proposal
there's
going
to
be
four
main
portions,
only
three
of
them
will
be
in
the
actual
php
library.
The
fourth
is
going
to
be
in
the
hotel
collector
because
it's
just
for
error
processing,
but
we
have
the
propagator
the
id
generator,
and
then
we
have
four
detectors
all
for
aws
services
and
then
the
error
processing,
which
is
done
in
the
collector,
the
go
download.
B
So
the
propagator
is
provides
aws,
x-ray,
specific
propagation
formats
for
the
http
headers.
That
needs
to
be
specific
for
aws
x-ray,
trace
header
format
right
now,
open
telemetry
uses
the
w3c
trace
header
format
and
below.
We
can
see
the
difference
between
the
two
different
formats.
Here
we
have
the
w3
trace
header
format
with
the
id,
and
then
we
have
the
amazon
one.
Following
so
to
implement
that
propagator,
we
need
three
different
functions.
We
need
the
inject
function,
extract
and
fields.
B
So
here
we
have
where
would
be
contained
and
it's
a
it's
just
going
to
be
a
class
called
aws
x-ray
trace
context
and
it's
going
to
implement
the
text
map
by
specifications
and
here's
where
the
methods
will
be
defined
so
with
inject,
it's
essentially
just
injecting
the
value
into
a
carrier
so,
for
example,
into
the
headers
of
an
http
request,
and
it
should
accept
three
parameters.
B
The
context
from
the
previous
span
tree
the
text,
map
carrier
interface
and
then
the
setter,
which
I
got
from
the
other
from
the
text
from
the
original
text
map
propagator
function
in
php
that
is
already
defined.
That
is
one
of
my
questions
later
that
I
guess
you
can
address.
Let
me
just
I'll
just
get
through
these
different
functions.
B
First
and
then
we
can
address
the
questions
I
have
so
that's
for
injecting
and
then
extracting
is
just
exactly
how
it
sounds
is
you're
extracting
the
value
from
an
incoming
request
and
that
will
extract
the
metadata
from
the
context
and
return
a
new
context,
creating
created
from
the
old
context
and
then
pass
that
on
to
the
next
process.
B
So
the
fields
is
essentially
the
predefined
propagation
fields.
So,
if
your
carrier
is
reused,
you
should
delete
the
fields
before
you're.
Calling
inject
and
more
details
are
defined
here.
I'm
just
going
to
be
skating
over
this
document,
mostly
and
don't
want
to
drag
it
on,
but
essentially
what
the
use
cases
for
this
is
along
pre-allocation
of
fields,
especially
in
systems
like
grpc
metadata
and
also
allowing
for
a
single
pass
over
an
iterator.
B
So
here's
where
it
would
return
the
list
of
fields
that
will
be
used
by
by
text,
mac,
propagator,
all
right
and
the
questions
I
have
concerning
these-
that
maybe
bob
or
someone
else
could
answer
is:
where
should
it
be
prop
the
probably
gonna
be
located
in
terms
of
the
php
library,
so
it
should
be
within
sdk
trace
or
should
it
be
within
the
contrib
folder
and
the
security
needs
to
be
considered
here
are
like
credentials
used
or
some
other
php
specific
security
that
needs
to
be
considered
and
then
also
what
are
the
getter
and
setter
methods?
B
Is
that
just
a
helper
method
that
or
helper
parameter
that
helps
set
these
values
within
extract
and.
E
Inject
yeah
I
mean
so
going
back
to
the
first
question
bob.
This
is
the
again
we
were
looking
at
the
you
know
way.
Contrib
is
just
a
folder
today
within
the
main
core
repo.
Obviously
other
languages
have
a
contrib
repo.
You
know,
because
it's
easier
for
vendor
integrations
to
actually
sit
outside
core
and
you
know,
get
core
can
be
built
without
vendor
integrations
and
then
clearly
you
know
there
can
be
another
build
which
is
incor,
including
you
know,
vendor
specific
libraries.
So
what?
What
is
your
recommendation
at
this
point?.
A
So
the
our
plan
was
originally
to
have
this
contrib
folder
live
in
the
in
our
php,
monitor
repo,
until
we
had
an
explicit
reason
to
need
a
separate,
contrib
repo,
and
I
think
that
we're
probably
getting
to
that
point,
I
think
that
it
might
be
worth
coming
up
with
an
open,
elementary
php,
contributor,
repo
and
then
starting
to
move
our
contribute
can
trip
things
there
rather
than
in
the
route
we
just
hadn't
had
like
a
specific
need
for
that.
Yet
I
can
take
that
action
item
of
getting
that
separate.
E
Yeah,
I
would
propose
that,
because
you
know
we
want
to
kind
of
overall
at
the
project
level
be
consistent
in
terms
of
how
can
trip
contrib
is
structured,
and
you
know
how
we
actually
do
release
releases
and
builds
and
and
that's
exciting,
because
I
know
the
new
relic
components
are
also
in
the
same
folder
today.
So
at
least
you
know
that's
you
know
that
would
be
consistent.
A
D
A
A
A
Sweet,
okay,
that's
cool
and
then
yeah.
I
think
that
contributor
is
the
right
place
for
that
security
need
need
to
be
considered
and
credentials
used.
I
we
don't
have
any
like
plain
text
credentials
stored
in
our
repos.
Now,
if
you
have
any,
then
we
probably
need
to
come
up
with
some
sort
of
methodology
for
that
yet.
But
you
can
be
prescriptive
with
that,
if
you'd
like
oliver,
because
we
haven't
done
that
yet
and
the
security
that
we're
using,
we
have
these
psalm
securities
tools
that
scans
our
repo
as
part
of
a
github
action.
A
So
when
we
change
like
when
we
create
a
new
contrib
repo,
then
we
could
then
we
would
we'll
create
a
new
trip
repo
and
we
move
the
github
action
over.
It
should
still
do
the
same
security
analysis,
so
that
should
be
all
right.
Okay
sounds
good
and
the
answer
to
the
last
one
I
have
no
idea.
So
that's
something:
okay,.
E
E
No,
we
just
built
out
the
the
github
action
workflows
for
the
security
you
know,
codeql
and
and
others.
So
I
agree.
That's
what
we
use
for
php.
E
A
D
B
Okay,
so
I
guess
I'll
find
out
what
these
are.
I
guess,
as
I
implement
it,
but.
A
The
other
thing
that
I
want
to
make
sure
that
I
don't
forget
to
tell
you
about
this
document.
Is
you
should
we
should
definitely
make
sure
that
family
reviews
this
document
too,
because
he's
been
working
on
the
w3c
spec
in
open,
summary
php,
and
he
might
want
to
see
this
just
to
make
sure
that
he
has
contextual
awareness
of
what
you're
trying
to
do
amber?
Do
you
want
me
to
just
ping
him
with
this
on
get
on
slack,
or
do
you
want
to
follow
up
with
him.
C
Who
is
this
yeah
he's
out
like
for
an
hour,
so
he
won't
get
it
right
away,
but
oliver
I
can
give
you
his
email
or
actually
it's
just
in
the
document
there.
The
can
we
bring
him
on.
I
mean
yeah,
he's
he's
pingable,
but
he's
just.
C
A
Spec
for
the
hp
repo,
his
name
is
f-a-h-m-y.
E
Okay,
okay,
cool
cool,
very
good,
so
oliver
we
can
bring
him
on
the
issue
itself
and
we
can
post
the
link
to
the
doc
so
that
he
can
also
take
a
look
and
provide
any
feedback.
B
Got
it
okay,
great
all
right?
So,
let's
move
on
to
the
id
generator,
so
the
id
generates
a
a
pretty
simple
method,
or
I
guess
class.
But
it's
the
purpose
of
this
component
is
to
confirm
conform
to
aws
x-ray,
trace
id
format
so
currently
otel
uses
a
different
id
format
and
the
the
whole
the
whole
point
of
this
is
just
just
just
to
switch
it
to
the
aws
x-ray
id.
B
So
it's
going
to
have
two
methods
and
the
first
one
is
the
generate
trace
id
which
is
used
for
generating
a
new
trace
id,
and
this
is
the
one
that
I
will
be
implementing
the
original
one
or
there's.
Also
another
method
called
general
generate
span
id
which
won't
be
mutated,
it'll,
be
the
same
as
the
original
implementation
by
hotel,
because
there
is
no
constraints
by
aws
x-ray
for
that,
so
here's
an
example
to
kind
of
illustrate
how
we
would
be
converting
it.
B
So
a
trace
id
is
generated
on
a
date
and
we
get
that
time
stamp
and
we
use
an
epoch
converter
to
change
the
date
into
an
epoch,
timestamp,
and
then
this
is
what
it
would
look
like
and
then,
after
using
that
ebook
converter,
we
convert
it
to
hexadecimal
and
then
the
remaining
24
digits
are
randomly
generated,
so
essentially
that
the
the
only
constraint
with
aws
extra
trace
id
is
that
the
first
first
eight
hexadecimals
are
the
timestamp,
and
then
we
have
the
version
number
here,
then
the
rest
are
just
randomly
generated
as
originally
in
hotel.
B
So
again,
I
guess
this
has
been
answered
already.
Where
should
it
be
located?
It's
just
gonna
be
looking
in
the
contrib
folder
now
or
not
control,
but
the
repository
and
then
here
same
question.
The
security
needs
to
be
considered
here.
B
A
The
answer
to
that
is,
we
don't
really
have
like
a
set
standard.
We
try
and
do
our
absolute
best
of
key
like
maintaining
the
same
amount
of
code
coverage
and
not
letting
it
decrease,
but
unless
it's
like
a
dire
circumstance
like
we
is,
we
don't
have
like
a
set
like
if
it's
less
than
90,
then
you
can't
merge
this
and
or
like
okay.
It
has
to
be
above
a
certain
amount.
It's
just.
It's
sort
of
a
judgment,
call
that
the
approvers
and
maintainers
keep
like.
A
B
Good,
so
now
just
the
detectors,
this
will
be
a
pretty
quick
cover
coverage,
so
this
is
we'll
be
having
four
detectors:
ecs
ec2,
eks
or
lambda,
and
the
detector
recognizes
whether
an
application
is
instrumented
with
hotel,
php
sdk
and
is
running
on
any
of
the
aws
services
or
not
so,
and
then
after
it
would,
it
would
be
populating
the
resource
with
meditate
metadata,
according
to
whatever
is
available
for
that
given
resource
or
that
given
service.
B
So
a
couple,
quick
questions
again
same
thing:
these
have
been
answered.
Are
there
any
other
considerations
or
I
am
missing?
I
guess
we
can
cover
that
after
I
finish
going
over
these
different
detectors,
so
the
ecs,
the
detector,
will
find
out
if
it's
running
on
an
ecs
environment
and
the
metadata
that
it
will
be
populating
is
container
id
and
name.
Those
are
the
only
two
that
are
available,
so
the
get
container
id
and
get
host
name
are
essentially
helper
functions
for
this
detect
method,
which
is
we'll
just
run.
B
B
The
ec2
detector
is,
if
the
application's
running
on
an
ec2
instance.
So
for
this
I
still
need
more
information
from
the
aws
x-ray
team
to
understand
what
they
want
us
to
return
and
populate
with
their
resource
and
we'll
be
having
a
meeting
with
them
later
today
to
find
out
what
exactly
they
need
and
then
for
the
eks.
B
B
So
here
we
have
detect
and
it'll
be
checking
if
it's
running
on,
if
it's
an
eks
instance
it
if
it's
running
on
kubernetes
and
then
it'll
get
the
credentials
and
get
essentially
the
cluster
name
and
the
cluster
id
and
it'll
populate
it
regardless,
if
not
it'll,
just
return
an
empty
resource
and
then,
lastly,
the
lambda
detector.
This
is
similar
to
the
deal
with
ec2.
I
still
need
more
information
on
from
the
aus
x-ray
team,
but
I
was
just
looking.
B
A
A
You
so
I
think
eight
is
probably
that
should
probably
also
be
in
contrib
once
we
get
that
up
and
running
same
sincerity,
same
consider
the
same
security
consideration
unless
you
all
have
a
separate
like
unless
you
all
have
separate
security
considerations
that
you
need
to
make
on
your
end
and
then
I
don't
think,
there's
any
considerations
that
I
can
think
of
right
now.
B
Awesome,
okay,
great,
so,
lastly,
is
just
the
testing
strategy.
This
project
will
follow
td
tdd
practices
during
development,
and
the
framework
like
you
get
you
guys
are
using
already.
It's
just
gonna,
be
the
php
unit
for
writing
the
unit
tests.
B
Currently
I
don't
have
any
unit
tests
written
out
or
ideas
written
out,
yeah
it'll
just
be
kind
of
generally
normal
abnormal
edge
cases
and
a
generally
wide
coverage.
B
But
this
is
something
I'll
be
implementing,
be
going
over
and
writing
out
in
my
documents
within
the
next
week
and
then
integration
tests
at
least
one
will
be
implemented
once
the
propagator
and
ig
generator
are
completed
so
that
there
can
be
a
full
pipeline
between
the
hotel,
php,
instrumented
application
and
aws
x-ray,
but
yeah
that's
about
it
for
the
design
proposal.
A
E
Like
a
great
start
to
me,
cool
and
and
bob
we
will
plan
to,
you
know
again,
obviously
do
the
you
know
full
design,
get
prs
for
each
of
these
components
and
then
also
tests
full
text.
So,
looking
forward
to
this.
A
Looks
like
there's
a
lot
of
there's
this
document.
It
shows
a
lot
of
like
good
design
considerations
and
it
looks
like
you'll
have
a
lot
of
cool
work
to
do.
E
Yeah
definitely
yeah
I'll,
be
able
you
know,
added
x-ray
support
again,
it's
a
good
test
for
tracing
for
various
language,
libraries.
So
super
happy
to
add
this
to
php.
E
Cool
thanks
oliver
and
and
again
I
I
have
to
drop.
I'm
sorry
bob,
but
thank
you
again
for
taking
a
look
and
everyone's
feedback
would
be
awesome
to
have.
If
you
guys
have
any
concerns,
or
would
you
like
to
see
more
detail,
please
just
add
your
comments
to
the
doc.
E
C
D
F
Some
news,
I'm
regarding
the
spec
there,
currently
some
differences
with
the
implementation.
What's
the
plan
to
upgrade
this
the
rpe
part
first
or
sorry
and
rp
at
the
same
time,.
A
Usually
we
we
usually
try
we're
not.
We
haven't
released
our
release
candidate,
yet
so
we
can
we've
been
doing
api
and
sdk
updates.
At
the
same
time,
once
we
get
to
a
point
where
we're
we're
feature
dependent
like
we
have
enough
features
that
we're
1.0
release
candidate
compliant,
then
we'll
have
to
start
considering
api
and
sdk
updates
at
the
same
time.
But
right
now,
that's
not
a
consideration.
We've
really
taken
heavily
because
we
haven't
had
to
okay
we're
not
worried
about
backwards
compatibility
breakage.
Yet
at
this.