►
From YouTube: 2021-11-22 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
Yeah
I
know
on
thursday
evening
when
we
had
our
asia
asia-pacific
job.
I
mean
there
was
definitely
confusion
about
which
was
the
right
zoom
meeting
to
be
in.
C
B
Okay,
well,
it's
because
the
we
had
the
zoom
meeting,
both
in
the
meeting
invite
and
in
the
meeting
description.
Yes,.
A
A
The
the
one
downside
of
this
new
there's
two
downsides
to
the
new
setup.
The
first
is:
if
people
have
access
to
google
calendar
but
not
to
the
zoom,
they
can
delete
meetings,
but
they
can't.
I
don't
know
if
they
can
move
them
around,
and
the
second
is
at
least
once
a
year.
We
have
to
refresh
them,
because
the
zoom
links
will
only
last
one
year.
A
A
Apparently,
because
like
they
now
want
to
enfor
what
this
setup,
if
it
works
they're
going
to
use
on
kubernetes,
I
think
as
well
because
kubernetes
what
they
did
is
they
just
created
one
zoom
account
for
every
single
sig,
so
they
just
guaranteed
to
not
overlap.
A
A
A
Okay,
we'll
get
started
now,
and
people
from
the
other
link
will
probably
slowly
filter
in.
So
yes,
and
thank
you
for
adding
that
to
the
agenda,
make
that
bold.
A
So
for
the
sig
check,
carlos
looks
like
you're,
adding
updates
for
the
spec
right
now.
So
it
looks
like
no
updates.
By
first
week
of
december,
there
will
be
a
monthly
release.
Okay,
great
perfect,
any
updates
for
metrics.
E
We're
looking
to
mark
the
sdk
stable
relatively
soon,
so
I
know
that
riley
has
a
short
list.
There's
a
few
pr's
to
take
a
look
at
the
other
thing
is
the
prometheus
exporter
needs
to
get
specified,
that'll
be
after
the
sdk
part
of
the
specifications
mark
stable.
So
if
you're
interested
in
either
of
those
take
a
look
at
the
open
prs.
A
Perfect
thanks
any
updates
for
logs.
I
don't
think
we
have
t
run
this
week,
so
we'll
skip
that.
Php,
slow
and
steady
progress
always
need
more
maintainers
and
distributors.
Yep
java
possible
patch
release
will
be
needed
for
some
metrics
breakages
we're
waiting
on
one
last
piece
of
feedback
before
cutting
the
patch
release,
okay
java
and
just
to
clarify
for
the
java
folks.
I
I'm
assuming
from
the
way
this
is
written.
This
patch
is
only
for
the
non
like
the
metrics
functionality,
which
is
not
ga.
Is
that
accurate.
A
The
actual
changes
in
metrics
yeah
cool
java,
instrumentation
1.9.0
release
delayed
this
week
for
an
android
fix,
fixed
exemplars,
not
being
recorded
by
instrumentation
logging.
Instrumentation
story
is
being
worked
out.
A
bit
clarification
here,
don't
want
instrumentation
to
depend
directly
on
the
sdk,
so
introducing
an
appender
api
and
instrumentation
repo
using
log4j
logback
java,
util
logging,
jboss
logging
and
others
cool
javascript.
Metric
api
has
three
to
do
four
in
progress.
A
C
A
And
for
net
released
1.2.0
beta
2,
which
addressed
several
metrics
sdk
issues.
Another
release
is
planned
in
the
next
couple
of
days
and
the
prometheus
exporters
being
improved
for
go.
We've
added
a
new
maintainer,
hey
congrats,
aaron
claussen
from
lightstep
active
work
is
ongoing
for
metrics
logging
and
bug
fixes
we've
canceled
the
thursday
sig
meeting.
Do
the
u.s
holiday
this
week
yup.
I
expect
that
probably
will
be
the
case
for
most
cigs
c
plus
release.
1.1.0
is
planned
for
today.
There's
a
link
here,
there's
a
pr
for
it
as
well.
A
A
I
assume
released
given
how
this
is
written,
but
it
doesn't
actually
clarify
rust.
Carlos
will
meet
the
sig
tomorrow
to
discuss
their
current
state.
Carlos
any
context
here
like
it's
funny.
We
like
we
haven't,
had
to
check
in
from
rust
in
a
while.
Like
do
you
happen
to
know
where
things
are
before
you
meet
with
them.
F
Not
really
yeah,
okay,
this
is
exactly
the
point.
Yeah
yeah
somebody
at
the
sikh
mentioned
that
they
wanted
to
provide
the
feedback
of
what's
the
current
state
and
so
just
to
be
clear,
I
used
to
think
that
they
wanted
to
have
this
a
typical
tc
review,
but
no.
F
A
Okay,
awesome,
let
us
know
next
week
how
that
goes:
erlang
will
release
another
release:
candidate,
ready
for
1.0
tracing
to
do
docs,
docs
and
more
ducks
alrighty
first
topic
after
the
check-in
is
from
me.
So,
as
people
may
have
noticed
today
we
have
a
new
zoom
and
calendar
setup
that
was
implemented
late
last
week.
A
This
was
done
because
we
only
had
three
or
I
think,
four
in
the
end,
zoom
ids
from
the
cloud
native
computing
foundation-
and
we
had
those,
so
we
could
have
overlapping
meetings
occur
without
being
on
the
same
zoom
call,
however,
that
still
had
issues
where
you
had
meetings
back
to
back.
That
would
just
bleed
into
each
other
and
the
recordings
wouldn't
get
set
up
correctly.
There
were
a
lot
of
challenges
with
it.
It
was
also
expensive
for
the
cncf
to
maintain
that
many
zoom
accounts.
A
So
what
we've
done
is
we've
taken
one
of
our
one
of
those
zoom
accounts
and
we've
gone
and
and
basically
created
meetings
with
it.
The
same
way
that,
like
a
human,
would
create
meetings
using
zoom.
So
each
meeting
now
has
a
unique
link
and
unique
password,
so
we're
no
longer
using
the
same
standard
password
across
the
meetings,
but
the
benefit
of
this
is
that
the
meetings
will
never
conflict
with
each
other
ever
so,
you
won't
have
meetings
bleeding
into
each
other.
You
will
not
have
conflicting
meetings
at
the
same
time.
A
No
one
needs
to
manually
manage
the
calendars
so
that
they
have
to
like
cleverly
arrange
the
links,
so
there
are
as
few
conflicts
as
possible.
So
this
is
good.
One
downside
is,
if
you
need
to
change
or
create
a
new
meeting
series
in
the
calendar,
you'll
need
access
to
the
calendar
and
to
our
zoom
account.
So
please
reach
out
to
me
or
someone
on
the
governance
committee.
For
that
there's
two
ways
we
can
do
this.
We
could
either
share
credentials
for
the
zoom
account
more
a
little
more
broadly.
A
I've
also
gone
and
created
a
google
account
for
open
telemetry
that
is
sort
of
permanently
linked
with
our
zoom
account,
and
so
what
we
might
end
up
doing
is
just
sharing
the
credentials
for
that
to
make
calendar
changes,
because
then
you
don't
have
to
fuss
around
zoom.
It's
all
set
up
already,
but
we'll
get
that
figured
out
as
people
want
to
make
more
changes.
A
So
it's
generally
good.
The
downside
is,
of
course
we
I've
deleted
all
the
embedded
links
from
the
documents
and
from
our
github
pages,
at
least
in
the
places
where
I've
seen
them,
because
the
ids
are
now
unreliable
right,
like
the
only
the
only
way
to
effectively
join
the
meetings
is
going
to
be
by
joining
from
the
calendar
links.
Unfortunately,
and
that's
just
due
to
how
we
can't
predict
how
the
ids
will
be
generated
anytime,
we
make
changes
to
the
meetings.
A
So
that's
the
update
I'll
do
another
scrub
of
github,
because
I
just
realized
I
removed
the
old
links
from
the
community
pages,
but
probably
not
from
the
sig
specific
pages.
So
I'll
take
a
look
at
those
today.
But
that's
that's
the
big
change.
If
you
use
the
calendar
to
join
meetings,
it
should
just
work.
Fine
everything
should
be
fixed
and
I
I
believe
I
went
through.
I
think
john
pointed
out.
A
A
Next
topic
is
a
specification
issue.
How
do
I
handle
coercion
of
non-string
attributes
and
exporters
like
prometheus,
with
which
only
supports
string
attributes
is
zero,
the
same
as
string
encapsulated
at
zero.
How
to
handle
null
undefined
attributes
is
null
undefined.
The
same
as
unset.
G
Yes,
I
put
this
in
here
in
js,
we
had
two
separate
definitions
for
attributes.
We
had
one
for
traces
and
one
for
metrics,
but
now
there's
a
like
a
you
know,
single
definition
that
the
spec
uses
for
all
attributes
for
metrics
and
traces.
G
So
we
were
going
to
use
the
centralized
definition,
but
previously
we
only
allowed
strings
in
metric
attributes.
So
if
we're
going
to
allow
more
data
types,
we
need
to
know
how
these
types
of
things
are
handled
because
for
metrics
in
particular,
it
affects
the
identity
of
the
metric.
E
This
is
also
true
for
resources
in
metrics,
but
yeah,
the
sorry
I'll
jump
in,
because
this
is
near
and
dear
to
my
heart,
we
haven't
finished
the
prometheus
specification.
E
If
you
look
at
what
most
implementations
I'm
aware
of,
do
they
literally
are
two
stringing
integers
and
two
stringing
booleans
to
true
or
false,
and
then
there
are
also
two
stringing
numbers,
which
is
the
one
that's
pretty
contentious
anything
more
sophisticated.
I
believe
the
collector
turns
it
into
either
json
or
just
actually
throws
an
exception
at
that
point,
when
you're
exporting
to
prometheus,
because
it's
kind
of
weird
we
will
specify
this
with
the
prometheus
exporter.
E
I
don't
expect
that
to
land
if
there's
a
chance,
it
lands
in
december,
but
you
should
be
okay
for
the
rest
of
the
spec
until
until
you
need
to
export
to
prometheus.
For
now,
I
would
for
now
I
would
mimic
what
the
collector
does
as
the
most
likely
thing
that
will
be
wasn't
specified,
but
we
still
have
to
kind
of
hash
out
details
the
question
around
null
and
undefined.
The
same
is
onset.
G
Yeah,
that's
kind
of
a
javascript
specific
issue,
because
the
having
null
be
different
than
undefined
and
having
undefined
to
be
different
than
on
set
is
a
sort
of
a
javascript
specific
thing.
So
maybe
that
is
just
a
language
specific
thing,
but
it
was.
I
was
brain
dumping
when
I
typed
that.
D
G
For
otlp
sure,
but
what
do
I
again
I
get?
I
guess
prometheus
is
my
is
my
second,
you
know
do
we.
I
don't
know
if
it's
even
legal
to
have
empty
attribute
values
in
prometheus.
D
Yeah,
I
just
want
to
make
sure
that
people
remember
ted,
promised
me
that
he
will
handle
this
stringification.
I'm
still
blaming
you
ted.
If
you
are
on
call
yeah.
H
I
apologize,
I
thought
I
had
handed
this
off
to
j
macd,
but
he's
obviously
also
super
busy.
So
I'll
keep
bugging
him.
E
One
thing
I
I
want
to
call
out
too,
though,
is,
if
someone's
using
a
null
attribute
in
a
metric
that
might
just
generally
not
be
a
good
thing
for
them
in
almost
any
back
end,
I
can
think
of
so
that's
one
thing
that
that
might
might
deserve
just
some
sort
of
a
hey.
This
isn't
the
best
idea,
we'll
support
it,
because
we
should,
but
just
as
an
fyi,
I
don't,
I
don't
think,
that's
actually
a
great
idea
in
most.
E
D
G
Yeah,
actually,
it
turns
out
that
the
common
definition
of
attribute
says
no
is
not
valid,
so
I
guess
that
answers
that
question.
E
And
if
you
need
the
link
to
how
the
collector
is
converting
attributes
to
strings,
we
can
get
that
for
you,
because
I
I
again
I'd
recommend
aligning
with
what
the
collector's
done
for
now.
D
Okay
and
that's
by
the
way-
that's
very
it's
a
pure
invention
coming
from
me
and
three
grand
so
feel
free
to
define
the
right
thing.
There.
A
Okay
and
daniel
did
you
get
all
the
information
you
needed
yeah,
I
think
so
yeah.
Okay,
great
next
point
is
the
state
of
hotel
and
planning.
Josh
and
ted
are
going
to
be
moving
prs
into
open
plummetry.io
this
week.
Last
call
for
concerns
and
additions
and
there's
a
link.
E
Here,
yeah,
so
real,
quick
in
terms
of
status,
we're
going
to
be
moving
this
into
the
open
telemetry
I
o
page,
which
means
everybody
has
access
to
change
it,
so
everyone
should
have
already
had
access
to
make
changes
they
needed.
I
think
I
accepted
almost
everything
that
people
clicked
in
here,
but
yeah
in
terms
of
owning
sections
and
owning
the
roadmap.
We're
gonna
try
to
keep
this
up
to
date,
every
six
months
or
so
we'll.
F
E
A
look
at
it
and
refresh,
but
you
should
be
able
to
go
in
and
change
the
status
in
that
open,
telemetry,
io
status,
page
anytime,
you
want
ted
and
I
are
working
on
getting
sections
into
there
and
then
the
other
thing
that
will
happen
is
sometime
after
the
holiday
there'll
be
a
higher
level
blog
article
for
users,
because
this
is
way
too
much
detail
for
a
blog
article,
but
it'll
just
be
like
hey
this
data
hotel,
here's,
how
cool
everything
is
and
how
awesome
the
work
has
been
come
join
us.
A
All
right
next
bogdan,
are
you
grateful
for
this?
I
care
to
it's
thanksgiving.
You
shouldn't
okay,
yeah,
I'm
thankful,
I'm
thankful
for
this
project.
A
Okay,
then,
I
think
we're
done
have
a
great
weekend:
everybody
for
sigs
that
are
still
occurring
this
week,
we'll
see
you
there
and
I'm
sure
some
might
may
end
up
canceling,
in
which
case
we'll
see
you
next
week.
If
you
have
a
holiday,
happy
holidays.