►
From YouTube: 2021-04-14 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
A
A
A
C
Okay
yeah,
so
I
wanted
to
start
with
with
this
one,
the
milestone:
it's
nice
we're
halfway
through
the
basic
support
it
took
us
about
two
months,
so
we
we
maintain
the
pace.
It
will
be
another
two
months
and
we
will
have,
I
would
say,
quite
quite
a
solid
implementation
of
implementation
of
logs
in
the
collector
we're
making
good
progress.
Everybody
that's
great,
so
this
one
then,
is
working
on
this
one
for
this
one
we
have.
C
C
D
Yeah
I'm
so
this
is
like
a
quite
large
pr,
so
I
think
that
it
would
be
best
if
patrick
would
join
us
and
maybe
discuss
it.
So
maybe
he
will
join
us
in
a
little
bit
and
we
could
go
back
to
that.
C
The
storage,
then,
are
you
making
progress
with
the
storage?
How
are
things
going.
B
Yeah
I
was
hoping
to
be
done
by
now,
but
it's
taking
me
a
little
longer
than
expected,
but
I
will
say
I
have
a
pr
out
there.
I
think
it's
worth
a
review
at
this
point.
There's
a
few
small
to
do's,
a
few
more
tests
to
add
and.
B
I
cannot
for
the
life
when
we
figure
out
what
what
the
lint
error
message
is
about
and
or
how
it
relates
to
any
changes
that
I've
made,
but
I
can't
reproduce
it
through
errors.
Yeah,
it
just
says:
there's
no
go
files
in
the
test
bed,
which
I
haven't
changed
anything
at
that
package.
So
I'm
not
sure
why
what's
going
on
there,
but
I
can't
reproduce
it
so.
But
let
me
try
to
rerun.
Maybe
it's
something.
B
We
don't
have
to
debug
it
now,
but
if
anyone
has
any
inside
it,
we
appreciated
him
a
little
stuck
on
it
but
minor
things,
though
I
think
it's
definitely
worth
the
review
at
this
point
see
if
the
implementation
is,
you
know
what
we
expected
and
any
major
feedback
items
I
can
start
working
on,
but
I
think
we're
probably
very
close
on
this.
C
C
E
Looking
into
this
at
all,
was
there
a
particular
thing,
or
I
spent
some
time
looking
into
this-
the
standard,
low
collection,
repo
and
I'm
I'm
in
the
progress.
But
I
am
not
sure
at
which
stage
which
step
it
it's
losing
data
or
yeah.
E
So
I
understand
the
logic
how
it
calls
every
some
time
and
it
copies
the
file
objects
and
then
read
it
to
really
till
end
and
maybe
reading
till
at
least
some
a
modification
that
what
I
am
my
thinking,
guy
yeah,
I'm
working
on
it,
but.
E
B
Observable
iq
help
agree
with
this
yeah
I
can
you
know
I
can
jump
on.
We
can
pair
on
this
or
you
know,
shoot
me
questions,
but
I'm
I'm
not
super
familiar
with
this
part
of
the
code
base
myself
and
I
think
the
person
who
wrote
it
has
left
so
our
company.
So
I
don't
know
that
he's
okay
yeah,
so
whoever
whoever.
A
B
This
will
have
to
really
dig
in
and
I'm
happy
to
help
do
that.
C
C
Okay,
I
guess
we're
good
with
the
current
ones
this
one
I
just
wanted
to-
let
you
know
as
justice
and
fyi
I
posted
this
schema
to
another
student's
proposal,
maybe
of
more
interest
to
christian.
I
guess,
chris,
you
had
your
proposal
earlier
related
to
this
one.
This
one
is
still
somewhat
different,
but
it's
related
to
the
one
that
you
did
a
few
months
back.
So
if
you're
interested,
please
review,
have
a
look
part
of
it
is
related
to
logs.
C
B
Haven't
yet
I
still
intend
to
do
this.
My
goal
is
going
to
be
to
put
together
basically
a
proposal
for
what
changes
would
make
sense
and
you
know
justify
all
of
them.
C
Okay,
cool
yeah,
I'm
done
with
my
questions,
so
I
don't
say
anything
else
here
in
the
document.
Anyone
has
anything
you
want
to
talk
so.
F
Yeah
hi,
it's
patrick
from
sumo.
I
just
missed
my
point,
which
is
the
second
one
there.
This
is
the
pr
for
the
ump
data
logs
translation,
yeah.
A
F
This
is
a
draft
that
got
deprecated
somewhat
by
the
already
merged
pr
and
I'm
willing
to
submit
a
you
know,
cleaned
up
version
of
this.
The
pldr
of
this
is
that
the
pr
that
got
merged
has
somewhat
of
an
unnecessarily
convoluted
logic
outside
and
I'm
not
really
sure
of
the
design
of
it.
I
have
the
design
of
the
worker
pool
ready.
The
downside
is
that
it
increases
a
cpu
consumption.
F
By
a
couple
of
percentage
points
I
can,
I
can
submit
a
pr
to
review,
and
then
we
can
decide
whether
we
want
to
actually
merge
it
in
order
to
discard
it.
C
C
G
I'm
just
saying
hi,
I
haven't
I've
had
a
conflicting
meeting.
Unfortunately,
so
I
haven't
been
able
to
attend
the
lodge
working
group
in
forever,
but
I'd
like
to
start
attending
again,
so
I
was
just
dropping
in
to
to
see
what
the
status
is
looks
like
things
are
really
chugging
along,
which
is
awesome,
yeah,
but
I'd
be
curious
to
know
around
like
the
sdk
and
api
front.
I
know
there
was
an
sdk
design
that
was
submitted,
but
I'm
just
curious
what
the
the
road
map
is
around
that
stuff.
C
G
Right,
so
this
is
just
work
to
make
the
collector
you
know
properly
translate
between
different
log
formats
essentially
and
do
log
processing
in
the
middle,
so
yeah.
C
Did
you
so
I
guess,
did
you
see
the
milestone?
I
was
just
sharing
the
screen,
or
did
you
use
that
I.
C
It's
it's.
I
guess
the
vast
majority
of
it
is
about
supporting
collecting
logs
from
different
sources
and,
like
I
don't
know,
we
have
this
kubernetes
done.
We
have
the
health
chart
now
which
is
locked
down
earlier.
It
was
the
generic
file
log
collection,
so
a
bunch
of
things
that
it's
all
related
to
collecting
things
and
parsing
and
stuff
is
already
working.
It
all
comes
from
stanza
right,
so
yeah
we
have
the
basic
processing
already
it
was
there
in
in
the
past,
with
the
attributes
and
stuff
we
have
the
processors
so
yeah.
C
That's
that's
all
we're
looking
at
the
moment
just
finalized
reading
from
the
the
most
common
sources.
So
we
look
journal
d,
it's
upcoming
and
then
we
want
to
also
have
the
otlp
json
format
formalized
and
read
from
that,
and
then
also
support
the
plugins.
C
What
stanza
calls
plugins,
which
is
support
for
predefined
formats
for
for
different
applications?
That
one
depends
on
another
work
that
is
currently
in
progress
in
the
collector,
which
is
what's
called
remote,
config
sources,
which
we
will
use
as
a
way
to
import
definitions
for
for
application
formats
for
for
parsing,
the
in
the
right
format.
H
So
by
building
an
appender
for
open
telemetry,
it
can
format
the
messages
accordingly
pass
it
on
through
oltp
and
that's
another
way
to
accomplish.
The
same
thing
is
to
build
appenders
in
the
other,
contribute
in
the
other
logging
libraries
that
everyone
already
uses
versus
building
our
own
sdks.
So
that
might
be
a
better
approach.
H
C
C
No,
the
sdk
is
to
help
build
the
appenders,
not
a
logging.
It's
not
a
full-blown
logging
library,
that's
not
the
intent,
but
how
you
build
the
appender
you
you
need
something
that
helps
and
makes
it
easy
to
beat
those
offenders.
That's
the
proposal.
If
you
look
in
the
to
the
the
op,
which
suggests
that's
exactly
what
it
says,
it's
an
appender
for
lot4j,
for
example,
and
other
scenario,
libraries,
but
how
you
build
it
is
using
the
open,
telemetry
logging
sdk
for
libraries.
H
C
A
You
know,
in
light
of
this
discussion,
I
actually
tripped
over
this
sdk
different
like
as
well,
so
then
I
looked
at
it
and
I
realized
what
what
what
we
were
after
there
was
what
you
described
from
a
sort
of
I
think
in
a
general
from
it
from
a
general
outcome
perspective.
A
This
is
a
good
thing
right
so
that
the
the
log
back
guy
doesn't
have
to
you
know
you
know
essentially
copy
and
paste
code
from
the
lock
for
jay
guy,
and
you
know
all
these
types
of
things
I'm
just
wondering,
since
we
are
sort
of
short
on
sort
of
bootstrapping
anyways
right
this
type
of
stuff.
You
know
one
other
way
to
look
at.
That
would
be
to
say:
hey,
let's
build
a
log
for
j
pender
and
then
extract
the
sdk.
Out
of
that,
I
was
just
wondering
how.
C
Much
you've
been
thinking
about
that
fine
yeah.
That's
I
mean
that's
so
the
idea
right
now
is
that
this
is
prototyping.
It's
not
like.
We
are
completely
sure
this
is
exactly
what
we
want
to
do.
So
what
you're
proposing
is
absolutely
fine
way
of
approaching
that
prototyping,
let's
just
build
it
and
then
we'll
see
what
is
the
right
portion
of
that
to
extract
as
an
sdk,
which
is
generic
and
what
is
just
the
appendage.
I
mean.
That's,
that's
completely
fine
yeah.
H
C
Right
right,
I
guess
one
of
the
reasons
we
call
this
a
prototype
is
to
make
it
less
scary
and
less
kind
of
we're
not
committing
to
actually
doing
this
in
the
sense
that
this
is
the
spec
we're
just
building
it
like
we
did
for
for
traces.
For
example,
we're
approaching
this
more
like
with
a
mindset
of
experimenting
it
a
bit.
I
think
that's
the
right
approach
and
what
you're
suggesting
fits
that
very
nice.
Let's
just
build.
H
C
Yeah,
that's
that's
a
fine
approach.
We
should
just
keep
in
mind.
What's
the
what's
the
final
goal
right,
it
shouldn't
be
just
kind
of
an
appender
from
which
it's
it's
not
going
to
be
possible
to
extract
the
portion
that
we
care
about
which
we
know,
but
the
the
design
is
there
right.
If
you
I
mean
it's
fairly
simple,
it's
nothing
complicated!
Really.
You
just
need
to
make
sure
that
the
boundaries
are
properly
delineated
right.
The
part
that
is
common,
the
part
that
is
specific
to
that
particular
library
and
should
be
good.
C
G
You
know
really
production
ready
and
then,
when
you're
talking
about
appenders
jonah,
it
seems
like
like
the
first
order,
is,
if
someone's
not
running
an
open,
telemetry,
sdk
they're
running
no
open
telemetry,
anything
in
their
application
right,
but
they've
already
got
log
infrastructure.
You
would
be
adding
that
appender
and
it
would
kind
of
work
on
its
own.
G
What
can
they
stop
running
in
parallel?
If
we
build,
you
know
an
sdk
that
can
take
data
in
from
that
those
appenders,
so
that
they've
just
got
one
stream
of
otlp
coming
out
the
door.
G
It
seems
like
that
order
of
doing
things
is
like
the
right
order.
As
far
as
like
getting
value
into
the
hands
of
of
end
users.
A
H
A
G
A
lot
of
sense
just
because
people
already
have
that
infrastructure
in
place
and
then
with
the
sdks
really
they
would
be
emitting
essentially
two
streams
of
otlp,
and
we
want
to
get
that
down
like
if
they
had
a
logging.
Appender
that
didn't
talk
to
the
sdk
they'd
have
like
two
parallel
strings
of
otlp,
one
with
traces
and
metrics
and
one
with
logs,
and
then
when
we
integrated
with
the
sdk
we'd,
move
down
to
just
one
stream
of
otlp
with
all
three
data
types
and
then
the
other
question
there
would
be
you
know,
is
there?
G
Are
there
advantages
at
the
sdk
level?
Having
like
one
sdk?
That's
aware
of
all
of
these
different
things,
you
already
have
some
of
that
by
being
able
to
just
act,
have
your
appender
access.
You
know
the
public
portion,
you
know
to
see
if
there's
like
a
span
there,
but
it's
that
that
would
just
be
the
like.
I
think,
investigation,
to
see
like
what,
if
you're,
actually
consuming
all
three
of
these
data
types
at
once.
What's
what's
advantageous
about
doing
that
in
a
client
versus
doing
that
in
the
collector.
C
Yeah,
I
think
that
that's
that's
a
completely
fine
approach.
I
think-
and
it's
I
completely
agree,
it's
less
scary
and
you
can
also
do
that,
probably
even
outside
open
telemetry,
on
your
own
repository
as
a
proof
of
concept
and
then
migrate
that
over
to
open
telemetry.
That's
that's
completely
fine.
If
anybody
wants
to
do
that,
I'm
I'll
be
happy
even
to
review
right,
even
if
it's
out
outside
open
telemetry.
That
would
be
great.
C
G
Awesome,
I
guess,
there's
also
going
the
other
direction,
which
I
think
is
just
maybe
another
form
of
appender,
which
is
like
appending,
trace
data
to
your
logs
right
like
there's
one
form
of
it,
which
is,
I
want
to
output
otlp.
So
I
want
something
that
takes
this
data
converts
into
otlp
and
attaches
trace
data.
If
it's
available,
I
guess
like
a
slightly
different
version.
G
C
Yes,
so
that
just
particular
limited
version
of
what
you
described
exists,
but
you
cannot
export
otlp,
it's
kind
of.
If
you,
if
you're
exporting
whatever
text
file,
you're
exporting,
then
you
can
just
say,
use
the
the
trace.
Ids
spanner
and
you
put
it
there
and
that
part
exists.
I
did
not
verify,
but
I
know
that
david
did
that
implementation.
It's
in
our
java,
auto
instrumentation.
I
think
library,
yeah.
G
The
marginal
add-on
is
we'll
just
add
this
data
to
what
other,
whatever
other
format
this
thing
produces.
But
I
guess
that
depends
on
the
pipeline
and
the
way
that
looks
for
these
different
logging
libraries,
but
anyways
anyways,
that's
awesome!
This
is
all
great.
I'm
glad
to
see
this
stuff
moving,
I'm
going
to
try
to
get
our
road
map
onto
our
website,
because
this
is
one
of
the
things
open.
Telemetry
is
not
doing
well
at.
G
This
point
is
like
making
our
roadmap
like
public
and
explainable
to
end
users,
and
so
I'll,
be
looking
for
feedback
like
from
this
group,
just
to
make
sure
I'm
representing
the
the
logging
roadmap
correctly.
Once
I
get
that
up
there.
C
Yeah,
I
feel
fairly
comfortable
publishing
the
the
collection,
the
collector
portion
of
that
we
we
see
clearly
that
we
are
making
progress.
It's
predictable
people
are
committed
so
that
I'm
confident
that
we
will
have
something
that
we
can
commit
to
something
and
have
something
in
the
collector.
With
the
logging
libraries,
it's
less
clear
right,
we
can
still
have
a
roadmap,
but
if
we
don't
put
dates
next
to
the
items
like
we
don't
really
know.
G
I
think
there's
there's
an
issue
with
the
logging
stuff.
We
also
like
just
setting
expectations
for
people,
because
the
approach
we're
taking
with
logging
is
a
little
bit
different
from
what
we
took
with
tracing
and
metrics,
which
makes
sense,
but
the
expectations.
When
I
talk
to
people
when
we
say
we're
doing
logging,
is
they
kind
of
they're
expecting
we're
going
to
build
a
logging
api
and
like
build
this
like
standalone
logging
system
and
we'll
eventually
get
to
that?