►
From YouTube: 2021-09-30 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
All
right,
I
guess
we
can
go
ahead
and
get
started.
You
know
tyler
and
aaron
aren't
going
to
be
able
to
make
it
today,
so
it
will
probably
be
a
somewhat
light
group.
If
you
can,
please
put
your
name
on
the
attendees
list
and
add
anything
you
want
to
talk
about
to
the
agenda.
A
A
All
right
so
first
thing
on
the
the
agenda
I
wanted
to
talk
about
was
I
kind
of
relate
to
it.
I
think
the
thing
that
the
josh
I
just
mentioned
here
as
well,
if
you're
going
to
do
a
contrib
release
in
the
near
term,
I
would
like
to
mark
these
modules
as
1.0.
A
So
I
think
we
should
indicate
these
as
1.0
as
a
preparatory
step
to
that.
As
part
of
the
last
release
I
went
through
and
ensured
that
every
every
module
has
a
version.go
alongside
it
that
can
be
updated
by
the
release
tooling,
and
this
way
the
instrumentation
that
uses
that
version
to
create
its
tracer
provider.
A
I
don't
know
where
I'll
find
it
in
there,
but
I
know
I
can
find
it
in
net
http.
When
we
create
a
tracer
provider,
it
will
now
use
the
version.
A
A
A
A
Next,
up
on
the
agenda
is
a
schema,
parsing
pr
that
grin
has
put
up.
This
is
just
a
draft
of
a
library
that
would
be
able
to
parse
the
the
open
telemetry
semantic
conventions,
schema
format.
For
my
version,
migration
information.
A
So
I
think
I
would
just
ask
that
people
take
a
look
at
this
skip
all
the
mods
and
sums
because
it
adds
a
new
package.
It's
fairly
straightforward.
It
just
defines
the
data
structures
right
now,
as
well
as
a
simple
parser
which
is
on
marshall
and
validate,
so
this
doesn't
yet
have
any
of
the
transformation
logic
in
it,
but
this
is
the
the
first
step
to
being
able
to
read
those
schemas
in
and
do
something
with
them.
A
So
if
people
could
give
that
a
look,
that
would
be
appreciated
and
one
subject
that
comes
to
mind
when
thinking
about
how
we're
going
to
start
utilizing
this
is
we
probably
don't
want
to
introduce
this
at
a
1.0
plus
version,
because
we
don't
know
if
we're
going
to
be
happy
with
the
api
as
it
exists
right
now,
so
we
need
to
think
about
how
we'll
be
able
to
make
use
of
that
from
our
stable
modules
or
if
we
can
somehow
gain
experience
with
it
and
comfort
that
it
is
stable
prior
to
integrating
it
with
any
of
our
stable
modules.
A
A
We
there
have
been
a
number
of
schema
changes
and
I
think
some
of
them
that
would
be
good
for
testing
from.
Currently
we
only
have
the
1.4
version
of
the
semantic
inventions
in
the
go.
Repository,
1.5
and
1.6.1
also
exist
in
the
collector,
and
I
think
those
would
be
good
to
generate.
A
1.6.1
is
a
0.1,
because
there
were
some
changes
made
in
in
1.6
that
were
they
just
wouldn't
have
works
they
they,
they
would
have
resulted
in
trying
to
generate
constants
that
started
with
a
number
which
your
identifiers
would
start
with
a
number
which
wouldn't
work
for
many
languages.
So,
but
I
think
that
that
those
were
changed
constants
that
were
changed
from
1.5
to
1.6,
and
so
there
should
be
some
changes
there.
That
would
be
useful
for
testing
the
migration
path.
A
C
C
Where
should
that
code
live
and
how
should
it
run
through
ci
cd
and
what
versions
should
be
given
because
it's
not
part
of
the
sdk
exactly,
but
it
will
be
dependent
on
by
the
sdk,
but
it
might
be
useful
by
the
collector
and
it's
not
a
1.0
the
same
as
an
sdk
is
so
it
seems
like
it
almost
gets
a
new
version
sequence
and-
and
I
I
don't
have
any
more
to
say,
except
that
this
question
might
come
up
for
the
for
the
exponential
histogram-
that
I've
got
a
prototype
of
someone
suggested.
C
A
If
it
doesn't
have
to
be
referenced
by
the
sdk,
contrib
might
be
a
good
place
for
it.
I
would
be
kind
of
wary
of
introducing
a
reference
path
from
the
code.
The
core
go.
C
Modules
to
contrib,
no,
not
like
not
like
that.
I
mean
to
say
that
for
introductory
purposes
or
prototyping,
I
could
put
this
exponential
histogram
aggregator
in
the
contrib
module
and
then
to
wire
that
in
you'd
have
to
you
know,
choose
a
different
constructor
code
path.
That
would
depend
on
contrib
directly
and
I
didn't
come
prepared
to
talk
about
the
overall
architecture
of
the
metrics
sdk.
Today.
I
talked
about
doing
that
last
two
weeks
and
I
still
talk
about
doing
that
in
the
future.
C
There
is
a
an
interface
present
today
that
lets
you
configure,
which
I
have
better
choice,
is
made
for
each
type
of
instrument.
So
there's
a
like
with
history,
there's
like
a
simple
package
for
this
simple
selectors
that
has
with
histogram
aggregator
and
you
can
choose
which
histogram
you
want.
So
what
that
contribute
module
would
until
this
becomes
official,
I
guess
it
would
offer
a
with
exponential
histogram
selector.
C
A
C
So
same
same
kind
of
version
in
question,
different
particular
library.
In
this
case,
the
the
resource
conversion
stuff
is
more
immediately
applicable
in
the
sdk,
whereas
I
don't
expect
to
stabilize
this
exponential
histogram
for
months
at
least
and
and
we're
not
even
sure
it's
going
to
be
a
requirement
for
the
sdk
ever
so
maybe
it
stays
in
control.
A
And
metrics
has
the
advantage
that
it's
not
yet
stable,
so
you
could
still
take
that
dependency
easily.
If
you
wanted
to
even
when
both
both
sides
are
unstable
right,
I
don't
like
dependencies,
I'm
sick
of
gomod,
but
how
do
you
really
feel.
A
Okay,
I
guess
we
can
move
on
to
the
next
item
on
the
agenda.
Steve,
do
you
want
to
talk
about
hotel
resource
attributes
and
what
we
discussed
in
slack.
B
Yeah
sound
okay.
B
I
I've
been
trying
to
use
this
environment
variable
in
kubernetes,
pod
specs
and
what
I.
D
B
Is
that
often
I
have
a
few
different
sources
of
the
resource
attributes
that
I'm
trying
to
splice
together,
like
I
can
collect
some
of
the
attributes
from
downward
api
injection
kubernetes,
some
of
them.
I
know
statically
and
I've
been
experimenting
with
this,
and
the
format
demanded
for
this
variable
is
very
stringent.
You
know
it's.
It's
a
key
equals
value,
comma
key
equals
value.
It
doesn't
tolerate
any
extra
commas.
B
So,
if
you're
trying
to
concatenate
things
through
very
crass
mechanisms,
like
you,
don't
have
a
shell
program
available
to
sniff
things
out,
you
can't
just
blindly
jam
these
things
together.
Like
say,
you
know,
always
append
a
comma
jam
them
together
and
if
there's
any
blanks
so
be
it
and
josh,
I
think
you're
nodding.
I
don't
know
if
this
response,
what
I'm
saying
I'm
so
rousing
sympathy.
B
I
did
look
through
the
specification
and
I
see
that
we
borrow
the
format
from
the
baggage
specification
which
is
flexible
with
some
white
space
in
between
it
tolerates
spaces
and
horizontal
tabs.
It
does
not
tolerate
new
lines.
B
So
that
says
that
it
has,
we
have
to
at
minimum
accept
that
format,
but,
what's
not
clear
to
me
is:
could
we
accept
a
looser
format
than
that?
So
in
other
words,
any
any
baggage
format
compliant
string
would
still
be
acceptable
to
us.
But
could
we
tolerate
missing
entries
between
commas.
A
I
don't
see
the
reason
why
we
couldn't.
I
don't
know
if
that's
just
an
implementation,
detail
of
ours
or
or
what,
but
it
is
as
long
as
it's
a
completely
missing
entry
and
not
a
malformed
entry.
I
I
would
think
we
could
just
ignore
it.
B
B
So
while
I
considered
proposing
a
patch
of
this
for
our
sdk,
I
then
thought
well
that
that
could
be
going
the
wrong
way
around
here,
because
if
a
user
found
that
such
an
environment
variable
works
for
the
program
using
the
go,
sdk
they'd
likely
be
surprised
if
they
then
started
using
some
other
language
sdk
and
it
was
rejected
there.
B
So
you
know
I'm
wondering
if
this
is
something
like
does
this
really
belong
in
a
spec
level
revision
before
we
would
do
anything
about
it?
That
so
happens.
No,
I
only
use
the
go
sdk
today,
but
I
I
could
be
pushed
into
using
something
else.
On
another
day.
C
A
Yeah,
I
think
it's
the
sort
of
thing
where
we
could
probably
do
it
on
our
own,
but
it
would
probably
be
best
if
we
did
it
in
concert
with
the
other
languages.
A
What
I
would
suggest
is
to
raise
the
issue
at
the
spec,
create
a
spec
issue,
proposing
it
discuss
it
at
the
specs
egg
and
if
nobody
wants
to
do
it
but
nobody's
opposed
to
us
doing
it,
we
do
it
on
our
own.
Otherwise
we
get
everybody
else
on
board.
B
Okay,
so,
but
let's
just
say
just
hypothetically,
if
the
spec
were
to
accept
it
and
prescribe
prescribe
this
behavior
on
the
other
stps
that
would
suddenly
render
them
out
of
compliance
right,
I
mean,
unless
they
happen
to
be
tolerant,
they
actually
have
been
serving
and
the
other
ones
yet
to
see
so
it'd
be
like
a
backward.
A
B
Right
right,
but
but
it
would
force
it,
it
would
bring
along
new
test
cases.
That
would
then
show
that
existing
implementations
are
now
out
of
conformance
if
they
did
not
accept
the
more
liberal
form.
A
Which,
I
think
is
fine.
The
the
hotel
versioning
policy
overall
is
supposed
to
be
that
any
given
version,
if
it's
in
conformance
with
the
spec,
is
it
conformance
with
a
particular
version
of
the
spec
as
well.
Okay,
so
a
user
shouldn't
expect
that
you
know
if
version
1.0
of
go
was
in
conformance
with
1.5
of
the
spec.
Let's
say
I
think
it's
1.1516
whatever
it
was
when
we
released.
A
B
Okay,
that
does
help
clarify
it.
I
I
came
at
this
environment
variable
kind
of
late
when
I
first
saw
it
it
made
me
uncomfortable
and
then
what
I
realized
was
that
in
each
of
the
programs
I
was
writing.
I
kept
on
adding
command
line
flags
to
accept
values
for
about
eight
resource
attributes,
and
I
realize
it's
still
losing
gain.
I
could
just
push
it
in
through
the
environment
really
much
more
flexibly
and
not
commit
the
compiled
program
to
demanding
all
these
values.
So
that's
how
I
started
using
it.
B
A
Yeah,
it's
a
bit
of
a
limitation.
I
I
wish
we
had
a
more
general
configuration
format
and
specification
for
the
sdk,
but
I
think
that
that's
something
that
the
ted
young
is
wanting
to
to
get
a
separate
working
group
going
to
try
to
address
in
a
cross-cutting
manner
and
say
you
know,
here's
how
sdks
broadly
should
be
configured,
here's
what
the
configuration
option
should
be
and
if
we're
going
to
define
the
configuration
language,
here's
the
one
that
everybody
will
use.
B
Yeah
yeah
makes
sense.
Okay.
Well,
I
think
that's
that
answers
my
questions.
I'll
look
for
the
free
time
to
write
up
an
issue
and
hope
I
can
justify.
A
To
be
fair,
I
I
think
it
should
be
pretty
self-evident
once
once
people
start
to
think
about
it
right,
it's
yeah
anyone
who's
written,
a
shell
script.
That
is
right.
We've
all
we've
all
done
this
or
or
run
into
the
situation
of
trying
to
comma
to
limit
things
in
languages
that
really
only
have
a
loop
right
and
you
end
up
with
a
trailing
comma
at
the
end
or
something
like
that.
Yeah.
B
I
mean
even
more
limiting
in
kubernetes
pod
spec.
You
have
no
script
at
all.
You
could
basically
just
jam
things
next
to
each
other
and
you
know
take
your
chances
on
whether
the
two
things
contain
intervening
comments
or
not.
A
All
right,
I
will
try
for
it
cool.
So
I
think
the
the
last
item
we
have
on
the
agenda
is
josh's
asking
for
a
0.25
release
of
metrics.
A
C
There
wasn't
much
that
are
ready
for
there
wasn't
much
there,
there's
not
really
a
user
facing
change
here,
but
there's
some
test
cleanups
that
I
have
been
fixing
up
in
the
contrib
repository
I'm
way
more
than
halfway
done.
So
I
would
say
if
you
caught
it,
I
still
don't
know
how
to
do
those
releases
and
I'm
not
a
maintainer.
Also
please,
and
I
will
follow
up
with
a
pr
immediately
on
the
contributor
sure,
will.
A
Do
I
think
I
can
do
that
this
afternoon?
I
don't
see
if
there's
any
reason
not
to.
C
And
then
I
will
continue
promising
to
do
my
homework
and
pitch
you
all.
A
brief
outline
of
the
current
sdk
we've
started,
making
a
note
of
all
the
little
cleanups
and
projects
that
are
left
to
get
us
to
a
1.0
type
of
thing,
and
we
can
also
hold
a
discussion
about
api,
which
is
I
I
don't
want
to
push
people
around
on.
That's
an
open
area
for
us
potential
api
change
in
coming
weeks.
Probably
next
week.
D
C
I
don't
I
wanted
to
have
a
pr
that
I
could
refer
to
sorry
about
that.
I
don't
like
to
clutter
up
the
polls
list.
I
had.
I
have
a
pr
open
in
the
specification
with
a
data
model
thing
for
that,
and
I
I
I
there
are
so
many
bugs
in
that
code
now
that
I
like
it
with
a
day
and
a
half
of
like
trying
to
write
down
the
data.
D
C
A
Okay,
you
mentioned
perhaps
a
couple
of
weeks
for
the
presentation
on
metrics.
I
know
tyler's
going
to
be
out
next
week
as
well.
B
C
Okay,
I
may
just
go
for
next
week
anyway,
and
I'm
gonna
start
sending
some
pr's
to
continue
the
existing
tickets
that
are
already
out
there.
This
sdk
api
we
already
agreed
on
and
stuff
like
that.
C
A
To
catch
up
thanks,
okay,
I
think
that's
everything
on
our
agenda.
Unless
anybody
has
anything
else
they
want
to
talk
about,
I
think
we
can
take
35
minutes
of
our
lives
back.