►
From YouTube: 2021-12-08 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
D
E
B
B
B
Now
the
next
one
exporting
from
hotel
to
data
prepper,
I
think
tigram
was
involved
in
this
one
here
and
basically
I'm
I'm
not
even
sure
what
data
prepper
is.
D
E
F
D
E
The
one
is
the
communi.
I
think
this
is
from
elasticsearch,
so
he's
not
from
elastic.
I
don't
know
who,
in
the.
D
B
All
right
next
one
is
use
the
full
http
client
settings
function
to
create
the
object.
B
Okay
is:
is
this
something
that
a
newcomer
could
work
on.
E
B
Okay,
no,
okay,
it's
fine
all
right!
So
a
desert
glp
support,
sending
data
to
nginx
proxy
traced.
I've
seen
this
one
and
I
replied
yeah.
So
this
is
I'm
taking
care
of
this
one.
Here
all
right
sounds.
B
Right
so
I
guess
the
problem
is
they
have
a
an
engine
x
between
the
trace,
gen
and
apm
server,
and
I
assume
apm
server
listens
to
hlp
and
trace.
Gen
generates
hlp
and
trace.
Generally,
we
use
grpc
by
default,
and
my
my
guess
is
that
nginx
has
not
been
able
to
proxy
jrpc
requests
here.
I
haven't
seen
anything
specific
to
grpc
and
I
remember
seeing
some
nginx
documentation
in
the
past
that
you,
you
need
to
use
an
extension
for
jrpc.
B
So
if
anyone
could
add
a
note
to
the
meeting
minutes
here
with
an
action
item
for
me,
I
would
appreciate
all
right
so
this
one,
we
took
care
of
this
one
and
we
took
care
of
this
one
all
right.
So
we
have
two
more
minutes
and
seven
days
yeah.
So
we
have
a
lot
here
so
seven
days,
so
rpm
package
doesn't
properly
mark
config
files
that
I
so
I
confirmed
that
this
is
not
happening
with
the
core
release,
but
it
it
might
be
happening
with
the
contrib.
E
E
So
also
also
keep
in
mind
that
for
for
contrib,
we
we
have
our
own
release,
targets
and
stuff
yeah
the
core.
We
use
the
builder
yeah.
B
E
Good,
you
know
good
good
good,
not
necessary
first
issue,
but
a
good
issue
to
have
is
we
should
change,
contribute
to
use
also
the
bill
yeah.
E
B
B
B
Okay,
all
right,
so
I
guess
that's
the
end
of
the
triaging.
B
And
let
me
close
those
ones
but
I'll,
create
one
here
very
quickly
and
have
a
country.
B
All
right,
so
I
have
a
few
pull
request:
reviews
in
the
queue.
So
if
anyone
especially
phone
core
would
fancy
reviewing
and
or
merging
them,
but
I
have
a
couple
of
other
ones
for
contrib
and
the
one
that
we've
just
seen
for
releases
so
yeah
for
people
who
are
approvers
maintainers.
E
The
client
info
change
yesterday
were
basically
all
correct,
because
I
saw
a
comment.
B
Yeah,
I
I
I
removed
the
dependency
on
on
otlp,
sorry
on
on
the
gold
jrpc
middleware.
A
B
E
B
Okay,
yep:
that's
fine,
just
note
that
you
know
the
contrib
test.
They
they
they're
supposed
to
fail.
E
B
What
is
that?
Oh,
yes,
we
did.
Okay,
yeah
contribute
has
been
merged
as
well.
So
both
sides
of
the
change
are
now
done.
B
All
right
and
then
three
for
contrib,
I'm
not
opening
them.
You
know,
if
for
people
who
are
fencing
reviewing
those
are
my
options
for
you.
Okay,.
E
Thank
you
jurassic.
The
next
item
is
mine.
I
saw
a
conversation
in
the
document
about
the
link
of
this
meeting
and
I
remember
no,
no,
a
conversa
somebody
was
asking
was
the
link
and
then
he
was
using
the
document
as
a
chat.
So
but
they
remove
that
quick,
quick
update
here,
so
we
change
from
having
a
permanent
link.
E
E
So
so,
if
somebody
modifies
anything
that
they
invite
even
a
adding
one
person
or
something
that
will
change
the
name,
can
we
that.
D
D
E
So
the
the
whole
problem
was
before
we
had
six
links
or
four
links
or
something
like
that
from
ncf.
Now
we
have
accounts,
which
means
with
the
account
that's
how
it
behaves.
It
behaves
differently.
Yeah.
G
Yeah
I
copied
over
the
link
that
we
had
in
the
gosig
notes
to
the
top
of
this,
which
should
link
to
the
calendar.
E
So
yeah,
that's
the
update
on
the
meeting
links.
Sorry
for
that,
but
that
also
improves
our
life
because
we
can
have
meetings
overlapping
without
having
to
quit
the
meeting
and
stuff
as
we
did
before.
So
it's
good.
B
All
right,
I
guess
the
next
one
is
mine
again,
and
it's
just
a
question
should
so
do
we
want
to
have
a
release
this
week?
Yes,
okay,
I'll
start
doing
the
release
for
or
start
the
process
for
contrib,
possibly
this
evening,
but
more
likely
tomorrow
morning.
B
Yeah,
so
that's
what
I
added
here
as
a
question,
so
should
this
one
here
be
the
last
one
the
next
one
will
be
on
on
december
22nd.
B
Isn't
it
like
on
wednesday,
so
when
two
wednesdays
from
now
is
22nd.
E
Correct
and
I'm
I'm
anyway,
you
have
the
other
one
to
skip
that
and
have
the
next
one.
On
january.
B
All
right,
so
that's
it!
You
should
have
all
of
your
prs
tomorrow
by
the
time
you
log
in
for
for
the
release.
A
F
A
Yeah
a
few
weeks
ago
I
discussed
with
anthony-
and
it
was
already
supported
in
otp
http
exporter,
so
that
yeah
I
kept
it.
But
you
don't
think
it's
necessary.
E
A
It's
okay
and
one
more
thing
that
is
not
resolved.
The
conversation
is
that
you
mentioned
why
we
recommend
z
standard
as
a
first
option
and
so
that
I
reply
from
the
reason
that
we
decided
to
add
more
compression.
Is
that
ggb
cpu
intensive
so
that,
although
it's
commonly
used
compression
methods,
so
I
think
we
should
recommend
c
standard
or
snappy.
Instead.
D
B
D
You
can
probably
make
a
recommendation
that
if
you
control
both
the
receiver
and
the
sender
both
ends
right,
then
that
is
the
recommended
high
performance,
compression,
etc,
etc.
But
if
you're
only
configuring
an
exporter,
I
don't
think
that's
a
valid
recommendation
to
make,
because
the
receivers
are
likely
not
configured.
That
way.
B
Yeah
but
that's
part
of
the
http
negotiation
right
I
mean
the
client
can
can
send
accept
headers
or
they
can.
You
can
say
what
it
supports
and
the
server
can
can
then
return
whatever
the
client
supports.
G
You
can
send
an
accept
encoding
for
a
response
saying
I
will
take
snappy
back,
but
if
it's
posting
data,
it's
saying
here,
this
is
encoded
as
snappy
have
fun
with
it
and
the
server
is
going
to
say.
Oh,
I
can't
deal
with
this,
so
you
need
to
send
something
else
which
will
mean
at
least
more
round
trips.
E
So
so
exactly
so,
the
negotiation
happens
in
same
client
request
only
for
for
response.
If
you
want
to
negotiate
the
the
request
as
well,
then,
as
anthony
pointed
you
either
have
to
send
an
extra
message
and
the
the
response
and
try
to
guess
like
sending
first
snappy,
then
z,
standard
and
whatever,
but
it's
got
it.
D
B
Yeah
yeah,
I
was,
I
was
confused,
I
mean
I
thought
it
was
part
of
the
accept,
accept
headers,
but
I
missed
the
fact
that
it
is
on
the
client
side
of
things.
F
G
Implementation,
we
look
at
the
content
type
better
and
say:
oh,
what
did
they
send
us
and
we'll
deal
with
it
as
we
can,
but
for
the
the
client
the
the
server
is
going
to
have
to
support
it?
Otherwise
everything
breaks.
B
Yeah,
I
think
that
the
full
one
is
actually
none.
The
only
contention
point
here
is:
what
do
we
recommend
users
if
they
want
to
add
compression?
I
think
so.
Should
we.
E
I
think
gzip
will
it
has
the
biggest
chances
of
working
for
them.
Even
though
may
not
be
the
most
performant,
but
it
will
work
and
if
you
care
about
performance,
I
think
you
will
know
some
problems
with
gzip
and
you
look
for
others.
So
so,
if
you
are
unknown,
if
you
are
a
beginner
newbie
in
this
area,
I
think
just
recommended
gc,
because
it
has
the
most
chances
of
working.
Is
the
right
call
and
if
you
are
very
advanced-
and
you
know
what
you
are
doing,
you
can
use
the
other.
B
So
perhaps
the
real
recommendation
here
should
be
consult
your
the
server
side
of
things
console
the
documentation
for
the
server
side,
instead
of
just
recommending
something
that
might
or
might
not
be
supported
by
the
server.
B
E
On
the
server
we
should
say
you
should,
but
I
think
we
enable,
by
default
all
of
them,
so
you
don't
have
to
enable
anything
so
yeah.
E
D
D
D
E
D
B
At
most,
we
could
link
to
a
blog
post.
If
anyone
has
one
handy,
we
can
link
to
a
blog
post
about
that,
but
we
should
not
go
deeper.
There
yeah.
E
F
E
I
Yeah
that
that's
me,
we
yeah
we
had
to
spend
some
time
getting
the
cla
signing
by
last
week,
but
we're
just
wondering
if,
if
there
was
any
any
feedback
on
this
on
this
pr.
E
You
are
good
jurassic.
You
should
start
doing
this.
H
Yes,
so
this
is
for
removing
default
components
from
the
core
and
as
per
discussion
in
this
pr,
I've
also
implemented
changes
to
duplicate
the
include
core
flag
and
remove
reference
to
default
components
and
tests,
and
this
is
also
ready
for
review.
E
B
So
what
is
the
the
criteria
for
that
two
reviewers
or
one
reviewer?
One
approver.
E
It's
first
of
all
in
core
is:
if
we
discuss
this
as
we
discussed
this
a
week
ago,
and
we
decided
these
are
the
action
items
and
all
of
them
are
done.
It's
ready
to
merge.
We
already
agree
on
that
correct.
Okay,
if
on
contrib
in
general,
because
that's
where
we
have
the
most
prs
on
contrib,
we
we
said
that
we
should
have
a
code
owner
code
owner
being
people
that
not
necessarily
are
our
approvers
or
whatever,
and
an
approver
if
it
happens
to
be
the
same
person
as
the
same
person.
E
H
All
right,
I
just
have
a
quick
question
about
the
pr
should
I
also
change
the
title
of
that
because
technically,
although
I
have
removed
reference
to
different
components
from
the
core,
the
defaults
that
go
file
is
still
in
the
core
right
now,
because
there's
a
dependency
to
it
from
the
collector
contrib.
G
Would
suggest
updating
the
title
as
well,
because
we
squash
merges
when
we
merge,
vrs
or
squash,
commits
the
pr
title
ends
up
as
the
commit
title
of
the
squash
commit.
F
Next,
one
is
fine,
let's,
let's
finish.
E
So,
on
the
first
one
I
I
I
trust
the
approvals
that
we
have
in
court.
So
it's
that
one
or
or
an
approver,
really
reviewed
and
did
all
the
things.
E
The
the
other
one
is
my
idea,
because
I
see
I
see
this
fact
that
we
we're
gonna
have
and
we
have
a
bunch
of
components
and
I
kind
of
want
to
have
a
sponsor
what
it
means
a
sponsor.
It
means,
for
example,
let's
assume
okay
like
tanzu.
They
have
a
couple
of
prs
and
none
of
the
approvals
maintainers
are
looking
to
that.
Thank
you
for
for
showing
myself
jurassic.
E
None
of
the
maintainers
approvers
are
looking
at
that
pr.
Should
we
kind
of
say
whenever
we
accept
a
component,
one
of
the
approvers
maintainers
have
have
to
approve
and
say:
okay,
I'm
gonna
be
the
sponsor
of
this,
which
means
I'm
gonna,
be
that
second
person
so
based
on
the
rule
that
you
jurassi
pointed
on
contribute.
We
need
code
owner
plus
approver.
E
D
E
B
E
D
B
D
B
E
B
E
But
the
reason
why
I
use
the
word
sponsor
is
more
or
less
that
I,
I
think,
also
think
it
should
be
a
volunteer
thing
from
from
us.
So
so
there
are
two.
Let's
put
this
way.
There
are
two
types
of
components.
There
are
some
vendor
components
which
I
think
we
should
apply
round
robin
unless
there
is
a
there
is
a
volume
in
here
and
there
are
like
a
shared
component.
E
The
shared
components,
I
think
we
should
so
what
I'm
trying
to
do
for
vendors,
because
we
said
we
said
that
we
want
to
allow
vendors
to
have
their
exporters
here.
I
think
we
should
do
round
robin
for
for
for
others.
You
should
volunteer.
E
E
Not
sure
if
the
rule
is
around
robin
or
not
ron
robin,
but
I
think
having
making
the
the
change
of
having
an
approver
for
for
every
for
every
component,
it's
gonna
help
us
a
lot
because
that
means
that
means
we
get
ready
to
merge
faster,
correct.
We
don't
have
to
to
wait.
I
mean
I'm,
not
gonna,
not
review
a
pr,
because
I'm
waiting
for
durasi
or
for
anthony
to
review
it
or
anything
we
know
exactly
who
should
review
it.
B
Okay,
that's
good,
so
I
agree
with
that.
I
guess
one.
One
thing
that
we
might
want
to
start
discussing
is
whether
we
want
to
decentralize
contrib
so
so
that
vendors
can
have
their
their
components
on
their
own
repos,
so
they
can
control
the
life
cycle.
B
The
contrib
right
now
is
the
place
they
we
all
want
to
be
because
of
its
visibility,
but
I
don't
think
I
would
recommend
anyone
to
run
the
contrib
distribution
in
any
situation.
It's
just
too
bloated.
It's
just
too
many
things
and
some
components
are
too
unstable,
and
you
know
I
would
certainly
always
recommend
people
to
build
their
own
distributions
anyway,
and
if
that's,
how
other
people
are
feeling
as
well,
then
we
might
start
encouraging
vendors
to
decentralize
and
provide
some
tooling
around
the
builder
for
people
to
build
their
distributions.
B
E
But
we
already
have
the
tools
to
to
prove
that
also
one
problem
is
we
don't
use
the
tools
in
country?
I
think
we
should.
We
should
remove
all
our
main
files
and
default
components
files,
because
once
we
have
all
of
these
removed
so
so
I
think
the
reason
why
I
asked
to
remove
default
components
was
the
idea
that
everyone
wants
to
be
in
that
file.
E
So
so,
by
removing
this
idea
of
default
components,
nothing
is
default.
It's
just
wherever
they
live.
It's
makes
makes
things
more
more
more
nicer
for
for
releasing.
E
So
so
what
I'm
trying
to
say
is
probably
now
we
should
define
the
official
distributions
from
our
site
that
we
support
and
I
think
we
should
not
support
all
the
components
in
the
world
distribution.
E
I
think
we
right
now
right
now
we
have
a
distribution
which
we
call
hotel,
call
collector
core
or
whatever
we
call
it,
but
that's
more
or
less
open,
telemetry,
oss
or
whatever.
We
call
it
because
it
plays
nice
with
jager
with
zip
king
with
prometheus.
So
it
plays
nice
with
open
source
solutions
and
not
necessary
with
vendor
solutions.
E
B
Yeah
I
mean
for
graffana
I
last
week
I
just
created
a
new
repository
for
our
distributions.
We
don't
have
any
solutions
right
now,
but
you
know
that's
that's
where
that's
what
I
would
I
wanted
to
use
as
a
as
an
example
for
others
to
see
how
it
can
be
done
yeah,
so
we
don't
actually
have
to
have
all
of
those
all
of
those
vendor
specific
releases.
As
part
of
the
releases
repository,
we
can
have
our
own
under
profana's
domains.
We
can
have
our
you
know
our
builders
or
releases.
B
B
Otp
and
with
upx
that's
about
like
five
megabytes
of
in
size.
So
that's
that's
wonderful,
yeah!
Now,
perhaps
another
one
for
you
know
focused
on
logging.
One
focus
on
tracing
one
with
load
balancing,
so
so
we
can
discuss
which
releases
you
want,
but
I
think
the
message
that
what
we
should
agree
now
is
on
the
message
that
we
send
to
vendors.
You
know
so,
should
they
start
considering
having
their
distributions
as
part
of
their
domains?
B
Should
we
not
accept
any
more
vendors
as
part
of
contrib?
As
part
of
that,
do
we.
E
I
cannot,
we
cannot
call
we
not
accept
more
vendors
as
long
as
we
accept
vendors
yeah,
so
so
yeah.
So
the
the
rule,
the
rule,
because
I
want
to
be
even
super
vendor
neutral.
If
we
have
any
vendor
code
right
now,
we
should
accept
any
other
vendor
if
we
want
to.
If
we
want
to
give
up
on
that,
we
should
give
up
on
all
the
vendor
code
that
we
have
right
now,
so
not
saying
I'm,
I'm
I'm
just
trying
to
make
sure
that
we
are
fair
to
everyone.
G
There's
a
big
important
distinction
between
the
distribution
definitions.
You
know
what
what
components
go
into
a
build
of
the
collector
and
the
components
themselves,
and
I
think
it's
important
for
the
components
to
live
in
contrib
and
for
there
to
be
a
centralized
place
for
that,
especially
while
the
collector
core
is
still
relatively
unstable,
as
we
make
breaking
changes
to
core
having
everything
in
contrib
makes
it
feasible
for
us
to
keep
that
up
to
date
and
to
keep
the
ecosystem
whole.
G
There
are
already
a
couple
components
that
have
outside
dependencies
that,
in
turn,
have
dependencies
on
core
that
have
caused
us
problems
when
we've
had
to
update
core
and
those
outside
dependencies
need
to
be
updated
before
we
can
then
update
contrib,
and
I
think
that
would
just
become
even
more
of
a
problem
if
we
started
fragmenting
contrib
yeah.
B
G
So
if
we
are
going
that,
I
think
we've
we've
talked
about
before,
and
I
think
it
would
be
really
nice
if
we
could
build
upon
the
collector
builder
to
build
a
service
that
could
be
deployed
where
you
you
push
a
manifest
and
it
responds
with
okay,
here's
a
compiled
binary
and
if
we
can
host
that
somewhere
put
a
nice
website
in
front
of
it
forget
the
the
name
of
the
there's
a
web
server.
G
That
does
something
similar
to
this
right,
where
you
can
yeah
caddy
you've
got
check
boxes,
for
I
want
these
components
and
in
my
build
and
then
it
gives
you
back
a
build
of
it.
If
we
could
do
that,
that
would,
I
think,
be
wonderful
for
users.
E
Okay,
so
I
think
we
should
as
a
follow-up,
that's
not
definitely
that
it
gives
us
to
the
end
goal,
but
as
a
follow-up,
we
heard
that
we
want
to
remove
the
contrib
distribution
and
switch
it
to
builder.
For
the
moment.
Correct
second,
is
we
want
to
give
more
more
power
to
the
vendors,
at
least
for
the
vendors
to
to
make
more
changes
even
in
contribute?
E
Third,
we.
We
are
not
yet
ready
to
speed
the
country
because
of
not
the
core
not
being
extremely
stable,
even
though
it
got
more
stable
than
before,
but
we
are
still
not
there
yet
for
the
moment,
so
we
we
need
to
reconsider
this,
maybe
in
january
february,
when
when
we
have
a
better,
better
stability
there.
B
E
So
for
front-end,
I
think
jurassic.
One
of
the
first
part
is:
let's
define
a
grpc
or
I
think
grpc
is
good.
Let's
define
the
grpc
service
for
the
builder,
with
the
request
and
response,
because
once
you
have
that
that
can
be
the
with
the
grpc
to
http
stuff,
you
can
build
an
http
endpoint
out
of
that.
If
you
want
and
somebody
can
start
building
the
ui
correct
out
of
this.
G
Yeah,
so
do
we
need?
Do
you
already
see
that
that
feels
a
little
overkill
with
me,
because
we
we
should
post
a
manifest
to
it
and
get
back
either
a
link
or
a
binary
that
it
seems
like
it
should
be
as
simple
as
that.
E
So
so,
if
you
want
to
do
this
at
least
use
open,
whatever
is
the
open.
H
E
Open
api,
or
something
like
that
so
anyway,
I
want
the
contract
to
be
written
in
the
file
versus
in
documentation
and
stuff
like
that,
and
the
thing
is
grpc.
If
you
write
the
grpc
service
anyway,
it
generates
that
open,
open
api
and
and
and
stop.
So
that's
why
I
I
said
to
be
grpc,
because
you
can
generate
open
apis
and
stuff
if
you
want
only
the
open
api.
Okay
sure
write
the
open
api
file
and
install
and
do
that.
C
I
don't
want
to
interrupt
yells
flow
because
I'm
like
remedial
relative
to
everyone.
Where
would
in
this
world
where,
like
things
are,
people
are
building
on
top
of
like
a
contrib
distro?
Where
would
stuff
like
the
like,
there's
certain
processor
internals,
like
the
filter
config?
C
E
So,
first
of
all
is
that
is
that
component
that
you
are
referring
to
or
module?
Let's
call
it
module
because
component,
it
means
something
in
the
column.
So
no,
but
is
that
module
intended
to
be
public
or
not?
I
mean
we
need
to
to
start
making.
These
calls
like.
Is
this
an
internal
module
for
for
some
of
the
processors
that
we
want
to
expose,
as
in
the
in
the
support.
C
I
think
the
idea
is
like,
if
it's
not
so
in
this
case,
like
the
filter
config,
which
is
internal
right
now,
if
people
start
building
their
own,
the
the
all
the
configuration
will
just
sort
of
like
drift,
so
people
have,
like
all
sorts
of
custom
configuration
formats,
so
I
would
think
something
like
this
wants
to
be
public
right.
E
C
Yeah,
I'm
less
worried
about
the
components
and
more
just
the
modules
underlying
the
components
so
when
people
want
to
provide,
say,
custom
components
that
are
similar
to
some
public
ones,
but
maybe
do
something.
You
know
like
specific
to
my
internal
use
case.
I
can
still
ensure
parity
on
stuff
like
configurations
so
that,
like
future
users
can
have,
you
know
different
the
same
interfaces
to
configure
things.
E
E
Yeah
we-
and
this
is
maybe
remember-
we
said
that
we're
gonna
discuss
again
in
february
about
if
we
really
want
to
have
all
the
components
move
away
or
we
we
give
more
more
freedom
to
the
component
owners
in
the
repo.
I
think
this
is
a
good
point
of
keeping
everything
in
the
same
repo,
because
we
can
ensure
more
consistency
across
different,
even
different
custom
components.
E
So,
let's
when,
when
we
make
that
final
call,
I
think
this
should
be
taken
into
consideration.
B
I
think
I
think
the
next
big
step
is
releasing
view
one
for
the
collector
core,
and
that
is
like
the
api
for
other
components
and
that's
the
official
api
right
then,
and
on
top
of
that,
I
think
the
dagger
community
will
build
jager
v2
and
that
could
serve
as
a
like
test
bed
or
guinea
pig
in
seeing
if,
if
the
core
is
enough
or
if
we
rely
or
if
we
have
to
rely
on
contrib
and
the
packages
within
the
contrib,
like
the
extra
modules
and
based
on
that,
we
can
give
guidance
to
other
folks
on
what
to
do.
C
Cool
thanks,
y'all
yeah,
no,
no
rush,
just
something
I've
bumped
into
and
I'm
having
to
what
I'm
ending
up
doing
right
now
is
like
basically
rewriting
a
bunch
of
internal
stuff
to
like
provide
some
more
interfaces
anyway.
E
Is
that
the
case
is
that
the
case?
Let
me
know
I
mean
we
should
we
should
not
force
you
to
do
to
copy
paste
our
code
like
we
try
to
be
friendly,
but
but
again
we
may
say
no,
sometimes,
because
we
didn't,
we
are
not
ready
yet
to
publish
something,
but
if
you
can
help
us
to
polish
the
apis
of
some
components
and
make
them
public.
If,
if
you
you
are
willing
to
do
that,.
C
C
Okay,
yeah
I'll,
let
you
know
I
just
something
I
popped
into.
Thank
you
and
I
think
it's
a
good
discussion.