►
From YouTube: 2021-10-13 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
So,
yes,
let's
give
myself
to
get
my
camera
going
yeah.
So
as
you
as
most
of
you
probably
know,
we
use
the
zoom
instant
meetings
feature
right
now
for
all
the
sigs,
so
every
zoom
account
has
an
instant
meeting
link.
That's
specific
to
that
account.
However,
we
have
enough
overlapping
sig
calls
that
our
three
or
four
zoom
accounts
are
insufficient,
because
sometimes
we
have
like
four
sigs,
followed
by
three
sigs
and
the
meetings
start
blending
into
each
other.
B
So
it's
not
working.
So
I
talked
to
cncf
and
they
said
we
don't
really
have
a
solution,
because
kubernetes
just
gets
one
account
per
sig,
it's
the
way
they
get
around
it.
But
what
I
did
was
I
integrated
zoom
with
my
personal
google
calendar,
which
allows
me
to
generate
as
if
I
was
a
human
like
generate
custom
meeting
links
for
each
call.
B
The
only
downside
will
be
if
someone
wants
to
edit
a
meeting
and
change
the
zoom
link
they're
going
to
need
to
link
their
calendar
to
one
of
the
zoom
accounts.
So
we
got
to
figure
out
if
that
means
having
a
shared
google
account
that
people
sign
into
or
if
multiple
people
can
link
to
zoom
but
I'll
get
this
sorted
out.
C
C
B
Yes,
I
will
and
let
me
join
the
old
one
anyway.
Sorry
I'll
stop
interrupting.
A
All
right,
thanks,
morgan,
I
see
someone
has
very
conveniently
added
the
agenda
to
to
the
meetings
notes.
D
I
added
a
couple
things:
yeah,
okay,
so
just
first
of
all,
the
journal
d
has
been
integrated
into
the
collector.
This
is
ready
to
merge,
I
believe,
depending
any
last
minute
reviews,
but
I
just
wanted
to
call
that
out.
D
D
There
is
a
proposal
to
make
to
enable
journal
d
log
consumption
remotely
and
that
would
use
general
d
gateway,
which
is
fairly
close
in
terms
of
its
capabilities
to
journal.
Ctl
haven't
done
one
one-to-one
comparison,
but
it
does
have
some
of
the
key
things
like
check
pointing
and
whatnot.
So,
potentially
we
can
solve
that
remote
question
as
well.
There
mostly
just
wanted
to
call.
A
D
Well
it
it
basically
means
that
you
have
to
have
the
journal,
the
gateway
executable
on
the
system
where
the
logs
are
so
you
still
sort
of
have
a
dependency.
It's
just
shifting.
It.
A
D
I
haven't
found
anything
yeah
I
have
you
know
this
isn't
something
we
looked
into
extensively,
but
I
mean
the
convenience
thing
is
that
it's
almost
a
guarantee
that
if
you
have
journal
d
logs
on
your
system,
you
also
have
journal
ctl
yeah
on
that
system.
They
they.
B
A
Yeah,
okay,
I
think
yeah.
I
think
we
should.
We
should
merge
the
the
receiver
itself
and
then
we'll
see
what
the
feedback
is
right.
People
will
need
to
start
using
it
and
then
we'll
see
whether
there
is
actually
need
to
do
something
else,
or
it's
going
to
be
just
always
the
case
like
that.
It's
always
going
to
be
present.
So
there
is
nothing
else
to
do.
D
Great
next
time,
it's
mine
too.
I
wanted
to
just
float
an
idea
and
and
kind
of
give
feedback
on
this.
So
I'd
like
to
see
I'd
like
to
instrument
our
library
with
some
internal
metrics
right
like
how
many
times
we're
opening
files
closing
files.
Just
just
all
these,
you
know
very
basic
things.
D
It
strikes
me
that
there's
a
challenge
here-
that's
maybe
different
than
in
the
collector
itself,
because
we
can't
really
depend
on
collector
packages.
Otherwise
we
risk
introducing
circular
dependencies.
D
D
Basically
just
has
a
very
like
basic
representation
of
the
open,
telemetry
data
model
and
and
then
basically
to
provide
then
initially
a
way
to
emit
those
as
logs,
like
the
same
way
that
the
library
emits
logs
now,
but
those
logs
would
have
a
structure
that
represents
the
hotel
metric
structure
and
then
could
be
converted
back
to
metrics
with
like
a
receiver.
D
If
we
want,
or
or
they
can
just
be
useful
to
look
at
in
logs
later,
though
like
in
the
next
step,
would
be
basically
like
when
we
instantiate
a
log
receiver,
we
could
pass
in
a
channel
and
then
emit
metrics
back
up
the
channel,
and
then
those
can
go
to
ops
report.
D
A
What
if
we
use
the
the
open
flange
go
sdk
the
metrics
sdk,
wouldn't
that
yes,.
D
Yeah,
so
that's:
okay,
that's
the
other.
The
other
gotcha
that
I
was
thinking
of
is
that
I
don't
think
it
would
so
if
we,
if
we
take
that
on
as
a
dependency,
then
we're
basically
doing
that
on
behalf
of
the
collector
itself
as
well,
and
the
collector
has
been,
as
I
understand
it,
pretty
careful
to
not
take
that
on
yet
so
I
was
assuming.
A
It's
actually
working
progress.
No,
that
was
working
progress.
It
currently
uses
open
sensors,
but
there
is
a
branch
which
is
not
enabled,
I
believe
yet,
but
which
uses
the
open,
telemetry
metrics
sdk
to
emit
all
metrics.
So
that's,
that's!
That's
the
plan
right,
so
we
should
be
switching
swapping
out.
The
open
sensors
by
open
telemetry
go
sdk.
If
we
do
that-
and
I
think
it
will
happen,
then
I
think
it's
fine
right
that
the
library
itself-
that's
that's
the
intended
use
right.
That's
that's!
How
it's
supposed
to
work.
A
The
libraries
can
emit
their
own
metrics
and
then
that's
fine,
like
the
logging
library
can
emit
its
own.
The
question-
I
guess,
even
if
we
do
that
is
what
would
be
the
conventions.
How
do
we
name
things
right?
The
names
of
the
metrics
so
that
they
are
consistent
at
the
moment.
I
think
everything
that
the
collector
emits
is
prefixed
by
hotel
daughter
of
their
underscore
something
like
that
and
but
I
think
that's
fine.
A
We
can
do
the
same
because
the
logging
library,
I
think-
or
maybe
it
can
be
configurable
right-
maybe
something
like
that.
Maybe
if
it's
not
exclusively
for
the
open
climate
tree,
then
we
just
make
the
prefix
or
for
for
magic
names
configurable
and
for
the
for
the
dimensions
for
the
attributes.
I
think
we
follow
the
open
telemetry
conventions
anyway,
right
yeah,
I
don't
know,
I
didn't
think
about
it.
Just
just
thinking
out
loud.
D
A
E
But
by
the
way,
in
the
other
pull
requests,
I
was
I
opened
several
weeks
ago
with
metrics
for
persistent
queue.
Bogdan
has
noted
that
he
would
like
to
let's
say,
stabilize
or
like
make
some
conventions
to
metrics
create
metrics,
an
open,
telemetry
collector.
I
was.
E
A
Not
yet,
as
far
as
I
know,
but
that
was
the
intent
we
wanted
to
have
some
sort
of
like
guidelines
about
what
should
be
components
or
or
or
whatever.
The
feature
is,
what
conventions
they
should
follow
when
they
want
to
emit
their
own
metrics
like
we
have
the
that
the
conventions
or
the
obs
report
actually
makes
it
uniform
to
emit
per
component
metrics
like
the
inputs
and
like
number
of
items
processed
and
all
that
stuff.
A
That's
that's
uniform
today,
but
if
you
want
to
limit
something
custom
like
the
like
what
you
said
with
the
persistent
queue
that
is
not
defined,
but
we
want
it
to
have
that
defined.
So
I
think
if
we
do
that,
then
that
also
hopefully
solves
the
logging
libraries
use
case
as
well
right
yeah.
So
it
definitely
is
related.
A
Yeah
anyway,
let's
let
let
me
try
to
find
that
issue.
A
I
think
we
have
let's
record
it,
not
then
I'll
create
one
to
to
discuss
how
we
do
the
the
custom
metrics
and
then
I
think
it
should
work
like.
If
you
want
a
review
on
the
proposal,
we
can
review
that
then,
but
no,
let's
see.
A
A
Okay,
can
we
move
to
the
next
one?
Are
we
yep
we're
thanks?
Okay,
so
the
ga?
What's
left,
that's
a
good
question,
so
I
went
over
the
list
of
the
things
that
we
have
in
the
specs
specification
repo,
particularly
so
there
were
a
couple
of
things
that
were
no
longer
relevant.
I
closed
those.
There
were
a
few
that
there
are
a
few
that
actually
need
to
be
done.
So
I
marked
those
as
help
needed.
There
is
one
I
believe
that
is
assigned
to
me
and
I
will
try
to
make
some
progress
on
it.
A
A
A
Yeah,
some
of
those
are
kind
of
tough
ones
that
there
were
a
few
attempts
to
try
to
address
those.
So
I
don't
know
if
there
is
an
easy
way
to
make
more
progress
like
like
the
one
that
with
how
do
we
distinguish
body
and
heart,
reduce
the
one
that
is
assigned
to
your
channel,
but
anyway,
that's
that's
what
we
have
open
right
this
this
is.
This
is
in
the
spec
and
then
there
is
a
fewer
number
of
open
issues
in
the
collector
itself.
A
I
think
six,
six
opening
issues,
one
of
which
is
the
journal
d,
so
hopefully
that
will
be
merged
and
then
there's
there's
just
anyway.
These
are
probably
easier
to
resolve
a
smaller
number
remaining
yeah.
And
the
third
item
is:
what
do
we
do
with
the
sdk
right?
So
the
prototype
begins
in
progress.
I
don't
know:
do
we
have
anybody
from
the
java
sdk
here
to
tell
anything
about
what
is
happening
there?
Updates
we
don't
write.
A
Yeah
no
looks
like
we
don't
so
yeah.
I
think
I
think
well
yeah
to
ga
right.
We
we
do
need
at
least
one
prototype
right
in
one
of
the
languages
completed
and
feedback
posted
so
that
we
know
this
is
the
right
direction
with
the
sdks,
at
least
so
that
we
can
mark
at
least
the
specs
specification
load,
clock,
specification,
sga
and
the
collector,
I
guess,
will
also
be
ready
by
then
I
don't
know
what
others
think.
C
So
I'm
actually
the
person
who
put
all
the
stair
in
the
click
run
I
apologize,
I
was
actually
not
able
to.
You
know
consistently
attend
the
calls
over
the
last
couple
months.
For
various
reasons,
I
was
just
wondering
what
the
status
is
right.
I
think
the
part
that
I'm
a
little
worried
about
is
that
on
paper
you
know
having
at
least
one
implementation
is
it's.
C
It
does
look
like
there's
some
progress
it
I
I
checked
the
prs
and
and
and
various
things
this
morning
on
the
java,
instrumentation
side
or
open
telemetry
dash
java,
but
it
doesn't
look
like
anybody
from
the
slate
of
people
here
is
directly
involved.
So
it's
kind
of
hard
to
kind
of
make
that
it
looks
like
we
probably
have
to
kind
of
proactively
go,
and
you
know
figure
out
if
somebody's
really
leading
that
over
there.
I
know
that
you
know
jonah
and
the
locks
are
you
guys
were
trying
to
work
on
something
he's?
C
Unfortunately,
not
here
today.
I
can
check
with
him
offline
so
might
not
be
able
to
sort
of.
C
Resolve
this
today
right,
but
it
looks
like
we
have
to
be
a
little
bit
proactive
there,
and
then
we
might
have
to
come
up
on
that
like
decision
to
see
whether
that
was
a
reasonable
requirement
right.
Considering
that
you
know
we
can,
you
know,
get
blocks
now,
yeah
generally,
we
can
get
to
your
files
and
all
of
these
other
places
and
and
we're
waiting
for
a
non-trivial
dependency,
that
we
don't
fully
control.
C
A
Yeah
yeah,
I
think
we
have
a
valid
point.
I
think.
Well.
At
least
we
can
ask
maybe
john
watson
for
an
update
there
if
there
is
anything
there,
but
I
think
you
have
a
very,
very
good
point.
If
no
one
from
this
group
is
involved
with
the
actual
implementation,
it's
it's
hard
to
tell
right
whether
we're
moving
in
the
right
direction
or
not.
By
the
way
there
is
actually
a
python
implementation
as
well.
I
forgot
it's
not
just
java.
There
is
a
python
implementation,
I
believe.
A
But
again
I
did
not
check
myself
what
the
implementation
looks
like
and
that's
probably
yeah,
and
if
nobody
else
from
this
group
looks
at
the
results,
then
yeah,
that's
not
good.
I
agree.
C
So
until
we
meet
again,
let
me
let
me
talk
to
jonah
and
see
where
you
know
if
he
has
like
a
more
direct
kind
of
update
and
we
can
share
that
in
in
the
in
the
slack,
if
necessary,
right,
yeah
and
then
tigran
you
just
mentioned
another
name.
Did
I
hear
that
right,
john
watson,
john
watson,
yeah
john
watson,
is
in
java
maintainer.
A
Okay,
yeah
he's
the
maintainer
who
he
was
here
in
this
meeting.
I
think
last
time
or
the
one
before
that,
and
he
he
was
planning
to
start
working
on
the
loading
sdk
for
java.
But
I
don't
know
where
exactly
we
are
at
the
moment
with
that,
and
then
there
is
the
python
implementation
and
one
of
the
python
approvers
joined
to
the
couple
meetings
ago,
and
they
said
that
there
was
an
implementation.
D
I
wonder
also,
I
know
some
folks
here
have
a
lot
of
experience,
writing
logging
related
code
and
go
maybe
there's
an
opportunity
to
push
that
implementation
forward
as
well,
and
then
maybe
maybe
we
have
a
little
more
control
over
that.
If
we
start
that
up
ourselves,
you
mean
go
sdk
yeah.
A
A
Yeah
I
mean
it
would
be
great
if
one
of
us
was
kind
of
personally
really
interested
in
one
of
the
language,
implementations
and
curated
that
or
maybe
participated
actively
in
the
implementation.
That
would
be
great
kind
of
we're
at
the
moment
somehow
detached
right
from
the
implementation.
I
did
think
with
john
before
he
started
the
implementation.
A
C
Christian
okay,
so
since
I
put
it
there,
I'm
I'm
happy
to
pick
up
the
follow-up
talking
to
those
two
people,
jonah
and
john,
unless
somebody
else
wants
to
absolutely
do
it
and
that's
also
fine,
but
otherwise
I
can
just
do
that
and
report
back.
C
C
C
D
D
Yeah
I
mean
work
hasn't
been
gone
on
it,
but
it's
kind
of
hoping
someone
would
pick
this
one
up,
but
we
you
know
myself
or
someone
on
my
team
perhaps
can
take
this,
but
basically
we
just
follow
the
same
pattern
as
we've
been
doing
for
all
the
other
receivers.
There's
already
a
there's
already
an
operator
in
this
library
in
the
log
collection
library,
for
this
works.
Well,
so
it's
just
a
matter
of
integrating
it
into
a
receiver,
and
I.
D
And
then
two
of
the
other
go
ahead,
so
I
can
just
go
through
if
you
want
two
of
the
two
of
them
are
almost
spec
issues.
Really,
you
know
clarifying
kubernetes
log
attribute
names
and
clarifying
input,
output,
expectations
of
parsers.
I
think
the
kubernetes
one
is
pretty
directly
a
spec
issue.
D
The
input
output
expectations
is,
I
would
say,
maybe
blocked
on
the
on
a
different
spec
issue,
which
is
the
one
that
is
basically
clarifying
the
usage
of
body
and
attributes
because
primarily
the
parsers
are
concerned
with
with
manipulating
those
those
fields.
So
I
think
probably
we
need
to
become.
We
need
to
gain
clarity
on
which
which
of
those
is
going
to
be
the
primary
point
of
manipulation
for
parsers.
D
C
B
E
Yeah,
so
I
think
that
this
was
something
also
mentioned
by
tigran
earlier
during
this
meeting
and
yeah.
It's
interesting
from
for
me,
because
I
think
we
have
no
consensus
on
that.
E
We
we
had
two
attempts
to
clear
clarify
that
one
was
providing
some,
let's
say,
conventions
or
suggestions
when
to
use
body
when
to
use
attributes
without
enforcing
users
to
use
one
or
the
another.
The
second
one
was
about
saying
that
essentially,
attributes
should
hold
key
values
and,
and
body
should
maybe
not,
but
there
was
no
no
consensus
on
either
of
them
and
I'm
wondering
what's
what
what
we
should
do
about
it,
because
this
is
a
recurring
item
essentially.
A
A
A
Have
to
be
exactly
consensus,
but
I
think
there
was
very
different
opinions
about
how
which,
which
way
we
should
go.
So
it's
difficult
to
make
progress
on
that
in
that
case,
so
maybe
once
there's
a
bit
more
evidence,
maybe
new
evidence
about
how
this
should
work.
Maybe
we
can,
after
that,
try
to
figure
it
out.
I
don't
know.
D
I
will
I
will
point
out
on
that
that
issue
here
the
clarifying
input
output,
expectations
of
parsers.
There
is
a
document
attached
to
that
issue
that
basically
tries
to
explain
the
design
decisions
behind
parsers
in
general,
so
it
covers
a
lot
of
different
things,
but
in
part
it
tries
to
explain
the
decisions
behind
this.
D
The
question
of
whether
maybe
the
question
of
body
versus
attributes
is
is
certainly
related,
but
perhaps
it
doesn't
have
to
be
considered
a
blocker
here
for
this
issue.
It
could
be
just
that
if,
when
a
decision
is
made,
then
we
come
back
and
make
any
appropriate
changes
that
are
necessary.
But
really
the
point
is
the
parser
is
going
to
by
default.
Look
at
one
of
those
two
fields
and
put
things
by
default
in
the
same
place
on
or
in
that
field
after
it
parses
them.
But
those
are
the
default.
D
In
any
case,
I
invite
people
to
read
that
doc.
If
you
want
please
feedback,
and
maybe
we
can,
maybe
we
can
close
that
one
out.
C
Yeah
that
one's
been
open
for
a
long
time-
and
I
think
people
have
been
popping
up
being
confused
by
it.
So
I
think
we
need
we
might
just
have
to
walk
up
to
a
point
where
we
have
to
call
it
one
way
or
the
other
and
live
with
the
consequence.
But
I
know
that
I,
for
sure
would
probably
like
to
read
those
things
one
more
time
before
offering
an
opinion.
D
Definitely
I
don't,
I
don't
think
anyone
has
weighed
in
on
on
that
since,
since
that
dock
was
attached
to
the
issue,
so
it'd
be
great.
D
Okay,
I
think
the
other
one
embedding
the
log
collection
operator
configs
directly
into
the
receiver
configs
frankly,
this
is
this-
is
a
code
cleanup
task
which
we
just
haven't
gotten
back
around
to
so,
in
my
opinion,
it
doesn't
need
to
be
a
blocker
for
considering
this.
This
effort
complete.
We
could
move
it
to
as
a
follow-up
task
in
the
next
phase,
but
initially
it
was.
It
was
thought
to
be
pretty
important,
but
I
everything's
working
just
fine
right
now,
as
is
so
I
don't
know,
we
necessarily
need
to
worry
about
it.
D
So
it
wouldn't
actually
change
the
structure
of
the
config.
It
would
just
be
the
way
it
would
change
the
way
that
it's
interpreted,
and
you
know
it's
basically
just
switching
over
to
using
map
structure
instead
of
native
yaml
libraries
right
now,
there's
sort
of
a
shim
in
there
to
convert
instead
of
using
mac
surgery.
C
D
All
right
I'll
move
that
one.
Unless
anyone
lets
me
know
everybody,
you
know
in
the
next
hour,
so
okay
other
than
that
looks
like
I
mean
a
potential
bug
and
syslog
receiver.
D
A
Are
you
talking
about
three
zero?
Nine
five
yep.
A
A
A
A
A
A
None
of
it
is
considered,
stable
and
generally
available,
but
we
we
did
testing
we
tried
with.
I
think
we
saw
some
customers
as
well
seems
like
they
are
good
right.
Whatever
is
missing
there.
They,
it
should
be
just
regular
feature,
editions
bug,
fixes,
whatever
I
think
it's
going
to
be
business
as
usual.
A
E
Yeah
perhaps
like
on
this
tough
ones,
because
this
was
largely
discussion
with
with
yuri
shkuro
and
to
some
extent
with
with
sergey.
Maybe
we
could
organize
some
some
time
with
them
and
just
just
have
a
call
and
discuss
the
synchronously,
but
that
would
make
it
easier
to
to
get
a
consensus
on
on
what
we
should
do,
because
I
I
don't
think
that
they
are
happy
either
that
currently,
the
specification
leaves
like
a
lot
of
ways
to
do
that,
and
this
makes
people
confused.
A
F
Them
is
it
worth
doing
one
in
the
off
week,
or
is
that
going
to
conflict
to
to
accelerate
it
or
just
wait
until
the
two
weeks?
From
now.
A
I
think
yeah
next
week
is
fine,
let's
maybe
ping
them
in
the
issue
it
is.
It
is
so
there
is
the
pr,
but
the
pr
is
closed
right.
There
is
the
the
issue
is
open,
so
I
I
don't
know
if
they,
so
maybe
let's,
where
exactly
did
we
have
the
most
active
discussion?
I
think
it's
on
the
pr
rather
than
on
the
issue.
Maybe
so
wherever
is
that,
let's,
let's
ping
them
try
to
reopen
the
discussion
and
then
we'll
see
whether
what's
the
suitable
time
to
have
a
live
discussion
or
maybe
resolve
it
offline?
A
I
think
it's
so
the
issue
is
still
assigned
to
you,
shamik
right
yep.
Do
you
do
you?
Do
you
feel
like
you
want
to
continue
working
on
that
or
you
prefer
to
give
it
up
to
someone
else.
E
A
E
Has
if
anyone
has
idea
how
to
make
it
close,
and
I
mean
like
not
close
because
of
no
consensus
but
close
with
some
consensus
and
a
better
solution
that
we
have
right
now
then
yeah
like
I
I'm
good
with
anyone
taking
it
over.
But
if
not,
then
I
can
continue
helping
with
that,
and
I
think
that
if
the
next
step
is
to
organize
a
meeting
I
can
help
with.
E
D
Yeah,
I
think,
we're
good.
We
got
a
plan
for
many
of
the
items
and
hopefully,
next
week
we
can
come
back
and
focus
on
on
on
some
more
all.