►
From YouTube: 2021-06-10 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
Hey
it's
going
pretty
well
over
yourself.
B
A
Yeah
yeah
yeah,
I'm
hey
robert
robert's
over
there
at
I
don't
know,
was
it
10
o'clock
for
you
something
like
that
right
now,.
C
A
10
o'clock
exactly
yeah
yeah,
I'm
I'm
at
a
comfortable
1pm.
So
it's
so
great.
B
A
That's
a
good
question.
It
hasn't
been
that
way
for
a
while
there's
some
some
months.
I
I
kind
of
grow
a
really
small
version
of
my
back,
but
no
it's
it's
been.
A
As
I
used
to
say,
the
easiest
way
to
do
it
is
just
you
don't
shave,
but
it
yeah.
I
know
what
you
mean
it
is
it
like.
It
becomes
extremely
frustrating
at
times
and
you
just
play
with
it
endlessly,
eventually
so
yeah
it's
it's.
D
A
Well,
cool,
I
think
some
people
are
still
filtering
in
for
those
of
you
who
are
joining.
Please
add
yourself
to
the
attendees
list
and
we
can
wait
for
some
quorum
and
we
can
probably
get
started.
I
see
there's
also
some
people
that
have
added
some
stuff
to
the
agenda.
If
you
have
anything
you
want
to
talk
to
or
talk
about,
please
add
it
there
and
yeah,
we'll
probably
give
it
another
minute
or.
A
A
A
A
A
Please
be
sure
to
do
so
if
you
haven't
yet
and
anything
you
wanted
to
talk
about
in
the
agenda
we'll
get
to
that,
but
to
start
us
off
I'd
love
to
get
a
little
bit
of
a
recap
what's
going
on
in
our
project
board,
and
by
that
I
mean
a
lot
and
a
little
at
the
same
time,
we're
at
308
issues
done
at
this
point,
with
only
three
remaining
open
issues
that
have
been
currently
identified
before
we
can
get
a
release
out
for
our
rc.
So
there's
some
really
great
progress.
A
We
have
zero
to
do's,
which
is
just,
I
think,
the
first
time
we've
had
that
and
so
yeah.
It's
we're
getting
really
close.
So
definitely
some
really
positive
for
momentum
and
progress
over
the
past
week,
thanks
to
everyone
on
the
call
or
not
on
the
call
watching
this.
Virtually
that
has
contributed,
there's
been
just
like
a
lot
of
positive
effort
here,
so
I
really
want
to
thank
you
all
and
appreciate
it
definitely
a
positive
direction.
A
That
being
said,
maybe
we
could
jump
into
the
three
remaining
issues
you
stopped
by
myself
have
them
assigned
to
us,
and
we
would
talk
a
little
bit
about
that
progress,
we're
you
know
pursuing
in
in
the
trying
to
close
these,
because
I
can
go
forward
first,
if
you
don't
want
to
jump
in,
but
otherwise
we
could
probably
just
start
and
talk
about
the
otp
refactor
yeah.
E
Sure
the
trace
part
got
measured,
both
the
jrpc
and
http,
and
I
have
been
kind
of
slow
this
week.
But
I
just
like
my
open
apr
that
I
need
to
update
with
recent
changes
and
I
see
that
you
have
removed
some
convenience
functions
that
we
had
that.
That's
something
that
I
need
to
update
on
my
jar.
E
But
I
expect
that
to
be
done
by
today,
but
I
think
that's
that
doesn't
block
our
rc,
because
that's
metric
only.
I
guess.
A
Okay,
that
sounds
good.
Okay,
this
pr
right
here;
okay,.
A
E
A
A
That
being
said,
gustavo
kind
of
pointed
out
there's
a
pr
this
past
week.
That
was
closed.
That
was
removing.
E
A
It
removes
the
install
new
pipeline
and
the
new
export
pipeline
functions
from
all
of
the
exporters.
It
also
renames
new
export.
It's
just
new
and
new
unstarted
exported
to
just
you
started,
and
this
was
in
response
to
something
that
was
really
raised
in
slack
just
kind
of
saying
this,
just
to
make
everyone
kind
of
aware
of
what
was
going
on
here.
These
functions
were
originally
included.
A
Just
to
that,
like
it's,
it's
very
verbose
to
set
things
up
with
just
the
the
new
function
you
have
to
set
up
a
tracer
provider
or
a
controller
like
all
these
different
things
on
top
of
the
exporter
as
well,
so
they
were
intended
to
be
like
these
convenience
functions
that
did
things
and
did
things
in
a
production
ready,
first
class
best
practices
are
enabled
way.
A
The
problem
is,
is
that,
as
this
thing
has
progressed,
one
of
the
major
things
that
like
happened
is
a
lot
of
the
identifying
factors,
got
unified
into
resources,
and
these
functions
don't
particularly
handle
those
really
well
currently
or
other
ways
to
attribute
things
as
attributes.
A
So,
instead
of
trying
to
retrofit
them,
which
they
already
were
very
like
verbose,
like
some
of
them,
took
configs
for
that
exporter,
plus
configs
for
the
controller
plus
configs
for
the
tracer
provider
and
then
tried
to
merge
those
all
together,
and
so
you
had
like
these
really
clunky
looking
interfaces
that
were
not
necessarily
uniform,
but
they
were
the
functions
themselves
were
present
each
one.
The
idea
here
was
to
just
there
was
a
few
proposed
solutions
and
it
was
kind
of
agreed
upon
that.
A
We
wanted
to
just
take
these
out
right
now,
not
necessarily
with
the
end
purpose
of
never
returning
them,
but
just
take
them
out
and
get
user
feedback
like.
Let's,
let's
release
this
with
the
minimal
set
that
users
can
start
to
use
and
when
users
come
back
and
say
like
yes,
there's
definitely
a
need,
because
this
is
like
a
little
too
rose,
but
here's
the
function,
signature
that
would
work
for
us
and
here's
the
function
work
for
us.
We
can
make
sure
that
we're
implementing
the
best
practices.
A
I
think
we
can
add
them
back
at
that
point,
but
currently
we
want
to
like
release
them
without
them,
so
they
were
removed
at
this
point.
So
just
a
heads
up,
especially
for
people
who
are
rolling
with
updates
the
next
time
that
you
go
to
try
to
do
another
sdk
setup.
It's
going
to
be
a
little
bit
more
complex
because
you
have
to
set
up
the
tracer
provider
and
register
it
or
set
up
the
message,
controller
and
register
it
as
well.
So
just
a
heads
up
there.
A
But
that
being
said
back
to
the
grpc
exporter,
for
the
oclp
like
this,
I
think
is
I'm
guessing
it's
not
nearly
as
important
as
as
guess.
I've
just
put
it
out,
because
it's
not
something
that
is
going
to
be
critical
to
getting
the
stable
release
out
in
the
fact
that,
like
this,
doesn't
have
to
be
there.
A
But
one
thing
that
it
does
do
is
it
does
move
portions
of
the
code
into
a
forward
facing
otlp
exporter
for
the
metrics
export,
I
think,
is
the
important
thing
here,
which
kind
of
brings
up
a
little
bit
of
an
issue
that
I
wanted
to
talk
about.
Later
on
in
the
agenda,
there's
a
new
pr,
I
think,
trying
to
get
this
export
ready
for
the
release,
but
maybe
we
can
kind
of
talk
about
that
in
a
second
after
we
get
through
the
rest
of
the
issues
here.
Gustav
is.
A
You
wanted
to
add
about
like
the
needed
tasks
before
we
can
probably
call
these
issues
done.
E
The
the
trace
one
doesn't
have
the
json
format
already,
but
the
old
hotel
px
party
still
has
this
option.
C
Okay,
yeah.
A
Okay,
so
I
guess
that
was
kind
of
maybe
we
can
just
jump
into
this
now,
because
it
kind
of
seems
tremendous
conversation
this
for
those
who
haven't
seen
this,
it
was
just
posted
just
an
hour
ago.
It's
the
idea
is,
I
think,
we're
correct
from
wrong
anthony
we're
getting
rid
of
the
entirety.
C
Exporter
package,
or
is
just
the
portions
of
the
tracing,
just
the
portions
that
supported
tracing
so
the
the
the
otopia
exporter
can
still
be
set
up
to
provide
metrics.
It
still
has
all
of
the
infrastructure,
like
the
split
driver
and
those
sorts
of
things
that
were
used
to
support
traces
of
metrics
separately.
I've
just
removed
any
reference
to
traces
from
that,
so
that
it
will
no
longer
be
used
for
exporting
traces,
and
we
have
a
clear
push
for
people
who
want
to
export
traces.
Go
use.
The
new
hotel
trace
exporter.
A
So
one
of
the
questions
I
have
is:
is
it
not
a
requirement
from
the
specification
that
we
sh
need
to
be
able
to
support
the
otlp
configurability
of
traces
and
metrics
as
environment
variables
like
we
need
a
unified
way
to?
Actually
we
need
a
unified
otlp
exporter.
C
F
C
Yeah,
that's
that's
going
to
be
a
really
difficult
thing
for
us
to
support
and
I
think
there's
already
I'm
hearing
from
some
groups
that
are
trying
to
implement
this,
that
the
the
increase
in
size
from
including
exporters
is
noticeable
and
unfortunate.
So
we
probably
don't
want
to
do
that
as
a
general
thing,
perhaps
as
some
sort
of
convenience
api
where
we
say
if
you
know
what
you're
doing-
and
you
really
want
to
pull
in
all
of
this
into
your
binary
and
give
users
as
much
flexibility
as
possible.
C
A
Okay
yeah,
I
I
somehow
thought
this
was
like
a
big
issue
because
we
originally
had
like
in
a
way
where,
if
you
wanted
to
specify
a
metrics
endpoint
different
than
you
wanted
to
specify
a
trace
endpoint,
you
could
just
run
essentially
two
of
these
exporters,
but
it
didn't
fit
the
specification
and
that's
why
we
had
to
build
this
whole
driver
setup.
I
thought,
and
so
I'm
a
little
hesitant
about
like.
A
A
Right
right,
okay,
this
might
be
what
I'm
looking
for.
A
Yeah,
okay,
all
right,
I
think
I
need
to
maybe
review
some
of
this
specification.
I
I
also
wonder
if
one
of
the
specifications
just
poorly
written
because
of
what
you're
exactly
saying
like
if
you're
requiring
environment
variables
to
specify
like
you,
know,
export
types
or
something
like
that
for
something
that's
not
stable,
then
that
may
not
be
a
well-defined
specification.
A
I
will
need
to,
I
think,
take
a
little
closer
look
to
this,
but,
okay,
we
can.
E
Java
has
different
mod
project
portraits
and
metrics
as
well.
A
For
the
otp
exporter
as
well,
yeah,
okay,
that
is
helpful.
I
would
be
very
surprised
if
bob
didn't
let
that
go
if
it
wasn't
a
part
of
the
specifications.
So
that's
that's.
C
Yeah
and
in
terms
of
the
environment
variables,
you
know
we
can
still
have
two
separate
packages
and
have
both
of
them
look
at
the
same
environment
variables
right.
One,
we'll
look
at
otlp
exporter,
otlp,
endpoint
and
export
otobrace
endpoint
and
the
other
we'll
look
at
ltlp,
endpoint
and
otlp
metrics
endpoint.
A
Yeah,
I
think
it's
just
the
one
that
like
aaron,
was
pointing
out
that
like,
if
you
need
to
specify
like
which
yeah,
maybe
I
can
see
if
we
can
find
it.
D
A
Oh,
thank
you
yeah.
This
is,
I
think,
what
I
was
looking
at
yeah,
and
this
is
the
thing
that
was
postponed,
is
what
you're
talking
about
right.
Okay,
yeah,
okay-
and
I
think
this
is
if
this
is
what
I
was
remembering,
yes,
which
I
was
better
at
remembering
because
this
is
exactly,
I
think,
what
all
the
contention
was
over
and
it
was
split
out
just
exactly
what
we're
saying.
I
think
at
this
point.
Okay,
that
makes
more
sense
thanks
for
the
link.
A
On
unless
customer
anthony
wanted
to
touch
base
on
a
little
more
of.
A
This
I
can't
see
faces,
but
I'm
just
going
to
assume
silences
compliance
cool
last
thing
in
the
in
progress
is
this
development
implemented
plans?
I
started
to
do
a
little
bit
of
an
inventory
of
all
the
exported
interfaces
that
we
have.
The
takeaway
that
I
guess
has
just
been
discussed
in
the
past.
A
Is
that
there's
two
approaches
here:
adding
a
private
method
to
interfaces
and
then
potentially
for
exporting
a
no-op
implementation
and
there's
some
pretty
good
reasons
to
not
do
that,
which
I
think
grpc
kind
of
gives
us
a
little
bit
of
a
way
for
it.
So
we
want
to
make
sure
that
we
document
our
plan
to
extend
interfaces
and
make
sure
that
we
understand
which
interfaces
potentially
could
be
extended
and
understand
that
is
in
place,
and
you
know
developers
in
the
future
understand
this
as
they
go
forward.
So
that's
my
task.
A
The
goal
here
first
is
to
get
an
inventory,
so
I'm
working
on
that
currently
and
then
there
should
be
a
pr,
and
I
think
that
should
be
it
for
all
of
the
open
issues
in
our
rc.
So
I
think
with
that.
It
really
is
just
this
grpc
refactor
is
the
thing
that's
going
to
be
defining
the
the
blocking
issues.
A
Here
are
the
steps
that
are
remaining
in
this,
I'm
wondering
which
one
of
these
are
going
to
be
required
so
that
we
can
actually
do
the
rc
and
which
ones
are
it's
things
we
could
do
separate
to
the
rc.
E
I
think
that
anthony
pr
is
about
to
remove
the
trace
from
the
old
otlp.
Exporter
crosses
the
the
last.
E
C
C
That
it
that
includes
the
otlp
metrics
exporter
for
completeness,
so
I
don't
know
what
we
want
to
do
about
that.
Do
we
do
we
want
to
ensure
that
we
rip
metrics
entirely
out
of
all
of
the
examples
that
would
be
marked
1.0,
in
which
case
we
should
create
some
separate
examples
for
metrics
and
leave
them
at
point
21
when
we
make
the
the
rc
you
also.
C
I
was
expecting
that
that
package
wouldn't
or
that
module
would
not
be
included
in
the
1.0
rc.
It
would
go
to
0.21
when
we
make
the
the
1.0
rc
release.
F
C
E
Yeah
I
see
I,
I
think
that
the
hotel
px
party
will
only
exist
until
while
we
do
the
rc,
I
don't
see
how
they
they
try
and
work
on
will
take
longer
than
the
1.0
release
so
at
when
we
actually
do
the
1.2
release
that
the
otp
will
not
exist
anymore.
Just
for
the
rc,
I
guess.
C
C
Perhaps
we
get
to
rc2
and
we've
merged
the
otlp
metrics
exporter,
at
which
point
we
could
remove
the
otlp
exporter
that
has
currently
handling
metrics
direct
users
to
that
one,
and
then
we
would
have
a
trace
exporter
that
is
1.0
or
rc2
and
we
would
have
a
metrics
exporter.
That's
v
22
and
no
exporters,
otlp.
A
C
B
A
C
That
is
also
an
option.
I
was
trying
to
be
prepared
for
a
world
where
that
pr
was
not
ready
soon,
but
it
looks
like
that's
not
going
to
be
the
case,
so
that's
also
an
option.
Yes,
okay,.
A
Yeah
I
mean-
I
think
that
seems
I
feel
like
to
be
honest.
I
feel
like
the
reviews
for
getting
the
otlp
metric
stuff
up
and
running
is,
can
be
fast
and
loose
because
it's
something
that
is
almost
certainly
going
to
change.
I
think.
Well,
I
guess
the
transforms
are
already
like
kind
of
proven
and
if
we're
copying
the
transforms,
then
it's
just
that
api
and
that
api
might
change
so
yeah.
A
I
think
it's
super
critical
to
have
everything
like
perfect
in
the
metric
side
of
things,
especially
as
you're
saying,
I
guess
the
experimental
thing.
So
maybe
we
could
try
to
get
that
going
a
little
faster,
but.
C
Yeah,
to
the
extent
that
it's
going
to
be
largely
a
forklift
of
what
already
exists
for
metrics,
at
least
that's
my
expectation,
and
we
know
the
api
is
up
for
change
anyways.
I
would
be
fine,
just
dropping
it
in
with
a
cursory
review
of
yes,
this
looks
sane.
This
is,
you
know,
gustavus,
not
being
evil
and
adding
bitcoin
mining
into
into
people's
exporters,
or
something
like
that
right
and
then
we
go
from
there.
F
Yeah,
okay,
I
would
prefer
that
I
would
rather
have
no
g,
no
weird
wonky
modules
and
no
no
http
over
having
like
unstable,
with
stable
elements
inside
of
it
that
are
going
to
be
removed.
C
How
do
we
want
to
sequence?
This
would
should
I
update
my
pr
to
completely
remove
the
otlp
module
and
its
exporters
and
then
depend
on
gusava's
landing
to
provide
the
metrics
exporter,
or
would
we
want
to
combine
them.
F
I
think
I
think
they're,
independent
and
yeah
if
you
were
to
just
remove
the
rest
of
the
grpc
or
the
metrics,
and
we
can
move
the
metrics
examples
to
a
dvd
right
like
that,
can
have
come
afterwards.
It's
an
experimental
feature
and
then,
as
as
long
as
gustavo's
lands
at
about
the
same
time,
it
should
be
okay.
A
I
think
that
these
could
get
merged
independently,
and
I
would
agree
that,
if
anything
you
could
update,
yours
is
to
essentially
just
remove
the
otp
otlp
exporter
package
and
just
anticipating
this
one
to
land
as
long
as
you
or
I
don't
make
a
release,
I
think
that
that's
totally
fine,
you
know,
because
otherwise,
then
there
would
be
any
support
for
metrics,
but
I
think
that
that's
viable
and
then
honestly,
then
gustavo,
even
after
the
release,
like
you're
saying
we
could
work
on
like
the
http
support
in
the
experimental
metrics
package.
A
The
yeah
settles
I
I
think
that
that's
fair
in
my
opinion,
if
other
people
think
differently,
I
think,
if
that's
also
fair.
A
Does
that
sound
good
to
you
anthony
the
the
example
stuff
I
I
would
just
rip
out
as
well.
I'd
start
cutting
deep
because
it's
just
getting
in
the
way
of
progress
at
this
point.
C
Yeah,
I
I
think
that's
the
the
right
plan
as
far
as
the
metrics
http
support,
I
think,
to
the
extent
that
the
http
support
you
know
that,
like
the
the
dealing
with
the
mechanics
of
http
is
already
handled
in
the
trees
exporter
and
really
it's
just
used
protobuf
to
serialize
it
and
send
that
over
http
and
all
of
the
metrics
data
model
changes
are
likely
to
live
in
that
protobuf
and
the
common
transform.
C
It's
probably
less
of
a
concern
implementing
http
metrics
prematurely,
but
to
the
extent
that
we
don't
know,
if
anybody's
actually
using
it
either.
It's
not
a
high
priority.
A
Yeah
gustavo:
what
do
you
feel
about
working
on
the
http
metrics
side?
Is
that
something
you
could
have
your
time
better
served
on
something
else.
E
C
Okay,
yeah,
I
think,
by
the
time
you
get
down
to
whether
we're
shipping
you
know
otlp
data
over
grpc
versus
http.
All
of
the
things
that
are
likely
to
change
in
the
metric
system
have
been
changed.
The
transform
package
is
probably
where,
where
all
of
that
will
happen,.
D
A
A
A
Is
we
have
this
traces
directory
in
a
metrics
directory
and
then
we
have
an
oclp
and
we
have
an
ocfp
trace
and
we're
gonna
have
an
otlp
metrics
directory?
A
Does
that
seem
weird
to
anyone?
Or
is
it
just
me.
A
One
thing
I
think,
there's
two
ways
you
can
go
right:
you
can
try
to
take
the
otlp
stuff
and
move
those
into
a
metrics
in
a
trace
directory.
One
of
the
other
things
I
was
thinking
is
going
the
opposite
direction
and
taking
the
prometheus
directory
and
the
jager
and
the
zipkin
directory
and
moving
them
one
level
up
and
just
getting
rid
of
these
trace
and
metrics
directories
or
just
letting
it
go
and
just
being
a
happy
accident
of
history.
I
guess.
F
So
the
reason
why
the
reason
the
rationale
behind
having
it
that
way
is
so
that
there
can
be
shared
code
amongst
the
grpc
and
http
implementations
between
the
two
between
the
matrix
and
the
traces
which
I
think
initially
won't
be
the
case.
But
if
we
ever
want
to
move
to
that
world,
we'll
have
to
be
we'll
have
to
have
some
way
of
having
a
common
internal
package.
F
A
E
F
Yeah
yeah.
C
We
would
need
to
keep
internal
as
part
of
the
name,
though,
to
ensure
that
others
can't
accidentally
depend
on
what
we
view
as
an
internal
api
while
still
being
able
to
export
identifiers
out
of
it.
I
think
it's
still
going
to
be
weird,
even
even
with
otlp
otlp
trace
and
otp
metrics,
because
they're
separate
modules,
so
we
would
need
an
otlp
internal
module
that
those
would
depend
on
much
like
the
the
internal
metrics
module.
C
I
just
created
as
part
of
separating
out
the
the
metric
stuff
that
the
top
level
api
was
depending
on,
but
I
think
that
that's
probably
still
slightly
less
weird
than
pulling
it
up
into
exporters
and
having
an
internal
exporters,
mod
or
exporter's
internal
module.
That's
really
only
used
by
otlp.
A
So
I
did
notice
in
the
java
exporters.
They
went
with
this
option
where
they
get
rid
of
this,
like
trace
and
metrics
distinct,
distinguishing
directory
in
the
exporters,
which
kind
of
makes
sense
just
for
historical
context
that
the
accident
of
history
that
aaron's
talking
about
is
originally
all
exporters
existed,
either
in
metrics
or
in
traces.
And
then
we
found
out
that,
like
there's
things
like
the
otlp
that
it
does
both,
and
so
we
moved
them
up
here.
A
I'm
kind
of
leading
to
this
idea
that
we
just
get
rid
of
this
trace
directory
metrics
directory
move
the
prometheus
and
jager
and
zipkin
up
one
level,
but
especially
given
this
whole
conversation
of
the
internal
package,
it
seems
really
well
scoped
if
we
can
keep
it
at
this
level,
but
if
other
people
think
differently,
I
I
don't
know
I'd
be
naming's
hard,
and
this
is
this:
is
a
bike
show
our
current
situation?
I
don't
think
is
ideal,
though,
is
what
I'm
saying.
A
Yeah,
that
is
true,
they
are
still
unstable
import
paths,
but
I
hear
you
if
we
don't
do
it
now.
It's
never
gonna
happen.
F
A
Yeah,
I
I
think
that's
a
fair
idea.
The
problem
there,
though,
is
that,
like
the
next
release,
is
going
to
be
the
rc
and
I'd
rather
not
include
deprecated,
like
paths
in
an
rc
prior
to
actually
like
unless
it
was
already
stable,.
F
A
It's
a
good
way
to
phrase
it
I'm
not
opposed
to
that
I'm
easily
swayed
as
you
can
see
yeah
I
like
that
idea.
A
I
will
create
an
issue
for
that,
and
people
can
weigh
in
on
that.
I
think
we're
just
getting
to
the
final
picking
details
on
this
one.
A
Okay,
like
I
said
I
want
to
try
to
cap
this
and
I
think
I'm
at
five
minutes.
It
should
be
fuchsia.
A
Yes,
I
need
anyways,
there's
some
really
good
jokes
that
are
just
about
to
happen,
but
I
want
to
focus
man,
I'm
gonna,
I'm
sorry,
I'm
gonna
butcher
your
name
baktik.
D
On
that
one
yeah,
you
were
close:
okay.
A
Sorry
so
you
had
this
proposal
for
the
go
sdk
logger.
This
is
probably
going
to
be
a
little
bit
of
a
conversation,
so
I
just
wanted
to
give
you
the
floor,
and
maybe
we
can
kind
of
go
over
this.
D
Yeah
hi
hi,
I'm
bartik,
I've
probably
attended
the
segmenting
for
for
a
couple
of
couple
of
times,
but
just
wanted
to
start
with
the
introduction.
D
I
work
I
work
with
aws
actually
team,
so
just
looked
at
the
standardized
logging
issue
and
like
just
came
up
with
it
with
us,
with
some
solutions
that
I
had
in
mind
and
like
just
written
a
one
page
proposal
talk
so
just
wanted
to
discuss
like
a
couple
of
ideas
with
you
guys
and
like
wanted
to
get
it
get
a
feedback
on,
like
the
best
part,
to
move
forward
for
the
standardized
logging
across
the
across
the
sdk,
so
so,
basically
I'll
just
go
over
quickly,
so
that
we
get
time
for
other
things
to
discuss.
D
So
I
I
had
like
two
solutions
in
mind
like
one
is
like
standard
standardized
logging
solution,
which
is
like
we
provide
like
a
default
like
our
own
custom
implementation
as
the
default
as
the
default
implementation,
and
we,
we
probably
also
provide
a
provider
api
to
like
set
custom
logging
solutions
like,
for
example,
if
some
users
wants
to
set
the
custom
logging,
so
they
should
be
able
to
set
it
using
that
logging.set
logger
api.
D
So
the
the
idea,
the
basic
idea
is
like
we
provide
our
blogging,
like
default
logging
like
if
they
want
to
use
that
or
if
they
want
to
enable
like
the
custom
logging
solution.
So
we
basically
provide
like
logger
interface.
So
in
this
case
the
the
difference
would
be
like.
D
So
I
I
I
kind
of
like
this
like
this
idea,
because
this
this
is
like
pretty
much
scalable
and,
for
example,
like
basically
when
we
like
design
logging
for
sdks.
One
thing
that
I
personally
feel
that
we
should
consider
is
basically
like
log
flooding
issues,
so
you
know
we
kind
of
like
basically
develop
interface,
where
we
we
can
wait
limit
the
logging.
D
D
So
this
is
the
solution.
One
and
the
other
solution
I
had
in
mind
is
was
like
basically
use
the
popular
logging
framework
as
like
the
default.
One
like,
for
example,
it's
a
logs
f
loggers
as
the
default
logger
and
then
basically
providing
this
api
using
which
we
can
provide
our
custom
logging
solutions.
So
I
have
added
like
a
small
comparison
between
like
log,
zap
and
log
rest,
so
like
just
just
we'll
we'll
just
quickly
go
over
like
log
is
a
very
basic
logging
framework.
D
It's
a
decent
library.
If
you
want
to
use
as
the
default
implementation,
I
am
personally
more
inclined
towards
app
it's.
It
basically
comes
with
the
testing
package
and
it's
very
structured
and
it's
very
performance
critical.
So,
for
example,
let's
say
if
you
want
to
set
up
logging
based
on
like
like.
If
the
application
is
performance
intensive,
then
you
can.
You
can
fine-tune
the
logging
based
on
that.
So
that's
a
good
thing
also.
It
provides
like
basically
number
of,
for
example,
for
sdk,
like
scenarios.
D
You
know,
for
example,
if
you're
doing
retries
to
send
the
data
to
the
collector,
so
it
we
can
basically
limit
those
loggings
and
helps
us
with
log
flooding
issues
as
well,
and
then
there
is
a
log
logger
as
it
provides
the
seven
logging
levels.
D
It's
I
think
it's
more
popular
for
like
structuring
json
data,
so
I
I
I
personally
don't
think
this
would
be
pretty
much
applicable
or
would
be
useful,
but
we
can
still
look
at
as
a
comparison
to
other
other
logging
solutions
and
and,
as
part
like
loggress,
is
very
compatible
with
log
packet.
So,
if
you're
like,
if
sdk
currently
uses
the
lock,
then
it
would
be
easy
to
move
easy
migration
to
logos
so
yeah
this.
This
was
just
the
solutions
that
I
had
in
mind
like
could
appreciate
any
feedback.
D
I
I
would
personally
would
prefer
solution,
one
as
it's
more
custom,
and
you
know
it's
more
scalable.
We
can,
we
can
add
more
methods
and
interfaces
to
provide
more
logging
functionalities.
F
Have
you
done
any
research
on
current
interface
based
logging
solutions?
What
comes
to
mind
is
the
log
r
log
l-o-g-r
package.
B
F
Yeah,
let's
see
only
good
here.
F
Yeah,
that's
the
one
where
that
is.
You
depend
on
that
as
an
interface,
and
then
you
have
to
fulfill
a
back
end
to
it.
That
way,
you
can,
but
have
you
done
any?
My
general
question
is
the
interface
portion
is
probably
the
one
we
want
to
use
just
because
we're
not
in
the
business
of
defining
which
back-end
people
want
to
use
for
a
number
of
different
reasons,
and
what
back
in
the?
D
F
Us,
but
it
should
be
a
user's
choice
like
the
application,
writer's
choice.
A
That's
that's
actually
kind
of
my
main
question
here
is
that
exact?
We
do
have
a
position
on
that.
A
We
and
it's
exactly
what
aaron
said
that
we
we
don't
tell
you
what
back
end
you
should
be
using,
but
we're
actually
a
little
bit
stronger
in
that
we
tell
you
what
format
should
be
sending
the
data
in
so
the
open
source
specification
is
still
in
the
experimental
form
of
defining
a
log
data
model
and
essentially
like
an
sdk
pipeline,
and
I
definitely
want
to
make
sure
that
whatever
we
come
up
with
here
is
not
going
to
have
long-term
implications
that
are
not
going
to
be
compatible
with
this.
A
This
is
a
I
think
if
you
haven't
taken
a
look
at
this
one
yet
like
this
is
something
I
wanted
to
include
in
that
document.
You
can't
that's
the
other
thing.
There's
no
comments
enabled
on
this
by
the
way.
So,
if
we
do
enable
that
okay
cool
but
yeah,
this
definitely
has
a
little
bit
of
a
an
overview.
But
then
the
data
model
goes
through
some
of
the
logging
packages
that
you
mentioned
as
well,
and
their
compatibility
with
this
data
model.
C
So
I
think
part
of
the
idea
of
the
open,
telemetry
logging
is
that,
instead
of
specifying
the
interface,
we
we
specify
the
data
format
that
goes
to
the
backend
right.
So
a
zap
appender
would
translate
to
the
otlp
log
format
or
a
log
or
as
a
pender
would
translate
to
the
otlp
log
format.
This
kind
of
sits
in
front
of
that
and
says
okay,
but
we
in
our
library
want
to
have
a
consistent
interface
that
we
use
for
blogging.
C
That
may
then
write
to
a
zap
implementation
or
logarithms
implementation,
which
then
may
write
to
an
oclp
offender.
It's
kind
of
a
goldberg
ask
pipeline
that
gets
set
up,
but
I
think
they're
trying
to
address
two
separate
ends
of
the
which
log
system
do.
I
use
question.
F
Yeah,
this
one
seems
a
lot
more
targeted
at
the
the
stk
portion
kind
of
like
an
exporter,
whereas
we
would
probably
be
more
like
we
would
also
want
to
define
the
api
side
of
it.
Where
we
say
like
here
are
the
methods
that
hotel
logging
will
use,
and
if
you
use
this
configuration
api,
you
can
change
where
it
gets
sent
to.
C
C
Yeah
they're
not
even
really
key
value
pairs,
or
they
end
up
being
used
that
way.
But
it's
got
a
very
attic
attribute
that
it
pairs
up
by
taking
two
at
a
time
off
of,
whereas
I
think
we
would
pass
attributes
which
caps
like
key
value.
A
Yeah
another
thing
to
keep
in
mind
with
this
third-party
solution
is
that
this
is
going
to
become
a
dependency
on
anybody
that
takes
a
dependency
on
us.
So
we
want
to
evaluate
that
pretty
critically,
and
you
know,
I
think,
log
that
you're
mentioning
here
is
the
standard
library
which
is
everyone's
going
to
take
dependency
on
that.
A
So
I
think,
if
we
try
to
do
something
along
the
lines
of
here,
like
it'd,
be
my
preference,
even
though
everybody-
probably
everybody
even
on
this
call,
has
defined
their
own
logger
interface
at
some
point
in
their
career
or
multiple.
It
may
be
something
I
think
that,
like
we
could
try
to
explore,
I
think
and
see
what
best
fits
us
versus.
D
A
Yeah
and
and
like
that,
aaron
and
anthony
are
kind
of
pointing
out.
It's
like
this
is,
I
think,
an
interface
that
we're
going
to
be
using
in
the
sdk,
not
necessarily
well,
I
guess
the
the
tricky
wicket
as
ted
young
would
say
is
that,
like
the
contrib,
repo
will
also
probably
want
to
be
using
this,
and
the
instrumentation
packages
will
probably
also
want
to
be
using
this
to
provide
a
uniform
way
of
you
know,
signaling
things
or
locking
things
through
our
sdk.
I.
A
F
C
A
yeah,
but
I
think
that
gets
to
the
work
that
the
aotel
log
working
group
needs
to
do
over
the
next
year
or
so
in
terms
of
defining
that
api.
If
we
can
start
with
something
that
we
have
in
the
sdk
packages
for
use
by
exporters,
perhaps
it
is
something
that
is
exported
so
that
it
can
be
used
to
contrib
as
well,
rather
than
just
an
internal
in
the
sdk,
but
that
is
a
very
simple
logger
style
facade
over
bring
your
own
log
implementation.
C
As
long
as
it
can
satisfy
this
interface,
we
use
that
to
allow
end
users
to
bring
their
own
logging
backend
to
to
the
exporters,
so
the
exporters
can
integrate
with
their
logs
and
then,
if
we
do
end
up
defining
an
hotel
log
api
and
an
implementation
of
an
interface
that
we
want
end
users
to
use.
We
provide
our
own
implementation
of
this
sdk
log
interface
in
terms
of
that
as
well.
So
we
say
you
want.
C
You
want
a
full
hotel
solution,
great
plug
this
in
to
the
sdk
uses,
otlp
backend
for
it,
and
it's
all
hotel
all
the
time.
A
Yeah
cool,
I'm
gonna
have
to
cut
the
conversation
off.
This
is
a
really
good
one.
If
you
could
definitely
allow
comments
on
here.
I'd
love
to
make
some
of
these
comments,
but
I
think
this
is
good
feedback
here.
I
want
to
make
sure
that
we
get
to
eddie
and
anthony
as
well
on
this
topic,
but
if
we
have
any
more
conversation,
I'm
gonna
try
to
put
them
on
the
issue
or
in
the
dock
itself,
but
thanks.
D
A
Raising
the
topic
yeah
thanks
guys
for
the
feedback:
okay,
eddie.
If
you
want
to
jump
in-
and
we
can
talk
a
little
bit
about
the
release
updates.
B
Sure
yeah,
so
I
was
talking
about
this
last
week
with
everyone
who's
here,
but
basically
I'm
trying
to
help
set
up
this
script
to
help
with
like
module
versioning
when
we're
releasing
versions,
for
example
like
1.0.0
or
in
having
being
able
to
have
like
the
ability
to
specify
one
set
of
modules
which
are
versioned
together
with
another
module
set,
that's
versioned
independently,
so
we
might
have
part
of
the
repo
that's
like
has
like
the
the
top
level
intel
module
be
like
1.0,
with
like
metrics
being
like
0.21
or
something
so
I
have,
I
guess,
like
most
of
the
scripts
done
now.
B
I
just
have
like
the
tagging
script,
to
finish
up,
but
basically
so
far
I
wrote
out
like
the
preliminary
workflow.
Basically,
it
will
be
kind
of
similar
to
the
one
that
we
had
before
and
so
now
we
have
like
this
version
by
yaml
file
and
then
all
the
scripts
are
written
in
go
so
hopefully
that'll
be
a
little
easier
to
maintain
in
the
future.
If
anything
comes
up.
B
The
first
one
is
basically
the
version
dot
go
file
currently
is
in
like
the
repo
or
sorry
the
root
directory,
and
it
literally
is
just
like
a
string
saying
like
the
0.20.0,
so
I
saw
that
it's
referenced
a
few
times
by
other
like
say
like
test
scripts
and
some
places
in
like
resource
sdk
resource.
I
think,
but
I'm
thinking
I
might
just
change
that
to
I
might
like
remove
this
this
this
file,
I
guess
and
replace
it
with
the
correct
version
that
is
seems
to
be
like
referenced
by
these
files.
B
So,
for
example,
it
says
like
I'm
trying
to
share
my
screen.
If
you
don't
mind,
sure
should
be
pretty
quick.
B
So
there's
it's
just
called
a
few
times
like
hotel.version,
and
it
seems
like
it's
in
this
case
like
it's
a
test
file
and
it
says
telemetry.sdk.version.
So
I
might
change
that
to
remove
that.
I
don't
know
that
seems
like
a
minor
thing,
but
I
wanted
to
make
sure
that
that's
not
something
that's
like
being
called
upon
by.
A
I
don't
think
so.
This
was
not
much
thought
has
gone
into
this
other
than
we
know
that
we
needed
that
identifier,
and
this
is
how
it
came
out
too.
You've
spent
a
lot
of
time
thinking
about
this,
so
I
think
that
if
you
propose
a
change,
it's
something
that
we
can
review
and
code
and
have
a
little
bit
better
understanding
of
what
you're
thinking
here
is,
so
I'd
probably
recommend
just
doing
that,
and
then
we
can
kind
of
go
from
there.
A
C
What
I
don't
want
to
end
up
doing
is
having
to
go
hunting
to
try
to
find
all
of
the
places
we've
referenced
a
version
or
to
worry
about
someone
adding
a
new
reference
and
not
updating
the
the
script.
That
updates
the
version
right
so
to
the
extent
that
we
have
one
place
where
it
lives
and
only
one
place
and
everything
references
that
that's
valuable.
C
C
Definition
and
the
the
internal,
where
we
define
a
user
agent
that
we
use
for
exporters.
A
C
A
I
think
that
this
is
also
the
other
thing
is
like
the
telemetry
sdk
version.
This
needs
to
be
pretty
yeah.
This
needs
to
be
accessible
to
users
as
well.
I
imagine
most
users
should
be
sending
this
but
yeah.
It's
I'd,
love
to
see
the
change
that
you're
thinking
and
maybe
I
could
understand,
like
the
questions
that
you're
having
if
it's
a
small
change
like
if
it's
going
to
take
500
lines
of
code,
then
yeah.
Let's
talk
a
little
more
about
that,
but
I.
B
Think
right
now
it's
I'm
probably
going
to
keep
the
version
file
and
then,
like
I
guess,
depending
on
what
this
means
like,
if
it's
the
top
level
module
or
if
it's
like
the
sck,
I
can
make
it
try
to
get
that
version
from
the
yaml
file,
which,
like
anthony
said,
should
be
like
the
one
place.
People
need
to
make
changes.
C
Yeah,
the
problem
with
that
is,
that's
often
done
when
you're
building
an
application,
because
you
can
add
build
time,
use,
go
command
line
to
specify
the
value
of
a
constant
and
say
no.
This
constant
version
is
actually
y
or
z,
but
we
don't
get
into
the
applications
build
time
since
we're
a
library
where
we
don't
get
to
decide
how
they
build
their
application
or
what
they
specify
at
build
time.
So
we
have
to
have
a
hard-coded
constant
somewhere
in
a
go
file.
C
That
would
be
folded
in,
I
think,
perhaps
having
a
version.go
at
the
top
level
of
each
module
that
we
have
might
make
sense,
and
just
you
know,
make
it
very
standard.
Templated
and
the
version
tool
can
go,
find
version.go
in
the
top
level
of
every
module
and
update
it
to
whatever
version
that
module
is
being
updated
to.
C
A
I
agree,
I
think
if
that
sounds
like
a
a
positive
step.
We
are
running
out
of
time
on
this
meeting.
I
can
probably
stay
on
for
another
five
minutes,
but
I
just
want
to
like
be
conscientious
of
other
people's
times
that,
on
the
call,
we're
30
seconds
away.
So
if
you
have
to
jump
off,
I
understand
anthony
is
the
only
other
person
with
stuff
on
the.
C
We
can
talk
about
that
asynchronously.
I've
just
been
thinking,
as
I
make
some
changelog
updates
that
as
we
go
forward
having
a
v
1.0
and
a
v
point
21,
we
may
need
to
to
deal
with
how
how
we
represent
those
in
the
change
log
in
some
different
way.
All
I'm.
A
A
Okay,
cool
well,
everyone
thanks
for
joining
and
thanks
for
staying
a
little
bit
over
and
I'll
definitely
see
y'all
and
talk
with
you,
asynchronously
I'll,
look
forward
to
things
and
hopefully
do
some
more
reviewing.
But
until
then
I'll
see
you
all
next
week,
bye.