►
From YouTube: 2021-09-15 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
B
A
There
is
an
upstream
pr
that
needs
to
quick
update
on
that.
I
think
paulo
just
told
me.
A
I
won't
be
able
to
join
the
correct
collector's
seek,
but
you
can
tell
people
that
I
will
pick
up
the
st
that
still
pr
between
now
and
the
next
meeting.
C
Okay
got
it
yeah,
because
we
need
a
yeah
hard
dialogue
for
that
yeah
sure
I
will
mark
it
as
before.
Next
meeting.
A
Yeah-
I'm
sorry
about
about
that.
But
hopefully
you
will
come
soon.
A
C
A
E
E
Yeah
yeah
do
you
know
which
version
of
go
you're
using
nintendo.
C
Oh
yeah,
so
my
current
api
is
followed
by
this.
So
I'm
not
sure
if
someone
can't.
E
But
can
you
try
updating
to
go
117
and
see
if
that
fixes
your
issue?
We
may
need
to
make
clear
somewhere
what
the
the
minimum
requirements
to
build.
This
is.
If
we're
going
to
require
117..
Okay
got
it
yeah
sure
I
will
try
yeah
thanks.
A
Also,
usually
when
yeah,
so
I
think
I
think
we
should
discuss
in
that
issue,
but
I
I
did
not
see
that
problem
so.
E
C
E
So
there's
the
the
the
issue
that
you
had
assigned
to
me
about
how
to
handle
duplicate
semantic
inventions.
I
suppose
this
could
be
a
good
place
to
discuss
that.
I
think
tigran
and
I
have
both
commented
on
the
issue
that
we
should
attempt
to
avoid
it
in
the
spec
and
if
it
becomes
unavoidable
in
the
spec
find
some
way
to
add
an
additional
layer
of
name
spacing.
A
A
D
A
Can
it
be
in
one,
can
we
have
sometimes
code
changes?
Yes,
it's
possible
right,
that's
the
point
yeah.
So
the
question
that
I
have
is,
if
we
decide
to
add
these
new
namespace
and
stuff
in
a
newer
version.
Is
that
an
acceptable
thing,
or
should
we
think
about
this
namespace
right
now?
Well,
we
can
still
do
a
breaking
change.
E
So
the
the
goal
there
would
and
part
of
the
reason
why
we
have
separate
packages
for
separate
versions
is
so
that
we
don't
ever
get
rid
of
the
old
versions
and
they
can
continue
to
be
used.
So
if
we
add
you
know,
one
seven
comes
along
and
we
decide
we
need
to
add
namespaces
there.
Then
we
add
namespaces
at
the
one
seven
package,
but
we
don't
change
one
six,
one
and
one
five,
and
so
anybody
that's
that's
using
this,
continue
to
use
them
without
issue.
A
D
A
E
I
think
we
talked
about
simcon
in
that,
but
I
will
review
that
and
see
if
there's
something
we
need
to
add
to
that,
to
make
clear
that
this
is
a
thing
we
may
do
and
and
should
be
expected.
A
It's
a
possibility
that
we
don't.
We
don't
want
to
close
our
door
to
do.
Okay
and
the
last
question
that
I
have
rely
related
to
semver,
and
then
we
can
close
that
issue.
So
if
we
check
the
versioning
and
it's
clear
we
can
check,
we
can
close
it
otherwise
update
the
versioning,
and
we
are
good
on
that.
The
last
question
about
this
I
have
is:
should
we
ship
separate
modules
for
every
every
every
semantic
convention
version
or
we
ship
a
module
with
old
semantic
convention
versions,.
E
I'm
not
sure
it
makes
a
huge
difference.
They're
they're,
a
collection
of
strings
and
go
will
to
the
extent
that
they're
all
very
similar
or
identical
go
will
intern
them
and
de-duplicate.
A
D
It's
very
likely
that
schema
translation
when
you
do
that
you
do
it
based
on
the
schema
files
content
rather
than
hard
coding
the
references
to
symbols
to
the
for
the
convention.
So
it's
probably
not
the
use
case
where
it
matters.
Okay,
so
then
then,
but
may
you
do
maybe
you
do
some
some
very
specific
conversion,
in
which
case
you're
right
you're
doing
some.
I
don't
know
from
this
version
to
the
other.
You
know
exactly
one
attribute
has
changed.
Maybe
you
do
that
yeah,
that's
supposed
to
so
the
reason.
A
D
E
Yeah,
I
think
in
in
the
near
term,
while
we
don't
have
resource
translation
and
and
merging
able
to
handle
multiple
schema
versions
having
that
information
might
be
important,
but
in
the
long
term
I
think
the
sdks
and
the
collectors
should
handle
a
translation
from
one
schema
to
the
next
and
be
able
to
to
deal
with
multiple
schemas
being
used
in
an
application
transparently
to
the
users
yeah.
We
should
feel
comfortable
about
having
multiple.
A
Yeah,
then,
then,
that's
fine,
that's
fine!
I
was
just
okay
we're
trying
to
to
brainstorm
a
bit
anyway.
We
all
also
decided
that
extracting
something
into
a
separate
package
is
backwards
compatible.
So
we
should
not
be
worried
that
at
one
point
we'll
start
having
a
separate
package
and
extract
the
other
packages
out.
A
D
A
question
regarding
the
change
for
the,
which
adds
the
settings
for
logs
collectors
on
logs
in
the
config
file,
which
is
fine.
I
did
review
that.
I
I
just
do
not
quite
understand.
What's
the
urgency,
why
is
it
a
blocker?
What
what's
the
intent.
A
A
A
A
Does
it
make
sense
why
it's
the
urgency
right
now,
because
I
want
to
yeah
ability
for
the
for
the
config
and
right
now
the
flags
are
part
of
the
configuration
okay,
yeah
and.
E
E
And
I
have
an
issue
that
I
need
to
pick
up
that
I
think
will
follow
on
with
this
for
other
telemetry
configuration
where
there's
some
config.
That
needs
to
be
added
that
we
wanted
to
avoid
adding
new
flags
for
in
the
first
place,
so
that
we'll
we'll
use
a
the
same
mechanism
put
it
in
the
config,
get
it
into
the
the
service
settings.
A
Yeah
so
so
I
think
I
think
it
would
be
good,
maybe
to
write
a
half
pager
of
when
things
should
be
in
config
versus
when
things
are
are
feature
flags
by
feature
flags.
I
think
we
should
add
this
concept
to
the
collector
and
tell
people
that
a
feature
flag
can
be
added
and
removed
once
the
the
feature
is
default,
enabled
or
or
or
or
stuff
to
to
for
people
to
to
know
that
does
it
make
sense
to
everyone
to
have
to
support,
feature
flags
and
have
different
guarantees
for
those
compared
with
configuration
things
yeah.
D
E
C
D
Enabled
or
disabled
by
the
end
user
without
the
collector,
which
is
I
guess,
if
it's
not
in
the
configuration,
then
probably
you
control
it
by
environment
variables
or
something
like
that.
So
you
turn
on
and
off
the
features.
But
typically
again
you
use
those
for
features
which
are
experimental,
which
you
want
to
make
available
to
the
end
users
to
try,
but
there
is
no
guarantees
that
it
will
stay
there.
So
I
think
yes,
that
works
right.
It's
not
in
the
config,
it's
an
environment
variable
and
we
can
come
up
with
some
naming
convention.
A
A
Yeah,
I
think
I
think
we
should
we
should
probably
have
a
document,
a
half
page,
describing
these
scenarios,
where,
where
we
have
this
kind
of
command-line
feature
flags
enabled
by
the
command
line
or
environment
variable
equivalent
for
this,
if
we
want
or
and
or
environment
variables
equivalent
for
this,
but
I
think
we
we,
we
should
document
and
we
should
add
this
concept
and
annotate
every
flash.
That
is
a
feature
flag.
A
So,
for
example,
there
is
this
this
pr
that
tries
to
add
use
hotel
instead
of
oc
for
metrics
library
internally,
for
for
whatever
reason
during
the
transition,
we
want
this
flag.
I
think
this
is
a
feature
flag.
Correct,
like
you
enable
a
feature
disable
the
other
one
whatever,
but
we
should
not
guarantee
that
this
feature
is
a
configuration
that
we
guarantee
stability
for
it.
D
B
They
have
a
concept
of
feature
gates,
so
there's
a
single
dash
dash
feature
gates,
flag,
that's
present
on
all
kubernetes
components
and
there's
a
unified
library,
then
that
everyone
references
to
figure
out
essentially
what
to
do
with
with
the
flag.
And
then
in
your
code
you
can
reference
feature
gates,
just
say:
if
it's
enabled
or
not,
I
don't
think
we
have
the
same
sort
of
horizontal
problem.
A
Yeah,
but
is
that
in
the
feature
gate,
for
example,
if
there
is
a
method,
is
fully
enabled
can
that
method
be
removed
or
or
is
considered
to
always
stay
there
once
you
added
a
feature
gate,
so
it's
it's
removed.
B
Eventually,
the
feature
gates-
progress
from
alpha
beta
to
ga
alpha
is
means
that
it's
disabled
by
default
and
you
have
to
add
the
flag
to
enable
it
beta
means
it's
opt
out,
so
you
then
have
to
disable
it
in
the
feature
gates,
flag
and
ga
means
it's
always
on.
A
A
Okay,
so
I
think
this
is
an
interesting
approach
and
I
think
we
should
adopt
the
same
approach
for
for,
for
things
like
we
use
hotel
instead
of
open
sensors
for
metrics
and
stuff,
like
that,
I
think
we
should
adopt
this
this
new
pattern
for
for
for
our
features
that
we
want
to
enable
and
then
and
then
similar
tigran.
A
We
can
do
the
same
thing
with
the
very
experimental
things
instead
of
protecting
by
build
flags
to
give
users
an
easier
way
to
enable
things
we
put
them
into
the
binary,
but
we
enable
only
if
the
feature
gate
or
whatever
we
call
it.
It's
enabled
will
be
alpha
at
one
point,
we'll
make
them
better.
I
think
this
is
a
great
thing,
and
probably
somebody
should
own
should
own
us
probably
copy
paste
from
from
kubernetes,
mostly
the
documentation
of
how
to
to
do
the
feature
gates
or.
However,
we
call
them.
E
Ahead
anthony,
I
I
think,
to
the
extent
that
they're
a
list
of
strings
that
say
enable
or
disable
this
feature.
It
also
opens
up
the
opportunity
to
put
them
in
the
config,
because
we
could
then
have
a
stable,
config
entry.
That
is
feature
gates,
which
is
a
list
of
items,
and
things
can
come
and
go
from
that
list
of
items
that
that
may
have
effect.
D
A
I
think
we
we
we
have
anthony,
I
think
small,
baby
steps.
Let's
start
with
the
fact
that
we
have.
We
have
this
need
right
now
for
a
couple
of
the
flags
that
we
have
to
be
marked
as
feature
flags
feature
gates,
whatever
we
call
them
and
then
and
then,
if
we
have
the
same
problem
for
for
for
config,
we
extend
that
for
the
config
support
as
well.
Does
it
make
sense.
E
Sure
I'm
just
thinking
that
I
think
long
term,
a
goal
I
would
like
to
see
is
that
the
only
flag
the
binary
has
is:
where
do
I
get
my
configuration,
because
that
enables
as
much
flexibility
as
possible
to
be
put
into
that
configuration
file
so
that
end
users
don't
have
to
go
and
figure
out?
How
do
I
change
how
this
is
invoked?
E
A
D
E
C
D
And
would
work
nicely,
except
for
the
case
when
you
need
to
experiment
with
the
format
of
the
configuration
or
the
structure
which
I
guess
after
the
ga
is
probably
never
so
maybe
that's.
That's
fine.
Let's
have
that
problem
when
we
have
it,
but
I
like
the
proposal
I
like
that,
it's
all
contained
in
the
configuration.
I
agree
with
the
with
the
premise
that
it's
it's
better
to
have.
A
Yeah,
the
only
problem
with
that
is
vendors
like
us,
like
amazon,
will
ship
a
binary
with
the
config,
and
if
people
want
to
enable
a
feature
just
a
feature,
they
will
have
to
modify
that
config
file
copy
paste
and
do
some
things
that
would
that
is
much
easier
to
do
with
feature
flags
with.
If
this
is
a
flag.
E
A
Yeah
so
so,
but
somebody
has
to
champion
this
and
we
need
this
before
we
can.
We
can
stabilize
the
config,
because
I
don't
want
to
put
the
reason
why
I
want
this
is
because
some
of
the
flags,
for
example,
the
the
related
to
metrics,
when
we
complete
the
switch
to
open
telemetry,
they
will
be
actually
obsolete
and
not
important.
For
this.
E
Okay
yeah,
so
it
sounds
like
the
temple
thing
to
do.
Right
now
is
to
have
feature
gates
as
cli
flags,
and
we
can
always
extend
the
configuration
later
to
add
to
them.
If
we
decide
that
that's
a
better
approach
to
take
in
the
long
term.
A
A
Anthony
because
of
this,
would
you
be
able
to
start
writing
some
small
proposal
on
this
that
we
can
agree
on
and
start
making
a
bunch
of
these
flags
that
we
currently
have
part
of
this
feature
gates
thing
sure
yeah
I'll
try
to
put
together
a
one
pager
on
that
yeah,
and
I
hope
I
hope
this
is
a
good
progress,
because
I
was
worried
that
we
will
be
forced
to
add
some
some
properties
to
the
config
that
we
we
are
not
comfortable
to
maintain
forever.
D
A
Yeah
so
after
after
anthony
is
going
to
give
us
the
one
pager
we'll
work
on
this
and
and
and
make
make
it
happen.
A
Yeah
anthony,
so
please
don't
hesitate
to
ask
david.
He
has
experience
from
kubernetes
with
this,
so
pink
him
to
to
help
understand
better
how
how
we
can
do
this
thanks
thanks
everyone,
the
last
topic
that
I
have
unless
somebody
added
another
topic
and
just
keep
checking,
is
it
oh
yeah?
We
have
more
topics.
A
No,
no.
This
is
just
me
adding
the
topics
that
we've
been
discussing.
Okay,
perfect,
the
last
one
that
I
want
to
discuss
is
related
to
the
proto.
A
You
know
everyone
if
you
saw
this
instagram
made
me
okay
anyway,
here
it
is
so
it's
in
the
open,
telemetry
proto,
the
pr
332
we
had
yesterday
a
discussion
during
the
specs
meeting
about
this,
and
the
whole
idea
was
right.
Now
we
have
defined
only
a
request,
object
and
a
response,
object
that
are
very
tied
to
a
rpc
communication
or
over
the
network
communication
between
between
a
client
and
the
server.
A
And
we
do
not
have
a
message
that
that
can
be
used
to
to
store
data
on,
for
example,
on
the
on
the
persistent
storage
or
kafka,
or
something
that
does
not
necessarily
send
back
a
response,
and
the
reason
why
we
need
this
is
to
allow
us
in
the
future
to
have
the
flexibility
to
add
control
fields
or
metadata
fields
specific
to
the
protocol
to
the
grpc
protocol
or
to
the
http
proto
protocol
like,
for
example,
sequence
id.
A
If
we
do
some
kind
of
chunking
or
some
timestamps
that
are
relevant
for
for
whenever
we
send
the
data
and
stuff
like
that
which
are
not
relevant
to
be
stored
in
a
persistent
storage
and
there,
you
just
need
the
just
the
data.
You
don't
need.
Any
control
features
that
we
may
have
between
client
and
server.
A
And
then,
as
a
follow-up,
if
we
agree
on
this,
what
we
will
need
is
to
do
another
pr
that
I
send
you
to
the
collector,
which
is
4050,
which
is
this
one,
which
means
our
definition
of
grpc
client
server,
that
we
have
that
works
with
p.
Data
have
to
work
with
a
request,
object
that
contains
a
p
data,
contains
the
data
part
not
and
and
may
contain
other
fields
in
the
future.
That
will
not
be
part
of
the
p
data
like
very
protocol,
specific
fields.
A
So
as
an
example,
I
think
there
was
a
a
point
with
with
josh
mcdonald
proposes
to
have
some
kind
of
sequence
of
every
message
and
have
some
kind
of
ack
response
to
like
build
another
tcp
on
top
of
the
the
the
grpc
for
for
for
guarantee
delivering
over
multiple
hops
and
stuff
like
that,
and
and
then
that
this
is
something
that
is
very
specific
to
a
protocol.
And
we
should
not
care
about
that.
In
the
p
data
in
the
data
things.
A
Thank
you.
So
I
think
this
is
the
last
thing
that
I
did.
There
is
also
a
pr
about
the
current
status
of
the
pro
of
the
collector,
which
I
would
like
you
people
to
review,
and
I
believe
we
are
getting
extremely
close
to
to
have
more
stables
that
we
want.
So
currently
I
split
different
components,
parts
so
the
otlp
protocol
itself.
I
was
considering
it
stable.
We
we
are
depending
on
stable
protobufs
and
we
are
doing
the
right
thing.
I
mean
in
terms
of
http
and
grpc.
A
I
think
we
are
implementing
the
protocols
right.
The
otlp
logs
is
better
the
functionality
for
the
receivers
I
consider
it
stable.
The
logs
is
better
because
of
the
format
not
being
stable.
The
configuration
I
was
considering
better
until
we
finalized
the
config
part
that
may
change
otlp
protocol.
How
we
define
the
receiver
exporter.
A
A
I
think
I
mean
anyway,
I
think
I
have
to
fix
something.
Then
we
have
batch
processor,
which
I
I
put
it
as
beta
memory
limiter.
I
put
it
as
beta
and
I
think
we
are
officially
having
the
first
rc
of
the
model
we
have
couple
of
issues
identified
since
the
last
one.
We
will
do
the
next
release
on
rc1
and
the
whole
collector
api
is
better.