►
From YouTube: 2020-07-29 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
A
Sure
looks
like
he
grins
not
joining
okay.
So
oh
me.
A
A
A
Okay,
I'll
ping,
paulo
just
looks
like
he
was
looking
at
it.
C
B
A
F
F
A
Like
we
want
to
like
we
pass
through
the
headers
so
like
in
the
signalfx
receiver,
you
can
have
like
a
special
header
and
then
gets
passed
through
down
to
the
exporter.
F
Why
don't
we
just
pick
this
up
next
week
when
he
can
make
it.
F
A
Yeah,
okay,
let's
see,
has
only
james
reviewed
it
yeah,
okay,
okay,
so
I
may
I
mean
a
son
been
to
this
one
been
keith
because
he's
been
working
on
the
vlogging,
which
does
it
doesn't
exactly
fluent
bit
as
I
understand
it,
so
there
may
be
some
he
may
have
some
inside.
G
D
So,
basically,
that
pr
is
the
entire
feature,
but
I
was
told
to
break
it
into
two
parts
for
it
to
be
easier
to
review
and
merge.
So
it's
basically
one
and
I'm
leaving
it
there
for
reference.
If
anyone
needs
context
and
stuff
and
but
yeah,
both
parts
are
ready,
I'm
just
waiting
for
the
first
one
to
be
merged
to
to
make
the
second
pr.
For
the
second
part,
okay,.
A
A
Okay,
yeah
I'll,
take
a
quick
look
at
see.
If
I
think
there's
if
emails
needs
to
review
it
or
if
it's
ready
to
go
and
then
I'll,
if
it's
ready
to
go
I'll
ping,
apollo,
pollock
or
submit
another
maintainer
can
merge
it
so
I'll.
Take
a
quick
look
after
the
call.
H
G
C
I
actually
had
I
can
talk
through
it
a
little
bit.
We
were
going
to
do
it
in
the
next
meeting
for
the
vlog
specifically,
but
this
is
well.
It's
agent-based.
C
It's
better
yeah
I'd
hoped
to
I'll,
have
dan
join
next
week,
because
okay,
he's
he's
one
of
the
developers,
but
I'll
just
give
you
a
little
bit
of
an
update
and
then
sure,
maybe
we
can
talk
through
what
the
intent
would
be
and
I'll
post
some
docs
in
the
meeting
notes
in
just
a
few
minutes,
but
so
we
we've
just
recently
open
sourced
our
this
is
blue.
Medora,
slash,
observe
iq
our
log
agent
as
open
source.
C
It's
go
based.
We
did
a
little
demo
of
it
a
while
back
now,
but
now
it's
finally
available
performance.
I
think
you
know
I'll
share
some
of
the
docs
that
we
used
aws
amazon's
performance
test
suite
to
to
provide
some
baselines
against,
like
fluency
fluid
bit,
and
it
performs
very
well
so
I
think
that's
been.
C
You
know
that
was
kind
of
our
target
and
our
intent
in
the
next
you
know
couple
sprints
for
us
is
to
create
an
integration
with
open
telemetry
to
allow
it
to
be
a
you
know,
native
or
as
close
to
native
as
possible,
either
using
receiver,
and
I
know
we've
talked
morgan
with
you
a
bit
about
what
that
would
be,
whether
it's
receiver
or
another
type
of
integration
to
pull
that
in.
So
that
was
an
area
we
were
looking
for
some
feedback
on
probably
the
best
integration
method,
and
so
I
I
that's.
C
That's
probably
my
biggest
question.
You
know
we
can
import
this
as
a
go
library,
but
I
don't
know
whether
that's
really
a
reasonable
option
or
if
there's
a
preferred
method,
whether
it's
grpc
and
that's
a
that's
an
available
option
as
well.
Do
we
have
sort
of
an
idea
of
what
what
the
preferred
method
is.
F
Before
we
get
to
that,
do
you
want
to
talk
about
the
goals
that
you're
trying
to
achieve
with
this
with
the
group.
C
Yeah
sure
so
so
really
our
intent
is
to
provide
a
you
know,
log
agent,
that
is
ultimately
a
replacement
for
fluency
or
like
log
stash,
that
is
higher
performance
significantly
higher
performance
go
base,
but
then
maintains
the
level
of
configurability
that
those
have
so
think
that's
kind
of
an
area
where
I've
seen
some
of
the
higher
performance
agents.
Maybe
they
don't
have
quite
that
same
level
of
like
an
easy
to
put
together
pipeline.
C
So
that's
that's
kind
of
our
initial
goals,
because
we've
kind
of
have
a
background
of
building
these
integrations
we're
we're
we
have
roughly
50
or
so
integrations
that'll,
be
ready
to
go
so
as
plugins
that
you
can
just
drop
in
and
use
for
things
like
you
know
if
it's
nginx
or
tomcat
or
whatever
you
may
be
looking
for
so
so
we've
you
know
sourced
this.
Our
goal
is
to
you
know.
C
This
just
seems
like
a
good
potential
opportunity
to
to
use
this
and
get
this
into
the
hands
of
some
customers,
but
is
that
kind
of
what
you
look
for
morgan
or
kind
of
your
thoughts
on
the
goal
of
the
project?
Yeah.
F
C
Yeah,
exactly
and
I'll
show
the
doc
to
to
show
kind
of
where
it
shines
in
terms
of
performance
and
and
then
we're
happy
to
show
kind
of.
We
wanted
to
take
a
pass
and
just
just
integrate
together
and
then
come
back
and
show
what
we
have
to
the
group
and
maybe
get
some
feedback
on
that.
So.
E
C
C
I
can
speak
for
us
yeah
I
mean
I.
I
don't
think
that
I
don't
think
we're
necessarily
opposed
to
the
idea.
I
think
you
know,
but
I
do
think
that
certainly
the
folks
on
this
team
would
want
to
an
open
telemetry
project
would
want
to
see
what
we're
doing
make
sure
that
it
meets
their
guidelines,
approve
you
know,
so
so
I
think
for
us.
C
It's
just
been
a
building
this,
because
we
we
believe
this
is
the
right
approach,
but
you
know
in
a
lot
of
ways
we're
trying
to
follow
some
of
the
guidelines
that
open
telemetry
has
has
already
produced
so
mark.
I'd
say
that
we're
not
we're
not
opposed
to
that,
but
we're,
I
think,
we're
just
trying
to
take
small
steps
and
make
sure
everyone's
bought
in
before.
We
would
suggest
something
like
that.
F
Yeah,
it's
worth
it
worth
discussing
next
week
when
you
have
the
full
presentation,
I
also
plus
30
grand
to
make
sure
that
he
joins
okay.
There's
advantages,
I
mean
the
disadvantage
is
we've
already.
You
know
like.
I
think
several
people
have
already
invested
a
lot
in
in
the
fluent
bit
work,
but
at
the
same
time
this
is
natively
written,
go.
F
There's
you
know
it's
a
lot
sort
of
probably
easier
to
integrate
with
there's
a
single
package,
I'm
curious
and
we'll
go
into
this
next
week.
We
don't
need
to
talk
about
it
too.
Much
here,
like
obviously
fluent
bit,
has
a
lot
of
investment
in
all
the
plugins
for
it
and
its
ability
to
receive
logs
from
different
sources
and
reformat
them,
and
your
agent
is
relatively
new.
F
So
I,
I
suspect,
there's
a
bit
of
a
disparity
there
in
terms
of
capabilities,
but
we
can
go
over
that
next
week
and
have
that
conversation
great,
give
give
it,
but
I
agree
mark
with
with
your
assertion
it
would.
You
know
it
seems
like
a
great
opportunity-
and
I
think
would
be
a
lot
of
benefits
to
doing
that.
E
E
F
Mark
did
you
get
because
I
don't
know
if
you
attended
the
meeting
a
few
weeks
ago,
like
so
the
there's
already
a
version
now
of
open
telemetry,
the
collector
running
with
fluent
bit
attached
to
it
and
processing
logs.
I
can
plus
you
into
some
of
the
comments
from
that
meeting,
so
you
can
find
out
more.
E
Yeah
wesley
told
me
about
it-
I
just
I
just
I'm
struggling
like
it-
has
limited
value,
but
not
as
much
value
as
if
it
would
be
a
native
part
of
the
collector.
Really.
The
piece
that
I'm
looking
for
is
both
the
schema
definition
and
the
correlation
context,
like
the
kilo
things
that
all
customers
say
is.
Can
I
do
correlation
from
logs
to
traces
to
metrics
and
vice
versa?
F
I
mean
the
correlation
will
also
rely
on
the
sdks.
Unfortunately,
and
so
there
was
a
presentation
as
well
a
few
weeks
ago,
of
the
first
rev
of
the
java
sdk.
That
will
do
that.
You
know
this
was
like
a
sort
of
alpha
quality
sort
of
very
basic
test,
but
I
don't
think
you
I've
never
seen
a
solution
where
you
can
do
correlation
of
traces
and
logs
purely
with
like
a
simple
logging
agent.
Usually
you
need
an
sdk
attached
to
the
application
or
the
automatic
instrumentation
that
we
offer.
G
Sorry
I
was
away
for
a
second
mike
joe
lynch
here.
Do
you
could
you
pass
a
link
to
where
the
the
the
project
is
in
github
or
wherever,
wherever
your
documentation
might
live.
C
Yeah
I'll
paste
it
right
into
the
agenda
here.
G
A
Cool
a
couple
kind
of
process
updates,
so
we're
still
working
to
get
down
kind
of
a
better
way
to
get
things
triaged
and
make
things
make
sure
things
get
reviewed.
So
you
know,
ideally
people
won't
have
to
you
know,
come
into
the
meeting
and
have
to
ping
people.
You
know
wait
until
until
the
meeting
right
to
ping
people
make,
you
know,
make
sure
people
look
at
stuff,
so
that's
still
yeah.
Ideally
we
but
yeah
we
might
have
to
kind
of
like
yeah.
A
I
feel
like
people
are
kind
of
pushing
uphill
still
to
to
get
stuff
reviewed.
So
I
guess
I'll
just
note
that
it's
still
a
work
in
progress.
I
think
one
thing
we'll
probably
start
doing.
We
won't
do
it
this
week,
but
maybe
next
week
we'll
start
looking
at
like
new
issues
that
have
been
filed
since
the
last
meeting
to
make
sure
that
those
are
getting.
A
You
know
triaged
as
they
come
in.
We
have
a
backlog
to
work
through
right
now.
So
I
don't
think
there's
too
many
to
like
work
through
and
in
this
call,
but
I
think
ideally
going
forward
we'll
take
a
look
at
the
issues
and
make
sure
there's
a
good
kind
of
you
know,
look
over
once
a
week
and
yeah
so
so
yeah.
So
just
some,
I
yeah
some
continuous
process.
Improvements
will
happen
in
the
next
few
weeks.
E
I
have
a
question
on
that
and
again
might
be
my
subjective
opinion.
It
just
feels
to
me
from
the
feedback
I'm
getting
that
the
project
is
growing
and
we
don't
necessarily
have
the
right
amount
of
reporters
and
maintainers
to
be
able
to
handle
all
the
stuff
that
is
coming
in,
especially
given
the
large
number
of
interns
from
both
google
and
amazon.
F
E
A
Yeah
so
yeah
one
thing
we're
we're
talking
about,
and
maybe
we
can
once
yeah.
We
have
some
better
ideas
around
this,
but
just
some
things
like
we're
considering
are
like,
should
you
know
vendors
be
coded
owners
code
owners
in
their?
You
know
for
aws
exporters.
You
know
it
still
require.
A
You
know,
like
probably
some
other
approver
to
approve,
but
you
know
maintain
her
to
merge,
but
it
would
at
least
like
you
know,
give
a
little
bit
more
yeah
allow
vendors
to
know
like
have.
They
have
domain
expertise
and
there
are
certain
areas
to
build
make
sure
they
approve
changes
to.
H
Yeah,
just
to
add
on
on
top
of
what
jay
saying
I
was
already
planning
today
to
start
with
update
the
code
owners
with
putting
kind
of
specific
receivers
and
exporters
to
certain
owners,
and
we
maintainers
keep
doing
the
merchant
checking
the
overall.
But
the
review
itself
kind
of
have
a
specific
set
of
persons
that
know
the
internals
and
specifics
of
each
export
and
receiver.
A
Okay
sounds
great,
thank
you
yeah,
so
I
think
yeah.
I
think,
that'll
help
some.
I
think
we
also,
I
mean
just
making
sure
that
there's,
I
think,
there's
also
just
improv
like
giving
stuff
triage.
It's
not
just
getting
stuff
getting
people
to
a
privilege
to
like
review,
stuff
and
and
and
people
to
merge
it.
It's
just
making
things
get
routed
appropriately
and
that
people
know
that
there's
there's
something
that
something's
blocked
right,
that
they
need.
They
need
action.
A
So
I
think
it's
not
just
having
enough
approvers
and
maintainers
it's
just
getting
stuff
routed
appropriately
and
making
sure
people
know
that
you
know
they
have
stuff
to
do
so.
I
think
that.
E
A
Out
loud,
so
we
there's,
we
have
the
project
board.
A
So
in
theory
the
maintainers
can
look
at
this
column
the
reviewer
approved
and
see
that
you
know
their
stuff
has
been
improved
and
in
theory
ready
for
merge.
I
don't
know,
maybe
this
doesn't
mean
ready
for
merge,
but
it's
pretty.
A
Basically,
if
you
search
about
like
your
own
assignee,
then
you'll
see
that
there's
like
I
guess
I
don't
have
any
pr's
assigned
to
me
right
now,
but
you
see
pr
is
assigned
to
yourself
here.
So
in
theory,
if
a
pr
is
assigned
to
you,
then
it's
waiting
on
some
action
from
you.
A
Yeah
yeah,
so
I
think
yeah.
If
we
have
to
have
my
uniform,
I
have
to
have
some
yeah
some
way
to
like
yeah
ping
people
as
well,
but
so
right
now
you
can
at
least
in
theory
search
for
what's
assigned
to
you,
but
this
is
kind
of
the
problem.
What
kind
of
like
what
I
mean
in
terms
of
stuff
being
routed
like
there's.
A
F
A
Yeah
yeah,
so
yeah,
so
yeah
still
broken
progress
and
definitely
yeah.
I
mean
yeah.
If
people
have
any
ideas,
any
other
ideas
of
stuff
to
do
definitely
open
to
improvements.
A
A
So
basically,
if
an
issue
isn't
assigned
to
a
milestone,
then
it
means
untriaged.
So
currently
we
have
like
86,
86
and
core
and
35
in
contrib
that
aren't
triaged.
Maybe
they
were
kind
of
in
the
past,
but
and
yeah
they're,
not
a
assigned
milestone.
So
this
will
work
on
yeah
get
yeah,
maybe
recruit
some
people
to
help
triage
all
these
get
through
the
backlog
and
then
next
week,
ideally
or
whenever
we
get
to
the
backlog,
we
can
start
looking
at
them
weekly.
A
There
won't
be
there
shouldn't
be
as
many
but
yeah.
So
ideally,
these
will
cause
somebody.
Somebody,
like
somebody,
brought
up
asking
about
milestones.
I
think
it
was
yeah.
I
think
it
was
the
guy
that
was
asking
about
oauth
but
yeah.
We
currently
don't
have
milestones
to
find
beyond
ga,
so
for
now,
stuff
will
probably
just
go
into
either
ga
or
or
backlog,
meaning
postga.
A
So
hopefully,
we'll
know
more
next
week
about
this
will
be
it's
yeah.
It
may
not
all
be
done
next
week,
but
yeah
we're
trying
to
make
a
dent
in
it
at
least.
F
A
F
A
I
think
I
think
we
probably
need
tigran
bogdan,
maybe
steve-
for
that.
Actually,
okay
yeah
to
take.
F
A
Okay,
okay,
yeah,
so
I
think
so
it's
not
just.
We
can't
just
assign
it
to
the
milestone.
It
has
to
be
tagged
as
well.
F
Correct
and
the
the
reason
is
because
some
sigs
have
their
own
milestones
and
you
can't
double,
assign
things
to
milestones
in
github,
so
we're
using
that
tag
and
then
we're
generating
those
github
projects
for
each
sig.
So,
for
example,
there's
a
github
project
for
that's
org
wide
for
the
specs
issues,
and
so
the
specs
issues
are
all
organized.
We've
got
we've
tagged
and
prioritized
everything
that's
required
for
ga
and
then
it's
on
a
kanban
board
that
people
are
working
through
and
we'll
just
want
to
do
the
same
for
the
collector.
E
So
I
I
like,
I
don't
know
my
understanding
of
the
scope
of
open
dynamite.
Maybe
it's
the
wrong
understanding
is
that
we
want
to
claim
promiscuous
support
in
the
collector
correct.
It's
that
yes,
true,
then,
in
my
mind,
maturing
the
exporter
for
the
prometus
exporter
for
cortex
and
the
kubernetes
discovery
pieces
are
probably
should
be
ga
bunkers.
F
F
Metadata,
that's
real
bad.
I
thought
we
already
were,
though,
but
mark
I'm
guessing.
You
have
more
information
than
I
do
given
that
you
brought
it
up.
E
So
I
specifically
point
morgan
to
the
discovery
of
which
and
which
for
british
endpoints,
to
scrape
so
it's
like
discover
the
nodes
and
then
add
the
collection
rules
for
the
receivers
to
go
scrap,
and
I
do
not
believe
that
that
is
done.
I
know
for
a
few
people
at
amazon
working
on
it
with
some
other
people,
which
I
don't
know
their
names.
Okay,.
F
A
Free
we.
F
D
F
So,
okay,
I
know
they're
overhauling
how
a
lot
of
the
prometheus
stuff
works
right
now,
just
from
seeing
the
prs
go
through.
So
maybe
once
that's
done,
we
we
just
take
a
look
at
the
size,
see
if
there's
anything
that
can
be
easily
optimized.
E
The
other
question
that
I
had
morgan
on
gi
blockers
is,
if
you
still
attend,
because
I
didn't
attend
the
last
two,
the
matrix
things.
Yes,
there's
the
ongoing
discussion
about
the
viewer
api
yeah
and
I
told
that
the
view
api
is
a
ga
blocker,
and
I
don't
know
that
the
implementation
of
the
view
api
and
the
collector
is.
F
Done
but
maybe
I
haven't
been,
you
are
correct
on
both
of
those.
That's
why
I
was
saying
for
tracing,
I
think
we're
pretty
much
there,
but
for
metrics
there's
still
work
to
be
done
now.
I
know
they
made
some
progress.
This
week
they
had
a
couple
one-off
meetings
to
talk
about
the
views,
api
and
otlp.
F
So
I
expect
that
by
tomorrow's
meeting
more
a
lot
more
progress
will
be
will
have
been
made
on
the
spec,
but
I
won't
know
until
tomorrow,
just
because
I
had
conflicts
with
the
the
the
technical
discussions
this
week
and
couldn't
join.
E
F
F
Have
to
add,
there's
a
blog
post
going
out
like
in
probably
tomorrow,
but
they
just
have
to
add
release
colon
required
dash.
Forward-Ga
lolita
knows
how
it
all
works,
because
she's
been
at
the
maintainers
meeting.
So
if
you
ask
her,
she's
got
all
the
details.
F
If
they
add
that
it'll
show
up
on
all
the
ga
roll
up,
dashboards
and.
F
F
Unless
jay
you
happen
to
know,
I
can't
remember.