►
From YouTube: 2022-10-18 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
B
Yeah
yeah,
what's
hot
over
there,
is
that
like
32
35
yeah.
A
D
B
Cool
so
it
looks
like
we
have
probably
quorum
to
start
this
meeting
I
have
the
agenda
doc
open.
We
looks
like
we
only
have
one
item
right
now,
so
maybe
I'll
just
pause
for
a
second
and
we
can
let
people
fill
in
any
agenda
items
they
want
to
talk
about
today.
B
Also,
please
add
yourself
oops
to
the
attendees
list.
B
Okay,
cool-
we
can
jump
in
here
to
next
year.
The
first
one
up
you
have
follow-up
on.
How
does
the
EPF
ebpf
solution
differ
from
the
proposal
for
the
evpf
instrumentation,
so
let's
hand
it
over
to
you
yeah.
C
I
think
Aaron
might
be
a
better
person
like
whatever
we
had
like
a
one-on-one
attack.
I
think
those
are
the
three
points
he
described
there
like.
How
does
it
differ
from
ebpf?
C
The
major
ones
are
basically
the
Go
Auto
instrumentation
is
using
u-propes
and
but
ebpf
current.
The
other
project
is
using
K
probes.
If
you
don't,
you
can
open
the
link
I
put
in
to
see
what
is
a
k
probe
versus
what
say
you
probe
I.
Think
it's
just
so.
You
probes
are
like
at
that
top,
where
it's
application
system
Library,
so
you're
able
to
see
that
k-pops
is
much
lower
and
you
are
dealing
with
it.
Tcp
IPM,
those
kind
of
things,
I,
think
the
overall,
the
description
and
whatever.
A
Yeah
sure
I
think
that,
like
basically,
there
are
Works
in
a
different
layers.
So
this
is
foundation
instead
of
layer,
seven
application
layer
or
you
try
to
create
distributed
traces
and
metrics
so
go
applications.
You
know
things
like
database
queries
and
trpc
or
hdp,
because
which
basically
require
us
to
do
it
via
you,
probs,
which
is
a
one
of
the
features
in
ebpf
and
the
other
project,
the
other
than
previous.
A
It's
still
produce
a
different
type
of
telemetry
that
produces
metrics,
mostly
and
mostly
for
piano
events,
so
things
like
hard
risk
utilization
and
network
packets,
and
so
they
collect
different
data.
They
use
the
vpf
differently.
They
even
written
in
two
different
programming
languages
like
this
one
I
think
is
written
in
a
C
plus
plus
and
like
they
contain
the
logic
itself
is
really
different
like
we.
A
C
I
think
the
major
win
for
us
going
with
a
go
order,
instrumentation
I
think,
like
you,
are
suggesting
like
doing
a
database
or
grpc.
It
might
be
hard
to
do
like
in
any
other
language.
I
think
that's
a
biggest
advantage
and
that's
both
I
noted
as
my
thoughts
as
well,
like
basically
instrumenting
with
a
K
probe.
You
cannot
do
unless
you
are
doing
a
language
specifically
BPF
like
we
are
doing
I,
think
that
would
be
the
big
advantage
and
that
all
makes
sense
to
me
as
better.
A
Yeah
yeah
I,
totally
agree
like
David
harder
is
the
the
GPS
connection
is
encrypted
so,
like
you
have
to
sort
of
track
that
DLS
and
check
and
do
all
those
weird
stuff
and
like
when
you're
using
your
probes
and
you
are
sort
of
in
user
spaces,
simply
can
track
the
relevant
your
PC
method
and
see
the
arguments
and
produce
irrelevant
stands.
C
B
B
Perspective
is
this
appropriately
named
and
we
currently
have
the
target
of
putting
the
evpf
code
in
this
open.
Telemetry
go
instrumentation
project,
which
has
also
been
suggested
to
be
renamed
so
I'm
kind
of
wondering
what
your
thoughts
on
naming
for
discoverability
here
are.
C
This
code
is
still
going
to
be
instrumenting
go
code,
it's
not
like,
so
you
cannot
put
in
a
generic
ebpf
project
because
it's
still
instrumenting
only
go
code
and
every
language,
if
they
are
going
by
BPF
route,
has
to
be
in
the
language
specific.
That's
those
are
my
thoughts.
I
think
it
should
be
in
its
own.
Like
go.
Instrumentation
seems.
C
A
I
think
yeah
I
think
this
name
can
be
better
like
it
describes
like
what
the
technology
is
using,
but
not
at
what
type
of
the
telemetry
it
collects.
So
I
will
think
of
something
like
opposite
energy,
camera
or
some
I.
Don't
know
like
something
which
suggests
that
it's
producing
Canon
metrics.
B
B
So
that
might
be
something
we
would
want
to
I
know.
Let's
see
I
think
Robert
actually
created
an
issue
recently
around
naming,
let's
see
maybe
I'm
in
the
wrong
repository,
but
I
thought
it
was
in
the
community
Repository
actually
I'm.
B
Was
the
slack
oh
you're
right,
I
think
it
was
slack
Channel
okay,
I
feel
like
I,
could
probably
find
that
later,
but
I
I
agree.
I,
think
that
maybe
this
also
should
be
included
in
that
naming
revision.
But
I
do
like
that
idea
of
also
suggesting
something
like
open
television,
kernel,
instrumentation
or
kernel
collector,
or
something
like
that.
B
Oh
yeah,
the
kernel
collector
yeah,
look
at
that.
Okay,
it
might
be
worth
yeah.
B
Yeah
I
know
also
that
the
kernel
collector
may
get
confused
with
the
collector
repo,
but
I
do
think.
This
is
a
something
you
can
also
improve
on,
but
it's
still
like
I
think
a
closer
approximation
of
what
that
thing
is
actually
providing
rather
than
the
technology
it's
using
traffic
I
like
that
I
will
see
if
I
can
find
that
slack
Channel
and
include
this
in
that
discussion
or
at
that
conversation,
yeah.
B
D
B
Sounds
like
it's
a
pretty
good
understanding
that
we
wouldn't
want
to
try
to
merge
these
two.
They
do
provide
different,
Solutions
and
I.
Think
we
can
do
a
better
job,
identifying
that
for
the
community
at
Large.
So
there's
nothing
else
here
on
the
agenda.
I
did
want
to
talk
about
that
renaming,
but
I
think
that
I
don't
have
the
context
to
do
that.
Just
yet
I
do
know.
There
was
a
question
last
time
asking
about
how
can
we
progress
the
current
status
of
the
auto
Hotel
into
the
trip?
B
I
know
that
there
was
this
issue
that
we
had
open.
Oh
man
surrounding
this
I
don't
know
if
there's
been
any
progress
here
at
NFL,
we
want
to
get
an
update
on
this.
D
B
Yeah,
a
yeah-
maybe
that's
a
good
idea,
because
I
as
well
haven't
had
time
to
look
at
that.
So
maybe
we
could
just
talk
about
this
for
a
second,
so
I
think
the
the
main
thing
that
is
key
here
is
currently
everything
here
is
in
one
well,
it
should
have
an
owner's
file
somewhere.
B
Code
owners,
that's
the
name
of
the
file
and
that
currently
is
essentially
just
the
maintainers
and
the
approvers.
B
B
Yeah
here
we
go
okay,
so
I
think
this
is
probably
the
structure
that
we
would
want
to
bring
over
to
this
other
example:
I'm
sorry,
this
other
repository
so
actually.
B
So
one
of
the
things
is,
it
will
need
I
think
at
least
one
distinct
user
right,
because
there's
always
this
group
that
we
have
in
the
situation
that
actually
has
some
sort
of
ownership
of
it.
But
we
have
a
particular
individual
called
out
here.
B
B
I
think
that
they
currently
already
have
it,
but
it
just
needs
to
be
called
out
that
so
every
PR
in
a
sub,
let's
just
call
it
subdirectories,.
B
Something
like
that,
the
owner
user
itself
needs
to
actually
have
some
sort
of
approval
there.
I
don't
know
if
this
is
possible,
but.
B
Have
the
owners
themselves
be
able
to
merge
the
PRS
and
then
I
think
the
last
thing?
That's
key
for
the
collectors
approach
is
deprecation
strategy.
B
So,
if
they're
not
able
to
continue
on
us
owners,
but
I
think
this
also
needs
to
be
better
to
find,
because
it's
one
thing
to
say
that
you're
able
to
continue
on
as
an
owner
and
it's
another
thing
just
to
not
respond
to
something
for
an
entire
year.
So
you
know,
there's
probably
some
sort
of
Middle
Ground
that
needs
to
be
defined.
Where
that
that
becomes
the
question.
I,
don't
think
the
collector
has
ever
had
an
issue
with
this,
but
I
don't
know
just
kind
of
putting
this
out
there.
B
And
then,
if
unique.
B
Owners
of
a
sub
where
that
package
is
deprecated
package.
I
think
these
are
all
modules,
but
that's
actually
a
good
point
is
if
this
is
going
to
be
at
the
module
level.
B
Like
a
go
module
itself,
so
in
each
one
of
the
subdirectories
like,
let
me
just
open
this
up,
you
know
like
having
expectations.
There's,
not
really
a
need
for
an
owner
here,
because
it's
a
collection,
but
it's
having
somebody
be
an
owner
of
this
module
here.
I
think
is,
is
more
in
line
of
what
we're
trying
to
go
with
here,
so
I
think
go
module
is
the
demarcation
where
that
ownership
should
actually
be
defined.
As.
B
B
Yeah,
okay,
well,
is
this
a
good
start,
should
I
hit
comment,
and
then
we
can
build
from
this.
Does
that
sound
like
a
good
idea.
B
The
initial
owners
so
like
if
a
new
module
is
added
like
how
do
we
decide
on
that
mm-hmm
yeah
I
mean
I.
Think
that's
that's
a
good
point
like
it
needs
to
be
included
in
the
initial
PR.
That's
going
to
add
it
who
those
owners
are.
B
B
I
think
that's
a
pretty
fair
approach
here.
Also,
it's
just
to
say
that
anything
that
already
exists
as
a
module
needs
to
also
be
deprecated
or
assigned
another.
B
C
B
Okay,
I've
added
it
into
the
gosig
meeting
agenda,
so
I
will
talk
about
that.
There
I
think
that
looks
good
I.
Think
then
we'll
also
answer
this
question
with
that
initial
PR
as
to
like
who
the
owners
will
be
I,
don't
know
how
we
want
to
assign
owners.
Currently,
one
of
the
other
things
is
like
that.
B
Approvers
part
I
think
that
the
approvers
of
that
particular
one
for
the
source
code.
Modification
PR,
would
include
the
approvers
for
this,
not
necessarily
the
gosic,
there's
I
think
a
one-to-one
overlap.
This
thing
is
a
superset
of
that
Sig,
but
we
would
probably
want
to
list
it
that
way.
So
that
sounds
good,
so
I
think
then,
for
next
steps
on
getting
the
source
code,
modifier
or
source
code
instrumentation
merged
into
the
contribute.
When
you
talked
with
Anthony
I
think
he
was
out
of
the
loop
for
a
lot
of
the
discussion.
B
That's
happened
in
the
go
Sig
and
he
just
came
back
was
confused
by
this,
but
I
want
to
sync
with
them
as
well
on
Thursday.
So
that's
my
plan.
I
also
will
talk
about
this
on
Thursday
I.
Think
if
this
is
ratified
by
that
I
mean
it
would
probably
need
to
be
put
in
some
sort
of
policy
dock
that
we
have
at
the
top
level
of
this
repository.
So
probably
the
contributing
doc
or
something
like
that
I
think
is
probably
where
it
will
live.
I
think
that'll
be
the
yeah.
B
Yeah
so
I
think
if
there's
two
action
items
there,
then
to
assign
ownership,
but
also
to
then
add
it
to
the
policy
and
then
once
that's
done,
I
think
then
the
pr
to
accept
the
auto
hotel
is
the
next
step.
D
B
B
Okay,
then
I
will.
This
is
definitely
more
of
a
working
working
beating.
Yes,
that's
also
what
I
want
to
talk
about
next.
B
Okay,
cool
in
next
steps
for
the
evf
based
instrumentation.
That
I
think
is
also
for
discussion.
I'm
gonna
I've
been
talking
a
lot.
I
have
ideas
here,
but
I'll
hand
it
over
to
you.
How
do
you
see
this
going
next.
A
Yeah
sure
so
there's
this
open
pull
request
with
the
which
is
a
little
little
bit
outdated
and
it
updated
with
the
latest
commits
so
I
thought
I
can
take
it.
I
would
do
it.
Maybe
we
can
start
discuss
over
there.
It's
a
pretty
big
pull
request,
so
maybe
I
can
assist
that
I
can
walk
you
through
the
files
in
a
meeting
or
something
but
like
that's
what
I
had
in
mind
like.
C
A
C
B
I
don't
but
that's
a
great
question.
Stanza
is
what
you
said:
right,
yeah
I'm,
not
familiar
with
that
yeah.
C
Stanza
was
contributed
and
if
you
actually
see
there's
a
report
called
or
print
like
it's
now
currently
a
part
of
collector
country,
but
it
was
actually
contributed,
and
there
is
a
I
think.
Stanza
was
kind
of
contributed
in
like
dependent
chunks,
like
they
kind
of
wrapped,
like
they
set
up
their
own
repo
side,
repo
first
and
migrated
it
in
pieces
while
calling
those
other
you
know
third-party
chunks
and
like
progressively
moved
it
over
that
way.
I
don't
know
if
that
same
kind
of
approach
is
applicable.
B
Yeah,
so
I
I
agree
that
smaller
PRS
are
good,
but
I
also
feel
the
the
donation
side
of
this
as
well.
You
know
there
is
a
a
user
basis
is
already
being
worked.
B
This
is
always
going
to
be
a
hard
problem,
because
you,
you
also
don't
want
maintainers
or
approvers
of
this
project,
not
familiar
with
this
code
base,
because
that's
that's
also.
A
worry
here
is
to
accept
something
and
then
ask
the
user
base
to
go
fix.
Something
without
understanding
of
the
use
of
the
actual
code
base
is
a
problem,
so
yeah
I
see
I,
see
that
as
well
as
as
a
something
to
be
addressed,
I
also
see
it
as,
like.
B
I
see
a
few
approaches,
there's
obviously
some
structure
here.
This
is
a
singular,
go
module
right,
even
if
I'm,
not
mistaken,
yeah
yeah
is
even
getting
started
docs.
This
is
great.
B
A
It's
gonna
be
a
difficult
heck.
How
would
you
suggest
to
break
it
up
like.
A
Like
maybe
I
can
do
it
like
break
it
up
by
the
instrument,
difficult
instrumentation
libraries,
but
that's
not
going
to
like
played
it
to
very
small
parts,
because,
like
most
of
the
code
here
is
some
common
infrastructure
and
like
adding
a
job
PC
or
database.
Instrumentation
is
like
edition
of
one
file.
So
it's
not
going
to
help
a
lot
and.
B
So
Eden
I
know
you're
I,
I,
guess
I'm,
assuming
you're
able
to
commit
time
to
work
on
this
project
right
for
this
one
right.
Do
you
have
any
other
Engineers
that
are
looking
to
also
help
collaborate
on
this
one.
B
Yeah,
okay,
I,
so
I
I'm.
Definitely
one
of
the
things.
The
things
that
do
worry
me
about
just
accepting
something
from
a
donation
is
attribution.
It
needs
to
be
addressed,
I
think
so
yeah.
Maybe
we
just
talk
about
this,
so,
like
licensing
needs
to
be
updated,
I
think
the
other
thing
is
one
of
the
things
I'm
noticing
here
like
this
value
here
like
this
is
a
go
package
it.
Obviously
it's
going
to
change
based
on.
B
That
open
Telemetry
is
going
to
be
at,
but
the
other
thing
is
like
we
have
a
vanity
URL
system
so
like
we
would
want
to
decide
on
our
vanity
URL
to
host
this
so
similar
to
I.
Don't
know,
I,
never
typed
the
full
thing
yeah
something
like
this.
B
Like
there's,
there's
like
a
few
different
packages.
We
probably
want
to
put
it
here.
I,
don't
remember
all
of
our
vanity
urls.
B
Oh,
this
is
yes.
Wow
I
forgot
that
we
had
was
at
the
top
level
at
some
point,
but
yeah
we'd
want
a
vanity
URL.
So
you.
B
And
yeah
I
think
I'll
just
put
that
there
and
I
think
other
than
that
I
I'm
inclined
to
just
say,
like
you
know,
as
long
as
the
yeah
I
mean,
we've
already
got
a
lot
of
attribution
correct
the
the
code
I
want
to
give
it
a
once
over,
but
I
I
guarantee
that
you're
not
going
to
be
able
to
correctly
identify
bugs
in
14
000
lines
of
code
and
I.
B
Don't
necessarily
think
that's
going
to
be
a
issue
at
this
point
if
you're
going
to
adopt
the
code,
I
think
that
that's
something
that
like
we
should
try
to
do,
but
I
am
also
opened
up.
People
saying,
like
that's,
not
acceptable
and
having
their
opinions
heard
here
as
well,
but
I
I
just
like
if
the
project
is
trying
to
adopt
something,
it's
not
the
same
as
trying
to
create
something
and
I
think
in
that
process.
There's
a
little
bit
of
a
difference
in
in
how
that
review
process.
Going.
B
That
being
said,
I
also
want
to
say,
like
for
the
source
code,
modification
I
would
I
would
agree
that
that's
also
probably
the
same
for
the
pr
that
goes
into
the
contribute.
Repository
and
we
used
to
be
discuss
with
the
owners
of
that
repository,
but
yeah
I'm
open
to
hear
other
people's
opinions
here.
D
I
think
that
dividing
these
instrumentations
might
make
sense
and
update
them
one
by
one.
So,
for
instance,
we
can
add
https,
first
one
and
so
on,
and
also
what
I
would
do.
I
would
take
this
code
and
just
test
it
from
the
user
perspective
and
then
just
to
familiarize
myself
with
with
the
code
and
that's
how
probably
a
review
process
show
should
should
be
done
from.
From
my
perspective,.
A
The
the
testing
should
be
pretty
easy,
like
there
is
a
really
good
documentation
you
think
about
how
to
generate
this
is
the
tracing
for
like
a
couple
of
go
applications
that
crying
kubernetes
and
exceed
results
in
Jaeger,
but
yeah,
yeah,
I,
agree.
D
So
I
can
help
with
this
process,
so
I
can
try
to
test
it
and
maybe
review
the
code.
The
the
most
important
thing
to
me
would
be
to
to
add
to
commit
this
code
emerge
it
into
repository
as
fast
as
possible,
because
it
seems
that
there
is
very
time
consuming
process.
C
Yeah
I
agree
with
what
it
is.
I
will
also
try
to
run
and
test
it
on
my
end
as
well.
Maybe
we
should
come
up
with
a
goal
of
like
once.
We
merge
it
like
what
we
do
next
or
like.
Maybe
that
way
we
can
actually
start
creating
issues
and
around
this
and
get
familiarized
with
that.
I
think
that
would
be
a
good
way
to
learn
more
about
this
course.
C
Maybe
like
I
think
even
even
you
were
having
some
thoughts
like
I,
want
to
instrument
certain
core
collector
code.
I,
don't
remember
you
said
something
about
that.
A
X66
so
I
think
it's
in
the
next
thing
that
I'm
working
on
but
yeah.
We
would
probably
request
before
I
will
finish
this.
This
effort,
yeah.
C
A
C
Okay,
that
makes
sense,
I
think,
like
I,
said
I
think
maybe
the
goal
should
be
merged
this
as
soon
as
we
can
maybe
let's
timebox
to
a
month,
maybe
I,
don't
know,
and
in
a
month
let's
target
to
merge
this
in
and
then
add
a
goal
of
like
instrumenting
databases
or,
like
you
know,
any
other
things
we
can
think
of
like
that
way,
we
actually
can,
like
other
people,
can
get
familiar
like
I
generally
familiar
Myself
by
working
on
certain
small
bug,
fixes
or
anything
like
that,
and
anything
that
can
come
up.
A
B
So
Eden
next
steps
for
you
are
you
going
to
take
this
PR,
updated,
obviously
like
you're
saying
but
then
move
this
down
to
a
single
Library
instrumentation.
A
Let
me
first
update
this
progress
and
fixed
attribution
and
I
will
try
to
split
it
into
a
few
to
a
few
different
parts,
but
I'm
not
really
sure
that
something
that's
going
to
really
help.
But,
like
maybe
let
me
first
pull
Upstream
into
this
pull
request
and
I
will
like
notify
and
slack,
and
then
we
can
like
maybe
do
it
offline
and
like
see
how
how
complicated
it
is
to
understand
and
like
maybe
I,
can
like
walk
you
through
the
code
in
a
meeting
or
something.
B
Yeah,
okay,
yeah
reviewers
also
need
to
be
defined
for
this.
C
B
B
One
of
the
questions
we
also
had
was
the
merge
speed.
We
wanted
to
try
to
accelerate
this
one
of
the
things
in
the
contributing
docs
for
the
other
projects
is
we
have
like
a
timeline
for
merging,
which
is
a
full
business
day?
B
Oh
man,
I,
don't
know
where
it
is
and
it
has
to
have
approvers
from
different
companies.
That's
also
something
that
is
I,
think
more
of
a
manual
understanding,
although
I
don't
think
that
there's
anybody
on
the
call
that
works
at
the
same
company
here,
so
maybe
this
isn't
as
critical.
B
This
is
usually
I
think
this
is
adopted
from
like
the
general
Hotel.
However,
this
one
working
day
thing
I
know
is
also
not
included
in
like
say
The
Collector.
They
can
move
things
a
lot
faster,
so
I
guess
the
question
is:
what
does
this
community
want
to
propose
here?
Do
we
want
to
include
this
change
as
being
slow?
Do
we
want
to
add
this
later
or
do
we
want
to
not
have
this
at
all.
A
B
Yeah,
okay,
I
heard
I
heard
conflicting
opinions.
There,
like
it'd,
be
good
to
go
slow
because
then
everyone
get
used
to
it,
but
also
you.
B
Okay,
I
I'm,
looking
at
this
I
can
take.
This
has
an
action
item.
B
This
I
will
take
as
an
accident,
but
I
will
probably
need
to
contact
the
TC
to
adjust
this
because
I
don't
know
if
I
have
permissions
this.
This
is
an
Eden
action.
Let's
go
like
that.
You
know
what
this
means,
though,
and
yes,
okay.
So
in
two
weeks
the
next
meeting
we'll
plan
to
have
a
little
walkthrough
of
this
PR
and
and
have
everybody
go
through
that
way.
Yeah.
B
B
Okay,
all
right
anything
else,
we
wanted
to
put
on
the
agenda
or
talk
about.
D
Maybe
maybe
one
last
comment
regarding
the
CPA
ebpf
instrumentation
correct
me
if
I
am
wrong,
but
I
believe
that
we
can
use
this
technique
for
instrument
any
native
program
on
Linux
at
least
not
only
go
programming
language,
but
also
programs
that
are
written
in
other
native
languages.
A
Yeah
yeah
you're
right.
It
should
work
for
him
just
like
roster
still
other
languages
like
I'm,
less
familiar
I'm,
not
like
a
rough
programmer
or
C,
plus
plus
programmer,
so
I'm
less
familiar
with
like
how
to
exactly
do
it,
but
I
think
it's
like
one
of
the
cool
things
here
is
that,
like
we
can
tie
another
way
to
like,
like
maybe
we
could
in
the
future,
do
like
the
growth
stuff
sort
of
like
generic
and
like
in
the
future,
use
the
same
infrastructure.
The
same
code
base
for
other
languages
as
well.
D
Yes,
because
I
was
thinking
about
extending
this,
you
know
to
to
do
other
languages.
C
No
I
think
that's
where
some
language
specific
is
coming
like.
If
you
have
to
instrument
like
a
grpc
from
rust,
you
can't
write
the
code
in
like
you
need
some
offsets,
and
all
of
that
you
can
do
it
theoretically,
but
I'm
not
sure
if
that
would
be
feasible.
Yes,.
C
The
technique
is
definitely
generic,
but
there
are
going
to
build
some
language,
specific
nuances.
D
C
B
Is
this
affect
our
decision
on
what
we
want
to
do
for
naming
of
this
project
at
this
point,
because
we
do
have
go
in
the
title
of
this
repo.
A
I
think
it's
like
pretty
long
term
to
apply
it
to
different
languages,
so
yeah.
B
Okay
yeah,
it
sounds
good
to
me
and
I
think
there
are
migration
options
in
the
future
for
the
repo
naming
and
since
we
have
a
valid
URL.
That
would
be
too
impacting
good,
though,
and
I
think
that's
a
great
question.
So
thanks
for
bringing
it
up,
okay,
anything
else.
B
Okay,
we
can
end
here
a
few
minutes
early
thanks.
Everyone
for
joining
I've
got
some
action
items
and
I
will
try
to
get
those
out
and
thank
everyone
else
as
well.
So
thanks
everyone
talk
to
you
in
two
weeks.